Don't run in place

Don't upgrade a dep unless you can articulate how the new version is better.
Don't switch tools unless you have a good reason. Because you heard the new thing was good, or because you think the current tool is bad is not a good reason. How is the old tool failing? List the ways. Steelman the argument that you should not switch.
Don't re-write anything unless you have a good reason. You not personally having written the old thing isn't a good reason.
Some framework fads are more worthy of adoption than others.
- React.createClass -> classes -> function components -> containers -> HoCs -> render props -> hooks. Rewriting the same code through all of these changes is the full time job of a useless engineer.
- Be judicious, wait a while and see how things work out for other people. Ideally, wait until you see the backlash after the initial hype. If you haven't seen any backlash, you might not have waited long enough to adopt.

Don't externalize your internals

Own your build configuration, co-locate it with your application code.
Don't publish your lint config as a separate package.
Don't share code across repos by publishing and installing packages unless you absolutely must. It's really inconvenient. Copy-paste should be your first solution.
The more you can take all the code relevant to your app and put it in the same place, the better.

All dead code must be removed.
Code for variants of resolved experiments must be removed when the experiment is resolved.
Code that is permanently feature flagged out must be removed.
When in doubt, err on the side of removal. You can always revert your commit and bring it back.
Don't ever let anyone convince you keep dead code in the codebase because "we might need it"!

Fix all console errors and warnings. Production first, but also dev. Every console.log is a bug.
If your test runs output anything other than PASS or FAIL and the test names, make that stop.
You must have zero lint warnings.
You must have no tests that flake fail. If you have some, disable them and assign fixing them as P1 bugs.
Your error log must be high-signal. Go now and ignore non-actionable errors.

If your test automation give you sufficient confidence to ship code without manual testing, stop everything and build test automation.
When you fix a prod bug, write the test that would have caught it.
If your production monitoring can't alert you when something critical breaks, stop everything that build production monitoring.
When something breaks in production and your monitoring didn't alert you, create the monitor that would have alerted you.