I was recently asked by some colleagues about my favourite books on programming. And not just books on coding, but on improving their understanding of successful teams.



Many programming books have had an impact on me, and some more so than others. It’s not a surprise that the books I read earliest in my career also had the biggest impact. And fortunately some of those books were pretty good.

The Mythical Man Month

Frederick P. Brooks

“Adding manpower to a late software project makes it later.”

The great thing about reading a classic is that it provides you with a knowledge and context shared by many others. Even if the book is difficult, the rewards go beyond the simple knowledge gained by the experience. Fortunately reading The Mythical Man-Mon is a pleasure, and it’s wonderful to see so many of our industry’s aphorisms in their full context: The Second-System Effect, No Silver Bullet, Plan to throw one way — you will anyway.

The one that always resonated with me the most is the last. I’ve simply never been able to really understand a programming or systems design problem until I’ve solved it at least once.

The amazing thing about The Mythical Man Month is that it doesn’t feel dated, even though it was first published in 1975. Instead it simply feels like a group of programmers discussing the very same challenges the industry has today, with just different technology in use.

Writing Solid Code

Steve Maguire

Bugs don’t just “go away”.

This book had a big impact on me as young software developer.

It was the first time I saw in print the principle “bugs that go away by themselves come back by themselves”. It’s something that I’ve often repeated to myself, and my team, if nothing else but to prepare us mentally for when that hard bug does come back. The chapter advising developers to “proactively step through your code during development, don’t wait for the bug report” improved my productivity enormously, and I followed the practice for many years.

The book was written when Microsoft was at the height of its power and influence, and while much of the book now feels dated (C is the only language discussed), there are still many insights contained within.

The C Programming Language

Brian W. Kernighan and Dennis M. Ritchie

“hello, world”

What can one say about this book, that hasn’t been said already? Perhaps this: that of all the books written about programming, this has the highest information density of them all.

And yet it’s so pleasant to read.

There is something about the tone of this book — the way the authors speak to you. They explain everything, and yet never seem patronizing or condescending. The joy they feel for their craft — it really does seem like this book comes from a time when programming was a craft — is unmistakable.

Many of today’s programmers — web developers, iOS developers, front-end engineers — may have no need to ever read this book. But for those who have not done so, and really want to improve as programmers, work through this book. It’s a rite of passage.

The Unix Programming Environment

Brian W. Kernighan and Rob Pike

Ken Thompson was once asked what he would do differently if he were redesigning the UNIX system. His reply: ‘ I would spell creat with an e.'”

The Unix Programming Environment is a book you can’t read too soon. It’s something I wish I’d come across years before I actually did. An authoritative and comprehensive manual for using Unix as a programmer, it clearly explains concepts such as inodes, hard and soft links, system calls, and the power of joining programs together via stdin and stdout. By the time I came across this book I already knew these concepts, but had never studied them before in one place, and in such a coherent manner.

This book is a testament to the influence of the Unix operating system. Even though first published in 1984, almost every piece of technical learning in this book can be used successfully with a modern Linux distro.

Peopleware

Tom DeMarco and Timothy Lister

“The major problems of our work are not so much technological as sociological in nature.”

Unlike The Unix Programming Enviroment, Peopleware is one of those books that you can read too soon. And like How to Win Friends and Influence People, if the book seems pointless or naive, you probably need to wait a few more years.

Fortunately by the time I first read it I had already realised that successful software companies are not really about computers — they are about people. This book clarified many of the ideas in my head about high-performing teams, and gave me the confidence to push for what was important to my teams.

But unless you have already embraced the true nature of successful programming — that it really is about the people — I’m not sure if Peopleware will help you. But once you start to do so, it’s a great book and probably the best one there is on programming management.

Becoming a Technical Leader

Gerald M. Weinberg

“Growth in the real world”

Becoming a Technical Leader is both an interesting and subtle book. At times it feels like a self-help book, at other times a Machiavellian explanation of how programming teams really wok. But in the end it’s sincere and mature, and wants to help.

Weinberg’s introspective style will appeal to many programmers, and it appealed to me. This book is useful because it talks about many of the practical issues of becoming a technical leader or manager within a team of developers — and from many unexpected viewpoints. The advice to keep a journal is interesting, as are the discussions of power within an engineering team. He also spends much time on what it feels like to learn new skills, skills that often feel unnatural.

Like Peopleware, it can be too soon to read this book. I was many years in software development, and had already been a tech lead, before I really appreciated this book.

The sooner the better

Reading great — that is, classic — books on programming can make such a difference in one’s career, particularly early on. Because as one’s career progresses, books contain less new technical knowledge and insight. One is often less receptive, since one is simply more experienced.

So my advice to younger programmers is to study the great programming books early in your career — doing will have a huge impact.