Cover image for The book every programmer should read

The book every programmer should read

vnbrs profile image Vinicius Brasil ・2 min read

Writing code that any programmer who read can understand is a must-have skill for software developers. The fact is: only 20% of the programmers have the ability.

“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” — Martin Fowler

When I started caring about code readability I noticed that my code started to be:

  • easier to maintain
  • easier to refactor
  • reusable
  • consistent

The book

Robert "Uncle Bob" Martin's "Clean Code: A Handbook of Agile Software Craftsmanship" is the clean coder programmer bible. This book talks about code, behaviour, automated tests and so on.

Let's get practical! Writing meaningful names.

One of Clean Code chapters talks about meaningful naming. In this story, you are going to be the code reader. Take a look at this function:

def calc(n1, n2)
  return n1 / n2

Do you think calc is a good name for this function? Uncle Bob would say: no! Why?

  1. calc is an abbreviation: don't!
  2. Functions do something. It must be named with a verb.
  3. Even I rename calc to calculate, it still be vague. We need to improve the semantics by giving the function name more meaning.

This function divides two numbers. divide is a good name for it.

def divide(n1, n2)
  return n1 / n2

result = divide(1, 2)

We still have problems with it. "n1" and "n2", the parameters, are not semantic. What if we call them "dividend" and "divisor"? The same thing to the "result" variable. It should be called something like "quotient".

def divide(dividend, divisor)
  return dividend / divisor

quotient = divide(1, 2)

Much more semantic!

If you are not convinced to read this book yet, take a look in this picture and buy this must-read book!

Posted on Oct 19 '18 by:

vnbrs profile

Vinicius Brasil


I’m a business-minded software developer. Apart from programming, I’m majoring in Theology, I like photography and I study music.


EBANX is a global financial group with a Silicon Valley attitude. We believe that people should have the power to choose and go further, and that is why we offer local payment methods on the largest websites worldwide.


markdown guide

It is a good read, definitely in the top 10, but I would not say it is THE BOOK, and also I would not recommend it for junior developers that are in their first 2 years of programming (as in they have bigger fish/books to fry).


Hmm, interesting. Actually it’s among my personal top 3 of influential books and I’ll have every new developer read it in my team.

I read it when I was already an experienced developer. It was more about giving things names and good example that already did out of a gut feeling.

But I haven’t thought about how it it is received by inexperienced developers...

Is it just your feeling or do you have tales to people that actually had problems understanding it?


I did not tried to test it on juniors, it is common sense I guess.

It solves issues they do not encountered yet, do not understand so they will not apreciate.

They have bigger fish to fry: a language, paradigms, dev tools, how software works in general and how is developed and so on.

There’s surely a lot to learn, but juniors are actually able to learn a lot in a short amount of time.

Moreover, “common sense” doesn’t really count. That sounds like not allowing children to try something only because one think they won’t make it.

So for me, clean code next to testing is one of the foundations of high quality code and I’ll start teaching that as early as possible.

We do coding dojo’s every sprint so we actually practice what we preach :)


I read it at the start of my second year and I'd actually agree with that. The book is amazing and will definitely improve how you write code, but the examples are written by an experienced Java programmer and some of them are quite hard to understand for beginners.

If you do decide to read it, don't be afraid to stick to the topics that seem relevant and skip ahead here and there (as I did). It's a great book to come back to after some time has passed and the appendix/summaries at the end are very helpful.


None, I think is specific, because every dev has its own gaps and knowledge.

For example Clean Code and Clean Coder goes hand in hand, covering complementary skills.

Before these the Pragmatic Programmer may clear the way into explaining what devs actually do.

There are 2 posts on dev.to with top 10, I think we can start from there, but all are equal important.


Learning to code first, then you can understand the "rules" and how/when to break them.


I also recommend, as supplements to Clean Code, The Clean Code Talks given at Google about a decade ago by Misko Hevery (Ref: youtube.com/playlist?list=PL-XjMWI...) and the classic Code Complete by Steve McConnell. I should note that I found myself disagreeing with a few items in the Clean Code Talks, but as our boy Freddy Brooks tells us, there's no silver bullet (Ref: en.m.wikipedia.org/wiki/No_Silver_...), so keep your mind open to the guidelines so you know when to use them as rules or break them completely; every code base has a history and point of view that must be understood before you can even begin to decide when to break the rules or enforce them.

Generally speaking, if you can't articulate a clear and very specific engineering trade off that you're making by not following the guidelines, you're probably best served by sticking to the safety of the best principles practiced in the books and videos mentioned here. That last bit is my own opinion, feel free to disregard if you have a clear and specific reason to. There's an art to everything, including science. ;)


+1 for Code Complete, that one was a game changer for me.


There is no one single thing in the universe worthy as ultimate title. Also, reading books does not make us any better in programming. Yes, I said that. Reading books is a pleasant rest, but it adds literally nothing to the quality of the code we produce. Reading books does not improve our skills.

Coding does. Writing code, not reading sophisticated musings.

So I would suggest to treat reading books as an entertainment and stop wasting time thinking it will somehow affect our qualification and/or proficiency.

Write code if you want to be better in writing code. Read books if you want to improve your skills in reading books.


By that logic I guess you are trying to improve your blog post reading skills. 🤣


I treat reading blogs as an entertainment. I am sceptical about the possibility to find something useful in blogs.

And I am more of a writer than reader here on dev.to.

By that logic, I guess you write nothing useful here. Stop wasting your time and go write some code! 🤣

This in an incredibly short sighted comment. Of course reading books on programming will improve your potential. Practice will cement it.

As a blog writer is your aim merely to improve your writing? I would assume you feel your words can somehow help others no?

Of course reading books on programming will improve your potential.

I love “of course” as the main and only argument of the premise. It always sounds bullet-proof.

I would assume you feel your words can somehow help others no?

My words can make somebody think, that’s correct. 10LOCs would make it better than 10 posts I wrote, but nowadays people tend to read fiction, not the code, so I am here in the mainstream. I am trying to raise problems, not to provide pieces of advice, though.

Also, improving my writing skills matters a lot.


"Refactoring: Improving the design of existing code" by Martin Fowler is one of the better books.

The refactoring problems which he has addressed are real. The "catalogue" section of the book talks nicely about the steps (step 1, step 2, step 3 ... ) of each refactoring techniques.

The first edition was released in the year 2000 I think , using Java as language of choice.
The second edition has been released just recently , using JavaScript as language of choice


I've mentioned it before, but "Dreaming in Code" by Scott Rosenberg is also something of a must read for coders. I bring it up here because it demonstrates the importance of clean coding (and good project management) principles through the chronicle of several coding disasters. Makes for a nice companion read.