Clean Code Matters, But Doesn’t Sell… Usually

I’ve been a clean code evangelist for as long as I can remember. It all started way back in January 1998 with my first programming assignment. Picture this: my 18-year-old self, sitting among 120 other bright-eyed students in an old, run-down building, thinking we were in paradise. Yes, paradise — a paradise of rusty doors, cracked walls, and squeaky wooden chairs. We were there to learn to code, to take those first few steps on the road to becoming real software developers.

Our very first assignment? A simple one. Take two numbers, swap them, and print out the bigger one. I remember laboring over that code, making it “perfect.” I carefully chose the variable names: x1, x2, and temp (for the temporary variable, obviously). I felt so proud — ridiculously proud, in fact. There I was, in the middle of that dusty classroom, convinced I’d created code that even a mathematician would respect. And I’m sure you know that feeling too, that satisfying sense of a job well done. I remember handing that paper to the teacher with one last, pride-filled glance. Yes, I thought, this is the beginning of a beautiful journey. (Spoiler: reality had other plans.)

Back in my university days, I was surrounded by other passionate developers, all of us eager to learn, to improve, to master the art of clean code. I remember the exact moment I completed a tough bit of logic and, looking at it, realised it worked but didn’t look right. It didn’t have that clean, elegant feel that I wanted it to have. So, I did something that felt radical at the time — I deleted all of it and started over. Clean code was worth the time, the effort, and yes, the extra struggle.

Fast forward 25 years, and I’m still that proud little programmer. I’ve written thousands of lines of code, spent hundreds of hours refining and re-refining my work, all in pursuit of that elusive “clean code.” Every time there is a new requirement, it’s the same ritual: Analyse it, build a model in the head, code it, test it, clean it up, and then repeat the steps until satisfied with the outcome. And after all that? I feel just as proud as I did that day in 1998, swapping those two little variables.

But after graduation, at work, it was another story entirely. I can still remember saying to myself. “Is this it? Is it inevitable that every codebase eventually devolves into a tangled ball of spaghetti?” As the horror started to sink in, I stared at the screen in front of me, dreading the layers of tangled code that were now out of my control. I can still remember, the feature was complete and everything somehow worked, but none of us were sure why it worked. And, to my eyes, the code was just… itchy. You know that feeling — it looks functional but painful. There was that nagging urge again: to delete it, to rewrite it, to make it clean. But this wasn’t just my code anymore. It was part of a bigger system, a system that had already been tested and approved by QA, a system that was about to go live. My hands itched to refine it, but the reality was clear: I had no choice. The team was celebrating the feature’s release, and there I was, silently mourning its messiness. I somehow swallowed the shock and moved on.

From the beginning, I was on a quest to write “the best code.” Even though I wasn’t entirely sure what “best” even meant back then, I talked about it with my peers, learned from books, and later, the internet, about clean code practices. And with each year, the code got clearer. I learned that clean code wasn’t just for my own peace of mind but also for anyone else who’d read it. Yes, clean code matters — not just for me, but for everyone who would ever interact with it. And if you’re still with me here, I bet it matters to you, too.

My career started changing. Besides writing code I started managing projects, leading teams, and eventually working closely with stakeholders, managers, and sometimes even end-users. Still, I held on to my clean code values. I made sure to write code when I could, always advocating for best practices in code reviews and encouraging my team to take the time to make things right. But then, the inevitable conflict arose: the deadlines.

It was one of those giant multi-year projects, with hundreds of developers and a dizzying amount of code to manage. I was leading a team of 40, responsible for automating half a dozen complex processes with software and hardware, a setup that I thought would last a decade. So there I was, spending weeks ensuring the code would be maintainable, elegant, and future-proof. And there was my delivery manager, impatiently tapping his fingers on his watch, asking me why it was taking so long.

I sat across from the delivery manager, launching into my usual speech about the importance of clean code. I went on about complexity, best practices, thorough testing, and how crucial it was to avoid creating a mess for future developers.

He listened for a moment, then cut in, “Look, the deadline’s already set. We have to show this feature at the company-wide demo next month. Are you saying it can’t be done?”

“Yes, exactly,” I said, firm and resolute. “It can’t be done right with that deadline. If we push it through by then, we’ll have to skip critical tests, cut corners, and rely on hacks that’ll leave the code barely holding together. It’s going to create a mess that’ll be painful to maintain.”

He didn’t even blink. “I don’t care if it’s bad or even terrible code,” he replied, leaning in with a look of absolute certainty. “Just get it done. Use whatever tricks you have to. Hardcode if you need to. It just has to work by the demo.”

