Being a developer means that you’re on a life-long learning journey. I think that’s a journey everyone should be on, but in the software world it’s mandatory.
Your current knowledge has a half-life of around five years – i.e. half of what you know now will be of no value to you in five years.
Brutal, I know.
But this isn’t a world for folks who don’t like to learn new things. Personally, I love learning new stuff 🙂
Today I’ll be talking about specific books you can use to learn new skills that’ll give you knowledge I believe will survive your whole career – and I hope that’s longer than five years!
But are books the best way to learn? Actually, I don’t think so.
I think the learning experience is way better when content is taught in-person by an expert, and you’re learning in a group environment.
That’s a course, and these kinds of courses can be pretty pricey.
When your employer pays for them that’s great! But in this case it’s because your employer wants you to learn something to add value for the employer, not necessarily for you.
But that’s still not the best way to learn.
For me, the best learning happens in a workplace where best practices are the norm, your team has high expectations for the quality of your work, and processes and mentors are in place to help you achieve high standards.
Sadly, those kinds of workplaces aren’t common at all. If you’re not in a situation where your professional development is taken care of by the business, you need to take care of it yourself.
They’re not cheap, but you can get a lot of value out of them if you’re willing to put the work in.
Depends on the book. But regardless of the kind of book you’re learning from, it’s worth putting in some time and effort to get the most out of it – reading the book is just the start!
If it’s a “Learn technology X” type book where you’re learning a new programming language or tool, the book will undoubtedly have exercises and examples to work through.
Do the exercises.
Working through the exercises in these kinds of books will increase your learning massively. It’ll also give you hands-on experience installing and working with the tooling that supports the new technology.
And if the book has a companion website, please don’t download the code for the examples.
Unless it’s approaching a thousand lines of code (and I’ve never seen that much code in one example), you’ll be better off typing the code straight out of the book.
Laborious, I know.
But pecking away at the keyboard will force you to notice small details in the code that are otherwise easy to miss if you’re just reading the code – something I’ve learned from painful experience :/
Finally, think of a small project you can use the new technology in. Even trivial projects will shine light into the dark corners of new technologies that some book authors like to gloss over!
You’ll notice that the three books I’m discussing today are all theory and concept-type books. These are the kinds of book that survive that five-year half-life we were talking about earlier.
This is different to the standard technology book. They often won’t have exercises, just summaries.
So what’s the best way to bed down your new knowledge, and make it your own?
This comes down to your learning style. Personally, writing things down is how I understand and remember new knowledge.
Some people have to make pictures, like mind-maps. Others like to talk about what they’re learned to someone else.
I love writing things down in a basic workbook because:
So I recommend to at least start by keeping a written record, and try new stuff from there to find out what works best for you.
Finally, think hard about how you can use your new knowledge straight away. Maybe there are situations at work or with your personal projects you can improve?
Doing this will really cement your new skills and will make you a practitioner of the new topic, instead of someone who just read a book about it!
Let’s get to the books already.
These are books that I’ve personally read, and personally recommend. I’ll be linking to them throughout the article, and note they’re not affiliate links.
I’ve written about design patterns previously, and I think they’ve got a lot going for them if they’re used judiciously.
The thing is, even if you never implement a design pattern in your life, a lot of design patterns have been baked into programming language frameworks and application containers.
Recognising and understanding these design patterns will make your life a whole lot easier when you encounter them.
For that reason alone they’re worth learning. And if you learn to use them right, you’ll be a better developer.
And why Head First Design Patterns?
Because it’ll get you up to speed on design patterns as fast as humanly possible.
The Head First books can be a shock – the pictures, crossword puzzles and join the dots exercises can make you feel like you’re back in elementary school again.
As they carefully explain, this is all in aid of making stuff stick in your brain. So swallow your pride and do the kooky exercises 🙂
The canonical book on the subject is Design Patterns by the ‘Gang of Four’ (Gamma, Helm, Johnson & Vlissides, aka ‘GoF’).
I’m not recommending this as a book to start with. Even though the GoF book uses an example application to illustrate the design patterns, I personally found the context presented by the Head First book made the subject matter easier to learn. Maybe get Design Patterns later as a reference because it covers way more patterns than the Head First book (which covers the most important ones!).
Once you’re comfortable with design patterns, another great book to look at is Patterns of Enterprise Application Architecture by Martin Fowler. You’ll find this book helpful if you’re working with .NET or JEE in the enterprise world.
Clean Code by Robert “Uncle Bob” Martin is a compendium of things we should be doing when we code, but often don’t.
Uncle Bob is a character, to put it mildly.
He’s well on the road to becoming the patron saint of confused programmers the world over, and Clean Code is his message to you when you’re tired, stressed, under pressure or just sick of what you’re working on: do it right.
The subtitle of the book is “A Handbook of Agile Software Craftsmanship”, and while a lot of the content has nothing to do with “agile” development, everything in the book will help you write better code.
All the while Uncle Bob will be right alongside you, reminding you that extraordinary results require extraordinary effort, inches make champions, how you practice is how you play, and every other cliché grizzled coaches have yelled to make their teams great. Evangelistic and charismatic, Uncle Bob also makes it fun.
But don’t think this book is just a cheerleading effort by someone who looks like your granddad. It’s both a deeply tactical and erudite book on everything from how to choose good variables and function names through to how to start implementing TDD and Refactoring.
It’s such a massive and useful book I’ve been dipping in and out of it for years. I always come across something I really should be doing better. So I concentrate on applying that to my work for a while, and then going back for the next thing I can improve.
Really, it’s everything a good programmer should be doing anyway, but sometimes, ahem, forgets about.
This book sits in the same space as Code Complete, by Steve McConnell. Code Complete is a very similar book in that it goes into the nitty gritty of writing good, maintainable and correct code. I prefer Clean Code because it’s a bit more current and covers more territory that’s relevant to the modern developer.
This is a massive book, and not as immediately actionable as the last two books I’ve just discussed.
But learning from it will be a major investment in your development as a software professional.
So what’s it all about?
Domain Driven Design, by Eric J. Evans, presents a process for understanding and modelling complex domains.
Evans defines a domain as a sphere of knowledge, influence or activity (e.g. a ‘receivables’ tracking app would be in the ‘accounting’ domain).
The reason this is such a big deal is that while businesses often have very similar domains (accounting, contracts, sales etc), they all have complex, arcane and unique processes and rules for managing those domains.
Large software projects tend not to fail because of technical reasons, but because of an inability to represent a business domain with complex rules effectively in code.
This is the problem that Domain Driven Design helps solve.
While I cheerfully and heartily recommend this book, I have to give you a couple of warnings: it’s long, somewhat dense and defines a lot of terminology that’s destined to be jargon only other domain modellers will understand.
But like I said, it’ll give the tools for dealing with complex business problems successfully.
If you don’t think these are the best books for you personally, I hope you’ll still take your professional development as a programmer into your own control.
No matter what book you use to improve, remember to get the most out of it by taking notes and finding practical ways to use the information from the book as soon as possible.
Other than that I hope you’ve enjoyed the article, and I’d love to hear about your personal book recommendations.