Live data from Hacker News

Signs of an Immature Software Developer

pragmaticsoftwareengineering.com

51–60 of 100 posts

Re: Signs of an Immature Software Developer

#51

> Do Test Driven Development A lot of this is common sense stuff, but it might be better to replace this part with "Write tests." TDD is the kind of thing that sounds great in a blog post, but doesn't actually seem to work in the real world. At the very least, TDD is not a benchmark of a "mature software developer."

What world do you live in that TDD does not work in? I definitely do not do TDD all of the time, but when I do it works absolutely perfect. I'd pay any employee a 20% maturity bonus for applying TDD consistently.

People are all getting mad about the "best practices" bit as if it's not just a fact. Does it hurt that much to admit that maybe you're not always the mature developer you'd want to be? I sure am not, I always get carried away writing cowboy code, maybe writing tests after, maybe not because I'm in a hurry and we can stand a bug or 2, and the CI/CD will catch any syntax errors anyway.

The rules are simple though. You determine the best practices, you apply them, and your code will be more correct, it will be written faster, you will spend less time being confused, your final product will be closer to the specifications, and it will have less bugs.

How could this be contentious? No way there's anyone out there that truly feels they wouldn't push less bugs to production if they always could and would apply TDD.

Re: Signs of an Immature Software Developer

#52
post #6

I take issue with point 4 "Rejecting of Best Practices". The article states "Simply put, best practices are non negotiable.". Problem is, "best practices" is large body of rules-of-thumb which are almost always context dependent and often contradictory. Often they lead to worse code overall when applied outside of the relevant context. So I would reformulate as: Only reject a "best practice" if you understand why it…

How do we know what the ‘best’ practices are? Presumably everyone thinks their own practices are the best, otherwise they wouldn’t be doing them. ‘Accept best practices’ just sounds like ‘do it my way because it’s the best’.

This is such a great question!

Re: Signs of an Immature Software Developer

#53
post #40

> Do Test Driven Development A lot of this is common sense stuff, but it might be better to replace this part with "Write tests." TDD is the kind of thing that sounds great in a blog post, but doesn't actually seem to work in the real world. At the very least, TDD is not a benchmark of a "mature software developer."

It “does actually seem to work” at my workplace.

And so I have noticed teams and orgs which go for eternity without seeing effective examples of TDD in practice. Is there any resource which might help people like that (includes me?) something that shows TDD in real life scenarios maybe.

Re: Signs of an Immature Software Developer

#54
Signs of an Immature preacher. Define a bunch of rules that sound good. Ignore contradictions between them. Write blog posts and books. Live off the proceedings of the cult you built.

TDD is PITA and I do not know any one soul that actually follows it. But it does sound good.

Best Practices are a dozen a dime and if anything they can serve as to identify which kind of books the team lead once read.

I could go on but I'm seriously bored by this type of posts/attitude. I only commend because nowdays they seem to come disguised as "pragmatic".

There are some valid points in there but there are zealot red-flags as well. Funny enough 'no zealots' is one of the points.

Re: Signs of an Immature Software Developer

#55
post #6

I take issue with point 4 "Rejecting of Best Practices". The article states "Simply put, best practices are non negotiable.". Problem is, "best practices" is large body of rules-of-thumb which are almost always context dependent and often contradictory. Often they lead to worse code overall when applied outside of the relevant context. So I would reformulate as: Only reject a "best practice" if you understand why it…

> Only reject a "best practice" if you understand why it was there in the first place.

Best practice is to refer to this as "Chesterton's Fence."

Re: Signs of an Immature Software Developer

#56
post #6

I take issue with point 4 "Rejecting of Best Practices". The article states "Simply put, best practices are non negotiable.". Problem is, "best practices" is large body of rules-of-thumb which are almost always context dependent and often contradictory. Often they lead to worse code overall when applied outside of the relevant context. So I would reformulate as: Only reject a "best practice" if you understand why it…

[deleted]

Re: Signs of an Immature Software Developer

#58
post #6

I take issue with point 4 "Rejecting of Best Practices". The article states "Simply put, best practices are non negotiable.". Problem is, "best practices" is large body of rules-of-thumb which are almost always context dependent and often contradictory. Often they lead to worse code overall when applied outside of the relevant context. So I would reformulate as: Only reject a "best practice" if you understand why it…

From my experience, it is usually the expert beginner developer that takes up religious ‘best practices’ discipline. This is roughly around the time they are about to get over the plateau and hit 6-7 years of experience. The identity begins to attach to things that fit that timeline, as in, ‘I am roughly here and therefore based on how I see myself, I should be aligned to what I perceive my identity to be’. This real…

That's my experience as well.

The problem is not so much the individual rules, but the "black and white thinking": believing that everything in programming (or life) can be distilled to very simple rules, without nuance or prior thinking before applying them.

It's a very comfortable position to be in, but it severely hampers your professional development.

Re: Signs of an Immature Software Developer

#59
post #29

Lots of critical nuance is missing, making it sound like it’s written by a “happy-path” eng manager. If your “mature engineers” are business- and team-focused (read: doing what they are told), disregard innovations in tech and evolution (and evangelism) of best practices, you’re gonna have a boring team that will eventually get disrupted either from outside or inside of your org.

Business-oriented means "we do realize that the money don't magically materialize out of thin air and that anything that keeps customers happy/helps attract more is significantly more important than any code purism nonsense."

Re: Signs of an Immature Software Developer

#60

> Do Test Driven Development A lot of this is common sense stuff, but it might be better to replace this part with "Write tests." TDD is the kind of thing that sounds great in a blog post, but doesn't actually seem to work in the real world. At the very least, TDD is not a benchmark of a "mature software developer."

TDD seems like something that exists only in theory. Every place I’ve worked, from startups to F500s, has talked about TDD but has never implemented it. I’ve been in the industry over a decade, maybe it’s just me.
Post reply on HN