Early in my career, a team lead shared a simple rule that has stayed with me ever since. When refactoring code, stop and check your work every two or three minutes. If you go longer than that without checking, you have probably changed too much.
Refactoring often starts with good intentions. You see a piece of code that feels messy and want to improve it. You rename a variable, move a function, adjust a condition. Everything still feels clear, so you keep going. Ten minutes later, the code looks different, tests fail, and it is no longer obvious which change caused the issue. The problem is not refactoring itself. The problem is losing track of cause and effect.
Frequent checks force you to slow down just enough to stay oriented. Each change has a clear purpose, and its result is easy to understand. When something breaks, the search space is small. When something feels wrong, rolling back is simple. You are always working with fresh context instead of trying to reconstruct your thinking from memory. This applies whether you are running tests, refreshing the app, or just rereading the code with fresh eyes.
Long refactoring sessions feel productive, but they often hide problems. Too many lines change at once. Too many ideas mix together. When an issue appears, it is hard to tell which decision caused it. At that point, debugging becomes guesswork. You start scanning instead of reasoning. Confidence drops, and progress slows. Most of the time, the fix is not more effort, but fewer changes at once.
Good refactoring is calm and predictable. It should feel almost dull. Change one thing. Check it. Move on. This rule keeps refactoring safe, even in unfamiliar codebases. It also makes reviews easier, since each change has a clear reason behind it. Over time, this habit builds trust in your own work and reduces the fear of touching existing code.
I have tried breaking this rule many times. It never ends well. Checking your code every few minutes is not about speed. It is about control. It keeps refactoring intentional and prevents small cleanups from turning into risky rewrites. It is a simple rule, but it solves a real problem. That is why I still use it.
