About five years ago, I wrote a post titled “Clean Up Your Code by Applying These 7 Rules.” At the time, I was focused on writing clearer, more readable code and on sharing practical techniques that helped me improve my day-to-day work. Looking back, that makes sense. Clean code is an attractive idea. It promises clarity, maintainability, and a sense of control over growing complexity. Back then, I approached the topic mostly from the perspective of an individual contributor trying to write better software. Five years later, I still agree with the intent of that post. What has changed is my understanding of when and how those ideas should be applied. This is not a rewrite of the original article. It is a reflection on what still holds up, what feels incomplete today, and what experience added that rules alone could not. If you want to read the original version first, you can find it here. here What still holds up Several ideas from the original post aged well in my day-to-day, mostly because they are rooted in communication rather than technique. Readable code is still one of the best investments you can make. Clear naming, simple control flow, and small, focused units of logic make it easier for others to understand what a piece of code is trying to do. That has not changed, or at least not yet. The idea behind the Boy Scout Rule also still resonates. Leaving code slightly better than you found it is a healthy mindset. Small improvements compound over time, and a codebase benefits from care and attention rather than neglect. These principles work because they are not tied to tools or trends. They are about helping the next person, which often turns out to be your future self. Or create a path for some LLM to write readable code based on yours. Where my view has changed What feels incomplete today is the assumption that cleanup is always the obvious next step. Earlier in my career, I treated cleanup mostly as a local activity. I saw something I did not like, applied a rule, and moved on. Over time, I learned that cleanup is rarely just about code. It is about context, ownership, timing, and intent. Refactoring without understanding why code exists can be risky. A piece of logic that looks redundant or overly defensive might be protecting against a constraint you are not yet aware of. Removing it can introduce subtle bugs or undo decisions that were made deliberately. It can also be a costly exercise, when you come to the realization that after refactoring in, you ended up with the same solution because of these unknown constraints. I also underestimated how often technical decisions are driven by product needs, deadlines, or organizational constraints. In those cases, “clean” was not the primary goal. Shipping something that worked was. The rules were never wrong, but they were incomplete without context. What experience added Working on larger and older systems changed how I look at cleanup. Inheriting code I did not write forced me to slow down. It became clear that understanding usually creates more value than immediately improving aesthetics. I also started to see cleanup as a shared responsibility rather than an individual one. In a team, even well-intended refactoring can have side effects. Changes that feel small locally can ripple outward and affect others in unexpected ways. That is where context becomes crucial. Knowing why something exists matters more than knowing how to improve it. Principles over rules If I had to summarize how my thinking evolved, it would be this: clean code is not a checklist, it is a byproduct of understanding. Rules are helpful starting points, but judgment is what makes them useful. Sometimes the right choice is to refactor. Sometimes it is to document intent. Sometimes it is to leave things as they are and revisit them later. The goal is not perfection. The goal is stewardship, and delivering value to the customers. Closing thoughts I still believe in writing clean code. I also believe that respecting what came before is part of that responsibility. Code is a record of decisions made under pressure, with the information that was available at the point of writing it and often under constraints we no longer see. Revisiting my old post reminded me that learning is not always about new ideas. Sometimes reframing old ones can be even more valuable. In general, I can say that these rules have helped me write better code over the past 5 years, however, experience taught me when to apply these rules.

I Spent a Month Writing in Public: Here's What the Numbers Show

Checkout My Blog

Newsletter

Five Years Later: Clean Code Is Still Right (But Not Always Useful)

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

I Spent a Month Writing in Public: Here's What the Numbers Show

106 Stories To Learn About Clean Code

100 Pieces of Programming Advice from the Book Clean Code by Robert Martin

110 Stories To Learn About Refactoring

3 Things Coding And Prose Writing Have In Common According To Cory House

4 Simple Habits For Engineering Teams To Beat Technical Debt

I Spent a Month Writing in Public: Here's What the Numbers Show

106 Stories To Learn About Clean Code

100 Pieces of Programming Advice from the Book Clean Code by Robert Martin

110 Stories To Learn About Refactoring

3 Things Coding And Prose Writing Have In Common According To Cory House

4 Simple Habits For Engineering Teams To Beat Technical Debt

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps