The Pragmatic Programmer: your journey to mastery, 20th Anniversary Edition (2nd Edition)
David Thomas, Andrew Hunt
series of self-contained sections and filled with classic and fresh anecdotes, thoughtful examples, and interesting analogies, The Pragmatic Programmer illustrates the best approaches and major pitfalls of many different aspects of software development. Whether youâ€™re a new coder, an experienced programmer, or a manager responsible for software projects, use these lessons daily, and youâ€™ll quickly see improvements in personal productivity, accuracy, and job satisfaction.
The first edition of this book has often been regarded as required reading for all passionate developers along with Clean Code: A Handbook of Agile Software Craftsmanship, The Mythical Man-Month: Essays on Software Engineering and Code Complete: A Practical Handbook of Software Construction.
I read, originally read the first edition a number of years ago, which incidentally prompted me to actually read more about Software Engineering in general, and to also actually read the aforementioned books myself.
As someone, who came into software engineering as what is now defined as the "unconventional route" i.e. not from the Degree in Computer Science etc. My route, was actually fairly conventional for my generation, just from learning and playing with the Commodore 64 and just continued to tinker with computers until I figured out people would pay you for it!
I have tried to make it my focus to try and continually learn more about this hobby I have managed to make a living out of. Reading the original version The Pragmatic Programmer: From Journeyman to Master was rather pivotal in guiding the direction of continual learning.
Why I read this book ?
The first edition, having such a profound effect on my career and still taking pride and place in my bookshelf in my office, when I seen that the much anticipated Second Edition was published, I was quite keen to see how the advice may have changed over the 20 year period.
The first edition, had so many great take-away's in it and I would be the first to admit that along with the Mythical Man Month become the focal point with how to viewed software engineering projects and team work.
There book contained a lot of useful advice and strategies that any developer could implement and experience the benefits. One could argue that yes a lot of it may just be common sense, but as Voltaire once said "Common sense is not so common" and sometimes it actually takes a bit of discovery.
What I like about this book
Like the first book, this book is essentially a "Soup to nuts" book on what it's like to be a Software Developer and provides an overview of the multitude of things we need to consider when developing software.
For most people in the outside world, they live with the misconception that us software developers spend our days just cranking out code. The reality is we spend much more of our time reading, understanding, conceptualising and breaking down large problems. Actually getting to write code is in comparison only about 20% of what we do. The Pareto Principle at play again.
One the face of it, this book works in exactly the same way, as the aforementioned Pareto Principle. One may conclude that this book may contain and only emphasise concepts such as:
- Donâ€™t repeat yourself (DRY)
- Always be learning,
- Importance of Mindful Naming of Variables,
- avoid code rot
- Avoid Over Engineering
- Avoid premature optimisation
- donâ€™t make excuses when you mess up,
- Importance of unit tests
- Avoidance of Over-Testing
- Mindful of Developer Friction and the costs impacts
- Importance of Version Control,
- avoid global variables
- use properties or getter/setter methods,
- working well with and consideration of others
- Importance of refactoring code when needed,
- break down complex problems into smaller more digestible chunks,
- double-check emails before sending them,
There is certainly a lot of useful advice to be taking away and implemented. However, I also realise that there is also a lot of advice the book provides that is not written down, I certainly experienced a lot of eureka moments the book provided when I stopped reading the book
Personally for me, I found the section on Unit Testing to be especially thought provoking. Considering that in the book the authors stipulate that they themselves have stopped writing unit tests for all their code, primarily because they have spent years writing code in a way that ensures their code is Clean and easily testable.
Essentially providing guidance that if you write code with the aim in mind that ensures it conforms too and follows patterns and practices that you don't always need to test it.
They also highlight the fact, that just because your code has 100% code coverage with tests, it still doesn't guarantee that the code is bug free! There is still a high degree of Pragmatism that needs to be applied.
Personally, I find it extremely difficult to code without having Unit tests. Primarily because I simply hate having to run the entire application just to test the thing.
What I like about this book
I like the way this books presents and discusses what potentially could be really dull and boring but important subjects in a Software Engineering but come across interesting and engaging. I also like how there is something for everyone regardless of experience levels.
Personally, I have been developing software for 20+ years, and I still found the content interesting and thought provoking. You could also take the advice provided in this book and apply it every day and could become guiding principles how to work as a software developer.
Why I recommend this book
There are many books about working in software engineering or as a developer, some of my favourites include Clean Code - A handbook of Agile Software Craftmanship , A philosophy of Software Design , Soft Skills - The software developers life manual and The mythical man month all discussing the various aspects of our trade and I would have to include this book as the essential reading too!
how to decompose complex software systems into modules that can be implemented relatively independently.