Engineering dogmas exist because they solved a real problem once. Then they became unquestionable gospel that solves yesterday's problems while creating tomorrow's headaches.
Most engineering dogmas exist because they solved a real problem once. Then they became unquestionable gospel, and now they're solving yesterday's problems while creating tomorrow's headaches. Anton Zaides takes aim at five sacred cows that engineering managers keep worshiping even when they're obviously causing pain.
The dependency obsession is the first casualty. Yes, left-pad broke Facebook, but your CTO writing mathematical functions from scratch isn't the answer either. With LLMs, the calculus changes: it's easier to accidentally install garbage, but also easier to implement known solutions yourself. The trick is recognizing when you're pulling in 160k weekly downloads of a package that checks if numbers are even (literally just returns n % 2 === 0). Mandatory code reviews slow you down massively while giving you a false sense of quality. Pylon's approach is better: hire skilled engineers, trust them to merge their own code, and only request reviews when you actually need input or think something is risky. Pair programming beats async reviews anyway.
Sprints aren't agile, they're exhausting. The whole two week cycle of planning, standups, reviews, and retrospectives turns building software into running a treadmill. Shape Up's six week cycles with one or two weeks of unscheduled time afterward actually let people work calmly instead of sprinting constantly. Feature flags give you false security while turning your codebase into spaghetti. It starts innocently (decouple deployment from release) and ends with hundreds of active flags making everything harder to test. And the "self-documenting code" dogma is just as dumb as over-commenting. Sometimes a single line of explanation saves someone hours of confusion two years from now.
The pattern here isn't that these practices are useless. It's that good engineering managers balance dogma with reality and constantly reassess what actually works for their team right now. Don't release on Friday works great unless your deployment process is solid and your monitoring is good. Microservices help with scale unless you're a ten person startup creating distributed monolith hell. The dogma isn't the problem. Treating it as scripture instead of a heuristic is the problem.
Check out the full stdlib collection for more frameworks, templates, and guides to accelerate your technical leadership journey.