Developers Should Read the Classics Too

Most of what I post here is about Go and Zig. Two weeks ago I posted 21 Ideas from The Black Swan, which has no code in it at all, and it made me think about how little non-technical reading most developers do. I know many good programmers whose last novel was the one they had to read at school. I think they are missing something, so here is my case for reading the classics and other good books, even if you write code for a living.

Technical books get old Link to heading

I write technical books, so I am allowed to say this. Most programming books have a short life. Zig 0.17 removed @cImport and I already had to write about what that means for my own book, which is only a few months old. I try to put timeless advice in my books, most of it based on the UNIX philosophy. A program should do one thing and do it well, and it should work with other programs. That idea is more than fifty years old and it is still true in Go, in Zig and in whatever comes next. The code listings around it will get old anyway. The Odyssey is about 2,700 years old, Plato’s Republic about 2,400, and nobody is waiting for a second edition of either. A book that people still read after a few centuries is about things that do not change, like fear, pride, money, family and death. You will need to know about those long after your favorite framework is gone. I am not saying stop reading technical books. I am saying they should not be the only books on your desk.

You write all day Link to heading

A developer writes far more plain text than code. Commit messages, documentation, bug reports, code reviews, emails and design documents are all prose, and someone has to read them. Nobody learns to write well from style guides. You learn it the same way you learn to program, by reading a lot of good work until some of it sticks. Take Animal Farm by George Orwell. It is about a hundred pages and there is not one difficult sentence in it. A child can read it as a story about animals and an adult can read it as a story about power, and both get the whole book. I would like my documentation to work like that. After enough reading of this kind you start to notice when your own sentence is too long or says nothing.

Software is for people Link to heading

Most projects I have seen fail did not fail because of the code. They failed because someone did not understand what the customer wanted, or two teams did not talk to each other, or a manager could not admit that a deadline was wrong. No programming book covers that. Other books do. In Animal Farm the rules are painted on the barn wall, and during the night someone keeps changing them a few words at a time. Most of the animals are not sure what the rule said yesterday, so they accept the new one. If you have ever worked on a project where the requirements changed quietly and nobody wrote down the original ones, you have lived on that farm. In Crime and Punishment Dostoevsky spends hundreds of pages inside the head of a clever young man who talks himself into a terrible idea one reasonable step at a time. I have seen bad designs get approved in exactly the same way. 12 Rules for Life by Jordan Peterson is a very different kind of book, but one of its rules is to assume that the person you are listening to might know something you don’t. I cannot think of better advice for a code review. Another one says to compare yourself to who you were yesterday and not to who someone else is today, which helps a lot in a job where there is always someone who knows more than you.

A long book trains your attention Link to heading

We read in small pieces now. A post, a thread, an answer from a chatbot, then the next one. A serious book does not work that way. The Republic is one long conversation that runs for ten books, and near the end you have to remember what everyone agreed on at the beginning. The Black Swan builds its argument over four hundred pages and uses words that Taleb defined two hundred pages earlier. The Brothers Karamazov is close to a thousand pages and every character goes by three different names, so you have to remember that Alexei, Alyosha and Alyoshka are the same person. That is very close to what you do when you read a large codebase that somebody else wrote. The ability to stay with one difficult thing for two hours is getting rare, and it is the one that debugging needs most. Reading long books is a cheap way to keep it.

Old ideas are good ideas Link to heading

Taleb says somewhere that a book that has been in print for a hundred years will probably be in print for another hundred. Time is a hard reviewer. The books that got through it usually have something in them. The Iliad starts with the best fighter in the army refusing to work because his commander took his prize in front of everyone. Any team lead will recognise the situation. The Odyssey is about a man who needs ten years to get home because every shortcut he takes turns out to be a detour, and I have had projects like that. Then there is Plato. In the Apology, Socrates says that he is wiser than the others only because he does not think he knows what he does not know. In the dialogues he asks someone for a definition, then asks one small question after another until the definition falls apart. It is the oldest debugging session on record. Every developer who has been sure about a bug and wrong about it should read a few of those pages.

How to start Link to heading

Do not start with a list of the hundred greatest books. You will read two and feel guilty about the other ninety eight. Pick one book that you have always heard about and read twenty pages a day. Animal Farm is a good first one because you can finish it in a weekend. If a book bores you after a hundred pages, put it down and take another one. Nobody is grading you. Mix old and new, fiction and essays. A good modern book counts as well. The Black Swan is from 2007 and 12 Rules for Life is from 2018, and I put both next to Homer, Plato and Dostoevsky in this post without feeling bad about it.

None of this will make you type faster or pass an interview next month. It works slowly, over years, and you will not be able to point at the day it paid off. I still think it is one of the best things a developer can do with an evening.