The Pragmatic Programmer

The Pragmatic Programmer: From Journeyman to Master by AndrewHunt and DavidThomas

ISBN 020161622X

I liked this book so much that I asked to write the foreword, http://c2.com/doc/pragmatic.html. -- WardCunningham

I have read it and it's the book I wish my coworkers would read. -- MichaelSchuerig

It is also a very good complement to SteveMcConnell's RapidDevelopment which I was in the middle of when I picked up PragmaticProgrammer. Reading them together is sort of like eating chocolate and drinking red wine at the same time. -- PhilGoodwin

I bought it a week or so ago and sat up half the night reading it. A very fine book. It reminds me somewhat of the excellent ProgrammingPearls, though it has more on "higher-level" issues than ProgrammingPearls does. My guess is that good experienced programmers ought to know most of what's in it, but even they will find plenty to interest and amuse them. I can't imagine anyone who does software, whether novice or guru, not benefiting from reading the book. Buy it now! -- GarethMcCaughan

I concur. This is a very good book. My manager saw a copy on my desk and flicked through it chortling all the while: his claim was that all programmers are idealists, so the title was an oxymoron. -- KeithBraithwaite

Sigh. I wish there was some way to have managers consider programmers as real people. -- AlistairCockburn

And vice versa -- AnthonyLauder

I recently finished it, and agree that it is a worthy book. I will recommend it. I must say that I found the writing style in the opening 20-30 pages to be somewhat annoying, but after that it changed or I got used to it and the rest was pleasant to read. -- MatthewWilbert

I am enjoying this book so much! Leaving aside RealityChecks (which it shows many, many bad things that sometimes happen, and indeed had happened to me as well), it gives, in what's worth my opinion, some really good practices for software development... I was doing some of them, and now I understand better what I was doing; I have embraced some others (from ExtremeProgramming and other lightweight methodologies) and I see them there, explained and recommended. And then there are those things I've never thought about, and have never been taught or seen around... All of them make real pearls.

Besides, it's really easy to follow, examples and exercises are perfectly understandable and to-the-point, and challenges are, well, that :)

All in all a book I'll highly recommend to my coworkers, customers and friends. Thanks for it.

I've already read it a dozen times, and some sections about 20 times or so, and I'm never tired of it, I seem to be prone to easily forget wisdom, and the book is right there to remind me and make my work much more enjoyable and better. So much in so little space, I love this kind of density :-) -- DavidDeLis

Many useful ideas; numerous amusing anecdotes. Well worth taking the time to read it. -- MichaelChermside

I hate this book. It means I won't be able to make money writing about my ideas, which are quite similar. Seriously, it is concise, clear, and rings true on nearly every aspect, in my experience. -- Pete Hardie

However: I see some of the topics seem to contradict some of the XP tenets, like MetaProgramming, and AlwaysDesignForConcurrency?; Discussion? -- PeteHardie

Its sort of orthogonal to XP. Dave and Andy like XP but think that it is restrictive in terms of the developers it embraces. -- TomAyerst

My guess is the majority of the world's developers are not covered by a typical XP setup, and that's a shame, as I want teams everywhere to start adopting light-weight, low-inertia disciplines.

I am very pro XP, because for the first time we have developers all over the world thinking about methodologies, and realizing that they have a degree of control over their environment. Now that we have some momentum, I feel it is time to broaden the scope, and to bring more development teams into the light-weight fold. I very much hope that XP can broaden its base - that's why I've been experimenting with and talking about the SpiritOfXp? in an attempt to isolate what makes XP from the practice of XP. -- DavidThomas

I think the SpiritOfXp? is a difficult one. XP carries a lot of baggage with it and takes lightweight methods in a specific direction (Extreme individual and group discipline). XP, Crystal Light, Adaptive, Scrum etc all seem to grapple with a similar problem but come up with different solutions. Its something to do with the nature of software delivery being different to everything else and the development of a unique set of strategies to do it. Perhaps abstracting the key differentiators is a way to go? -- TomAyerst

How well has the book aged? Is it still relevant today four years after publication, or does it merely have historic interest?

Still every bit as relevant as it was when first published. It'll continue to be relevant until some who new programming paradigm replaces the current software development trends (and probably be worth reading even then)

I've just bought ThePragmaticProgrammer book, and I'm really enjoying reading it. Since it's such an excellent and well-received book, I expect nobody will mind whining about one thing that hit a nerve with me in the Orthogonality section:

: "We once worked on a project that required that a certain body of Java code run both locally on a server machine and remotely on a client machine. The alternatives for distributing classes this way were RMI and CORBA. If a class were made remotely accessible using RMI, every call to a remote method in that class could potentially throw an exception, which means that a naive implementation would require us to handle the exception whenever our remote classes were used. Using RMI here is clearly not orthogonal: code calling our remote classes should not have to be aware of their locations. The alternative - using CORBA - did not impose that restriction: we could write code that was unaware of our classes' locations."

There is truth to this but it's an oversimplification that some people (myself included) are very sensitive to. In fact, with both RMI and CORBA, every call to a remote method could potentially throw an exception - the difference is that the one traditionally used in CORBA stubs is a RuntimeException, and RMI's RemoteException isn't so it's checked by the compiler. AnoteOnDistributedComputing is a really interesting paper to read for a perspective on distributed objects and "location transparency" for anyone who's interested in this stuff.

The reason I bring all this up is that it's actually a very interesting topic that I've spent a while thinking about. When I was doing some CORBA programming, I had an idea: use a request-level interceptor to trap exceptions caused by "distributed object stuff" like network failures, and when they occur, instead of throwing an exception at the caller I would: leave the caller blocking, and then contact a central error handling object to tell it what happened - that object could then perhaps try to bring the connection back up (maybe contacting an alternative object, or waiting a little while for a restart, or something else depending on the application), and then retry the request on the caller's behalf, or do some sort of sensible abort. I never implemented it, but to this day remain curious about whether it would be Good. Has anyone tried an environment that works in this way?

-- LukeGorrie

Yes. This is the basic algorithm used in resilient networked systems. I should do a boundary adapter example for this. DualPathAdapter. -- RichardHenderson

See UnderstandingDistributedSystems and LocationTransparency. --

Another alternative is asynchronous communication. WouterLievens?

ThePragmaticProgrammer QuickQuestions

Q I have a question about one of the challenges in the PragmaticProgrammer book. It's the orthogonality challenge on page 43:

What effect do multiple inheritance (C++) / multiple interfaces have (on orthogonality)?
What's the difference?
Is there a difference between using multiple inheritance and delegation?

I would be grateful for any pointers or ideas for examples (code) to try and implement. AnswerMe -- BrunoWassermann

A ?

CategoryBook, CategoryEnterpriseComputingConcerns