Software consultant. Bestselling Author. Loves rum, alt culture, games & metal.
Formerly Head of engineering, chief technical architect, head principal engineer, lead dev, etc.
Location
London, UK
Work
Independent Software Consultant at Electric Head Software
"Clean code" as a discipline has only become increasingly important, software craftmanship as a movement, and it's raw commerical, politicised focus, can go get in the sea.
One of the most profound changes in my approach to software was understanding it to be literature. Functional literature, but literature regardless. Intent, characterisation, description, text, subtext, flow, rhythm, style, all effect software like they do prose.
It's a constrained form of communication, with grammar, and that's why we work in "programming languages". They are languages. With rules, idioms and quirks. These aren't analogies, it's what software is. It's storytelling. Constrained creative writing with purpose.
Basically, Donald Knuth was right, and called it a bajillion years ago - with the idea of literate programming. Today's languages are that thing. You will never be a great programmer unless you become an excellent communicator, and an excellent writer. The skillset is the same.
Critical thinking, expression of concept, reducing repetiton, form for impact, signposting, intent and subtext. If you want to understand great software, understand great literature.
Communication skills are not optional
If you want to teach a junior programmer to be a better programmer, teach them to write. Language is our tool for organising our thoughts. It's powerful. It has meaning. It has power.
I think it's best to rely on tooling and communication, both proactive, in review, and retroactive, to communicate what's desired as a team. Further, it's best to lean on your code review tools, like pull requests and merge requests, which not only preserve a record of decisions made, but also allows stakeholders to chime in.
As for 'clean code', it all depends on your approach, and your goals. If you're an OOP or FP maximalist, especially when the team is working in a multi-paradigm language like JS, TS, Rust, Ruby, Python, etc., there's absolutely many other factors to consider, than what's "idiomatic". Sure, there's an easy way and a hard way to solve a problem, and sometimes you can contribute your own thoughts and experiences. But this isn't just your codebase. It's your team's, other team's, future teams, and past teams.
Often, I find performance to be underappreciated, but performance is also subjective until it can be measured. Your tools and your review process, your communication process and perhaps even documentation process (but use sparingly, just to communicate objectives and areas of concern, rather than winding up as a maintenance sink, in addition to tests and review), are the major things you'll come to lean on.
I might also say, your approach matters, and using the term 'cleanliness' as a metric to describe code quality is highly subjective, to say the least, and not always that helpful. Linters, code coverage, unit tests and integration tests, end to end tests / smoke tests, regression tests, and most of all, team communication, are your number one guiding factors here.
I will admit, to answer the question originally stated, I regret the approach I once took in my career. I subscribed to FP and/or OOP, "idiomatic" religions, and often was adversarial when challenging the decisions of others. I've had to learn to reign it in, and provide constructive feedback and discussing higher-order goals than can just be addressed through a cursory glance at a PR/MR.
Further, it's always a balance. No single prescriptive approach works everywhere. "It depends" is better than solutioning right out of the gate. Ask more questions, and don't just jump in and do the work. Take a healthy, balanced, measured approach. To some, it might come easy. To others, like me, I've had to learn that software development is more than just writing code, however clean it may be. Much more.
Software Engineer @SciFY.
Live to learn something new -and write cleaner and more sustainable code- every day.
Passionate with learning and discovering new technologies, history, and psychology.
I used to think that clean code meant comments everywhere. Now I believe that truly clean code should be self explanatory, with comments only about "why", not "what".
I believe clean code (the book series) does have some great points, however, in real life a lot of these are hard to adhere 100%. The things that I have personally taken from these book series are writing code with meaningful variable names, function names that make semantic sense with the action they're performing, while I don't believe in 100% coverage, I do believe in testing the important parts of your application, the Pareto principle applies here in my case. Avoiding comments has been easy once I have everything making semantic sense. Taking function splitting to an extreme is one thing that I don't find particularly useful, if I can do it comfortably I will, otherwise I'm not gonna force it.
I've found great value in writing code with the mindset of a book author, I can come back to my code months later and pick up where I left without much head-scratching.
In the tech world where we have a constant struggle of egos, I'd be unrealistic to deny the value of clean code, as with many things, if you take it to the extreme its no longer worth the effort, but for developing countries that don't have as big of a tech community its a great resource to learn good principles by yourself
Clean code is code I can read. Clean code is code that any new developer can read.
Clean code is code that any developer can read, though the why may deserve some clarification from a developer experienced with the specific codebase.
Stage 1: Personal projects/university/learning:
Here I wrote code that gets used once and doesn't have to be maintained or changed once it is done. Readability here is get it done, fast. I don't judge my old self, but I can't go back to this lifestyle.
Stage 2: Early Professional Work:
Key here for me was reading Clean Code by 'Uncle Bob'. He gives a good set of rules for what is clean code but the two important ones are good variable names and shorter methods. In this stage I applied the rules without understanding why which in some cases lead to some pretty dirty code.
Also, in this stage I came across some good but a lot of really bad code. For example, I learnt why long classes were bad after having to make a bug fix on a 2000 line class (one of the scariest moments of my career).
Stage 3: Experienced Professional:
I agree with alot of the other answers: Clean code to me is readability. You spend so much more time reading than writing code. As much as possible you want to make code readable. And I would define readable as reducing the amount of thinking anyone reading your code has to do to understand it. You spend the most time reading code your so it's for you too.
Therefore readability for me is:
Good names for methods, classes, variables
Short methods: Think do one thing and one thing only
Prefer pure methods: Would define this as relying as little as possible on what is not passed into the method (but do use composition), and returning back a value rather than mutating the parameters.
Prefer immutable objects: With mutable objects always have to think in the back of your mind, has this changed somewhere else without me realising it.
Less is more: Write less code. Every line of code you write is a line someone has to understand, and a potential bug. Someone once told me "You are not paid per a line of code you write"
Tests: Testing improves readability because you don't have to read code to understand if it works.
I've come to realize that clean code isn't about getting to a perfect final state, but rather an unending process of making code easier to understand and easier to change. That can be done in many different ways, all with their own costs and benefits.
In the past, I used to think that you always had to produce clean code, no matter what.
Now, I realized that it's not possible and even bad for the business because it slows you down. You have to make trade-offs and focus both on the technical and business value of your code. Having technical debt is fine.
Latest comments (22)
"Clean code" as a discipline has only become increasingly important, software craftmanship as a movement, and it's raw commerical, politicised focus, can go get in the sea.
One of the most profound changes in my approach to software was understanding it to be literature. Functional literature, but literature regardless. Intent, characterisation, description, text, subtext, flow, rhythm, style, all effect software like they do prose.
It's a constrained form of communication, with grammar, and that's why we work in "programming languages". They are languages. With rules, idioms and quirks. These aren't analogies, it's what software is. It's storytelling. Constrained creative writing with purpose.
Basically, Donald Knuth was right, and called it a bajillion years ago - with the idea of literate programming. Today's languages are that thing. You will never be a great programmer unless you become an excellent communicator, and an excellent writer. The skillset is the same.
Critical thinking, expression of concept, reducing repetiton, form for impact, signposting, intent and subtext. If you want to understand great software, understand great literature.
Communication skills are not optional
If you want to teach a junior programmer to be a better programmer, teach them to write. Language is our tool for organising our thoughts. It's powerful. It has meaning. It has power.
It's a gift, it's for everyone. 🖤
I think it's best to rely on tooling and communication, both proactive, in review, and retroactive, to communicate what's desired as a team. Further, it's best to lean on your code review tools, like pull requests and merge requests, which not only preserve a record of decisions made, but also allows stakeholders to chime in.
As for 'clean code', it all depends on your approach, and your goals. If you're an OOP or FP maximalist, especially when the team is working in a multi-paradigm language like JS, TS, Rust, Ruby, Python, etc., there's absolutely many other factors to consider, than what's "idiomatic". Sure, there's an easy way and a hard way to solve a problem, and sometimes you can contribute your own thoughts and experiences. But this isn't just your codebase. It's your team's, other team's, future teams, and past teams.
Often, I find performance to be underappreciated, but performance is also subjective until it can be measured. Your tools and your review process, your communication process and perhaps even documentation process (but use sparingly, just to communicate objectives and areas of concern, rather than winding up as a maintenance sink, in addition to tests and review), are the major things you'll come to lean on.
I might also say, your approach matters, and using the term 'cleanliness' as a metric to describe code quality is highly subjective, to say the least, and not always that helpful. Linters, code coverage, unit tests and integration tests, end to end tests / smoke tests, regression tests, and most of all, team communication, are your number one guiding factors here.
I will admit, to answer the question originally stated, I regret the approach I once took in my career. I subscribed to FP and/or OOP, "idiomatic" religions, and often was adversarial when challenging the decisions of others. I've had to learn to reign it in, and provide constructive feedback and discussing higher-order goals than can just be addressed through a cursory glance at a PR/MR.
Further, it's always a balance. No single prescriptive approach works everywhere. "It depends" is better than solutioning right out of the gate. Ask more questions, and don't just jump in and do the work. Take a healthy, balanced, measured approach. To some, it might come easy. To others, like me, I've had to learn that software development is more than just writing code, however clean it may be. Much more.
Clean code does not necessarily relate to the number of lines of code.
It went from "important" to "vital".
If you don't keep your code clean everything will take more and more time until you clean it up.
And with everything I mean everything that has to deal with the code. Maintenance, changes, bugfixing,... But also onboarding new developers.
I used to think that clean code meant comments everywhere. Now I believe that truly clean code should be self explanatory, with comments only about "why", not "what".
I believe clean code (the book series) does have some great points, however, in real life a lot of these are hard to adhere 100%. The things that I have personally taken from these book series are writing code with meaningful variable names, function names that make semantic sense with the action they're performing, while I don't believe in 100% coverage, I do believe in testing the important parts of your application, the Pareto principle applies here in my case. Avoiding comments has been easy once I have everything making semantic sense. Taking function splitting to an extreme is one thing that I don't find particularly useful, if I can do it comfortably I will, otherwise I'm not gonna force it.
I've found great value in writing code with the mindset of a book author, I can come back to my code months later and pick up where I left without much head-scratching.
In the tech world where we have a constant struggle of egos, I'd be unrealistic to deny the value of clean code, as with many things, if you take it to the extreme its no longer worth the effort, but for developing countries that don't have as big of a tech community its a great resource to learn good principles by yourself
Clean code is code I can read.Clean code is code that any new developer can read.Clean code is code that any developer can read, though the why may deserve some clarification from a developer experienced with the specific codebase.
It evolved in 3 stages for me
Stage 1: Personal projects/university/learning:
Here I wrote code that gets used once and doesn't have to be maintained or changed once it is done. Readability here is get it done, fast. I don't judge my old self, but I can't go back to this lifestyle.
Stage 2: Early Professional Work:
Key here for me was reading Clean Code by 'Uncle Bob'. He gives a good set of rules for what is clean code but the two important ones are good variable names and shorter methods. In this stage I applied the rules without understanding why which in some cases lead to some pretty dirty code.
Also, in this stage I came across some good but a lot of really bad code. For example, I learnt why long classes were bad after having to make a bug fix on a 2000 line class (one of the scariest moments of my career).
Stage 3: Experienced Professional:
I agree with alot of the other answers: Clean code to me is readability. You spend so much more time reading than writing code. As much as possible you want to make code readable. And I would define readable as reducing the amount of thinking anyone reading your code has to do to understand it. You spend the most time reading code your so it's for you too.
Therefore readability for me is:
Readability trumps everything.
I've come to realize that clean code isn't about getting to a perfect final state, but rather an unending process of making code easier to understand and easier to change. That can be done in many different ways, all with their own costs and benefits.
In the past, I used to think that you always had to produce clean code, no matter what.
Now, I realized that it's not possible and even bad for the business because it slows you down. You have to make trade-offs and focus both on the technical and business value of your code. Having technical debt is fine.