Notes on "Clean Code" – How to Care for Code?

Click here to read my notes on the Clean Code book from the beginning. In this post, I wrote what went through my head as I was reading Chapter 1:

It Starts with Why It Matters

A French philosopher, by the name of Guillaume Ferrero, discovered the Principle of Least Effort and wrote about it in 1894 – long before a single line of computer code, as we know it today, was written. Nevertheless, I can't help but think that, had he been alive to witness how most code is written, he would have demonstrated coding as the epitome of the least effort principle:

[Coding] stops as soon as minimally acceptable results are found.

Sounds familiar? Well, I'm sure it does, because we've all been there; once we find acceptable results, there's no immediate need to improve the current solution; we just want to get the task done, get that dose of instant gratification and move on to the shiny new project. Putting out fires and plugging holes are good examples of tasks that we don't want to revisit once we found a good enough fix; that notion is a perilous inclination, of which I've been a witness (and a culprit/victim) more times than I'd like to be. It's hard to resist the temptation of instant gratification; it takes discipline, self-control, and foresight to seek delayed gratification instead. A landmark psychological study, the Stanford marshmallow experiment, found a correlation between seeking delayed gratification and being more successful in life. I believe the same concept can be applied to code: we can stop at acceptable results, and have a cookie (pun intended) to celebrate checking off a box that says we're done, or we can strive for more, and have two cookies to celebrate the fruit of going the extra mile.

But is completing a task as tempting as enjoying a sweet treat? You bet! It may even be more tempting than you think; thanks to dopamine: a neurotransmitter connected to certain feelings like reward (completing tasks), and pleasure (enjoying sweets). Usually, code requires multiple iterations to reach acceptable results; and with each disappointing attempt, the level of dopamine that gets fired is reduced; when our code works – according to our acceptance criteria (test cases) – we get a pleasant surprise: increased levels of dopamine (Schultz et al). But why are we inclined to seek a new task after finding minimally-accepted results for the one at hand? According to Hilary Scarlett in Neuroscience for Organizational Change, "[dopamine] levels rise when we experience something new"; so it's no surprise that our brains seek more dopamine by making us want to move on to that shiny new task.

Yet, a pastor by the name of John Piper, once said:

...newness is no virtue and oldness is no vice. Truth and beauty and goodness are not determined by when they exist.

I'm sure that he wasn't referring to code when he said that, but you'll see why I quoted him if you replace "newness" with "a green-field project", and "oldness" with "legacy code". We should care for the code we inherited, and the code we are writing for others to inherit someday; we should exert more effort to keep on improving all code to reach a higher level of craftsmanship than what's minimally acceptable. Michael Feathers, author of Working Effectively with Legacy Code, eloquently stated:

Clean code always looks like it was written by someone who cares. There is nothing obvious that you can do to make it better.

In order to justify that extra effort, we need to have a good reason; otherwise, our actions will fade away because we weren't inspired to fight the uphill battle against our natural tendency to be lazy (by sweeping the messy code under the rug). That's why Uncle Bob, aka Robert Martin, inspires us like great leaders do: by starting with why it matters to keep our code clean.

It was the bad code that brought the company down.

In one of his examples, he talked about a killer app that was born into short-lived success marked by software bloat; later version started crashing, so users moved away; eventually, the company vanished, and its failure was traced back to bad code! I can relate to that, and so can many of you; I've learned – the hard way – how costly bad code could be; Uncle Bob is trying to change that, one reader at a time.

P.S. Caring for code is hard; watch this TEDx talk for ideas on how to do so; simply replace "global warming" with something like "code refactoring" and you'll see what I mean: