The authors made a really good job here. They conduct the reader through a solid line of thinking, pointing out mistakes that even experienced engineers use to make.

The book has a good size, however, I would like to see a shorter Resources section - much of its content is outdated - and more real-life examples upon the main concepts.

Finally, I wish I had read this book back when I started my programming journey.

I could have benefited from reading this book earlier in my career. It's full of good advice. Sometimes maybe too generic, but I found it relatively easy to connect them to my work.

I don't think I can gush enough about this book.

It's the kind of thing I unconsciously resist reading because I know of all the guilty feelings it could provoke. Well, one thing I can tell you is that it's not like that at all. Oh actually, yes it is. The first chapter starts off gently reminding you that you should be constantly learning new things, for example, a new programming language every year (not necessarily because you want to have mastery of that language, but because it's good to keep your brain flexible, and keep looking at things at a new angle). And yes, there is a chapter near the end, about ruthless, aggressive testing, seeking out new and exciting ways to break your code. But I think that's all the guilt there is. If you can stomach those two things, the rest of the book is packed with, plain English, fad-free, common sense (and not so common sense) advice that you can actually apply.

You get a survey of all these cool technologies (again, nothing fad-like) that you could maybe give a spin to or that you've heard off but never got over the inertia to try out (although one wonders how many false problems would just go away if you would just use a purely functional programming language). But the book isn't really about technology, is it?

It's about craft and attitude. That's the thing that makes the book so gush worthy. You read the thing and you realise "oh, so this is how grown-ups hack". I wonder how much of this will actually sink in and affect my daily life as a programmer, though. Will I be that extra fraction more rigorous in my approach? Will I maybe be a little bit more aggressive, a little bit more disciplined, a little bit more humble? [And that's the wonderful thing about this book, it never exhorts the reader to be aggressive, disciplined and humble; it just is these things and its very being rubs off on you:].

It's worth reading. Maybe owning. Maybe going into little monasteries where every day starts with a Pragmatic Programmer reading ("let us code").

Definitely a 5-star book for a developer with less than 5 years of experience but if you have more than 10 years of experience, it will probably not teach you much.

I no longer have any need for mentors or friends now that I have AVClub (the AVQ&A and "Gateways to Geekery" columns in particular), Quora, and Stack Overflow.

Case in point: That I found this book. Over the past couple of years I have been gradually writing and less-gradually maintaining a code base for separate projects. It's getting the point where I might as well figure out what the hell I'm doing. So I go to Stack Overflow and find my way to a question like "What programming book do you wish you had read early in your career?" This book is the top answer.

The think I like about this book is that it is very high level and it makes a lot of sense. They make their point and move on. But that doesn't mean they aren't touching on some key issues in knowing what they hell you are doing. When I found myself thinking, "yeah yeah," that's when I knew I needed to slow down and pay attention. Unlike most books on coding, this one has aged/will age very well.

Out of the many good points made in this book, three of them are my main motivation lately:

1. Don't keep separate copies of important code or data. Eventually they will get out of sync and lead to madness. (This is summed up as the DRY principle: Don't Repeat Yourself.)

2. Automate everything possible. If you are following (1), you will wind up doing (2) out of necessity.

3. Keep everything, even the dinkiest script, under source control. With tools like Dropbox that have a "packrat" option, this is easier than ever. But a formal source control system is preferable.

With these three principles you can pretty much bootstrap yourself to any level of competency. Now I look at the regular manual tasks that I perform (and others perform) with utter disdain. And I understand why Doc Brown automated feeding his dog in Back To The Future. It is the only way forward.

I bought this book to read on a flight to NY. But I found it so motivating that a few chapters into the book I got out my laptop and started implementing the ideas that were popping in my head. Good stuff.

(Their love of Perl strikes me as a little misguided, but who am I to judge?)

Worth a read when starting your career in software development.

What Felix said

Is there a point to reviewing a technical book that is now 20 years old? Probably not, in most cases. However, this is a book that is still highly recommended by a large number of people.

I'm not really sure why.

Independent of the age of the book, I simply don't think it is particularly good. Sure, the technical information is often out of date, but given the style of the book, this isn't much of a problem. There are a number of issues with the book that absolutely are problems, however:

The advice often assumes the programmer has far more autonomy than expected

Some projects give the autonomy to pick languages, methodologies, libraries, tools, and whatever else goes into it, but this is not common. For example, when they talk about taking responsibility; this is all well and good, but there's a fine balance between taking responsibility and simply throwing yourself under a bus.

As another example, when talking about estimation, "...this may not be popular with management, who typically want a single, hard and fast number before the project begins." Yes? Likely, if they want it, they will get it in the end. While the points they make about estimating are reasonably salient, it should really say up front "in reality, you may be forced to produce a guesstimate, here's some advice to deal with this situation..."

Programming by coincidence, much of what is written in the "how to program deliberately" section may be out of your control. What to refactor and when to do it, what to prioritise, not "programming blindfolded" (i.e. attempting to build an application you don't fully understand or use a technology you aren't familiar with") - these are all making big assumptions. In fact, even the idea that whatever behaviour you are relying upon (the central theme of this point) is documented at all is absolutely not guaranteed to hold.

Many points are of extremely dubious benefit

For example, Reversibility, which talks about using CORBA as a way of insulating languages/platforms but doesn't even give a passing mention to the (arguably enormous) overheads this introduces in ease of implementation, or debugging, or potential performance, or added failure vectors, or...

Shell games is another one, and makes me question some of their own advice regarding thinking about your audience when you write. This section is ostensibly aimed at people who seemingly don't know much at all about (nix) shell(s) (so...perhaps Windows programmers?), but otherwise have enough experience to make sense of the rest of the book. It then goes on to show maybe 2 or 3 basic examples, which are superfluous to anyone that has spent some time with (insert *nix shell here), and likely useless to those who haven't...which is who this is aimed at. Huh?

Algorithm Speed is effectively a first lesson in Big-O notation, again, seemingly written for people who have never stumbled upon the concept before. Fine, I'm willing to forgive this somewhat (perhaps this assumption was more likely to hold in 1999, or perhaps it still does hold). My issue is that after the 10 minutes or so worth of material, they go on to recommend reading Knuth, which actually makes me angry from the sheer stupidity of that recommendation.

Metaprogramming goes down the rabbit hole of systems automatically configuring other systems,
again, without even paying lip-service to the issues this can cause (how much harder to test does this make it exactly? Please give your answer in orders of magnitude). This is even more egregious given earlier points talk about the Unix Philosophy (which this is so far away from, it might as well be on the other side of the universe).

Some points are obvious or are ridiculously short for the broad topic they purport to discuss

Power Editing could be cut down to "use a powerful editor" without much loss.

Text manipulation may as well be "learn a scripting language".

When to use exceptions, while being extremely language-dependent, is a debate that's been going on for many, many years. A few minutes worth of reading is going to bring very little clarity to the situation.

Some really terrible analogies

I'm highlighting this because there's a quote from Kent Beck in the front of the book regarding "...solid advice and wonderful analogies!"

The chapter on tools is rife with analogies, but the worst offender is in Text Manipulation, which uses the analogy of text manipulation languages being to code what routers are to woodworking, with a footnote clarifying that this is not a device for interconnecting networks. It goes on to describe them as "noisy, messy, and somewhat brute-force. Make mistakes with them and entire pieces can be ruined".

Firstly, analogies are supposed to clarify by likening something unknown to something that the reader does know, and has experience with. The very fact that they needed a footnote for this means the analogy has already failed. Not only that, but it then continues talking about how you can ruin something with a router...except on the other side of the coin, we're talking about source code. You know, that thing that you can duplicate infinitely and that's sitting in a revision control system?
The whole analogy and its further elucidation are so poor (my notes: profoundly f***ing stupid) that it boggles my mind.

Not everything is bad

My review might feel nitpick-y, and even I might agree to some extent. There is advice in this book that is good; talking about Software Entropy, the actual advice on the mechanics of Estimating are reasonable, as is their advice in Debugging. The section on Dead Programs Tell No Lies is a bit anaemic, but has reasonable advice. Code That's Easy to Test I'd actually like to staple to a few cubicle walls ("testing is more cultural than technical" is probably the most poignant phrase in the book).

In general, I would say the final two chapters are the best, or at least my scribbles are more akin to "this advice seems solid enough" rather than less flattering scribbles for the proceeding sections (I am curious though about these mythical teams, mentioned in Pragmatic Teams, that have people who do nothing but documentation - I could do with some of them).

In the end, however, there's too many times I've written something like "is this all?", "this section feels short", "this is mostly waffle", or some other variation on a theme. The added fact that there are some really very dated things in this book, most of them benign but potentially confusing for the less experienced, some of them unintentionally humorous ("This is likely to change at the same speed as Java - rapidly" or "A feature such as syntax highlighting may seem like a frivolous extra"), doesn't really help matters.

All in all, I think this book is greatly overrated. It lacks depth, and the bits of wisdom it does contain aren't really worth slogging through the rest of it to get to, despite its short length.

I expected to find a lot of great advice even for someone with great experience but it seems this book is more targeted toward beginners.

Carmack said it was good. It is!

به عنوان یک برنامه نویس مبتدی چیزهای زیادی از این کتاب یادگرفتم. مثال های عالی توی هر قسمت زده شده و حتی اگر قسمتی از کتاب هم قدیمی شده باشد با توجه به تاریخ نشرش واقعا ارزش خوندن رو داره .

A million stars! I got a hold of 20th-anniversary edition and holy shhh it is amazing! Up to date and upgraded, this book is really a holy book of programming. And it applies to life, not just programming, so a good read for everybody.