4 ms·
6. Posting click bait titles to your programming blog. Edit: here's a real critique. > Best practices are non-negotiable Have you ever argued about which pr
by hashkb 6y ago
6. Posting click bait titles to your programming blog.
Edit: here's a real critique.
> Best practices are non-negotiable
Have you ever argued about which practice was best? I have, many times. They are endlessly negotiable, and there is no canonical list of best practices.
- addicted 6y agoNon negotiable best practices does not mean it’s not arguable which practices are best. What it means is whatever you or your company decides are best practices as well as agreed upon industry best practices must be followed every time.
- ratww 6y ago> practices must be followed every time This is only good advice if you're solving very simple, very trivial problems, or if you don't have enough experience. (That, or if you redefine best practices to tautologies like "always test" or "always write good code"). For anything more complicated than the most trivial of software, it's important to deeply understand your best practices and if they make sense to each situation or not. Software is hard. There are no silver bullets.
- riffraff 6y agobut why should they? For example, you may have a rule that you need CI to pass to merge a branch to your trunk. But maybe CI is slow and flaky, and a business test fails on a PR where you've only changed the README. Sure, you can say "well, the rule is to only merge with green CI" and restart the failed job, but you can also think "well, I can merge this". Maybe it's ok, maybe not, but I think you should trust your fellow developers with doing the right thing rather than berate them "you didn't follow the rules!" Only a sith deals in absolutes.
- robjan 6y agoSenior developers learn that everything is negotiable
- tonyarkles 6y agoThey jumped out at me too. In software specifically, I’ve seen a lot of Best Practices come and go over the years and they’ve often contradicted the previous ones. Plus there are situations where I can, with good conscience, say “best practices say we should do X here, but because of reasons A, B, and C, I think we should do it this way instead.” The real trick is a) getting your team to agree on what practices to follow, and b) agreeing that if you’re going to deviate from them that there’s an expectation that you’ll need to justify that. “I did it this way because it’s the first thing I thought of” vs “I reasoned my way through this and this is why we should do it this way” are very different situations, even if they result in the same code.