The Pragmatic Programmer is one of the oldest books I have on my shelf. Recommended to me by several friends and colleagues when I first started development, it's quite possibly the one book that shaped my career as a developer.
Despite being originally published in 1999 (although, there is an updated, 20th anniversary addition I haven't yet read), most of the topics are as relevant now as they were 20 years ago, since the advice given is generalised to all programming languages.
I first picked this book up in 2013. Before that, I'd been a programmer at home, trying desperately to create mobile apps that would eventually make enough money that I could sustain myself without the 9-5.
What I hadn't realised at the time, is that my code was horrific! Spaghetti code with poorly named classes & variables, with zero tests and full of quick hacks that got the code working. Everything I made broke, constantly, and then I'd make a change and it would all be broken again. This was software development for me, and in hindsight I'm surprised I got through it.
When I eventually got to reading this book, I was working full time in my first real job and was already appreciating the importance of writing code that was above all, easily readable by another human being, and then hopefully by the compiler.
Despite only skimming through it at first, I learnt a lot. To this day, I've used the analogy of the broken window theory (where a single broken window in a car significantly increases the probability that the rest of the car will be vandalised and mistreated by others) several dozen times when spotting code that "does the job enough".
It teaches being proactive, and not necessarily asking permission first when you know something absolutely needs to be done. I've completed projects that would never have got out of the planning stage if not for learning this first.
There are however topics in the book that feel obvious, almost to the point of being condescending. Tips such as "Always use Source Code Control", or "Separate views from models" for instance would make you think "Well of course! These aren't tips, these are common sense!". My guess (since I wasn't a developer in 1999), is that a lot of processes that were in the category of good practice have become standard practice in the past 20 odd years. This book may well have played its part in that.
Picking it up years later, the book is full of highlighter marks and annotations over sentences that I've related to or found interesting, some of which are now more obvious to me only after being a developer for a few years.
For that reason, I'd consider it to be an invaluable resource for any developer, whether junior or senior, whether front-end, back-end, full-stack or any other flavour of development stack, and I couldn't recommend it more. Although, maybe get the 20th anniversary edition; I’ve heard only good things.
