Okay - first things first... I am in no way anti clean code, and I'm not saying it is necessarily a bad thing.
However... in recent years it seems to be becoming more like a religion - with overzealous 'experts' preaching it to the young faithful as the 'one true gospel', and condemning those who dare to speak against it as heretics. This is more like a cult, and is profoundly unhealthy for our industry.
But, isn't 'Clean Code' a good thing?
Yes, and no... depending on what you take it as meaning.
The word 'clean', in relation to code quality is obviously subjective and can mean wildly different things to different people - but I think we can all agree that the core of what is intended is:
Code whose purpose is clear to most who read it.
If we leave it there, that is a noble goal and will have many obvious benefits.
'Clean Code' starts to become a problem when its proponents treat it as a series of dogmatic commandments, rather than as a 'pirate code' that is more like 'guidelines'.
Why is this lowering developer quality?
Well... and this is just my personal theory - it seems to have created a mentality where:
The code should be understandable by the most junior dev in the team
I've actually heard this said in some places I've worked, and I've seen similar sentiments echoed online by 'expert' tutors. But, just think it through... if we adhere to this mentality then everything becomes a race to the bottom. We would actively seek to dumb down code to the point where it is more like an introductory reader for a five year old, than an elegant, nuanced work by a master author.
Advanced concepts in languages are deemed 'too difficult' or 'esoteric' without explaining anything about them - they're just swept under the carpet, or filed under 'do not use'. The overall result is a shrinking knowledge of the languages, and of programming techniques and concepts in general. If an indoctrinated new developer comes across any of the 'forbidden' items, they will often dismiss it as bad code and may even seek to replace it with something 'better' that adheres to the clean code commandments - sometimes unwittingly sacrificing objectively faster, more efficient, flexible code with something inferior.
The scary thing here is that the new developers do not know what they lack. They then become senior, and start preaching the same 'correct way' to the next crop of inductees - perpetuating and compounding the problem.
How do we fix this?
I think the best way is to change the way people are learning to code. We need to move away from 'you too can be a developer in 3 days - here's how' type tutorials that jump straight in there and show you how to do specific things in specific ways, and move back toward teaching people about the languages themselves, their features, and how to use them to convert your thought processes into functioning programs. The next step would be encouraging people to build for themselves - based upon what they've discovered and learned. After this they will be well versed in how things work and at a great point to start understanding existing codebases in their own way, and evaluating for themselves (maybe with some guidance) which techniques are better suited to different situations. Learning in this way will bring a much fuller understanding - resulting in much more competent, and - more importantly - creative developers.
To make an analogy, I believe modern teaching of software development has become too much like modern Lego; it used to be that you just had a huge tub of bricks, and you used your own ingenuity and inquisitiveness to firstly work out how all the pieces 'work' and fit together... then use your imagination and creativity to build the things you wanted to build. Nowadays, it's all single Lego sets with specific instructions, movie tie-ins etc. The instructions are followed unquestioningly, everyone builds the same 'cool' things. The joy and benefit of learning and creativity is lost - replaced with the instant gratification so desired in modern convenience culture.
Let's stop the rot, and bring back to software development what is being lost:
- Joy
- Curiosity
- Discovery
Cover illustration courtesy of Danny Sapio
Latest comments (31)
You should provide some examples, this is all a bit vague and fuzzy ...
Where I agree is that we shouldn't dumb things down to the extreme, by leaving half the features of our programming languages unused ...
Where I don't agree is that we we should strive to inject as many obscure features into our code as we can, just to make it more "terse", or to prevent our senior devs/rock stars/ninjas/code magicians from "getting bored" ...
Readability and maintainability should be number 1 - ALWAYS.
Whether you call that "clean code" or not doesn't really interest me.
So, do I agree with the jest of what you're saying here? I don't know ... I'm not sure ... and that's the "problem" I have with this article ;)
Nice post!
I myself have used some time trying to figure out what would be the best way to write βcleanβ code. And I agree that readability should not make devs with high level of expertise downgrade their code just to make anyone understand, resulting in newer devs not learning more efficient and effective approaches of how to accomplish something.
You seem like someone with a lot of experience and I would like to know if you could recommend some good books that have helped you learn to come to the level that you are at now?
To be honest, no books really stick out in my head as ones that really taught me a lot about programming - I've read many and have written code in many different languages from low level assembly language to super abstracted modern languages
I'm entirely self taught (starting aged 7), with most of the learning just coming through curiosity and discovery. I always treated programming kind of like Lego. I learned how all the "pieces" fit together (using some initial guidance from the BASIC manual that came with my 48K ZX Spectrum), then I just built stuff that came from my imagination, often being inspired by program listings that I would type in from magazines, or kids computer programming books that I got from the library or for birthdays/Christmas. I think all of this gave me a solid foundation to build on, and very much a 'play' type attitude to coding. I carry this through with me to this day - following paths and technologies that interest me (rather than what's cool), trying things out, pulling things apart to see how they work, and most of all... doing things in my own way - preferring to work things out for myself rather than blindly following tutorials. I've always found this to be a much better way to learn, and find that a deeper understanding of concepts is gained. I guess I've also been very fortunate to grow with all the technology - from the first real affordable home computers back in the early 80s, through to the internet age we now live in.
I will always remember the classic Usborne Computer Books - not sure I ever owned any, but I certainly borrowed them extremely frequently from the local library! π
Some other books that inspired me:
I guess my main advice is that - for learning - don't treat programming like an important work skill or an academic subject - enjoy it like a toy!
Since Lego moved to selling specifics rather than generics, they have become one of the most successful companies in their market; I thing that is relevant plays against your proposal; namely teaching Why without any/enough How is not going to make any money. Business today and the need for code to be written means we don't have the time to wax-on ,wax-off learn the fundamentals; we just need to get something working. Not saying it is right or good it's just reality
Ever heard of startups havocing due to technical debt they cant make the time to fix? Been in a few π most people shipping shit are consultants or bureau devs, most people discussing performance work in hardware and most people preaching style work in open source or with licensed long maintenance/evergreen software.
These perspectives are worth considering when entering a thread like this.
It is much like discussion workout routines with a sportsman, a strength athlete, a bodybuilder and a gymnast π
Funnily enough, Uncle Bob writes in one of the first pages of the Clean Code book that what he defines as clean code is one of many schools of thought and explicitly says that its rules and preferences should NOT be regarded as absolute. Something I heard from the mouth of no clean code hardcore supporter...
Reminds me a lot of the "A rant on change" article I wrote a while ago.
Although part of me wants to be careful about labelling anything new as inferior to the way we used to do thingsβ’, but at the same time, I see enough evidence that this is really hurting the software world that I'm inclined to think this isn't just me being a grumpy old dev (I'm not even really old tbh) and more just an actual problem that should be fixed somehow.
41:00: "so most teams actually like the idea of normalizing in fact some of them like it too much where if you have a creative idea of doing things differently, βoh I don't want to rock the boat, I don't want to do my own thing here or go off the reservationβ, so instead we tend to just gravitate towards the lowest common denominator on a lot of teams and that's not goodβ¦"
"The code should be understandable by the most junior dev in the team"
I have some issues with this. Say 5 years ago I would have fully agreed with you on this topic. Clean code for me was defined:
1) does what it says without surprises (mostly surprising side-effects)
2) is easy to read for everyone fluent in the language
3) is careful with used ressources ~ "efficient"
I think so far we are on the same page.
But I changed my attitude towards (2).
I agree upon that is not the goal to have. But today I would say
2) is easy to read for everyone in the audience
Which is a small change, but with an interesting impact:
Say you are working with a high skilled team there is no reason to hold back some knowledge. You are fluent in x so use it up to its full potential.
If you are publishing your code for your own behalf there is no reason anyway to hold back knowledge.
But if you are working on a team where others have to read your code the mentality of "when you do not understand quality code you are a low quality developer" does help nobody it only feeds your ego. The problem is not having a low quality team but you being a blocker in the team, because you cause extra work. I changed my perspective due to an experience where I supported another senior developer getting his project out of the door. The project was overdue. I knew newer language features the other did not at the time. So it was natural for me to put my knowledge to work. But what happened? I wasn't there when my code broke and he had to fix it. Instead of fixing the code right away he was forced to learn the new language features.
Of course you could argue with educational debt on the companies side - and you would be quite right with that - but this is of no help, when you are in a hurry to to fix just a simple bug.
So: Yes, it would be easy to blame "low quality developers", but it doesn't help the team. Sometimes there is even no time or money to educate your team.
Write for your audience - and if you are the only senior then it would be better for the team you write junior level code than to foce every other developer to adapt to your level. If that feels wrong, maybe you are in the wrong team?
Yup, it's a fine balance... but in recent years I do feel the balance is being lost - at least in places where I've worked
Those who preach simplicity at all costs sometimes consider what you describe as pure elitism, while it is not the case.
You can cut "junior" and the same statement may look way less ridiculous if you consider "ninja" hacks, over complicated loops and other fancies that do not bring much more value or better performance.
It's quite the same with too much abstraction that ends up in a dead-end, and you have to rewrite pretty much everything six months later, which always makes me laugh as long as I don't have to dive into it π€£.
Don't get me wrong with this comment. Complexity is part of the job and the joy ^^. I agree with most of your points but I just find complexity is quite often used inappropriately.
There are some good points in this article. Specifically, I agree that many new developers know how to do some things (by doing tutorials) but lack the understanding of the why.
Moreover, we need to let developers think through things for themselves.
It is a complicated problem with that no black-and-white solution will fix.
My suggestion would be that we have clear standards for junior developers to follow. Letting them go off an do their own thing won't really invoke creativity but a mess. There is a period of time where they just need to trust and absorb from others more experienced. As they mature, you can allow them to be more influential on coding standards, let them think on their own. You may even want to have a supplementary codebase, or a portion of the codebase, that it more lack to see what those developers come up with apart from the current standards.
Order and consistency in a codebase is more important than anything. However, the focus of clean code should be to the end of reducing complexity, which may or may not improve readability--often it does.
In a word, clean code almost always will provide higher code quality than no coding standards. However, that does not mean that there aren't some gaps that we have to be intentional to fill in to get the most from it.