We've all been there. You're deep in flow, solving a problem, and you write something that works but... isn't quite right. The variable names are vague. The function is doing three things instead of one. There's a comment that says "TODO: clean this up."
"I'll refactor it later," you tell yourself. Narrator: They did not refactor it later.
I spent years accumulating technical debt with this exact promise. Every "quick fix" that became permanent. Every "temporary solution" that's still running in production. And honestly? It nearly killed my latest project.
The Wake-Up Call
Last month, I was adding a simple feature to a project I'd been building for months. What should have taken an hour took three days. Why? Because I was navigating around six months of "I'll refactor it later" decisions. Functions with misleading names. Tight coupling everywhere. Logic scattered across files with no clear pattern.
The feature worked eventually, but I was exhausted. More importantly, I'd lost the joy of building. Every change felt like defusing a bomb.
The Hidden Costs
Here's what "later" actually costs:
Mental overhead: Every time you open that file, you have to re-decode what past-you was thinking. It's like paying compound interest with your attention.
Slower iteration: Features that should be simple become archaeological expeditions. You spend more time understanding existing code than writing new code.
Lost momentum: Nothing kills motivation faster than dreading your own codebase. When opening your project feels like homework, you've lost.
The mindset shift that changed everything
I made one simple rule: If I'm touching a file, I leave it better than I found it. Not perfect. Just better.
Adding a feature? Clean up the function names while you're there. Fixing a bug? Extract that nested logic into a helper. Touching a view? Rename those cryptic variables.
Five minutes of cleanup today saves thirty minutes of confusion next week.
The Boy Scout Rule
This is basically the Boy Scout Rule: "Leave the campground cleaner than you found it." But here's the key insight I missed for years: you don't have to fix everything.
You're not refactoring the entire codebase. You're just improving the small area you're already working in. It's opportunistic. It's incremental. And most importantly, it compounds.
After two weeks of following this rule, my codebase started feeling different. After a month, adding features was actually fun again. Functions had clear names. Logic was where I expected it. The code was becoming self-documenting.
When "Later" Is Actually Never
Let's be honest about what "I'll refactor it later" really means:
- "I'll refactor it when I have time" = Never (you won't have time)
- "I'll refactor it when the project is done" = Never (projects are never done)
- "I'll refactor it when we hit issues" = Too late (you're already drowning)
The only "later" that works is "the next time I touch this code" - which is exactly the Boy Scout Rule.
Practical Guidelines
Here's what I actually do:
If it takes less than 5 minutes, do it now. Rename that variable. Extract that constant. Add that type annotation.
If it's bigger, create a ticket. But be honest: will you actually do it? If not, do the 5-minute version now.
Don't refactor for hypothetical futures. Refactor for clarity today. The future will take care of itself.
Test as you go. Small refactors are easy to verify. Big ones are scary. Stay small.
The Exception
There is one valid "later": when you're prototyping or exploring an idea. Throw away code can be messy. But the moment you decide it's staying, that's when the Boy Scout Rule starts.
What Changed
Six months ago, my codebase felt like a weight. Today, it feels like a tool. The difference? I stopped deferring quality to "later" and started making tiny improvements in the moment.
Your code doesn't need to be perfect. It just needs to be slightly better than it was yesterday.
Also, if you're working on projects that need a clean blogging platform to document your journey, check out Pluma.ink - I built it to keep technical writing distraction-free.
Tags: #productivity #coding #webdev #programming
Top comments (0)