If some legacy project don't try at least using clean code then it is a good indicator of death trap job. I am wrorking one of that. ... at least this job cannot steal any AI.

Interesting thoughts, and I agree on some level, but it's a balance.

I try to write clean code from the start, but I don't force it, because sometimes you just need to write something down in order to really understand the solution needed. Local messiness is ok in that case, and as soon as I know it works I clean it up: refactor parts to other functions, move functions together that belong together, refactor functions to a class so that I don't have to pass the main object that is "now" clearly being passed around all over the place, use AI to add type annotations and tell me if there are obvious bugs.

What I mean by local messiness is that on new code, I don't let the whole code get messy, as soon as a function is "figured out", I clean it up. As soon as I see that several functions make sense to move into a class, i do it.

I don't obsess, but as a tech lead I lead by example and I can't ask others to produce decently clean code if I don't.

I write code assuming that in 6 months it'll either have to be understood by my colleagues or re-understood by me. And since at that point I will likely need just a fix, I really don't want to be thinking, "oh gosh this is so messy I really need to refactor as part of this fix", I want to minimize how much of that I need to do so I don't introduce new bug.

I have to say, here is a very good filter to ask at your next interview: do you have refactoring tickets, how often? If the answer is that they don't, they only refactor as part of fixes or "when they have time" (read never because when is there nothing to deliver), then they are not a team I'm interested in. Unless of course they say "we really need someone to help us get better at that".

Anyways thanks for a nice article.

It sounds like you haven't read Clean Code. In the book it says that code should as far as is practicable be self-commenting and hence comments should not be needed in the majority of cases.
Also nowhere does it mention such fripperies as dashes around comments.
I get the email thing (who would not want an empty inbox?) but it's a poor analogy as your inbox tidiness largely affects only you.

Totally agree, follow the flow however have your body/heart/mind align and focus on what's important, that's the key.

Yeah, I really feel this - sometimes you just gotta push forward and not let all the code-polishing slow you down.

What I learned working at a company where we maintain about 200 repos, some are decades old and some were created literally last week:

