A few months ago, I wrote about 13 software engineering laws, which are observations about how software projects behave.

Manager.dev

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.

5 engineering dogmas it's time to retire

1. Don’t reinvent the wheel - find a package

3. 2-4 week sprints are how modern teams work

4. Every code change should be behind a feature flag

5. If a comment is needed, the code is too complex

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

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.

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.