The Three Books

David Wickes wrote an excellent post called Three Books, which claims that any senior developer should be able to recommend three books to a less experienced colleague. There are various reasons for this and some nuance, so please read the post!

I wish I had been lucky enough or had the foresight to read these books when I was 25. I’ve tried to pick three varied books that give you solid foundations to be a good software developer.

The Phoenix Project

This helps you understand there’s so much more to shipping software than raw technical skills.

Making anything non-trivial requires teamwork. This brings social and organisational challenges.

These are different from what you learn in a computer science degree. This book helps you see these issues, the dysfunctions organisations can get into, and how to get past them.

If you understand the concepts in these books, you’ll be able to help your team work better and be more likely to have successful projects.

After reading this book, if you enjoyed it and found it helpful, I’d go straight into reading The Unicorn Project, which is the successor, but from a developer's point of view.

The Unicorn Project is the organizational civil-war novel that every technology and business trailblazer must read.

Christopher O’Malley

Growing Object-Oriented Software guided by Tests (GOOS)

I read this book long after working with ThoughtWorks (TW), a software consultancy company. For many years they worked with the company I was in, coaching us on how to write software the modern way.

Before this, I was mainly a solo developer, bashing code out and copying it to prod on small websites. TW taught us how to work on big projects, which requires you to work entirely differently due to the different challenges working as scale brings.

Reading GOOS, it’s apparent that it’s a blueprint for what TW taught me and what I have been coaching my team.

It would be a long post if I were to talk about everything they introduced, but some core values were:

  • Working on big things is hard. So cut scope, break the problem down and work iteratively.
  • TDD
  • Fast feedback loops
  • Pair programming
  • Trunk-based development
  • Heavy emphasis on automation

Yes, it’s a book about TDD, but it feels more significant than that. It’s a practical book showing how to build a real, complicated thing in what I would consider the right way. Many people lament that too many TDD articles are simplistic and not “real world”. The answer to that whining is this book.

Refactoring (2nd ed)

I have no evidence for this, but anecdotally, most developers don’t know how to refactor very well. Many don’t even know what refactoring is. Most aren’t refactoring anywhere near enough.

The good news is, if you study this relatively short manual on refactoring, you’ll level yourself up as a developer. Once you understand what refactoring is and practice what is explained in this book regularly, you’ll improve the code you work on. You’ll increase your and your team’s productivity, and refactoring will reveal better designs for your system.

If you’re a developer who claims, "I don’t have time to refactor", you’re wrong. Your definition of refactoring is likely incorrect, and you certainly don’t know how to practice it effectively.

Honorable mentions

These were books that were very influential in my development. However, I recognise my juniors are very time-starved and suffer from vast information overload. These books are great, but they should probably only be picked up if they catch the individual’s eye.

The C Programming Language

This may be a function of sentimentality, as C was the first language I properly studied.

It’s a wonderfully short book and easy to read, but at the same time, it goes deep into how your computer works.

The big thing you’ll have to overcome is the concept of variables that are the actual data and variables that point to data. This requires you to leap across a somewhat abstract thinking barrier, but it’s essential to make it, and it’s applicable outside of C.

Functional Programming in Scala

Writing your abstract data types like Option, List etc., will help you realise that a lot of functional programming (FP) is not all that complicated. It’s a fun book and taught me much of my FP knowledge.

Practical Object-Oriented Design in Ruby (POODR)

Sandi Metz teaches what it means to be a good developer from a technical and behavioural standpoint.

We are similar in respect of not tolerating bad excuses for poorly written code. Her discussion about the importance of exemplary code has stuck with me.

She shows you how to write good, object-oriented code throughout the book. Like refactoring, there’s a lot of talk about OO from thought leaders on the internet, but most of the time, it’s clear that the person’s idea of what OO is wildly different from what is written by experts, like Sandi.

OO gets a lot of negative press these days, mainly due to the faddy nature of our industry.

Function good, class bad.

This book is relatively short and gives you an excellent intro to OO.

Don’t Make Me Think

A common sense approach to web usability

If you wish to describe yourself as “full stack”, you should acknowledge that you won’t be an expert at everything but should appreciate all aspects of your craft.

This book will help improve your empathy for users and give you some practical ways to ensure the website you’re making works well.

In this second edition, Steve Krug adds essential ammunition for those whose bosses, clients, stakeholders, and marketing managers insist on doing the wrong thing. If you design, write, program, own, or manage Web sites, you must read this book."

Jeffrey Zeldman

Release It!

I read the first edition of this book a while ago; a 2nd edition was released in 2018.

For someone who had previously been manually copying code into production without a second thought, it taught me what it takes to release and operate systems at scale.

Writing code is one thing, but creating sustainable and straightforward systems is a skill that needs to put more effort into learning and improving.

It introduced me to the circuit breaker pattern, which is a pattern for isolating failures. It keeps small failures small rather than escalating and taking down your entire system. You'll find this pattern in most modern, web-scale systems, and often now it's built into things like Istio

There are many more gems like this; it's worth reading.