Too many people passed through this codebase. Each coded in their own way in the past. There were no guidelines. Even the language chosen for the code sometimes is different as we are in Brazil, but some people insist coding in English (even though some don't understand English very well and make mistakes)

Since the pandemic, when we had a sudden boom in repo creation for obvious reasons, we defined internal guidelines and put some order in the chaos. One of them is regarding clean code.

But when you have tens of devs it's still quite difficult to keep it tidy. We then introduced code review to try help with it. The code review regarding clean code was more of a means to educate the dev on how they could have done something better than asking them to change their structure, but they are free to refactor it if they have the time. Over time it made the overall code much better.

Some devs love refactoring like you said. There will always be this one guy who will refactor 5k lines of other people's code before he can start his own task, which can lead to bugs in portions of the code that aren't going to be tested. We don't encourage this sort of thing.

What we tell them is if they are not familiar with one specific repo, they take a look into its structure. If it's the familiar structure we defined, do it according the guidelines. If it's not, try to infer the overall structure it was written on, taking examples on similar functionality that's already there if possible. If it's in English, keep writing in English. If it's in Portuguese, write it in Portuguese.

We don't always have time for refactorings. But when we do, it's usually targeted at those older legacy projects that are on a different stack we currently work on. Many of the new "last week" creations are there to substitute the decades old code that became really difficult to upgrade for security reasons and are still open to be used outside the intranet. These are treated as fully new code and have specialised teams working on them.

The idea is that if the code you were told to work on is an old mess, you shouldn't stress out about refactoring the chaos.

Did the author really “let go” of Clean Code?

The title at least claims so. Somewhere at the first paragraphs we read

“Leave the code in better shape than you found it.”, they said.

And the piece ends with:

“Leave the code better than you found it.”

I'm left with the impression that the only things the author really have 'let go' of are Inbox Zero and maybe the word 'shape': which is totally fine, but not exactly the revelation I expected.

Respectfully, the author doesn’t appear to have rejected Clean Code at all. What they’ve realized is that it shouldn't be followed above all else. And that’s fair. Context matters. Tradeoffs exist.

And rules sometimes need to be bent, broken, or reimagined, in order for us, engineers, makers, to really come up with something new.

There shouldn't be any 'absolutes'; not, at least, in creative work, like ours should be...

But the subtle glorification of “productivity at all costs” goes again into that somewhat misguided direction... As if procrastination is inherently bad - and not, also, something that can give us the break we sometimes need to proceed.

Thanks for sharing your thoughts. Whole point of such articles is to get everyone thinking about it.
On the topic I guess everyone have their own style of handling code written by someone else and also how they write new code. And there is always room to improve both, if you understand what you are touching.
If you don't understand then don't touch it.
If you touch something it should go through the Unit test cases existing and also new cases should be added if they don't exist.
Unit cases also help the other guys to understand the purpose of the block of code that we write.
Finally we have to be the change that we want to see in the world.. write clean code and then expect clean code from others. :P

The business context is always important for what you are doing.

That's indeed important not to refactor things for the sake of refactoring. Refactoring must add business value, not only artistic perspective.
Clean code allows you to model your domain bottom-up, which is critical, as the top-bottom approach will lack the infrastructure layers (which also need to be clean and self explanatory).
A 5000 line file is a product black box, there is no need to touch it, as most of the case you will not manage non-regression correctly as the business acceptance criteria are probably ill-documented.
So you can leave it as is and abstract it away so that nobody that is not interested does no have to read or even to see this file. That is clean code. Create a clean interface, separate concerns with abstractions, interfaces, HOF, etc... Why do you want to modify an existing code that works ?

Letting go of clean code will bite you back, as this effort conducts to domain fine graining and a general tendency to aim for quality and maintainability, basically SOLID principles are aimed.
Refactoring things without need is not clean code, it is, as said, unneeded and a waste of time and effort.

Nice article and some good points, I think. I was working as a web developer back in the 2000s and early 2010s, when it was pretty much PHP / MySQL all the way.

Many of the apps and sites I worked on were a hotchpotch of hastily written and scarcely commented scripts, something that was not all that uncommon in web dev at the time.

Sitting down and trying to clean an entire project in one go was just not possible, it took way too much time and inevitably led to more errors. This, coupled with the idea of putting multiple updated files live at the same time, led us to do as the author suggests. Clean up the existing functions as you come across them during other work.

Personally, I do agree with the zero inbox analogy to an extent. You know that there is nasty code there, you see it daily and your urge is to sort it out immediately (empty your inbox).

But maybe, as long as that nasty code is doing it's job, isn't it better to try and just live with it, safe in the knowledge that it's time will eventually come and it will get cleaned up?

Cytotec Misoprostol Online | Compre seu Cytotec Original Online

Cytotec Misoprostol Online - Venda de Cytotec Original Online. Compre agora e receba em até 24h no conforto da sua casa de forma sigilosa.

Nosso site: cytotecreal.com/

I would agree - this is reality when you have something to do. Instead of Agile I like to think evolutionary coding. Code to meet a need and keep it as simple as possible. Then enhance, as needed. The only code that is finished, is the code that isn't being used. (pretty close to being true)

Just like in evolution, the only things not evolving are the dead ends.

One of the top skills should be the ability to read code. Sort of like the issue of someone who has studied a language for years - but can't understand what is said to them. I honestly would prefer to test people on if they can understand code written by someone else - but it might be too harsh of a test - thankfully AI is helping with this.

My code tends to be clean and elegant - but I also have more than 40 years of experience... What I do now is code to make it easy to find bugs. After all, there will be. This means logging isn't an after thought, it is built in from the first. There are always going to be some bugs that won't show up except in production, and you can reproduce stepping through code (race conditions come to mind).

Sir, I think you have ignored the first rule of keeping a tidy house. If you do a little bit every day, it never becomes really messy and its easier to keep up with. How does doing that every day make it pile up? It's completely the opposite for me. I work with very large Monolithic codebases every day, and the ones no one has taken care over are generally unstable and a nightmare to add anything to. Have you never come back to something you took some care over and found it super easy to maintain or extend? There's a famout Steve jobs quote about caring what the inside looks like even though no one gets to see it. Same for code - I can tell which ones an apple and which ones a Dell, the Dells look like code no one cares about.

That's a very clever approach (not because I also do the same), because it shows the evolution of the project, the HOW it flaws. If you feel you can't find something important, refactor this exact part. Clean code is not just a set of rules, this is a philosophy of code which is easy to refactor and extend

Great article and I can totally relate. There's no doubt that "Clean Code" is more often overused than underused. I've see projects with a few simple CRUD operations done with "Clean Code" standards without any reason whatsoever. Ironically, you can make your code messier with "Clean Code" standards when used inappropriately.

Many developers are obsessed with abstracting things by default, creating more problems than they solve.

This is my endless discussion, looks like many devs instead of read and understand the intention of the book just read some blogs here and there that are summarizing the whole book.

The they stick in one or two points only: meaningful (method|var)names that become phases not words, short functions that replace a single line by another three ones appending one more call the stack and contributing to the cognitive load or abstract so many things introducing indirections that become hard to maintain later

Clean Code is a good book to read and apply with common sense and I like to mix up the ideas with A Philosophy of Software Design from John K. Ousterhout, it sounds to me a good balance to read, understand and choose what to follow and apply

I think it is essential for us as developers to practice clean coding for future readability and better maintenance. However, as time-consuming as it can be, we must embrace the utilisation of AI tools to help us maintain the code structure more efficiently. I still advocate to write code manually in our first try, but we can utilise prompt coding to ask for a better way how to optimise the earlier version of our code. For example, asking CoPilot "how would you suggest this part of code to be more efficient" can give us an insight the overlooked mistake we did during our first writing to avoid the similar mistake in the future.

"Tim Ferris' 4 hour work week got me back on my feet" - the book is a fraud. Take a dash of skepticism before mentioning it: buzzsprout.com/2040953/episodes/13...