Live data from Hacker News

Signs of an Immature Software Developer

pragmaticsoftwareengineering.com

41–50 of 100 posts

Re: Signs of an Immature Software Developer

#41
post #2

> 5. Happy Path Focused Preach it! I am dealing with this now, having taken over a project from someone who thought this way. Yes it works, but is full of bad error handling, cryptic exceptions, race conditions (particularly TOCTOU bugs), non-atomic database updates, and more. "But it works" they say, which is true. But a simple SQL query shows duplicate or missing data where there shouldn't be and other violations o…

I have also seen the other extreme. Where people are overly paranoid about the app throwing any exception and try to capture everything that could possibly go wrong until the heat death of the universe. Handling every error somehow, often without understanding what is supposed to happen in this case. So you end up with things being in weird states and secondary effects for what would have just thrown a fairly easy to troubleshoot exception otherwise.

Re: Signs of an Immature Software Developer

#42
post #9

> Simply put, best practices are non negotiable This here is a sign of immaturity. Following Best Practices to the letter without knowing why is fine if you're a student or a junior developer, or if your work is not much off the beaten path. But as soon as you're doing anything more complicated than stringing libraries together you have to know what you're doing and why you're doing it. You have to know the tradeoffs…

Even if you are aware of the why, you need something (wisdom, extensive experience, etc..) to be sure when to enter into confrontations whether or not a particular best practice should or should not be used.

Re: Signs of an Immature Software Developer

#43

Somehow missing (6), which is calling a fellow professional or coworker "immature".

Publicly reprimanding past, present and future colleagues in order to boost your own standing by setting goal posts may be a bit of red flag, for my money at least. Writing about specific issues, with examples, to teach a general-rule, ideally in a humble way, rather than setting goal-posts, would be more productive.

Re: Signs of an Immature Software Developer

#44
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…

No,your skepticism is warranted and I'll back you up here. "Best Practice" is a common excuse I hear from juniors to justify cargo cult coding. The example of "testing" being evoked a "best practice" is strained. Testing is not a "best practice", it's a basic step in software design where you have accountability for results. It can be done wrong.

Re: Signs of an Immature Software Developer

#45
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’.

I think we don't know. The term best practices is now so overused that it's lost its meaning and usefulness.

On a similar vein... whatever it is you're doing, it's an anti pattern.

Re: Signs of an Immature Software Developer

#47
post #25
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…

I’ve come across junior colleagues who latch on to some "best practice" that they read/heard about, then preach it to anyone who will listen and aggressively debate it to death, instead of actually getting any work done. The solution is to ignore these "my thing is objectively better than yours in 100% of cases" debates - choose the pattern/design/paradigm/thing with the least compromises and do something productive…

There should be a rule 0: work, don't talk.

Usually when people are focused on working and working together fast, the converge on pragmatic efficient solutions.

Of course 'together' is subtle here ..

Re: Signs of an Immature Software Developer

#48
post #34

> 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 does work quite well if you follow it. Why do you think it doesn’t work in practice?

I’m not OP and do not want to state whether TDD works or not, but in my experience it would increase development work significantly on apps which have complicated state machines as their business logic. It would probably end up being less work overall, when we factor in all the bug fixing work, that would happen after such an app would’ve been released without TDD.

Re: Signs of an Immature Software Developer

#49
post #34

> 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 does work quite well if you follow it. Why do you think it doesn’t work in practice?

There may be a domain where it makes a lot of sense, but I've rarely encountered it. Writing and maintaining test code takes just as much time as any other code. You often encounter problems during the actual implementation part that challenge your preconceptions. So if you write the tests first, then you'll end up rewriting them many times. TDD also encourages you to write junk tests that provide no safety, which will then need to be maintained and fixed at every refactor. But the biggest problem is that others on the teams simply won't do it, and neither will you when a deadline looms near. TDD aspirations don't last very long in production.

The one place where I think it works well is implementing a well defined protocol. If you have exact definitions for inputs and outputs, then writing the tests first can make things a lot easier. But it's rare when you have such a clean problem to solve.

Re: Signs of an Immature Software Developer

#50
post #9

> Simply put, best practices are non negotiable This here is a sign of immaturity. Following Best Practices to the letter without knowing why is fine if you're a student or a junior developer, or if your work is not much off the beaten path. But as soon as you're doing anything more complicated than stringing libraries together you have to know what you're doing and why you're doing it. You have to know the tradeoffs…

I'd say it's more likely sign of Dunning-Krueger.

But I fully agree with the rest of your comment, the more decades I spend programming, the more I realize that the answer to pretty much any question related to SW development should start with "It depends. ..."

Post reply on HN