I’ve been writing software for more than a decade now, and one of the most important lessons I ever learned came from a conversation early in my career. I told a colleague - a seriously brilliant engineer - “You know, the code in our app is kinda shitty.”
He smiled, nodded like an old monk on a mountain, and said:
“It’s shitty everywhere.”
And honestly?
The longer I’ve been in this profession, the more I realize how unbelievably true that is. Every company, every team, every project - big or small - ends up with its own personalized flavor of chaos. Yet we keep pretending that somewhere out there, maybe at Google, or Netflix, or some mysterious Scandinavian startup… someone is writing perfectly clean code.
Spoiler: they’re not 🙃
And that’s fine. Really.
✨ What Even Is “Clean Code”? (Be honest… nobody has one definition)
Over the years I’ve heard more definitions than I can count. “Readable.” “Simple.” “Consistent.” “SOLID.” “Elegant.” “Whatever I personally would write if I had more time and fewer deadlines.”
It’s all vibes. No one agrees on anything.
Ask ten developers what clean code means and you’ll get twenty-seven different answers. Clean code isn’t really a standard - it’s a feeling. It’s that moment of peace where your brain goes, “okay, at least this part won’t haunt me in three months.”
A universal definition?
Yeah… let me know when you find one 😌
🚧 Real Projects Don’t Start Clean
They start with pressure.
With managers wanting something “on the screen.”
With proof-of-concepts.
With deadlines.
With juniors doing their best.
With code written at 2 AM during a sprint that should have never existed.
Codebases don’t start messy.
They start fragile - and reality breaks them instantly.
🔥 The POC That Accidentally Became Production
This one is legendary. There was a quick prototype built by juniors. It wasn’t meant to live longer than a week. It was basically duct tape with feelings.
Then a manager burst in like, “We just need ONE more thing - add a quick chart so we can win this contract!”
The chart was hacked in.
The contract was won.
The POC was shipped straight to production 😭
Developers have spent YEARS fixing bugs in that area. Everyone keeps saying “we’ll refactor it soon,” but somehow there’s always something more important. And that’s how legacy is born - not through bad developers, but through successful hacks.
⛏️ The Five-Year Refactor (that’s still “almost done”)
Another time, a team started refactoring a big module.
Responsibly. Carefully. Step by step.
A year passed.
Then another.
And another.
I ran into the manager a while later and she proudly said, “We’re almost done refactoring that module!”
Almost.
After five years.
Refactoring doesn’t finish.
It just slowly transitions into folklore.
🎻 The Perfectionist Senior Who Accidentally Created Spaghetti
Once I worked with a senior backend dev who was genuinely brilliant. His code reviews were essays. He analyzed edge cases no one had ever asked about. He rewrote variable names like he was editing a novel.
And yet… somehow the application was a disaster.
Full of holes.
Inconsistent.
Unstable.
Why? Because people were terrified to ask him questions. No one wanted him reviewing their PR. No one wanted to touch “his code.”
And when developers are scared, they don’t improve things - they work around them. Quietly. Secretly. Carefully.
And nothing grows faster in silence than spaghetti 🍝
Perfectionism doesn’t create clean code.
Perfectionism creates fear.
And fear creates chaos.
😂 The Magical [enableSpecialMode]="true" That Should Never Have Existed
Okay, this one is from long ago - but it’s still one of my favorites.
There was a bug.
Fixing it caused another bug.
Managers were playing political ping-pong about what should be fixed first.
Deadlines were screaming.
And the fastest, safest fix - the one that wouldn’t break anything else - was to slap this little masterpiece into a component:
[enableSpecialMode]="true"
The funniest part?
There was no “special mode.”
It didn’t exist.
The name was a lie.
But hey - it worked. It fixed the issue instantly.
We all promised to refactor it “later.” We all knew “later” meant “never.” And yep - nobody ever refactored it 😂
Hacks live longer than most engineers.
🤖 AI: The Cleanest-Looking Mess You’ve Ever Seen
Now we have AI.
AI writes code that looks clean. It’s beautifully formatted, consistent, neat, readable…
and completely unhinged underneath.
AI happily introduces new dependencies, solves symptoms instead of causes, ignores architecture, and produces logic nobody understands. It’s like having a very fast, very confident junior who never asks “why” and generates 300 lines of elegant nonsense in three seconds ✨
The future of legacy is machine-generated - and painfully well-indented.
📊 Business vs Clean Code: A Fight Clean Code Always Loses
Developers want stability, clarity, maintainability, structure.
Business wants speed, features, deadlines, demos.
Not because business is bad - but because that’s how business works.
Clean code is incredible.
But clean code doesn’t win deals.
Clean code doesn’t impress investors.
Clean code doesn’t magically beat competitors.
Excel wins. Always.
🤔 So… Is Clean Code Even Worth Trying For?
Yes.
Absolutely, yes.
But not the mythical version from books. Not the holy-grail, perfect, glistening, immaculate codebase that survives unchanged for years.
Clean code is not a destination - it’s a direction.
It’s an intention. A mindset. A kindness to your future self. A way to make things less painful rather than perfect.
Write the cleanest code you reasonably can. Refactor when it matters. Communicate your hacks. Understand your shortcuts. Choose clarity whenever possible.
But also - and this is crucial:
💛 Don’t punish yourself for the messy parts.
💛 Don’t feel guilty for compromises you had to make.
💛 Don’t compare your real code to textbook fantasy code.
💛 Don’t assume anyone else has it all figured out - they don’t.
We all have dark corners in our codebases.
We all have embarrassing files hidden deep inside the repo.
We all have something like:
[enableSpecialMode]="true"
lurking somewhere in production.
And guess what?
We’re still good developers.
We’re still learning.
We’re still doing our best.
Clean code matters - but being kind to yourself matters more 💛✨
Top comments (115)
Hey, nice one! 👏I really like the topic of your article!❤️
I can say that perfect code doesn't exist, because perfection isn't something software naturally has, it's a human idea, dependent on context, perception, and time. All we can do is write code that is constantly improving, code that is clear, safe, and maintainable, which brings us closer to perfection without ever fully reaching it.
Even though today we have libraries at our fingertips, an infinite number of tools, and unlimited resources online, perfect code remains an illusion we aspire to reach. This is because every developer has different experiences, tastes, and priorities. What seems clear and elegant to some can appear complicated or confusing to others. To perceive code as ideal is impossible, because our minds all think differently.
Not to mention that requirements change, technologies evolve, and teams come and go, so code that seems clean and well-structured today can become inefficient or hard to maintain in a few months or years. Perfection cannot be maintained over time because the environment in which code exists is never static.
Even with all the resources available, we still have to choose between implementation speed, readability, performance, testability, modularity, accessibility… and the list goes on! 😂 We can't maximize all of these at once, every decision involves trade-offs. Perfect code would have to excel in all these dimensions simultaneously, which is impossible.
Languages change, best practices evolve, and what we consider clean code today may be outdated tomorrow. Perfect code cannot exist because standards and human understanding are continuously evolving.
It’s like being a student who wants to know all the subjects, and on top of that, understand them perfectly!😂
Thank you for your article @sylwia-lask !
Thank you so much for such a thoughtful comment ❤️
And I completely agree with you: technologies evolve, best practices shift, teams change, and I've seen perfectly “clean” code become outdated overnight during migrations or refactors. The definition keeps moving because the industry keeps moving.
But there’s one thing that doesn’t change for me: keeping our ego out of the way and writing code that’s simple, clear, and understandable to others. No matter the stack or the trend, readability and kindness toward future maintainers always win.
Thanks again for sharing your perspective - loved reading it! 🙌✨
So true! At a minimum, your code should be readable, clean and commented where necessary. You said: “Survivable code” and you're right… as long as it runs and remains maintenable, it's good code; not perfect, but good, and that's enough.
Absolutely! And you’re right - “survivable code” doesn’t mean we stop trying or lower our standards. It just means we aim for code that’s readable, maintainable, and sensible in context.
We should always try to do our best, but do it with a bit of pragmatism and a clear head 😊
Thanks for the thoughtful comment, Pascal!
Survivable Code is more of a function of organization size and other factors of inertia. Check the US Social Security Admin. Code in COBOL still survives 55 years later. No doubt many weapons systems still being maintained rely on Ada code from at least 30 years. And the VA's Veterans Health Information Systems and Technology Architecture (VistA) still is running on MUMPS from who knows when it was written.
Your code will not survive when Fortune 100 gobbles up your fast-growing Russell 2k employer. F100 execs buy product lines and sales forces. They pull the plugs on the systems that come with those acquisitions.
You’re right that long-lived systems often survive because of organizational inertia rather than elegance - COBOL, Ada, MUMPS… they’ve definitely earned their place in history 😄
But that’s also exactly why I think “survivable code” isn’t only about age or how long something stays in production. For most engineers today, survivability is about clarity, maintainability, and how well code can evolve with the team and the product - not necessarily whether it runs for 50 years in a government agency.
The Fortune 100 scenario you described is very real, but it’s also a completely different context from day-to-day engineering in modern companies.
So I’d still argue that writing understandable, pragmatic code is valuable regardless of the system’s eventual lifespan - even if someone someday pulls the plug.
Thanks for adding another angle to the discussion!
Evolving code -- a rewrite or patched to the point of no recognition hardly can be called survivable code. That is known rightly as Disposable Code. It survives organizationally, but its original execution physics are corrupted by every change.
Quite the opposite. Survivable code is as I have stated: code that runs the systems humans are too dependent upon that no one dare pull the plug. Such code survives by being unchanging and indispensable. It is predictable, reliable, and reveals absolute adherence to execution physics (time and memory costs).
Here is another example: the humble ECU. How many 10+ year old cars on the road today are rambling down streets with their ECUs? Those ECUs are executing structurally complex code--memory-constrained under real-time execution environment--that likely is not readable.
Yet, it is the quintessential definition of survivable code: it runs perfectly within a highly constrained, hostile physical environment for decades without change. Its survival is due entirely to its predictable physical execution, not an egghead's abstraction model.
Heed my dictum: Code that survives is code that is predictable.
What most think is readable really is predictable. Can you read the source, put it thru a mental compiler into a mental CPU and see the output from a mental machine?
Thanks for sharing your perspective - I really appreciate the depth and passion you bring to this topic. I definitely see where you’re coming from: in highly constrained, safety-critical systems, predictability is everything, and “survivability” truly does mean decades of unchanged, deterministic execution.
My post was focused more on the everyday reality of modern software teams, where constant change is the norm and code needs to survive through evolution rather than by remaining static. Different contexts lead to different definitions - and that’s exactly what makes this discussion so interesting.
Thanks again for taking the time to elaborate - it’s been fascinating to read your angle on it.
Concepts Survive. Order entry, Customer look up, Inventory reconciliation—these pieces of Ubiquitous Language are the foundation, often unchanged for decades—the real language.
Code Perishes. The Python, Java, or C++ code that implements those concepts is disposable as are those languages. When the original author leaves, the implementation complexity often ensures that the code is more likely to be rewritten in the next iteration than perfectly maintained in place.
The business domain constants represent the "physics" of the business operation. They survive personnel changes, language migrations, framework churn, and even massive architectural shifts (e.g., from monolithic mainframes to microservices).
The code, the 3GLs, the 4GLs, the frameworks—those are just the transient, perishable implementations (the mechanism) of those concepts.
More than mere variant definition, we are standing at far different elevations. At my height, I see Domain Modeling, what the system is.
What you see is Implementation Detail, that is, how parts of the system are built, the part for which you might have current responsibility.
The domain is durable; the details are disposable.
This is genuinely fascinating to read - your perspective on “survivable code” is something I don’t see discussed often, and it clearly comes from years of hands-on experience with systems most developers never touch.
Honestly, it feels like too much good insight to leave buried in a comment thread.
If you ever feel like writing a full article about this - the philosophy, the constraints, the historical context, the real-world examples - I think a lot of developers would benefit from it.
Your view is unique, and it deserves its own space.
If you publish something, please tag me - I’d really love to read it.
Thank you for your overly generous kind words.
When I was quite young, I worked with a much older man who learned programming during his career in the Air Force. As he told me, in his time, there were no computer science departments, no degrees, no formal training. Rather, he learned on the job after learning about how the Air Force worked from the ground, upward.
He understood the work from execution physics of machines limited by their available components. He understood organizations and human work flow. He was the best programmer of the bunch.
We talked about why code written by the comp sci grads tended to be terrible. He said they lacked business experience. The lacked organizational experience -- real work experience. Luckily, I had various work experiences and was curious about humans and human processes. My degree had been earned in a different field so he gave to me a pass.
He said because comp sci grads had no idea how recorded information traveled through pipelines of real world departments, their code failed to capture succinctly such processes. In short, the did not know the true language, the language with constructs like order entry, customer lookup. They knew nothing about how paper forms captured human work flow and what were the expectations of real people.
He said they knew only how to write fancy algorithms. The problem of course is all they had were hammers and everything they thought they saw were nails. The pedagogy of men has gotten ever further removed from the execution physics of both machines and living reality.
Code is organizational automation, not algorithmic implementation.
Much of computing came from the digitization of paper forms first perfected during the scientific management era of factories, circa the 1920s. Forms captured responsibilities (who fulfills what), authority (approvals), timing (when forging, assembly, fulfillment would happen), exceptions (what had to happen when inventory of parts could not fulfill assembly needs).
For a long time now, comp sci grands only see: database schema with validation rules.
Real life is not algos, data structures, complexity. Real life is data capture, work coordination, exception handling, reporting.
As most programmers lack knowing machine physics, so too, they lack knowing organizational physics, you know, both "I did not expect that behavior!" and "Why isn't anyone using our system? We wrote it for them!"
IT departments are corporate zoos. Business operations are jungles. One is a curated habitat feeding abstraction kibble; the other is the natural wild where survival requires understanding actual terrain.
Stone, thank you for sharing this - genuinely.
There’s a lot of wisdom in what you wrote, and I can clearly see how your experience with real organizations and real workflows shaped the way you think about code. That perspective is rare today, and it’s one of those insights that only comes from decades of watching how systems succeed or fail in practice.
I fully agree with the core idea you highlighted: good software is never just algorithms - it’s an understanding of people, processes, constraints, and the physical reality in which those systems have to operate. When those pieces are missing, even the “cleanest” code falls apart.
Thank you again for taking the time to write all this. I appreciate you bringing a piece of that history and lived experience into the conversation - it adds a depth that’s hard to find.
Wirth pushed that for years: Pascal > Modula-2 > Oberon-2. Language design matters. It is hard to write "readable" APL.
A good tool to decide if a language itself results in self-documenting code.
99 Bottles of Beer
Totally agree - language design absolutely shapes readability. Some languages almost guide you toward clarity, and others… well, make you work for it 😄
And yes, APL is definitely on the „beautiful but not necessarily readable” end of the spectrum.
But that’s also why I find it so fascinating: even with well-designed languages, readability still depends so much on the person writing the code and the context they’re working in.
Thanks for the examples - always fun to look at how different languages influence how we think!
My story on the topic…
I began a side project in 2017 with a simple intention create a space where people could anchor conversations in the actual words being spoken in our public life. The design was small, human, and principled. And the technology we used to build it was cutting-edge at the time: React 15/16, early GraphQL, MongoDB, Babel, Express, and a front-end architecture that matched the best practice thinking of that moment.
For years, the project grew through sheer persistence and the effort of a dozen contracted developers. It was a civic experiment stitched together by a handful of volunteers and a deep belief that the internet deserved better public spaces.
Then something important happened:
Hacktoberfest.
In October of this year, dozens of developers from all over the world opened our repo for the first time. These were smart, curious engineers who genuinely wanted to help. And instead of momentum, they hit walls, because the architecture we built in 2017 reflected the assumptions of that era, while time had moved on.
They ran into issues immediately:
• outdated patterns that made onboarding slow
• React 17 + Vite + Material UI v4 that felt unfamiliar to new contributors
• Babel-era tooling that lacked modern TypeScript safety
• a backend built on Express + Mongoose 5 that required tribal knowledge
• file structures that made sense only to people who had lived through the whole history
Pull requests stalled and good, engaged developers stepped away. And that’s when the truth became clear to us, that Infrastructure shapes the creativity that can happen on top of it.
If we wanted the world’s developers to contribute, if we wanted to build a real open-source civic platform with a community around it, the foundation needed to feel inviting, and modern.
So we made the decision to undergo a full rebuild and reactor the entire code base.
A backend migration from JavaScript + Babel to TypeScript, modern Express, and Mongoose 8.
A frontend migration from Vite + React Router + Material UI to Next.js 16, React 19, and shadcn/ui.
Clear file boundaries, typed GraphQL, predictable flows, and infrastructure that developers enjoy working inside.
The goal was make it so contributors should arrive, understand where things live, and feel empowered to build features that matter.Open-source work should feel joyful, not frustrating.
The rebuild is long, deliberate, and thoughtful, and it honors the early years while clearing space for what’s next. Because Quote.Vote has always been a civic project, and civic projects grow stronger when many hands can help shape them.
This migration ensures exactly that it becomes a platform where outside developers can join without friction, contribute with confidence, and focus their energy on the creativity and purpose at the heart of the project.
That is the story of Quote.Vote’s evolution from a 2017 experiment into a durable 2025 public-good system designed for openness, clarity, and community collaboration.
And now, with v2 underway, everyone can build with us.
github.com/QuoteVote/quotevote-next
github.com/orgs/QuoteVote/projects...
Wow, thank you so much for sharing this - what a beautiful story of how a project can evolve over time. And honestly, I love the decision you made. Technology ages much faster than the needs of the product, and sometimes the most caring thing you can do for a community is to rebuild the foundation so people can actually enjoy contributing again.
I absolutely agree that open-source should feel joyful, not frustrating. It’s so inspiring to see a team acknowledge that, honor the past, and still create space for the next chapter.
And I’ll definitely keep Quote.Vote in mind - I’m planning a post soon about good places to find welcoming OSS projects, and yours is such a perfect example of this mindset. Thank you again for writing all this, it really resonated with me. 💛
Thank you Sylwia! That is so encouraging to hear. Thank you for your post and the thoughtful reply. Please do tag me if you end up posting about OSS projects, I would love to read your next post.
very Insightful
Although I call out alot of bad code practices, i also admit from time to time that I also start with shit crappy code just to later, refactor it haha.
Awesome post! and btw i'm loving the friendly commit message you built haha, having too much fun with it.
Hahaha yes, “I’ll refactor it later” - said every developer ever 😄🔥
And thank you! I’m so glad you’re enjoying the friendly-commit-messages repo - I’m having way too much fun with it too.
At one point I asked it about the meaning of life, and it replied that to understand that, I first need to analyze what humans are made of 😂
This thing gets philosophical at 2am and I love it.
Your article and views perfectly align with current state of the industry. But things are changing. I believe I know how to write "clean code" and there is a straightforward guide how to do this as a matter of routine. The only caveat - it's not the code from Uncle Bob books. Take a look here.
I read Uncle Bobs book on clean-code. Also listened to his talks.
Most of it is true. Although his particular example on how to clean up this Java-Class does not really make it better. I once read a rant about it, it was good.
The good thing is, that Uncle Bob knows that all the clean-code "rules" are open for discussion - he dares us to disagree.
(Btw. I got the German instead of the English version of the book - the typesetting is awful: no syntax-highlighting, and wrapped lines in the middle of variable names.)
Anyway, I took some "rules" from the book and I like to apply them whenever possible.
My favorite one, which seldom is taught to beginners is this one:
This makes many design decisions much easier.
Thank you again for another thoughtful comment - I always enjoy your insights!
I also read Uncle Bob’s Clean Code years ago (in my case, the Polish edition 😄). And I completely agree: even if not every example lands perfectly, he raises a lot of valuable ideas and openly invites disagreement and discussion, which I appreciate.
The longer I work in this field, the less I rely on “gut feeling” for architectural decisions. These days I find myself reaching for proven design patterns much more intentionally - and almost every time I think: “Right, someone already solved this problem far better than I would have on intuition alone.”
That rule you mention - separating state-changing methods from return-value methods - is such a simple idea, yet it instantly clarifies so many design decisions. I wish more beginners were taught that early on.
Thanks again for contributing to this thread - your comments always add a lot of depth! 🙌
Yes, most of it is true. The problem with "clean code" is the subjective nature of the recommendations. It results in different (often conflicting) interpretations. But the worst thing is that even strict and correct following of all "clean code" rules does not eliminate subjective factors. Over time, codebase is just a bunch of scars of personal styles and approaches. Consequences are devastating - moths of onboarding, code silos, and constant mental overhead caused by incompatibility of the ways different devs see the problem and the solution. Not to even mention PR reviews, which often turn into personal fights and constant obstacles instead of code quality improvement tools.
The times when we could rely on subjective criteria and judgments are over; software engineering should be, well, engineering and use engineering approaches. Similar tasks implemented by different devs should look similar and should take similar time to implement. Code should be unified to the level, when subjective component is virtuall non-existent. This will make onboarding virtually instant, anyone can read/understand/modify anobody elses's code without any issues, PR reviews finally will be focused on the correctness of the solution of the business task instead of things like how methods are named or should it be split into two or not.
I completely agree that the subjective nature of “clean code” is one of its biggest weaknesses. Two developers can follow the same principles and still produce results that feel totally different. And yes, you’re absolutely right - PR reviews often drift into personal style debates instead of focusing on what matters: solving the actual business problem.
At the same time, I think there will always be some level of subjectivity in software, simply because humans write the code. Even with strong engineering standards, patterns, and conventions, we still bring different experiences, mental models, and ways of reasoning about problems.
I do love the idea of reducing that subjectivity as much as possible - unifying patterns, aligning approaches, making onboarding easier. That’s where solid engineering guidelines and architecture decisions really shine. But I also think there’s value in leaving a bit of space for individual reasoning, creativity, and flexibility. Otherwise we risk turning the codebase into something too rigid to evolve.
So for me the sweet spot is:
strong shared conventions + room for pragmatic judgment.
But I really appreciate your perspective - especially the part about focusing PRs on correctness rather than style. I wish more teams did that.
Proposed approach does not eliminate creativity. Quite the opposite: you don't spend time on minor irrelevant details and can apply creativity and problem solving skills at higher level.
Thanks so much for sharing!
I love seeing different approaches to what “clean code” means in real practice - especially when they come from people who actually build tools around it.
I’ll definitely take a look at your guide.
Even if we all define “clean” a bit differently, I’m always curious how others try to systematize it in a way that works in real teams. Open-source ideas like this usually spark the most interesting conversations.
Thanks again for contributing to the discussion!
I like it: ⛏️ The Five-Year Refactor. My usecase is the opposite of clean coding: Maintenant and refactor a Seven-Year ago forgotten codbase which is using day by day many users around the globe. Even the architecture is a nightmare, but the solutions is worst: I saw the creator of that project ( left the company 5 years ago ) is a dependency collector, plus functional programming fanatic in a bad way, because when all simple step are hidden behind of function generated functions which is cannot able to debug. That pattern are using on frontend and backend's well. Of coure company don't have resource to put enough developer to refactor it, the first ( and most important ) request was: eliminate vulnerability at any cost, all other is not important.
I just spend a half year to eliminate that, but those stepps is fare form refactory.
( any suicid developer welcome in this project )
Wow, that sounds absolutely brutal - I really feel for you. But honestly? You’re kind of a hero here. You spent half a year eliminating vulnerabilities across the entire project… meanwhile the team in my story needed five years to “almost refactor” one module 😅
So if anything, you deserve a medal for surviving that architecture and making it safer. Respect - not many developers walk out of a codebase like that alive!
Thanks!
For the full picture, as hobby I also try making a "clean" type safe useReducer npm module for react by jsDock. Where the source code core is only one file, 65LOC mostly remmark ( thx for jsDoc ) only contain a 16LOC actual code.
But at the end I recognize much better solution to burrow this file into project instead using as npm module, thx for a other 15 files which is just make that one file can be imported.
Even that small file is cannot call clean. Thx for Typescript type definition is bit strange and jsDock was using that type definition system also ( in two different syntax ). Yes it is perfectly TS compatible code also so can be import to any JS or TS based react code
.... but the final question is why? Because I think React is bit owerkill for many task, so I moving from React to pure HTML/JS/jsDock solution. To proof my concept is working also created a bit complex game (don't really playable) for hackhaton ( to feel the deadline reality )
Thanks for sharing the full story - I honestly love how much curiosity and experimentation you bring into your side projects. It really shows.
And I get what you mean about small utilities never feeling fully “clean.” Even a tiny file can grow sharp edges once you mix typings, compatibility concerns, and different ecosystems. That’s the funny paradox of simplicity - the closer we get to it, the harder it becomes to maintain.
I also agree that React can feel like overkill for many tasks, and I’ve definitely had moments where plain HTML/JS felt refreshing. But at the same time, the ecosystem around React solves so many “boring” problems that it’s often worth the trade-off - especially on bigger teams or longer projects.
Either way, I love that you explore these ideas by actually building things (even a small, chaotic hackathon-style game!). That’s the best way to test assumptions in practice.
Brilliantly put—this captures the reality of software development far better than any idealized coding philosophy. Clean code is aspirational, but delivering value despite constraints is the true mark of engineering.
Thank you so much! That’s exactly what I hoped to capture with this post.
Clean code is a great aspiration, but in real projects we’re constantly navigating constraints, deadlines, and trade-offs. We should always aim for the best we can - but also stay honest about the reality we build in.
Thanks so much! Clean code is always the goal, but real projects come with limits and trade-offs — we just do our best while staying honest about the realities we work in.
Absolutely - I really appreciate this exchange. It’s refreshing to talk about clean code without turning it into dogma. At the end of the day, we’re all just trying to build things that work, last, and make sense to the humans maintaining them. Thanks again for such a thoughtful discussion!
Thanks.
I like to try to leave things just a little better than I found it, while working on "business" tasks. I choose a certain amount of refactoring I think is a good idea and won't take too much additional time to do. Sometimes I choose that amount poorly, but at least the code gets clean-er.
I try to do the same. And honestly, it always frustrates me when developers intentionally skip small improvements just because “they didn’t write that part.” That mindset hurts teams in the long run. Uncle Bob described this perfectly with the Boy Scout Rule - leave the code a bit cleaner than you found it, even if it’s just a tiny step. Thanks for sharing this.
I have been project manager for decades and I always speak to the members of the project : remember 'we have plenty time to do things 2 , 3 , 4 or even more times, but not to do things the first time right!'
Thanks for sharing this! Yes — I’ve seen this especially often in startups, where time-to-market is everything. Sometimes you intentionally build something quickly because you don’t even know if the feature will be accepted by the business. Prototypes, experiments, quick wins… they all shape the reality we end up maintaining later.
The thing is, that people want their software to survive. And it can if you aim for the easy to maintain version. But what they sometimes forget, is that most software nowadays is vaporware. it needs to fill a gap right now and in a couple of months, or years, demands are totally different. Languages improve, or new ones are born. People progress, evolve, and so does software. In this continuous evolution, it is hard to slow down and reflect. So better pick a good battle, which you know you can win one day.
Exactly. Especially on the frontend - sometimes you start a project and the stack is almost legacy by the time it ships 😅
That’s why “pick a good battle” really resonates with me. Not every piece of software is meant to live forever, and that’s okay. Thanks a lot for the thoughtful comment - loved this perspective.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.