Hacker News Reader

Comment by goto11 | Hacker News Reader

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 was there in the first place.

Maybe I'm just being immature, though!

Otherwise some good points in the article. I'd say a good sign of maturity is that you understand you job isn't to write code, your job is solving problems for the business.

View on HN

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 :-)

For the juniors on my team, the next question I always ask after the answer "it's best practice" is always "why is it best practice?"

It's fundamentally important to understand why something is best practice, so that you know when it is not the best course of action.

Seniors can make the same mistake - I had one literally senior colleague argue that he's been coding for decades longer than I have (I was only coding for ~15 years at the time) and that I should just do as he says, but would not tell me why, or how that applied to the situation.

Definitely. I even had the previous lead developer at $work love to say that things were best practice without really giving much justification - it's fuelled my quest for 'why?' a great deal :)

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

"less talk, more rock" is how one of my colleagues put it.

The comment section on HN would become much easier to read if that was applied!

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.

Even testing is a nuanced argument. The application I’m working is one of the few exceptions to skipping testing. I have basic tests around the data import and export classes but everything else is manually tested.

The reason? It’s a small, rapidly-built prototype hooking two poorly documented systems together while the company makes daily adjustments to the manual process I’m automating.

Everything is in flux because we have just started working with a new vendor that will significantly improve our logistics. All of the chaos is deliberately considered and discussed weekly. (I’m in all of those discussions.)

It’s really beautiful to see this all come together. Once we’ve figured out how this will work, it’s time to firm up the internals and nail it down with tests.

Even if that day never comes, the application has extensive logging (~75% of the application code is devoted to highly detailed logs) and production errors will quickly be detected, with enough information to manually fix a bad import or export.

Once edge cases do come up, you can bet I’ll write tests to prevent regressions.

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

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 realignment means they eat up any and all bullshit they see at a developer conference or resort to appealing to authority (‘this is how Google does it’). And why wouldn’t they, they are in their eyes almost there, almost like the best.

Ultimately, this is still sincere, just leads to dumb results at times (eh, more like often). It is a form of establishing your own authority by associating yourself with authority, a coopting of something undeserved, but emotionally fulfilling. You feel like 6-7 years is enough, but it just ain’t. In it’s worst form, this is what it is and it’s pretty annoying to deal with.

/end Saturday morning psycho babble

That's my experience.

At the start I followed design patterns religiously. I was proud that I'd use those patterns. I wrote about them. I told employers. They employers were impressed. The code was an over-engineered mess. But it ticked the best practices box.

It still happens now. But this is mainly because management and other developers are enthusiastic about various techniques that have the label "best practice".

I last left a codebase in an international firm where everything was a dependency and everything was injected and everything was orchestrated. Everyone was enthusiastic that they finally had a codebase with dependency injection everywhere. I hope to never see that codebase again.

I call them "Medium Developers" - they have a medium amount of experience, and get a lot of their knowledge and dogma from Medium articles :)

I noticed this as well with myself and others. At 5 years you become an expert in whatever stack you choose. Whatever best practice you've adopted becomes religion. It isn't until year 6 or 7 or 8 when you start realizing you know less than you thought. By 20 years realize you know nothing and you have reached developer enlightment.

Coming to terms with the business side is the first step.

Having your best practises or framework mocked by the next generation of zealots is part of the process. Patterns you know and love become anti-patterns only to return in a distance future in some limited formed with great fanfaire.

Letting go and a realizing your project / patterns will get hijacked by the business side, other developers and often enough pms is freeing.

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.

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

“Best Practice” are usually zoomed out, birds eye view solutions.

It’s hard to argue with “you should use a version control” unless you have a very good reason not to.

However, if you get into the “you should always use single quotes” argument, in my opinion, that’s too shallow to be a “best practice”.

Exactly, also the difference between telescopic vs microscopic work. Code needs to be clear is a telescopic view. Your app needs to run 200fps is more specific, microscopic. A game might need to, a text processor might not. Circumstances dictate circumnavigation.

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.

I just remembered my first thought when I first heard someone say 'best practices'

'There is a Glittering Generality if I ever heard one'

https://en.wikipedia.org/wiki/Glittering_generality

This is such a great question!

Maturity (or seniority) is a form of growth and it has stages. I would call this article Stage 2: Do the approved thing.

It's an important stage. But people who stay in this stage too long become intolerable technical architects who yammer away about best practices and high level company goals, produce technical documents no one reads and plan team building events no one wants to attend.

To me stage 3 involves thinking critically about tradeoffs. Applying best practices in relevant contexts and rejecting them in others is a good example.

I always end up linking this silly blog post. https://medium.com/@webseanhickey/the-evolution-of-a-softwar... It sums up the seniority growth cycle better than I can in words.

"Stage 2" is very comfortable. It can give you a lot of power without the effort of doing research and acquiring experience.

Completely agree. Even further, the biggest problem of this list is that the items can fight each other. Your best testing strategy doesn’t save the company from bankruptcy if the deadline to have something done is next Tuesday. Honestly I kinda saw the first item in some of the authors guidelines. Not everything works for everyone else, that includes #4

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

Either that or the author is a best practices zealot.

My rule is "follow best practices unless you can show there's something better."

Corollary: any expert in a particular area should know better than best practices to deal with a given problem.

It also contradicts the other point about "being a tech zealot." Is memory safety a best practice? Some would certainly say it is. But what if a colleague wants to use C?

I agree, in software you are often designing custom things that need to take a subset of principles from many contradictory high level best practises.

Best practises are negotiable if you can attack them with first principles. This is the basis of critical thinking, which I think is more important than best practises.

Best practises will get you fast social agreement though, whilst critical thinking will upset many people because you challenge their idea's trying to find issues early or better options.

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

I’m sure if the author would expand on that statement, they would have a similar conclusion.

It’s just easier to say “Always follow” as you should always follow best practices until you have a great reason not to.

Infact they got it backwards. It takes confidence won from experience and paid for with crisis to say screw that to "Best Practices"

Reply on news.ycombinator.com