Engineering dogmas it's time to retire

5 engineering dogmas it's time to retire A few months ago, I wrote about 13 software engineering laws , which are observations about how software projects behave. Source yeah… Source Source Today, I’ll cover 5 practices that are considered ‘common wisdom’, and why I think worth reconsidering them. Don’t reinvent the wheel - find a package Every PR must be reviewed 2-4 week sprints are how modern teams work Every code change should be behind a feature flag/gate If a comment is needed, the code is too complex 1. Don’t reinvent the wheel - find a package Why waste time writing code that someone already wrote before you? The CTO of a startup I worked at hated dependencies. We worked with some 3D calculations (software for drones), and he was writing tens of mathematical functions himself. He insisted that even though it’s slower, he at least understands every part and can fix any bug that will pop up, and wouldn’t depend on anyone else for critical parts of our software. I used to make fun of that paranoia, and he sent me to read some crazy stories: The developer of left-pad took it down from NPM , breaking the builds of Facebook, Spotify, Netflix, and many more. It’s basically an 11-line for loop that adds spaces to a string. The is-even npm package has 160k weekly downloads(!). The author published it back when he was learning to code. Here’s what it does: You are also much more vulnerable to security incidents (and need to spend a significant amount of time chasing updates). In most smaller companies, there is no vetting process for packages (unlike for vendors) - every engineer does as they please. With LLMs, it’s easier to both get into this mess and get out of it: it’s much easier to install an unneeded dependency by mistake, but it’s also quicker to implement ‘known’ solutions from scratch. It’s a tricky balance. Another ‘common wisdom’ among software engineers is that project management software sucks. It’s a necessary evil you just have to deal with. I also thought this was just part of my job - spending hours chasing engineers to ‘keep the tickets updated’, so I could understand what’s going on and make better decisions. Switching to another tool felt like a huge project that was just not worth it. Linear took that to heart, and made switching super simple with a 2-way sync, keeping your legacy tool updated. I haven’t met an engineer who tried Linear and didn’t like it. Teams that switch to Linear see 2x more reported issues - engineers actually want to use the tool. More visibility => fewer meetings => happer engineers. Thanks Linear for supporting today’s article! 2. Every code change must be reviewed In every company I worked for in the last 15 years, we had mandatory code reviews (at least one, usually two reviewers per PR). A couple of months ago I wrote a deeper dive about the price of mandatory code...

Preview: ~500 words