This year I want to become a better programmer.

I realized that other than learning newer technologies and the day-to-day kind of learning you get just by doing your job, my skill level as a programmer has been stagnant.

Over the years, I’ve naturally understood and utilized some best practices like naming your variables and functions carefully and the single-responsibility principle.

My code is good.

Better than average, even.

But it’s not GREAT, and often I go too fast, leaving cleanup and other TODOs for later.

And later never comes.

So, in my pursuit of greatness, I bought a few books to start the year off and ignite the skill-up fire. I’m excited. Something about sitting back with a fresh new tech book and some coffee just feels right. Like it’s what I should always be doing. More books. Yeah. More books this year, Joe.

The first book: “Clean Code” by Robert C. Martin, otherwise known as “Uncle Bob”.

In order to improve my own comprehension of the book (I’m so selfish!) I figured it would be cool to do some summary/thoughts posts on each chapter as I read it.

So let’s begin.

Chapter 1: Clean Code

The chapter begins with a series of discussions on the topic of bad code. What makes code bad? Why do we write it? Is it really a problem?

A lot of it seems to boil down to the pressure to get the job done on time for our bosses. I know I have definitely chose to check some TODO-laden code in to source control simply for the purpose of calling it DONE and moving on to the next task.

It doesn’t feel good.

And when you or someone else inevitably has to work in that area again, the sloppy code and comments will only take more time to deal with. So in the end you aren’t saving time, you are just moving it.

This is unprofessional, and the author drives this point home by making the analogy: If a patient asked his doctor to skip washing her hands so she could operate on him faster, the doctor would know better. The doctor knows, more than the patient, that clean hands are necessary to perform the operation correctly. The same is true for us as developers. Although it is our manager’s job to push us to stay on schedule, it is our job to push back when needed to ensure the job is done right. It is our professional obligation to keep the code clean.

The chapter continues with a set of different opinions from well-known computer scientists on the question “What is clean code?”

Without going over each, the trending ideas are that clean code is:

Readable and expressive

Our code should clearly express its behavior. The author lavishly shares the idea that the code, like good prose, should flow with an obvious climax and resolution. Someone who reads your code later should think “Ah ha! Of course this is what this does.”


Less is more. Duplication of code should always be avoided. Methods and classes should do one thing well.

The exception to this would be if you are enhancing readability in an otherwise complex algorithm. Sometimes being more verbose (not minimal) can help readability, and that is more valuable in my opinion.

Written with care

The author notes that the book could actually be subtitled “How To Care For Code” as that is really the premise of the book. Code should look like someone wrote it with great thought and care.

And following that, we should always leave the code better than we found it.

One thing I thought about when reading that last part (leaving code better than we found it) - if your code-base isn’t well-tested already, it could be quite risky to touch any other code than the code you are currently working on for the task at hand.

I often think about refactoring some messy code I stumble across but realize that it could have breaking side-effects. That’s the unfortunate truth about some code-bases. I think the best you can do is just to improve the code you are working on.

Next month I’m ordering the book “Working Effectively With Legacy Code” By Michael Feathers (one of the quoted computer scientists in this chapter) which I’m hoping will have some useful guidance on issues like this one.


The chapter closes with the author humbly mentioning that the following ideas and techniques are only one school of thought and are not absolute truths. There are many other ways of writing good code, and we should study all of them.

I’m excited to keep reading. The next chapters cover the actual tactics for writing clean code. We will explore each one in future posts, so if you haven’t already, sign up for my newsletter below so you know when the next one comes out.