1. You’re an author
Want to impress your mom? Tell her you’re an author! An author is someone who practices writing as a profession. Developers write all day. Yet as developers, it’s easy to forget that each line of code we write is likely to be read 10 or more times by humans during its lifetime. These humans are our fellow co-workers. They’re busy fixing bugs and adding features.
Great authors are known for writing books that tell a clear, compelling story. They use tools like chapters, headings, and paragraphs to clearly organize their thoughts and painlessly guide their reader. Developers work in a very similar system, but simply use different jargon of namespaces, classes, and methods.
Clean coders use these tools wisely to manage complexity and tell a clear story.
2. It’s foundational
In recent years software practices like professional refactoring, unit testing and TDD have received a great deal of attention. These practices elevate code quality and maintainability. Implementing clean code principles is a foundational skill that pays off especially well when it’s time to refactor code or bring code under test. Clean code principles lead to source code that’s highly modular and thus easier to read and test. If you think of these practices as part of a house, clean code is the foundation.
3. Justify your technique
Imagine you’re sitting in a technical interview. If you’re asked about your code quality, could you provide a professional and rational justification? Or would this be you?
If that’s all you can say about writing clean code, that’s a bad sign. If you’ve never methodically considered the quality of your coding style, there’s likely plenty of opportunity for improvement. Those who write clean code are able to convey many concrete activities, patterns and techniques they use to keep their code clean. After all, clean code doesn’t happen by accident. It requires a deliberate and regular focus on clearly conveying intent.
What gets measured, gets managed.Peter Drucker
Building a vocabulary around clean code isn’t just useful for interviews and elevating your own code quality. It also fosters level-headed conversations in code reviews by establishing a common vocabulary and framework for discussing code readability.
4. Reading is hard
Developers often pride themselves with their ability to solve difficult problems. However, writing code is relatively easy. Reading is hard. This is why so many developers are tempted to rewrite rather than do the hard work of reading and comprehending existing code. Since reading code is naturally challenging, if you write code that you’re barely able to follow as you write it, you’ll find you’re unable to comprehend it all later. Professional developers write so much code that after a few weeks of separation, most the structure and design decisions fall out of memory. It’s like looking at the project with a fresh perspective. Not being able to understand your own code a few weeks later can be a really depressing situation. Trust me, I’ve been there.
5. Technical debt is depressing
Writing sloppy or confusing code injects technical debt into our projects. And while technical debt can be useful when carefully considered in context, excessive technical debt is depressing and drives talent away from the organization. When the easy things become hard, developers start voting with their feet and go elsewhere. Developers derive more job satisfaction out of the quality of their work than the quantity. Technical debt decreases the chance of reuse and sets a low bar for quality throughout the rest of the code base.
6. You’re Lazy
Larry Wall, author of the PERL programming language said the three great virtues of a programmer are laziness, impatience and hubris. Yes, laziness can be a positive attribute in the right context. As I stumbled through writing code in my early years, I learned the hard way that writing clean code really pays off. Professional developers strive to be the good kind of lazy. This laziness is based on putting extra care into the code so that it’s not so hard to write up front, and it’s easier to work with later. Writing clean code doesn’t take any longer. And once you grasp the principles you can actually code more quickly because terse, expressive code that does one thing is easier to manage.
When under pressure, it’s tempting to cut corners and ignore best practices. However, as Uncle Bob Martin reminds us in his book “Clean Code“, we don’t have time to be sloppy. Being sloppy ultimately slows us down in the long-term due to the increased frequency of bugs and the long-term costs of maintenance later. History has shown it’s unlikely you’ll find time to clean it up later, so why not do it right the first time?
7. Don’t be a verb
Okay, the other reasons are solid, but this one is the clincher: Everyone knows the previous co-worker whose name became a verb to describe dirty code.
“Oh man, this code has been Jimmy’d.”
Ouch. Comments like this are the kiss of death for long-term employment prospects. We want our co-workers to recommend and hire us in future positions, right? Being known for writing clean code is a great way to assure your co-workers recommend you and look forward to working with both you and your code in the future.
By Cory House