I felt a wave of frustration rising, but I pressed on, hoping he’d understand. “If we sacrifice quality now, we’re setting ourselves up for disaster later. Good practices aren’t just for today — they’re for everyone who’ll work with this code in the future. Rushing will make every update harder, every new feature a potential headache.”

He raised an eyebrow, shrugging. “How long are you planning on sticking around on this project anyway? A couple of years?”

I hesitated, thrown off. “Well… probably a couple of years, yeah, but that’s not the point,” I replied. “This code is going to outlast us both. It’s our responsibility to leave behind something that future developers can actually work with.”

He shook his head, a faint smirk on his face. “So you’ll be gone in a couple of years, maybe less,” he said, “and I’ll probably be on the next project by then too. Why are you worried? I just need it to work for the demo. That’s it. The stakeholders don’t care about how it’s written, and honestly, neither do I.”

I took a breath, choosing my words carefully. “It’s like… life after death,” I said, trying to make him see my side. “We may leave, but our code lives on. It has a kind of legacy. I want to make sure that legacy isn’t just a mess of technical debt. I care because it matters to every developer who’ll have to dive into this codebase after me. They shouldn’t have to struggle just because we didn’t take the time to do it right.”

“Look, I get it. You care about this stuff,” he said, humoring me. “But the company doesn’t measure success by how clean the codebase is. It measures success by how many features we ship and how satisfied the stakeholders are. My job is to make sure we hit that deadline. Long-term code quality? That’s not my problem.”

I felt a mix of frustration and resignation. He wasn’t wrong; in the world of big projects, immediate results were everything. Clean code was my priority, but to him, it was just a “nice-to-have.” In his world, code quality was just a checkbox — one that wouldn’t make or break the project in the eyes of management.

I knew the deadline wasn’t moving, and it was clear I’d have to make do. “Alright,” I said, finally conceding. “I’ll get it done for the demo. But in the long run, the tech debt that we creating now is going to cost more than it saves.”

He gave me a satisfied nod, as if we’d just reached some mutual understanding. “Long-term costs are tomorrow’s problem. Let’s just get this feature out the door.”

As I walked out of that meeting, I realised something that had been staring me in the face: in many companies, clean code isn’t just undervalued. It’s actively sidelined because it doesn’t fit neatly into tight deadlines and quarterly targets. In a culture where speed is everything, taking the time to write clean code can make managers look like they can’t meet deadlines or deliver on time.

And that’s the irony: while clean code should be the hallmark of a responsible developer, in the fast-paced world of tight deadlines, it often ends up making managers look like they’re dragging their feet. So yes, clean code matters deeply to us as developers — but at the end of the day, it’s rarely what sells.

It was a brutal awakening. Not everyone sees clean code as “the right way.” In the business world, it’s often just an extra line item, not an essential one. Clean code doesn’t sell. Features do. Demos do. Quick turnarounds and flashy progress — those sell.

Thinking I might find my people elsewhere, I took my philosophy to startups. Surely, I thought, startups would be different. They thrive on quality, right? But no, they thrive on survival. I’d have the founder rush in, telling me about a feature we had to have ready in a week because an investor wanted to see it. And that was that. Clean code ideals were nice, but they weren’t paying the bills. I didn’t need clean code; I needed a hack that would get the job done. And as much as it pained me, I’d cave, telling myself, Just this once.

I remember sitting there, staring at that mess of code and feeling like I’d betrayed my younger self — that proud, earnest programmer who meticulously picked variable names in the university auditorium. But the truth was that sometimes, clean code just doesn’t matter in the moment. Sure, in an ideal world, we’d always have the time to get it right. But this wasn’t an ideal world; it was a deadline-fueled frenzy.

Over the years, I learned that, to programmers, clean code is almost sacred. It’s the reason we write code. It’s what makes us feel accomplished, knowing our code is understandable, maintainable, and a joy to revisit. But for most business stakeholders? Clean code is like an expensive painting in a storage room — nice to know it’s there, but not exactly front and center. They want results they can show off. They want the feature that works now, not the code that’s easy to maintain later.

And so, while I still advocate for clean code and always will, I also accept that it doesn’t always sell. Features, demos, and deadlines rule the day. We programmers might think of clean code as the key to a good product, the “right way” to work, but in the end, it’s often seen as a luxury.

So yes, clean code matters. It’s valuable, and it’s the sign of a programmer who cares about their craft. But does it sell? Well… not always.