---
title: "5 engineering dogmas it's time to retire"
url: https://daily.dev/posts/5-engineering-dogmas-it-s-time-to-retire-00ncs6nnx
source_url: https://newsletter.manager.dev/p/5-engineering-dogmas-its-time-to
type: article
source: "Manager.dev"
published: 2025-12-16T07:07:14.902Z
updated: 2025-12-16T07:08:47.456Z
tags: ["leadership", "agile", "code-review"]
reading_time: 7
upvotes: 91
comments: 9
language: en
---

> ## Documentation Index
> Fetch the complete documentation index at: https://daily.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# 5 engineering dogmas it's time to retire

**[Manager.dev](https://daily.dev/sources/zaidesanton)** · 7 min read · 91 upvotes · 9 comments

## Summary

Five common software engineering practices deserve reconsideration: relying heavily on third-party packages creates security and maintenance risks, mandatory code reviews slow teams down unnecessarily, 2-4 week sprints drain joy from development, overusing feature flags creates codebase complexity, and avoiding all code comments is an extreme position. Each practice has merit but shouldn't be treated as absolute dogma. Engineering managers should balance these principles with their team's specific context rather than following them blindly.

## Full article

daily.dev links to this article rather than hosting it. Read it at the original source: <https://newsletter.manager.dev/p/5-engineering-dogmas-its-time-to>

## Community discussion

Top comments from developers on daily.dev.

**@idoshamun** · 7 upvotes

> We also moved recently to code reviews on request and it works great, and no sprints as well. Everyone is just working. Almost no processes

**@zygfrydchamczyk** · 2 upvotes

> Getting packages for everything is, in my opinion, a bad idea. First of all, it’s a security problem—a couple of really big packages (ua-parser, for example) were compromised recently, and you don’t have a lot of control over what’s inside if you update them automatically.
>
> In my opinion, you should create your own packages for small things like formatters, validators, etc.; use AI for more complicated, tedious features like parsers, generators, and DOM structuring; and use npm for the super complex parts of the app, like a web player.

**@xidib78169** · 1 upvotes

> At least I think the feature toggle is an elegant solution, but only if it is limited to a simple show/hide. It will not work if mutual toggles depend on each other's functionality. So any toggles that are not needed after the release is complete should be removed as soon as possible.

**@a\_meb\_a** · 0 upvotes

> great

## Similar posts on daily.dev

- [The Engineering of the Possible: Beyond the “Best Practices” Dogma](https://daily.dev/posts/the-engineering-of-the-possible-beyond-the-best-practices-dogma-jbljzq9xc) · Codemotion · 5 upvotes · 0 comments
- [Mistakes I see engineers making in their code reviews](https://daily.dev/posts/mistakes-i-see-engineers-making-in-their-code-reviews-uvlezwfro) · Lobsters · 2 upvotes · 0 comments

---

Tags: [#leadership](https://daily.dev/tags/leadership), [#agile](https://daily.dev/tags/agile), [#code-review](https://daily.dev/tags/code-review)

[View this post on daily.dev](https://daily.dev/posts/5-engineering-dogmas-it-s-time-to-retire-00ncs6nnx)
