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 ca...
For further actions, you may consider blocking this person and/or reporting abuse
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.
Definitely worth trying but we, as developers, should not take it at face value, which will happen , if clean code becomes the goal while it's a set of good practices to ease maintenance.
Very good post that should help people focus on what really matters.
This is the hardest part of the job, because we want to produce meaningful code that can be reused without cluttered blocks, but it's not 0 or 1, not "ultra bad Spaghetti" vs. "super clean wizzard" stuff.
Exactly - that was the whole intention of the post. Clean code isn’t a binary state or a moral judgment; it’s a set of practices meant to make maintenance easier, not a goal in itself.
And like you said, it’s all about common sense. We’re always balancing readability, reuse, and pragmatism - it’s never “perfect wizard code” vs. “pure spaghetti,” it’s everything in between.
Thank you for such a thoughtful comment - you captured the nuance perfectly. 🙌
Terrible pedagogy has led to terrible programmers, i.e., ignoring the reality of Von Neumann
Language matters. It is hard to write bad declaratives to the Hare compiler for its job to write op codes.
Interesting point - and you’re right that language and the underlying machine model shape how we think about code. But even with perfect pedagogy or perfect abstractions, humans will still write imperfect software. That’s just the nature of creative work under changing constraints.
In the end, every language - from Hare to the most high-level frameworks - still relies on clarity of thought more than anything else. Tools help, models help, but the human element is always the limiting (and beautiful) factor.
Thanks for sharing your perspective - always good to be reminded of the deeper layers beneath the abstractions. 🌿
Rightly viewed, programming is resource engineering. It is creative only in the sense of inventive under constraint, the execution physics of the machine.
Pedagogy, even for compiled langs these days teaches from the view of correctness = mathematical purity. Thus, ALL comp sci dept eggheads bring a false view.
Their siren leads directly to inefficient and unpredictable systems. Effect follows cause.
What they focus upon: Does the output match the mathematical model?
What reality demands: How long did it take the CPU? How much of the address space did it consume? Is the time/memory cost predictable and minimal?
Unconstrained abstraction is delusive.
Mathematical purity has given rise to poorly designed languages-ones that abstract away the machine's physics: hidden garbage collectors, unpredictable heap allocation, and implicit memory copying. Sure, you can get systems that are logically correct but physically unpredictable.
Aviation engineers can not afford to abstract away thermodynamics. Planes would fall from skies. Civil engineers ignoring gravity would give to us collapsing bridges.
Terrible teaching. Terrible languages. Terrible results. Effect follows cause.
Hardware is a tough master.
I have to say - I genuinely love your comments. This is exactly why I enjoy writing these posts: the discussion that follows is always a hundred times more interesting than anything I put in the article.
And I completely understand your point of view. The closer we are to the actual constraints of the machine, the more predictable and efficient our systems become. That mindset is becoming rare - and in the age of AI, auto-generated abstractions, and tooling that hides more and more underneath, it’s only going to get harder to preserve.
But that’s also why insights like yours are so valuable. They remind us that beneath all the layers, the physics of the hardware still rules everything.
Thanks again for sharing your perspective - I’m honestly enjoying your entire thread here.
In 10 years, AI will be generating Op Codes. The future language will be a highly declarative structured English wielded by systems level minds, not coders. AI will be lording over the execution physics.
Programmers, er, "engineers" are going buh-bye as are both 3 GLs and 4 GLs "creatives".
Corporate language wars will be nerd campfire stories from grandpas:
"Back in my day, Suzie, there was Java vs C++, because Moore's law made PCs faster and that made running Microsoft's perpetually shitty OS faster, which let them eat into Sun's workstation biz. Then there was C# vs Java or as grandpa says,' Empire Strikes Back'. Then came Rust (Amazon) vs Go (Google). It was the latest masquerade of Complexity World lock-in, i.e., as they brought back 1960s time-sharing rebranded as "the Cloud". Funny, the major time share firm of the 1960s, IBM, the firm that gave the world FORTRAN, failed to offer a dedicated language for IBM Cloud.They even supported COBOL! The Empire allowed a polyglot of a mess on their time sharing service."
I've been in this field 25+ years across multiple countries and industries.
The number one truth I’ve learned: nobody writes clean systems either.
Architecture always drifts toward entropy. Code rots in silence.
The only real skill is learning how to build things that still work when the original author has long forgotten how they work.
Thanks for writing this — people need to hear it without shame.
Thank you so much for this perspective. I completely agree — entropy is inevitable, and “code rotting in silence” is such an accurate description. If this piece helps even a little to take guilt and shame out of the equation, that’s already a huge win for me. Really appreciate you sharing this.
Great read—and I'd push back slightly on the framing.
In my experience, developers don't actually obsess over "clean" code. What we're really after is secure code. Clean is about readability and maintainability. Secure is about resilience against attacks, input validation, memory safety, least-privilege principles.
The tension: clean code is easier to measure and teach—you can point to linters and style guides. Secure code requires threat modeling, domain knowledge, and often less elegant patterns (verbose error handling, redundant checks, defensive logic that looks paranoid).
Teams under deadline pressure default to "readable" because security feels like an afterthought—until a breach makes it the only thing that matters.
But here's where I'll push back on myself: messy code hides vulnerabilities. Attackers thrive in complexity. You can't secure what you can't reason about.
So maybe the real hierarchy is: clean enables secure, but secure defines success.
Thank you so much for this perspective - I really appreciate the depth of your comment.
And I agree with you. I actually worked in banking for a while, so security was absolutely at the top of the priority list for me as well. Clean code is great, but secure code is non-negotiable, and it often forces you to make choices that aren’t “elegant” in the classic sense: extra checks, defensive patterns, more verbosity, more guardrails.
But that’s exactly the core idea of my post: different developers - and different industries - define “clean code” through completely different lenses. For some, it’s layers of abstraction and architectural purity. For me, it’s code that is understandable, maintainable, and yes, secure.
Readable code makes secure code possible. And secure code is what ultimately matters.
Thanks again for sharing this - loved your framing and the nuance you brought to the discussion.
That's true. In real world software development need to make profit for the business. We compete with times and budget. The fast you can get into the market, you're have more chance to success.
Ship fast, is a must. You can see which one is a junior developer writing code, and senior it's self. That's why we need to define the architecture, design first. Then follow with the technique and consistency across team.
At least, we can set the codebase following the standard.
Absolutely - I agree with you 100%. Good architecture, clear standards, and consistency across the team are incredibly important. In a perfect world, that’s exactly how things should look.
But as I wrote in the article, the real world isn’t always that clean or predictable. I know a project where a senior engineer introduced solid standards and planned a big refactor… and then the project got moved under maintenance and sent to a different department. Two juniors inherited it because they “just needed to fix a few things,” and they ended up spending a year doing their best with what they had.
So I try not to judge legacy code too harshly until I know the story behind it. Most of the time, it’s not caused by bad developers - just shifting priorities, pressure, and reality.
I'm caring less and less about how GenAI writes the code. Because it's only a short number of years before they can out code me anyway (and that's a cool problem to have). Rather, I'm more interested in wrestling with the AI to negotiate the contact for the code it is going to write for me. Spec-driven development is the way forward.
That’s a really interesting way to look at it - and I get the appeal of spec-driven development. As AI gets better at the “typing,” describing intent definitely becomes more important.
But the funny paradox is that the most precise, unambiguous and complete specification format we’ve ever invented… is still code itself 😄
That’s literally why TypeScript won - because executable, strongly-typed code is often a clearer spec than any written document.
Same with tests: they are executable specifications.
And formal methods exist for exactly this reason - to express intent in a form that machines can verify, not interpret.
Even today’s AI systems illustrate the same point: their best input for generating better code is… more code. Not prose, not natural language, but highly structured, explicit logic.
So I think we’ll keep swinging between higher-level specs and the reality that code itself remains the ultimate source of truth - just executable.
Either way, I totally agree that the future is about collaborating with AI instead of fighting it. That part feels inevitable.
"the future is about collaborating with AI "
I don't think everybody 'gets it' yet :) But those of us that do, I think, I pushing the envelope pretty hard. I mean, seriously, Agent Mode only came out in April and that was ground breaking. Opus 4.5 is absolutely blowing me away wth it's ability to help me understand a massive legacy codebase so that I can then go "ok, cool, now write me the tickets that deprecates that old API"
Napkin math says today I saved the company at least 2 weeks of doing things the 'old fashioned way' :)
I'm moving away from rules and more towards research files in markdown. I just ask the AI, hey can you summarise all that info in a markdown file in a way that quickly gets the AI up to speed in a new context window. I am having a LOT of success with this method.
Absolutely - I feel the same way. AI is incredible for getting up to speed in a huge codebase and helping us make better decisions faster. In many cases it really does save days or even weeks of digging, mapping, and trying to understand how everything fits together.
But I also think we’re still in that stage where we need to stay a bit cautious. Some older systems are so spaghetti-like, with decades of hidden edge-cases and tribal knowledge, that AI simply isn’t “there” yet to fully grasp all the nuance. Sometimes the model confidently explains something… that hasn’t been true since 2011 😄
Still, when you pair a sharp engineer with a capable AI, the results feel like actual magic. It’s such a powerful combo - the machine accelerates the exploration, and the human keeps it grounded in reality.
I’m loving hearing how others are using this workflow, so thank you for sharing your approach!
l like your article all the time. Well done:)
Thank you so much, Benjamin! Always appreciate your support 😊
you are welcome Sylwia :)
There are two meanings to "clean."
One is "having low cognitive load," and the other is "having low technical debt." Therefore, instead of relying on the abstract concept of being clean, we should focus on reducing cognitive load or technical debt. Writing code that reduces these will make it clean.
...Though, of course, that's easier said than done! Cognitive load can be reduced through a common language, which means we need to define that common language (this is precisely what domain-driven development is about). Technical debt, meanwhile, is the gap between the ideal and the implementation. Since the ideal, starting with the requirements, keeps "changing," focusing solely on the implementation doesn't hold much meaning.
Still, as an engineer, I believe we should strive to reduce these burdens as much as possible. The devil is in the details. There’s also the fable of the tortoise and the hare. By writing with the intention of reduction from the start, like in shift-left practices, we can avoid losing momentum later on.
Thank you for this incredibly thoughtful breakdown - I genuinely loved reading it. Your distinction between low cognitive load and low technical debt really resonates with me. I’ve felt that tension so many times in real projects, especially when requirements keep shifting and the “ideal” moves further away every week.
What you wrote about common language and reducing mental overhead is something I’ve seen play out in teams over and over again. When we’re not aligned on concepts, even the cleanest code becomes heavy. And when tech debt grows faster than features, even elegant solutions feel fragile.
That’s why I personally lean toward the simplest approach that reduces both the thinking burden and the future pain - even if it’s not perfect. It’s the only thing that consistently helps me stay sane through migrations, refactors, and constant change.
Really appreciate you taking the time to share this - it adds so much depth to the conversation.
The broader the abstraction, the harder it is to have the same interpretation of the concept.
Clean code should be easy to read, the main problem there is if you don't know the domain language it can be hard to read.
Clean code should be easy to understand, if you don't know the problem the code is fixing it is going to be hard to understand the solution.
Clean code should be easy to maintain. Some people find OO easier than functional.
I think the main take away from the clean code concept is write code you don't hate working with for a few years. If it lasts longer you done a great job.
Absolutely agree - that’s exactly the point I was trying to make. There isn’t one universal definition of “clean code,” because everyone interprets abstractions, readability and maintainability through their own experience and their own domain knowledge.
For me, the best approach is always: keep things as simple as they reasonably can be.
And yes - balancing abstraction is a huge part of that. Sometimes duplicating a small piece of code is actually cleaner than building a super-generic, hyper-abstract layer with five configs and seven properties. But of course, some people consider duplication the ultimate sin 😄
In the end, writing code you won’t hate in two years is probably the most practical definition we’ll ever get.
why are you making banger after banger like this
I can’t help it, the dev world gives me endless material 😂
Honestly, I completely agree with this. No one writes perfectly clean code on the first try. Most of the time, the “clean” version is what we end up with after refactoring, fixing mistakes, and understanding the problem better.
Real-world coding is messy — we experiment, rewrite, delete, and patch things together until it finally makes sense. Clean code is more of a goal we move toward, not something that magically happens right away.
At the end of the day, what matters is writing code that works, learning from it, and improving it step by step. Clean code isn’t a starting point — it’s the result of iteration.
Thank you! I completely agree - clean code really is more of a direction than a starting point.
And honestly, that’s the beauty of it: code is never so good that it couldn’t be a little better 😉
Iteration, refactoring, learning - that’s where the real “clean” happens.
Great article!
However, notice that "elegant", "consistent",... etc. these are not definiton s per sa. Yup there are more than one definition out there, but they don't conflict. In contrary, they complete each other.
My favorite is Grady Boochs: "Clean code is simple and direct. Clean code reads like well-written prose...".
Thank you so much for the comment!
And yes - that’s exactly what I meant when I said there’s no single definition of “clean code.” All these descriptions - elegant, consistent, simple, readable - don’t contradict each other, they just highlight different angles of the same idea.
And honestly, “reads like well-written prose” is also pretty far from being a definition 😅
It’s poetic, sure - but still more of a vibe than a spec!
Hello Sylwia, I've added you on Linkedin, I like your blogs as they're really transparent and honest, because it's true clean code doesn't exist lol.
I'm reading Clean Code book by Robert C. Martin, and working on my MVP, being honest this book it's really nice and good to learn more about Clean code, but, projects aren't perfect, however, I think if we follow certain rules for names and create functions that are easily to understand and not making them fancy it's the best way when starting a project, because later on we'll need to migrate them to a new technology or perform a refactor, so if we have an easy function that we understand it saves hours for us and we can improve the functionality and performance of that fuction, just as an example.
Thank you so much! And thanks for connecting on LinkedIn as well 😊
I’m really glad you enjoy these posts - I try to keep them transparent and honest, because (as you said!) perfect clean code simply doesn’t exist.
Clean Code is a great book, and Robert C. Martin makes a lot of valuable points. And I totally agree with what you're saying: following simple, clear naming rules and writing functions that are easy to understand pays off especially later, when you have to migrate, refactor, or onboard someone new.
Even small improvements in readability save hours (or days!) when you return to the code months later. So yes - clean code as an ideal is impossible, but cleaner code is always worth aiming for.
Thanks again for the thoughtful comment! 🙌
Ha nice article made me chuckle. Clean code (and LEAN code) is "less is more" for me, its about not giving myself a headache months or years later and making other people smile when they see what I created, not drown in cortisol.
It should be code that is easy to understand but well structured, often spread out across files its about reducing cognitive load and initial complexity (that is often hidden away through abstraction and pattens like SOLID plus other goodies).
Haha, exactly 😄
“Less is more” is such a good way to put it - especially the part about future-us not drowning in cortisol. Reducing cognitive load and making things understandable for the next person (or ourselves) really is the whole point. Thanks a lot for the comment, loved this take!
Hi, thanks for your input. And especially the example of the code reviewer who was so picky that he defeated the whole purpose of code review, by associating code review with pain.
The question you are asking, about where to stop, when we are cleaning up what we produced, has been a very old and fundamental quandary for artists, especially writers and painters.
Every day, I ask myself the question: do I need to stop here, or do I need to go further?
I agree that perfection is not what we are aiming for. Once a painting teacher gave me the maxim that "'better' can be the enemy of 'good'". I never forgot that.
In the business world, it translates as "the law of diminishing returns".
We need to strive for quality at all times; but there is a point where it's just not going to be worth it, because it won't make any difference in practice and nobody will care. That's the moment to resolutely say "that's it".
I really love the comparison to painting - it resonates with me so much. I always say that good code is a form of art in its own way. And just like in art, there’s probably no such thing as a piece that couldn’t be improved just a little more.
What makes software even more complex is the human side: painters work alone, but we work in teams, for people, under constraints, and inside organizations. So that saying “better can be the enemy of good” becomes even more true in our world - especially when the business is waiting and the clock is ticking.
Thank you for sharing this perspective. It adds such a thoughtful layer to the conversation.
hi, thanks for sharing.
I can relate to this, and i think all the items are quite correct.
I believe, yes, as you said, we should pursue for clean code, not feel too bad for the cases we could not manage, and yes, it is a direction and a roadmap, maybe which will not reach to a destination quickly.
Humbly, i would like to add another very important aspect: creating a decent/scaleable architecture...
But then, i am sure that one (maybe you) could write a similar post on this too. The problem is, i believe, a bad architecture might be harder to be sustained, especially if the project is big.
Thank you so much for this lovely comment - I really appreciate your perspective. And yes, I completely agree: clean code is more of a journey than a final state. We aim for it, we do our best, and sometimes real life pulls us in other directions - and that’s okay.
What you said about architecture really resonates with me. I’ve worked on projects where a solid, scalable architecture made everything feel effortless… and I’ve worked on others where a weak foundation made even the smallest change painful. Bad architecture truly becomes a long-term burden when the project grows.
Honestly, you’re right - this topic probably deserves its own post someday. Maybe I will write it, because it’s something I’ve seen play out many times in real teams.
Thanks again for sharing your thoughts - I genuinely enjoyed reading your comment. 🙌
Preach! Most of us aren’t writing ‘clean’ code — we’re writing ‘survivable’ code. And that’s okay. It’s the art of knowing what to leave messy and what to refactor later. Great read!
Totally! “Survivable code” is the perfect term - not pretty, but it lives long enough to ship the feature 😄
And yes, the real skill is knowing what to leave messy and what to clean up before it bites you later.
Thanks so much for reading! 💛✨
Wow, that’s honestly inspiring… kinda makes you see coding as more of an art than just strict logic. I love the idea that even little mistakes can turn out to work in your favor—it’s like life, but in code.👌
Thank you! I really love that perspective - coding is part logic, part art, and sometimes the “happy little accidents” teach us the most. 😊
Honestly this is the most comforting truth in software engineering 😄
Every time I open an old project, I go through all five stages of grief in about 10 seconds… and then remember, “Ah yes, this is normal.”
Clean code is basically like clean rooms on Instagram - everyone posts the aesthetic version, but behind the camera there’s a laundry chair, 17 tabs open, and a function named final_final_reallyfinal_version3()
We’re all just trying our best in the chaos. And somehow… it still works 🙃
I love this comment 😄❤️❤️
I’m crying at the Instagram comparison - it’s painfully accurate!
And honestly, who among us has never had a file named final_final_reallyfinal or a commit called “fix previous fix”? Can you even call yourself a software developer without at least one of those? 😂
Love this. Clean code isn’t a destination—it’s a moving target that shifts with deadlines, business pressure, hacks that worked, and ideas that aged. Every real project has chaos hiding under “quick fixes” and “we’ll refactor later.” The trick is aiming for clarity without pretending perfection exists. We’re all just trying to make tomorrow’s mess a little smaller than yesterday’s.
Absolutely - I love how you phrased this.
Clean code really is a moving target, shifting with deadlines, pressure, and all the little “we’ll fix it later” decisions every project hides.
At the end of the day, we’re all just trying to make tomorrow’s mess a bit smaller than yesterday’s - and that’s already a win in my book 😄
You all have the easy solutions and never learned how to code from your experience ☝️ pizza slap 🍕
Haha I’ll take the pizza slap - thank you 🍕😄
And true, everyone learns differently. Experience just takes many shapes these days!
respectfully, i do
Totally fair 😄
Respect accepted!
I do clean code, tnis is my example below
Haha alright, you got me - I stand corrected!
Clearly you are the one true exception 😄👌
Sylwia Laskowska, **“I really like the honesty in this piece. It captures something every developer eventually learns: clean code is more of an aspiration than a reality. Real-world projects are shaped by deadlines, shifting priorities, quick wins, and human limitations. It’s comforting to hear that even seasoned engineers deal with messy corners, strange hacks, and ‘temporary’ fixes that outlive everyone.
What stood out to me most is the reminder that clean code isn’t perfection—it’s a direction. We do our best when we can, we compromise when we must, and we try not to beat ourselves up for the chaos that naturally appears over time. This was a refreshing, relatable take on what building software actually feels like.”**
Thank you so much! 😊
And yes - that’s exactly how it is. Even the best engineers run into these traps. Changing requirements, deadlines, growing complexity… it all leaves its mark. Everyone more or less knows what “ideal code” should look like, but we simply don’t live in an ideal world.
So we do our best, stay kind to ourselves, and keep moving forward. 💛
Great write up
Thanks so much! Glad you enjoyed it 😊
Right!
Clears throat. Actually, we have hundreds of thousands of users who do. Writing clean (high-quality and secure) code doesn't have to be painful if you use the right tooling.
Thanks for chiming in! Tools can definitely help, as long as they support the team’s workflow rather than complicate it. At the end of the day, clean code is still a mix of tooling, habits and human decisions 😊
Make it work! If it works...leave it as is and move on to the next one even if the code smells like rotten cheese :P :P
Hahaha but we can’t torture our future selves that much 😆
A little love for the next developer (even if it's us) goes a long way!
Haha, totally agree, just teasing! 😄 Sometimes we overthink or overanalyze code that already works, simply because we feel it could be made ‘better,’ clearer, or more professional. And in the process, we forget the most important part: it already does exactly what it needs to do. If it works, sometimes the best improvement is to leave it alone. :D
Thanks for the inspiring take! It immediately got me thinking - when is it worth refactoring, when is it not, and when do we need to treat legacy cleanup as a bigger, intentional initiative instead of a quick pass?
Uncle Bob’s “boy scout rule” flashed through my mind… and then I realized this is easily a whole new post, not just a comment 😄
But yes, I completely agree - when the code is “good enough,” sometimes trying to make it perfect does more harm than good. “Better is the enemy of good” really applies here!
Raw truth: clean code is a myth we all nod along to — most of us just scramble to ship features under deadlines, and that’s okay.
So true! Deadlines, manager wars, frantic attempts to understand the domain… and we still just do the best we can 😄
By the way, I checked your profile - great articles!
Thanks for the advice, I have several years of experience as a software engineer, but I always remain humble and try to learn every day from excellent professionals like yourself in the field. 👍🏼
Thank you! 😊 And honestly, that mindset is what really matters. No matter how many years we have in the field, we’re all still learning - different projects, different constraints, different trade-offs every time. That’s what actually keeps this job interesting. 🙌
I like this, and it's very true.
Thank you! I appreciate it - and yes, it’s definitely a shared experience.
Excellent! I will share it in my newsletter :)
Thank you so much, Kevin! I really appreciate it - and I’m honored it made it into your newsletter!