From Rage to Refactor
The Stoic Coder’s Guide to Legacy Code Fury
You open a file, and it’s 2,000 lines of nested conditions with variables named temp, temp2, the_real_temp. Your blood pressure begins to spike. The original developer is long gone. Your rage changes nothing except your ability to think clearly about fixing the issue.
But here’s the thing: not all anger is useless.
The Two Flavors of Anger
The Stoics made a distinction that every developer needs to understand. There’s destructive fury, and there’s constructive frustration.
One paralyzes you. The other refactors.
Destructive anger assumes malice or incompetence. You look at that spaghetti code and decide someone was either stupid or lazy. Maybe both. You build this whole story in your head about the idiot who wrote this shit and how they clearly didn’t give a fuck about anyone who’d have to maintain it.
That anger feels justified. It also does absolutely nothing to fix the problem.
Constructive frustration looks at the same code and says, “Okay, this is problematic.” No story about the previous developer being an asshole. No moral judgment. Just acknowledgment that this code needs work, and you’re the one who has to do it. This kind of frustration becomes fuel. It motivates systematic improvement instead of rage-driven rewrites.
What Destructive Anger Actually Looks Like
I’ve been that angry developer. Early in my career, I inherited an e-commerce system that looked like it was written by someone having a stroke. My first instinct was to delete everything and start from scratch.
So I did. I spent three weeks rewriting the entire thing “the right way.” Added all these beautiful abstractions. Clean separation of concerns. Design patterns everywhere. I was so proud of myself.
Two problems: First, I broke shit that was working. Turns out some of that “terrible” code was handling edge cases I didn’t know existed. Second, my “clean” rewrite was over-engineered to hell. I’d created a different kind of mess because I was coding from emotion instead of analysis.
Rage-driven refactoring looks like this: dramatic gestures instead of pragmatic improvements. You’re not fixing problems, you’re proving a point to a developer who isn’t even there anymore. You’re writing code to show how much better you are, not to make the system actually better.
And here’s the kicker: that ecomm system I rewrote? Someone probably looked at my code a few years later and thought the exact same shit about me.
The Pause That Changes Everything
Seneca had a technique for this: catch anger in the first moments before it becomes rage. Notice the tightness in your chest when you see bad code, pause, and then choose your response.
Here’s what this actually looks like in practice:
You open that file. Feel that rage building. Your jaw clenches. Your inner monologue starts going off about what kind of person writes code like this. Right there, that’s the moment. Seneca says catch it before it catches you.
So you literally stand up. Walk to the break room. Pour some coffee. Not because you want coffee. Because you need three minutes to let your nervous system calm the down. You’re not avoiding the problem. You’re preventing yourself from making it worse.
Then you come back and refactor like a professional instead of an angry teenager.
The question isn’t “Is this code terrible?” The answer is usually yes. The real question is “Does my anger help me improve it?” And the answer to that is almost always no.
Understanding Why Code Gets This Way
Here’s what I’ve learned after 25 years: all code degrades over time. Yours, mine, everyone’s. It’s entropy, not evil.
Budget constraints force shortcuts. Deadlines demand compromises. Requirements change mid-sprint. That “quick fix” becomes permanent because there’s never time to go back and do it right. The elegant architecture you planned gets demolished by reality.
The developer who wrote that nightmare code? They were probably dealing with the same shit you are now. Maybe the product manager kept changing the specs. Maybe they were told to ship it by Friday or the company loses the client. Maybe they were maintaining ten other systems simultaneously and this one got the leftover brain cycles.
You don’t know their constraints. You just know what they left you.
And here’s the humbling part: the code you’re writing today, right now, with the best intentions and all your experience: that’s someone’s future legacy nightmare. Some developer in 2030 is going to open your files and wonder what the hell you were thinking.
Because they won’t know that you were dealing with a sudden API deprecation. Or that the business needed this feature yesterday. Or that you were juggling three projects and fighting production fires at the same time.
This realization doesn’t excuse bad code. But it kills the moral outrage that makes you useless.
Channeling Frustration Into Improvement
Once you’ve let go of the anger, you’re left with something more useful: energy. Frustration that says “this needs to be better” instead of “someone messed up.”
That energy goes into systematic refactoring. Not dramatic rewrites. Not proving points. Just methodical improvement.
Write tests first. Document what the current behavior actually is, bugs and all. Then improve incrementally. One function at a time. One responsibility at a time. Make it work, make it right, make it fast—in that order.
This is anger transformed into discipline. Into craftsmanship. Into code that’s actually better instead of just differently broken.
The Hard Truth About Your Own Code
You know what kills the rage cycle? Genuine humility about your own imperfect work.
Go back and look at code you wrote a year ago. Hell, six months ago. You’ll find stuff that makes you cringe. Because you’ve learned since then. Because you see the problem differently now. Because the requirements changed and your beautiful solution became technical debt.
The legacy code you’re cursing today is your own future legacy code tomorrow. The same pressures that created that mess you’re fixing right now are creating tomorrow’s mess in what you’re writing today.
That’s not defeatist. That’s reality. And once you accept it, you can stop taking bad code personally and start treating it as what it actually is: a problem to solve, not a villain to vanquish.
From Rage to Refactor
Marcus Aurelius said you have power over your mind, not outside events. You can’t control that some developer three years ago wrote shit code. You can’t change that you’re the one stuck fixing it. You can’t even guarantee that your fixes will be better in the long run.
But you can control whether you let rage make you stupid. You can choose to pause instead of react. You can acknowledge frustration without letting it drive your decisions.
The code is what it is. Your job isn’t to be mad about it. Your job is to make it better.
That’s the Stoic move. Transform the anger into action. Let the frustration fuel discipline instead of dramatic rewrites. Fix the problem instead of fighting ghosts.
Because at the end of the day, the only code you can truly control is the code you’re writing right now. Make it count.
Quote of the Day:
“The greatest remedy for anger is delay.” - Seneca
👉 If you enjoy reading this post, feel free to share it with friends!
Or feel free to click the ❤️ button on this post so more people can discover it on Substack 🙏
You can find me on X and Instagram.
Also, I just launched a new YouTube channel - Code & Composure