4 ms·
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 la
by goto11 6y ago
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.
- chrisseaton 6y agoHow 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’.
- bardworx 6y ago“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”.
- prox 6y agoExactly, 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.
- politelemon 6y agoI 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.
- Gibbon1 6y agoI 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 https://en.wikipedia.org/wiki/Glittering_generality
- debrice 6y agoThis is such a great question!
- narag 6y agoEither that or the author is a best practices zealot.
- bardworx 6y agoI’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.
- runawaybottle 6y agoFrom 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
- tarkin2 6y agoThat'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.
- ratww 6y agoThat'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.
- gilbetron 6y agoI call them "Medium Developers" - they have a medium amount of experience, and get a lot of their knowledge and dogma from Medium articles :)
- tiddles 6y agoI’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 :-)
- agumonkey 6y agoThere 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 ..
- mysterydip 6y ago"less talk, more rock" is how one of my colleagues put it.
- ta988 6y agoThe comment section on HN would become much easier to read if that was applied!
- minimaul 6y ago+1 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.
- Netcob 6y agoSeniors 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.
- Wowfunhappy 6y agoIt 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?
- lr4444lr 6y agoNo,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.
- kayodelycaon 6y agoEven 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.
- bregma 6y ago> 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."
- deleted 6y ago[deleted]
- snidane 6y ago"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.
- VLM 6y ago> 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.
- agloeregrets 6y agoCompletely 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
- drewcoo 6y agoMy 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.
- bhntr3 6y agoMaturity (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-software-engineer-db854689243 https://medium.com/@webseanhickey/the-evolution-of-a-softwar... It sums up the seniority growth cycle better than I can in words.
- ratww 6y ago"Stage 2" is very comfortable. It can give you a lot of power without the effort of doing research and acquiring experience.
- justsomeuser 6y agoI 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.
- bluishgreen 6y agoInfact they got it backwards. It takes confidence won from experience and paid for with crisis to say screw that to "Best Practices"