Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Signs of an Immature Software Developer

pragmaticsoftwareengineering.com

Post reply on HN
Print view View original

61–70 of 100 posts

Re: Signs of an Immature Software Developer

#61

Post by rantwasp »

ratww wrote: 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 think there is more nuance to this. If you know what the best practices are in general, you understand them and have a really good reason to reject one or two of them that’s one thing.

If you reject everything because “you know batter” that’s a totally different story.

Re: Signs of an Immature Software Developer

#63

Post by kar5pt »

ratww wrote: 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…

At my first job I assumed that the seniors at the company didn't know what they were doing since we weren't following certain "best practices". It took me a year or two to realize that there were good reasons why we weren't following those best practices. Now when I want to follow a best practice, I envision a skeptical senior engineer in front of me and think how I would explain to them why I'm doing what I'm doing. If I can't give a good reason, I stick with whatever is simplest to implement.

Re: Signs of an Immature Software Developer

#64

Post by ratww »

why_Mr_Anderson wrote: post #50
ratww wrote: 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. ..."

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

Yep. I was thinking of the same thing when writing other comments. It's very comfortable to "believe" one has the perfect answer to an entire class of problems, but it's never the reality.

Re: Signs of an Immature Software Developer

#65

Post by toastal »

jniedrauer wrote: post #21

> 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."

While not always applicable, I've found probably 80% of the time I feel “I should write a test”, I often a sign that I should leverage the compiler and model the data better in a way that doesn't allow the invalid state I would want to test. If you don't throw out some of the non-critical tests after your code is working, you're likely incurring a lot of tech debt in maintaining all of your tests that aren't really helping anymore.

Re: Signs of an Immature Software Developer

#68

Post by snidane »

goto11 wrote: 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…

"Best practices" are often just "common practices". In other words, this is how we do things here, adapt. Nobody ever investigated how "best" they really are.

It's actually the more senior devs who go beyond and investigate how things could be done better.

I agree that certain standardisation of practices need to exist. I would rather work with someone who calls even imperfect practices as "standard practices" and had an initiative on the side to explore better options vs working with someone who insisted on "best practices" because of their insecurity and shaky authority.

Zealous adherence to "best practices" is actually a good sign of immature developers.

Re: Signs of an Immature Software Developer

#69

Post by VLM »

goto11 wrote: 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.

I'd agree with and extend your remarks, if you can clearly document why you're creating your own best practice, then its OK. Or rephrased in a negative sense, If you can't clearly write and permanently document an explanation, then you probably don't have a good reason.

Re: Signs of an Immature Software Developer

#70

Post by runawaybottle »

ramraj07 wrote: post #53
villasv wrote: post #40

Earlier quoted context omitted.

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.

There’s a world of difference between writing tests for a rest api endpoint vs other types of pesky code. Too big a difference really. Writing a bunch of tests for your utility methods like a DateFormatter is obvious, but if you shackle up other abstract implementations with tests and strict type checking, you can easily make a piece of unalterable code (maybe that’s the point). The question is, what is the value in doing that? Why shackle up all parts of your codebase when only a few parts are critical?

I’ll admit that I also lack (and have lacked) guidance on testing.

Post reply on HN