Hacker News Reader

Comment by ratww | Hacker News Reader

> 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 and benefits. This means discussing and yes, negotiating what are considered "best practices", and sometimes rejecting them if they're getting in the way of having a good product.

View on HN

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.

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.

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.

The way I would state it is that you need to understand the tradeoffs of given best practices and whether those tradeoffs justify implementing those best practices on your project. It also gets into what best practices should be prioritized over others and on what timeline.

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.

Reply on news.ycombinator.com