The correct first phase is observation, not change. For the first 30 days: read the code, trace execution paths for the most critical operations, run the tests (if they exist), deploy one small well-understood change to learn the deployment process. Write down everything you learn.
Phase two (days 31-60): targeted improvement. Identify the highest-pain points — the areas causing the most incidents or slowing delivery most. Propose improvements based on evidence, not aesthetic preferences.
Phase three (days 61-90): systematic improvement. Start writing tests for critical paths that lack them. Build the case for larger refactors by demonstrating value with smaller ones.
The engineers who damage legacy codebases are the ones who rewrite from first principles before understanding what the system is actually doing.
— Dick Bassey | DevDick | 2026