the item

The Pragmatic Programmer
The Pragmatic Programmer

the questions

  1. How to be a better programmer

more about the

the consensus

One of the top, must-have books to read and practice as a programmer. If you want to be a professional, read this and learn

recent reviews

  1. Zen and the Art of Motorcylce Maintenance
  2. The Sparrow
  3. SEOMoz
  4. Mythical Man-Month
  5. Code Complete
  6. Pragmatic Programmer: From Journeyman to Master
  7. This Perfect Day

join our mailing list

if you liked
'The Pragmatic Programmer'
you also might like

Your Ad Here

comment on
'The Pragmatic Programmer'

book ideas? feature requests?
other information not related to 'The Pragmatic Programmer'?

continue the research

all external links are affiliate links. is used to provide real-time tracking

the review

What would you get if you took some of the best programmers in the industry -- you know, guys that have been around the block many times and know all the ins and outs of programming -- and had them do a brain dump of everything a master programmer does? Then suppose you took that information and broke it into easily digestible pieces, cross-referenced by topic and grouped by area of interest, finally wrapping it in a friendly, flowing, and entertaining format?

You'd get this book, that's what. Easy to read and digest, I found this book an excellent review of just about every tip and trick I've been using, all in a very accessible structure.

After a bit of a slow first chapter going over the philosophy behind the book, we launch right into DRY (Don't Repeat Yourself) and Orthogonality, two critical concepts in programming that keep popping up over and over again. Before we're even a quarter of the way through we're swimming in advanced concepts like Domain Languages. When you really "get" Domain Languages, DRY, and Orthogonality, it completely changes everything.

I found the overview of these topics wonderfully concise, interesting, and enjoyable to read. This is all stuff that you end up figuring out yourself anyway on your path to being a proficient coder, but it's great to have it all laid out like this. Some things, like learning a stand-alone code editor, took me a really long time to figure out. Some things, like shell scripts, text manipulation, and code generation, take your programming to a whole new level once you start using them. I wish I could take the section on understanding how GUIs prevent truly proficient programming and print it in bold text and stick it on a wall somewhere. We've turned our development environments into something more akin to a video game than a place for serious work. But I digress.

Especially nice was the exercises at the end of each section, little test and quizzes in C, Java, or just a good thought-provoking exercise. Somehow seeing the ideas play themselves out in code provides a lot more impact than just reading about them.

If I had any major problems with the book, I wonder if, like many great books, it's not just too much, too fast. I know for a fact we programmers love assimilating data like this: just the facts, ma'am. Give me the bullets and make it as quick as possible, I have lots of other things to read. But can we assimilate this new information and then have it make a substantial change in our practice? I don't know, mainly because I have learned the hard way about each of the things the book mentions, so I'm already a believer. For those coming in with a skeptical attitude? Perhaps with a lot of opinion but not a lot of real-world experience in dozens of shops? It might still be a long haul for them, but at least they can't say they weren't warned about how things will eventually turn out for them if they stick with it.

I also found the book to be at its weakest when it was the farthest away from programming, things like requirements and testing, which, although correct, kind of seemed like they were mailed in -- not as clear and precise as the programming stuff. Quite frankly, one of the things I consistently see missing in even senior programmers is the ability to incrementally model, gather future behavior states, and still keep development momentum, so it's not surprising that the book would be a little light in those areas.

Even when in a weaker area, though, the authors are dead on- target with the gist of what to do: be pragmatic. Yes, processes are great, but you have to keep in mind the big picture at all times. I laughed at their criticisms of Use Case diagrams -- the little stick men and bubbles some practitioners use -- they asked "would you show this to the customer? If not, then why use them?" Of course, the reason to use them isn't to communicate to the customer, it's to keep track and organize your analysis as you proceed, but their point is good anyway: if you don't know why you are doing something, stop doing it immediately. The one thing you absolutely cannot do as a professional programmer is let your mental model of how things "ought" to work get in the way of how they are actually working. Always be pragmatic.

I'm really sorry I didn't read this book when it came out several years ago. Even though I'm already doing about 90% of the stuff in these practices, the other 10% would have made a major difference in my work over the last decade. Very cool stuff like the blackboard idea would have been nice to know up-front, instead of ending up developing things very similar to it by banging my head against the wall.

This is one of the few books (Code Complete also comes to mind) that I would make required reading for development teams and programmers just coming out of college. The simple and concise framework makes for a great way to organize all the reading and education that is coming later. In fact, you could read a section of this book, then read a couple other books that just deal with that section, then move on to another section. Or you could take parts that you didn't grok and dive deep on them.

It's an excellent book -- easily in the top five programming books I've ever read -- and every programmer worth his salt should not only read it but have one close-by for reference.


the buzz

Nothing to see here, please move along
Nothing to see here, please move along
Nothing to see here, please move along
Nothing to see here, please move along
Nothing to see here, please move along
Nothing to see here, please move along
Nothing to see here, please move along

Programmers are craftspeople trained to use a certain set of tools (editors, object managers, version trackers) to generate a certain kind of product (programs) that will operate in some environment (operating systems on hardware assemblies). Like any other craft, computer programming has spawned a body of wisdom, most of which isn't taught at universities or in certification classes. Most programmers arrive at the so-called tricks of the trade over time, through independent experimentation. In The Pragmatic Programmer, Andrew Hunt and David Thomas codify many of the truths they've discovered during their respective careers as designers of software and writers of code. Some of the authors' nuggets of pragmatism are concrete, and the path to their implementation is clear. They advise readers to learn one text editor, for example, and use it for everything. They also recommend the use of version-tracking software for even the smallest projects, and promote the merits of learning regular expression syntax and a text-manipulation language. Other (perhaps more valuable) advice is more light-hearted. In the debugging section, it is noted that, "if you see hoof prints think horses, not zebras." That is, suspect everything, but start looking for problems in the most obvious places. There are recommendations for making estimates of time and expense, and for integrating testing into the development process. You'll want a copy of The Pragmatic Programmer for two reasons: it displays your own accumulated wisdom more cleanly than you ever bothered to state it, and it introduces you to methods of work that you may not yet have considered. Working programmers will enjoy this book.


What is this?

A while back I wrote an article on my blog listing all the books that hackers recommended to each other from the site HackerNews. The purpose was to provide a place to list book recommendations so that people didn't have to type in the same list over and over again. (HN gets several requests for book recommendations a week. I also get at least a couple each month). It was very well received, and many posters and commenters either asked that I make a site or sent me an email asking me to do so.

How is this any different from the list on the blog?

This list has more books. This list is sortable both by what question you have and your skill level. In addition, once you sort the list, you can save the link with your sort and send it to somebody else. So, for instance, when somebody wants a book for noobs learning to program, you can make a link for that and then reuse it

How did you collect these books?

Initially the list came from Googling "best book" and taking the books from the first few pages returned. Later, I added all the books that were mentioned "You left that out!" when Jacques posted the link. While adding those books, I came across a Stack Overflow link where programmers were asked to list their favorite tech books, so I included those too.

If I ask you to put a book on here, will you?

It depends.

These books were all gathered by finding places where hackers hang out and are suggesting books to other hackers and other hackers agree with them by voting up their suggestion. If I can find an example of this for your book, I'm happy to include it.

How are the books ranked?

I did the best I could with ranking. I am sure there are many things you do not agree with. It would be possible to add voting and personal ranking -- that would make the system much better. Heck, you could rank the books yourself and use it as a customized book list to show to people who want your advice. I'd like to do that, but if I've learned anything is to not let your featureset get ahead of the users. This first version will test the waters to see what kind of interest the community might have.