The Three Books
David Wickes wrote an excellent post called Three Books, which claims that any senior developer should be able to recommend 3 books to a less experienced colleague. There are various good reasons for this and some nuance, so please read the post!
I wish I had somehow been lucky enough, or had the foresight to read these books when I was 25. I’ve tried to pick 3, varied books that give you solid foundations to be a good software developer.
This helps you understand that there’s so much more to shipping software than raw technical skill.
Making anything non-trivial requires teamwork. This brings social and organisational challenges.
These are not the kind of things you learn on 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 you’ll be more likely to have successful projects.
After reading this book if you enjoyed it and found it useful I’d go straight in to reading The Unicorn Project which is the successor, but from developer's point of view.
The Unicorn Project is the organizational civil-war novel that every technology and business trailblazer must read.
I read this book a long time after working with ThoughtWorks (TW), who are 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.
Prior to this I was mainly a solo developer, just 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 completely differently due to the different challenges working as scale brings.
Reading GOOS, it’s very clear that it’s a blueprint for a lot of what TW taught me and subsequently 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
- Fast feedback loops
- Pair programming
- Trunk-based development
- Heavy emphasis on automation
Yes, it’s a book about TDD but it feels bigger than that. It’s a practical book showing how to build a real, complicated thing in what I would consider the right way. Lot’s of people bemoan that too many TDD articles are too simplistic and not “real world”. The answer to that whining, is this book.
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 actually is, practice what is explained in this book regularly, you’ll make the code you work on better. You’ll increase you and your team’s productivity and the act of 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.
These were books that were very influential in my development. However I recognise my juniors are very time-starved and suffer from a huge amount of information-overload. I think these books are great, but should probably only be picked up if they really catch the individual’s eye.
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 fairly abstract thinking barrier but it’s so important to make it and it’s applicable outside of C.
Writing your own abstract data types like Option, List e.t.c. will help you realise that a lot of functional programming (FP) is not all that complicated; although some of it, really is. It’s a fun book and taught me a lot of my FP knowledge.
Sandi Metz gives a lesson in what it means to be a good developer from both a technical and behavioural standpoint.
I feel like we are quite similar in respect of not tolerating bad excuses for poorly written code. Her discussion about the importance of exemplary code has really stuck with me.
Throughout the book she shows you how to write good, object-oriented code. 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 to what is written by actual 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 quite short, and gives you a wonderful intro into OO.
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 you should have an appreciation for 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."
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 was extremely influential in teaching me what it takes to release and operate systems at scale.
Writing code is one thing, but creating systems that are sustainable and simple to operate is a skill that sadly don't put a lot of effort into learning and improving at.
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 in to things like Istio
There are many more gems like this, it's well worth a read.