Continuous Refactoring
Productivity and efficiency are the hottest topics in tech today. Product leaders, through no fault of their own, often translate this into a relentless push for new features. The pressure to ship fast is immense, and I think this is actually a good thing. Great product teams (and great engineers) thrive by shipping frequently. As Paul Graham put it:
Tech companies must keep shipping cool new things or die. Not because customers require it, but because the best employees do. If your best programmers stop being able to ship new things, they'll leave to work somewhere they can.
This pressure can, however, take a toll on even the best engineers. The constant drive to deliver quickly can lead to them feeling pressured to write highly-coupled, hard-to-test code. The problem is, this approach doesn’t scale. Requirement X+1 will always be harder to integrate than Requirement X, and the likelihood of regressions increases exponentially.
Over time, these inefficiencies snowball, creating architectural icebergs—hidden complexities that make future changes slower and riskier. When engineers finally hit a breaking point, they feel the only solution is a full-stop refactor: pausing feature development for 2-3 weeks to “fix everything.”
The problem? Full-stop refactors rarely work. They are difficult to scope, often lead to unforeseen regressions, and almost always take longer than planned. As engineers, we instead need to embrace the Pareto Principle, accepting that 80% is often better and more valuable than 100%. We need to continuously strive for those marginal gains.
The Best Engineers Work Differently
The best engineers I’ve observed don’t attempt to solve everything in one go. Instead, they embrace the messy middle while making small, continuous improvements.
Before writing a single line of new functionality, they take a few minutes to refactor. They move side effects out of a function, rename a confusing variable, extract small helper methods, or add a missing test. These micro-refactors may seem trivial, but over time, they compound.
While doing this, these engineers gain a deeper understanding of the codebase before making changes. By cleaning up small areas of complexity, adding new functionality becomes effortless.
Why Doesn’t Everyone Work This Way?
The problem? Lack of agency.
Engineers often feel like they need to justify every minor improvement. And when small quality-of-life refactors compete with business-driven features, they get deprioritized.
The best engineers don’t ask for permission to clean up the code. They treat refactoring as part of their job, not a separate task. They see it as an investment in future speed, not a distraction from delivery.
They also understand a hard truth: there will always be future requirements, and the pressure to deliver will only increase. By making small, daily investments in better code, they ensure future work doesn’t become exponentially harder.
Balancing Refactoring with Rapid Delivery
The challenge is finding the right balance. Done badly, refactoring slows teams down. Done well, it actually speeds up team delivery over time while reducing regressions.
Here are a few practical ways to refactor without hurting momentum:
- Follow the Scout Rule – Always leave the codebase a little better than you found it. Don’t aim for perfection—just small, incremental improvements.
- Time-box refactoring – If a refactor takes more than 30 minutes before you start feature work, stash it and move on. You probably learned something useful while you were at it.
- Refactor in the direction of the change – Only clean up the parts of the code you’re already working on. Avoid deep, unrelated refactors.
- Leverage AI tools – Cursor and GitHub Copilot can suggest improved abstractions, more idiomatic code, and help generate tests.
Final Thoughts
The best teams don’t stop shipping to refactor, nor do they ship at the cost of maintainability. They do both—by making small, continuous improvements every day.
When refactoring becomes second nature, adding new features becomes easier, safer, and faster.