The Pragmatic Programmer: From Journeyman to Master

I've read a number of books on programming methodology lately - it's a good way to get ideas of how I could be doing things, and it's easier than working - and this is one of the better ones. Most such books have either good practical advice smothered under a layer of dogma - the advice may be good, but it's all got to be separated from the cant and jargon, and weighed individually. Others are good and thoughtful books without a lot of dogma, and also without a lot of practical application. These can be very thought-provoking, and often help you understand the work of producing code, or of working in a team to produce code, or of managing a team to produce code, but they don't give you anything as concrete as "use version control and show more unit tests, and here's why". Hunt and Thomas don't come off as defending an agenda, instead their advice is defended as both rational and experienced-based - a combination that's hard to beat. The writing is even pretty readable, which is rare in this realm.

One inaccuracy deserves to be noted: The authors' citation of experimental validation of the "broken windows" theory seems to be based on a folkloric retelling of the old Phil Zimbardo experiment - Zimbardo's account of this experiment is in The Lucifer Effect, and it's somewhat different from Hunt and Thomas's version.
Just so you know... show less

Here's a book for coders without much code, and still valid after nearly 20 years and several generations of software. It's a catalog of productivity practices, not only in coding but also in setting agendas, learning new methods, writing use cases and requirements, making estimates, fixing rather than doing workarounds, automating, documenting and other common project elements. Maybe it's not just for coders after all.

There's a lot of hype for this book, but I'd rate it as merely "ok". It has a lot of basic advice that is probably useful for beginner programmers; however, if you've been coding for a while, most of the advice will sound like common sense.

Some of the advice is actionable, but some is theoretical or ideological; some parts are language and framework agnostic, while others have become quite dated; there are a few bits of deep, meaningful advice, but mostly, the book consists of fairly simple aphorisms. It even has a detachable pull out with all the sayings.

It's an easy read, but rarely rises above the programming analog of "eat well and exercise regularly".

Some fun (and funny) quotes:

"Don't live with broken windows."

"Use tracer bullets show more to find the target."

"Prototyping generates disposable code. Tracer code is lean but complete, and forms part of the skeleton of the final system. Think of prototyping as the reconnaissance and intelligence gather that takes place before a single tracer bullet is fired."

"Check their spelling, first automatically and then by hand. After awl, their are spelling miss steaks that the chequer can knot ketch."

"Distributed systems such as EJB are leading the way into a new age of configurable, dynamic systems."

"We who cut mere stones must always be envisioning cathedrals." - Quarry worker's creed

"The limits of language are the limits of one's world." - Ludwig Wittgenstein show less

As a professional software developer of over five years, this book consisted of a number of things I hadn't before considered, and a number of things that I was aware that I should be practicing but have let slip by the wayside due to working in an extremely pressured environment (aren't we all?!) under decidedly not very pragmatic management. However, I think there's a lot to be said for taking matters into your own hands; if the people around you aren't going to make the effort to follow these principles, then it can be up to you to make the leap and hopefully others will follow suit. It's quite easy to forget exactly who you are working for and why, and become enclosed within yourself in these kinds of situations. Sometimes you need show more the kind of kick up the ass this book will provide.

What lets this book down in some ways is its datedness. Most if not all of the principles do not depend on concrete technologies or more recent developments, but some things were mentioned that have since been superseded by more efficient technologies, techniques and modes of thinking. This book would benefit well from a comparison with lessons we have learned from these more recent developments; both good and bad. For example, I think the agile methodology is a more pragmatic approach to software development but it was not mentioned in this book.

Also there are now a wider range of tools available to make our jobs as developers easier; better IDEs, VCSs, testing suites and many of the automation we have been encouraged to write has already been written for us. However, as pragmatic programmers, hopefully you will have done your own research and discovered these for yourselves rather than relying on the appendices of a book from the 90s. :) show less

Solid book when you are starting journey of a developer. Great guiding principles but don't be dogmatic about using them. They are useful, but they should not restrict creativity or practicality in problem-solving. The authors, Andrew Hunt and David Thomas, provide invaluable wisdom gleaned from their years of experience in the field. Their insights on "how to think" rather than "what to think" are exceptionally helpful for newcomers.

The book covers a wide range of topics from basic coding practices to effective debugging techniques, and from code optimization to managing your career as a programmer. The engaging writing style, coupled with numerous practical examples, make the book a pleasant read.

One of the key takeaways from the book show more is that a good programmer is not just about writing code, but about understanding the problem at hand and devising the most efficient solution. This philosophy is repeatedly emphasized throughout the book, highlighting the importance of being a "pragmatic" programmer.

Although the book is targeted primarily at beginners, even seasoned programmers can benefit from the wealth of advice it offers. However, some might argue that the book is somewhat outdated, as it doesn't delve much into recent trends like cloud computing or machine learning. Despite that, I believe the principles the book teaches are timeless and apply to any programming context.

While I recommend this book for its practical wisdom and broad coverage, it's important to remember that it's not a step-by-step coding manual. Instead, it provides a framework to think, behave, and approach problems as a developer.

In summary, The Pragmatic Programmer is a must-read for anyone embarking on a programming career, offering a great foundation on the principles and mindset needed to succeed in this field. ",,,1,0
116114,From Here to Eternity,James Jones,Jones show less

Lots of generic advice in this book. Some advice in the form of guidance helps, but a book filled with software engineering advice was a bit too much for me to handle. I had to skip pages, skim through topics and get to the point while reading this book. May be of interest to others, but I personally found that I had to skim through it rather than understand it. At a more general level, this book helps you to appreciate the architectural decisions involved in development of software like orthogonality and design patterns.

This book turned me into a professional programmer. Of course I had to work at it, but this book showed me the way. So I owe it a great debt. Like Extreme Programming, none of the techniques are new, they just work very well together. The book is short, some of the tips are strange (tracer bullets?), but most are exquisite, like Broken Windows (an abandoned house will be quickly vandalised if one broken window is not fixed immediately). Often compared to McConnell's [Code Complete], but this book is much broader, and barely touches on actual code or languages. The authors do prefer more dynamic languages, which is why they are now the Ruby champions, but they recognise that most programmers use more mainstream languages.

I still follow show more much of their advice, like investing in my knowledge portfolio, taking time to learn New Stuff. The month I spent learning FORTH is chalked up to experience, and I will probably never get to use my inside knowledge of the Z39.50 protocol (which is how Library Thing talks to library catalogues worldwide), but I tried Python and I now use it every day. Some investments pay big dividends!

Thank you, Pragmatic Programmers! show less