DEV Community

Cover image for The book every programmer should read
Vinicius Brasil for EBANX

Posted on

The book every programmer should 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
Enter fullscreen mode Exit fullscreen mode

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)
Enter fullscreen mode Exit fullscreen mode

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)
Enter fullscreen mode Exit fullscreen mode

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!

Discussion (19)

bgadrian profile image
Adrian B.G.

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).

colorcodedcode profile image
Robert Schaap

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.

stealthmusic profile image
Jan Wedel

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?

bgadrian profile image
Adrian B.G.

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.

Thread Thread
stealthmusic profile image
Jan Wedel

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 :)

larrojl profile image
José Luis Larroque

Which one do you suggest instead ?

bgadrian profile image
Adrian B.G.

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 with top 10, I think we can start from there, but all are equal important.

ash1eyish profile image
Ashley Maria

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

omarrodriguez15 profile image
Omar Rodriguez

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

gazzonyx profile image
Scott Lovenberg

I also recommend, as supplements to Clean Code, The Clean Code Talks given at Google about a decade ago by Misko Hevery (Ref: 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:, 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. ;)

dzuvan profile image
Јован Хрњак

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

codemouse92 profile image
Jason C. McDonald

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.

swarupkm profile image
Swarup Kumar Mahapatra

"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

d0ruk profile image
Doruk Kutlu

Every programmer should've read this.

rxrobo profile image

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

Thread Thread
designpuddle profile image
Chris Bertrand

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?