Scout Rule
The codebase gets better with every change — no separate refactoring projects
Leave the code better than it was found. That's the entire technical debt strategy.
While There Anyway
The developer is working on feature X in file Y. File Y has cruft — inconsistent naming, muddy logic, missing tests, unclear structure. Clean it up. Rename the variables. Extract the method. Add the test. No separate refactoring project needed. Just improve what gets touched, as it gets touched.
This is how debt gets paid down without anyone noticing. Continuous improvement baked into normal work, not a special-case interruption that needs to be scheduled, justified, and prioritized against features.
Technical Debt Is the Developer's Problem
The client shouldn't have to care about technical debt. They shouldn't hear about it in standups, see it on the board, or be asked to prioritize it against features. Technical debt is the developer's environment — like a carpenter's workshop. Keep it clean so the work stays efficient.
The same goes for testing. Unit tests, integration tests, whatever the project needs — the developer writes them to sleep well at night, not because the client asked. The client cares about working software. How the developer ensures it works is their responsibility.
Why Context Matters
The best time to improve code is when the developer is actively working in it. The understanding is already there. The code has just been read line by line. That context is valuable — use it. An hour later, the developer has moved on. A month later, the details are forgotten entirely.
No permission needed. No explaining technical debt to non-technical stakeholders. Better code is just a side effect of shipping the feature.
When Debt Blocks a Feature
Sometimes the debt is in the way. Can't build the new feature without fixing the data model first? Good — fixing it is the first step of the task. It's not a separate ticket. It's not a negotiation with the client. It's part of the work.
Major architecture changes, performance work, security fixes, foundational upgrades — these can't always be done in passing. But the trigger is always the same: the business need is real and the cost of not doing it is blocking progress.
The Solo Advantage
Most technical debt compounds because multiple developers create inconsistent patterns. Different styles, conflicting approaches, disagreements never resolved. Working solo, the developer has consistent patterns throughout. The scout rule keeps them clean.
When a second developer eventually joins, they're joining a codebase with clear conventions and established quality. That's far easier to onboard into than a mess accumulated over years of well-intentioned shortcuts.
In Practice
Before: muddy variable names, tangled control flow, duplicated logic. After: clear names, obvious flow, extracted shared logic. It takes five extra minutes. It saves hours of confusion later. That trade is always worth making.