The Pragmatic Programmer, 20th Anniversary Edition | Hacker News Reader

The Pragmatic Programmer, 20th Anniversary Edition

pragprog.com

524 pointsduck113 comments

The original version of this book is something I'll always treasure. It sits next to "Code Complete", the Gang of Four's "Design Patterns" book and Martin Fowler's "Refactoring" on my top shelf and I still read parts of it every year.

Add Fogel's "Producing Open Source Software" and Brooks' Mythical Man Month and you've perfectly described my shelf too. I found most of those when I was a lowly junior developer and they were instrumental in shaping my thinking, approach, and understanding of tradeoffs.

I'd love to see more people pick them up.

I just looked and realized that I actually have Mythical Man Month next to the Pragmatic Programmer book...

Same here. Those two books seem to be ordered only as pairs. ;)

Kernighan and Pike’s “the practice of programming” is up there with those on my shelf.

Yes. That book has probably shaped my thinking and coding more than any of the others above (although they are also very good).

Would you still recommend the original version? I have a printed copy and tried to read it ages ago, but gave up (it bore me). I am sure I'd appreciate it better now, but with a new edition coming out I'd be wondering whether I'm missing out.

When I first read it 5 years into my now 10 year programming career, it felt timeless. I've been meaning to reread it ever since. Curious what I would think now.

Hunt and Thomas themselves don't really recommend it anymore. Large parts of the industry have changed over the years. They're interviewed in episode 352 of The Changelog podcast. It's worth a listen if you're a fan, or interested in either edition.

That was a great listen. Thanks for the recommendation.

Ssh you're not meant to confess to design patterns these days ;-)

To any new grad reading this...Code Complete is still relevant !!

I bought a rubber duck for fun after reading the first passages as a student. Sincr then I've been known as the rubber duck guy and people constantly gift me them. They are all over the office.

I couldn't bring myself to do it for real with an actual rubber duck. But I recently came up with the concept of "comment ducking" which is when you just start writing a comment in the source code as if you were explaining to someone and that actually works as a substitute!

I used to think those books were great before I got my first job at FAANG. Literally the only thing that matters is moving fast. Technical debt is just the price of scaling and beating the competition. Code quality is really not important at all as long as the product works and is bug free.

So I’ve become extremely nihilistic about software development. It isn’t that I don’t think the properties of clean code and software craftsmanship aren’t worth it, it’s that companies and the engineers who build them from startups don’t care and are focused on keeping their doors open. Long term health is a very secondary concern.

I’ve done my fair share of preaching that we should refactor and start focusing on quality during code reviews and it’s basically just shouted down with “don’t fix what isn’t broken” and YAGNI.

While I share your nihilism about engineering quality in a startup environment, if you don't keep your doors open, the long term health of your codebase will fall to zero.

If you have an established, cashflow-positive company that's not hell-bent on scaling fast (or being forced to scale unnaturally by VC backers) then the balance swings back and it becomes worth investing in your codebase.

> Literally the only thing that matters is moving fast

> Code quality is really not important at all as long as the product works and is bug free

According to Robert C. Martin is not possible to move fast without good quality.

That's the thing though. Martin says that, but then you watch a company scale to billions of people ignoring all of his advice. So the question is - does Martin actually have quantitative proof that what he is saying is correct, or is he just selling wishful thinking? The field of software engineering as an academic discipline is the least understood of the computer science subfields because it's qualitative not quantitative field.

Of course scaling to billions of users only proves that it can be done without quality, not that they could have done it better with quality software.

I recently walked away from a client who had this attitude. I want to take pride in my work, when I cannot I suffer for it.

The way I look at it is the following:

There are times to take the shortcut (Business reason, for example), and there are times to do the technically sound thing (long term health, usually).

A healthy software team is doing both as it makes sense. That's quality software dev. It's when business takes over the software teams decisions and you always take the shortcut that quality falls off a cliff.

I've worked in those environments too much. I want to be able to take pride in the work I do.

I was underwhelmed by this book. I think that so many of the practices (like version control) have become so popular that reading an argument for their use seems superfluous.

That also makes it really jarring when it recommends something that decidedly hasn't taken off, like the blackboard design pattern.

I had the same experience reading "The Design of Everyday Things". To some extent, these books seem most valuable as historical artifacts of what the tech world was like thirty years ago, rather than current references.

> I think that so many of the practices (like version control) have become so popular that reading an argument for their use seems superfluous.

This made me laugh - not because you aren't right (in theory), but because I just took over a project from a big four consulting company. When I asked about the location of the latest version of the code (after looking in VC and not finding it)...answer: on the production server. "We could have checked it into VC, but didn't want to take the time."

I've seen at least n=6 of these in the past couple of years.

Sometimes the oldies are goodies.

I was just told at my day job that the team will not be using VC for tracking production analytics code because "using git is over-engineering".

There's a set of projects in an adjacent work group that does not use version control. Instead, they create snapshots at various stages of development (before certain formal reviews). These snapshots are fine, actually they're useful, but they don't replace version control. I had a chance to explain and demo git to one of them, who'd written some 10k lines of code between snapshots, to explain how git could help him manage his work better (easier to try things and roll them back, as the primary one). This helped, he had started to use it though I don't know if it's spread yet.

Fortunately there is no opposition to version control in their group, it's just momentum keeping them from changing.

This reminds me of the comic which has a machine gun salesperson trying to sell to a medieval king who says "I can't be bothered with that, I have a battle to fight!"

> using git is over-engineering

Their compass to locate "over-engineering" is a bit off track. Engineering starts after you have put your artifacts in git or any other VC :-)

Time to start the job hunt.

I can't recall if it was in Prag Prog but it's one of my favorite Andy Hunt quotes... "Change your team or change your team"

Sometimes I think "software engineering is too immature for there to be a rigorous standards body and professional engineering certifications" and then I see shit like this and wish there were a way to punish people for gross negligence.

I've seen this as well. It was also super critical bootstrapping code/config. It is so embarrassing I won't say who. But not having code in source control is still a thing. Sometimes if it's in source control, someone has still edited something on production and not checked it in.

> Sometimes if it's in source control, someone has still edited something on production and not checked it in.

I worked at a large fintech company that had serious problems with this. About the only hope we had for mitigating it was moving all the services to run inside docker containers and of course ban developers from accessing the systems directly.

My business partner worked at an education-related company you've almost certainly heard of about six or seven years ago. When he started he ask where the defect tracking system was. The guy he was talking to pointed and said, "Go ask Susan. She has a spreadsheet." It was, as you can imagine, pretty much all downhill from there.

was this education-related company, related to moocs ?

Not that I'm aware.

That boggles my mind. Maybe it is just where I have worked all of my 35 years, but source and bug tracking were always at the forefront of every engineering effort. Hardware and software, didn't matter. Code and documents. Requirements and design. Everything was tracked. If you had a printed requirements document in your hands, you could look up what the current working version was, and check that against the version printed on the first page. (yes, we used to print documents, back in the days of VT220 terminals....)

Who in their right mind works without version control? Who would want to? And version control has just gotten better and better over the years. I started with SCCS -> CVS -> SVN -> GIT (with a couple of side treks into Perforce and Clearcase). Currently using Bitbucket/Jira, but have also recently used raw git/gerrit. (The organization makes the choice)

What about "The Design of Everyday Things" strikes you as stale? It's been a while since I've read it, but I don't remember feeling that way when I was reading it. That being said, I was just getting started, so I was doubtlessly lacking context.

Can you recommend a book akin to Desi...Things that you feel better describes "modern" design?

Like reading a novel that created a stereotype/trope - so derivative!

This effect happens in a lot of ways: https://tvtropes.org/pmwiki/pmwiki.php/Main/SeinfeldIsUnfunn...

I found it curious that you felt a lot of material was anachronistic. Perhaps that's because I was around as a professional before it was the normal and have recommended this book so many times.

When I review the list of tips--which for those unfamiliar, is basically a list of take-aways sprinkled through each chapter--I find the list more timeless than anything.

https://pragprog.com/the-pragmatic-programmer/extracts/tips

The number of times I've told people that "select" isn't broken, or to use tracers, or fix broken windows is more than I can count.

When I finally read Romeo and Juliet, I was surprised at how many cliches and tropes were in it.

First time ever I've wanted to upvote multiple times on HN

When I finally read Romeo and Juliet, I was surprised at how many cliches and tropes were __from__ it.

There, I fixed that for you. ;)

That is the joke gridspy, the parent comment was being sarcastic and comparing Romeo and Juliet to the Pragmatic Programmer.

For goodness sake. Casting pearls before swine.

You missed the (clever) point.

With a nod to Fallout: "Teenagers. Teenagers never change." ;)

I think it really depends on when you read it. Code Complete was in the first handful of books I read about the practice of programming, apart from language-specific books, and I loved it. Years later I bought the second edition, having given away my first copy, but the magic was gone.

I didn't get much out of The Pragmatic Programmer myself. Maybe if I'd read it ten years earlier, it would have been my Code Complete.

30 years ago? That was 1989. How many companies were using source control in 1989? How about 1999? Still not very many. 2009? Well, now you will find quite a few using SVN, but Git hasn't really taken off yet.

I take your point but by 1989 there was at least 10 years or so of history in industry with source control. Granted it had not seen universal adoption.

In 1989? Lots of RCS shops who had recently moved to CVS and were excited about the "C" part...

They did use SCCS, RCS, and CVS, and also commercial SCMs such as PVCS. There were also file systems with integrated revision support on VAX/VMS and other "midrange" systems such as Norsk Data/SINTRAN. Of course, most people were applying adhoc "Cognac" SCM: rename your old revisions by appending ".old", ".vo" (very old), ".xo" (extra old) and so on until it becomes untenable, store individual customer builds, etc.

> There were also file systems with integrated revision support on VAX/VMS and other "midrange" systems such as Norsk Data/SINTRAN.

Versioned file systems were developed for source code management and go back to ITS and TENEX in the late 1960s. So version control as we know it, as a widespread (at least in the DEC world) practice dates back to the 1970s.

My first engineering job, 1984. All source code was in version control (SCCS wrapped in some tracking tools) and all bugs were tracked. By 1989 we were doing root cause analysis on all defects.

Redis seems like an example of a modern 'blackboard', what do you think?

Oh I think you would be surprised and horrified at how many billion dollar companies with large development teams still don't do version control properly, or at all.

A pattern I see recurring from teams that were forced to start doing version control begrudgingly:

Pull down code from staging or production to local machine. Make changes. Push to qa or staging to test. All good? Push to production. All good? NOW push it to version control.

W. T. F. F?

Keeps me up at night.

There are quite a few people at my company who resist “new” techniques, even if they are things like static linters.

20 years ago this stuff wasn’t prevalent, and now people should at least be able to make educated decisions. But, alas...

There's some good advice in the book, but I found the majority of it seems to be rather goldilocks flavored. Implement the features you need, but don't add too many, but don't omit important ones either. Write some documentation, but not too much or too little. Etc. You read it, and oh yes, very wise, but not really helpful? Not much here would be useful in resolving a dispute between two programmers, one who wants to do things one way and one who wants to do it a different way.

I'll agree with your summary, but I'll also argue that moderation is often a lesson coders need to learn/remember. It is easy to "know" in theory but become dogmatic in practice. There are reasons we are still learning the lessons from 30+ years ago - we keep getting dogmatic about concepts that interfere.

I think GP's point is that saying "you need to do X, Y, Z" in moderation" carries nearly zero bits of information. Of course I don't want to overdo or underdo something. But how much is too much? How much is too little? How do I know? And since code is something that accumulates over time, how do I maintain the balance?

Answers to these questions is what's needed for coders to do a good job. The original book does encourage you to think about it, but doesn't provide many answers. The way I remember it, it was very useful at introducing you to concepts, so that you know that X, Y and Z are a thing in the first place.

You’re lucky it’s intuitive for you. I think it’s valuable to have credible sources backing up my intuition because I’ve worked in orgs that document way too much and way too little. So just calling out a desire for just right documentation (with copious examples) is handy to me so that people don’t idealize no doc systems or spend half their time documenting.

The people who say, "This is all obvious" are often the people who understand the "obvious" the least.

I think the complaint wasn't that the book was intuitive or not, but that it lacks actionable guidance. "Make sure to write the correct amount of documentation in a clear manner." sounds great on the surface, but doesn't actually help someone who is trying to figure out what the "correct amount of documentation" or "clear manner" actually is.

I would counter that there value to spending time thinking about doing things in moderation, especially for those who think they do, but don't. It's a chance to shift their internal thought process such that they are a little more likely to think about that while doing their work, because they are now more familiar with it in a (second-hand) experiential sense. This is damn hard to quantify in terms of value, but it definitely greater than zero IMO.

Agreed, the book is hit or miss in this regard. My take on actionable guidance ..

Step 1: choose a metric that makes sense.

Step 2: set a target for the metric.

Step 3: iterate until you hit the target.

So for "good, clear documentation" the right metric might be "other people using the documentation to do things and/or demonstrate they've learned something."

The target might be set a quiz or asking people to use the documentation to do something, and get a 80% passing rate.

The truly pragmatic thing is to not insist on getting anything right thr first time, to measure by outcomes not outputs, and especially to value the input of other people and be empathetic to your users, fellow developers, bosses and yes, even yourself (no failures, just data...)

Might be brutally simply and obvious but still too many people manage to not achieve it. Appreciate a practical framework for how to measure too simply vs too complicated might be helpful, but often I suspect teams aren't remotely interested in a "let's not overcomplicate this" influence.

My own thoughts on this btw: https://mcconnellsoftware.github.io/struggle-design-balance/

People have a tendency to become extremists. I sometimes think of it as a ridge, with cliffs on both sides. People look at one of the cliffs, and back away from it, because it's a cliff, and it's dangerous, and so they're going to make sure that they don't fall off of it. But they get so focused on that cliff that they forget that there's also a cliff on the other side.

So in that sense, the advice is good and necessary. But it's kind of not, because the kind of person who needs the advice isn't often the kind of person who reads such a book.

I would argue that "the people who need to read this book" will read it and then announce, yes, of course, that's exactly how I do things. Perhaps that's why it's so popular. Everybody can see themselves in it.

but that's the entire point. Almost all of programming is walking a line between awful and over-engineered. There's sweet spots that one has to find in every part of the software delivery process.

The way to resolve the dispute (should there not be much difference between them) is to arbitrarily pick one and iterate in short bursts to ensure its assertions come good.

Because software is largely based on intuitive understanding due to its largely creative nature.

The other side of the coin is that people are constantly reinventing the wheel, bloating the tool sets, and relearning lessons already learned because of lack of standardization.

> goldilocks flavored

Sadly true of far too many "influential" books. Although I did enjoy reading it, I finished it in an afternoon - if that's possible, it's probably not hiding any real deep wisdom.

I haven't read the book, but I have to challenge the assumption here. That you didn't get anything out of it in an afternoon's sprint through it does not make it "probable" that it's not hiding any deep wisdom. It could mean that, or it could mean that you didn't stop to digest what it was actually saying.

>Not much here would be useful in resolving a dispute between two programmers, one who wants to do things one way and one who wants to do it a different way.

This is probably not what you meant, but: The last thing I want in those types of discussions is "But book X says this!"

There’s been a lot of love for this book, but I found the title to be jarring. When I was given the book to read, I was doing a lot of maintenance work, and was doing a lot of ‘duct tape and bailing wire’ kinds of fixes to keep the systems functional, while slowly addressing the root causes of downtime and issues. To me this was truly pragmatic programming, but nothing in the first few chapters even tries to deal with the levels of pragmatism I needed in my day job that had far too many night time wake up calls. I couldn’t finish it. Any wisdom the book may have was lost to me, and I’ll likely never pick up the book again, I associate it with too much PTSD from that time in my life...

> I couldn’t finish it. Any wisdom the book may have was lost to me, and I’ll likely never pick up the book again, I associate it with too much PTSD from that time in my life...

I have that problem with a few unfortunately good albums, but never would have thought that might apply to someone with a book.

Whats with companies constantly throwing people in the trenches and forcing them to be in constant maintanence mode all the time? I feel like they are just asking for burnout and turnover. If its that bad, give it to someone to greenfield some painful part of it rather than spend their life on the hamster wheel.

You'd be surprised how much companies operate in silos without any training, design, or planning.

Most of the time, you're just throwing crap together at the last minute. Doing things without saying no.

Sink or swim is poor management, but if you're young, at your first tech job or haven't experienced anything better, how would you know?

My first dev job was so terrible, I almost quit this career entirely.

If you're not saying no often as either a designer or a developer then you should be concerned.

The book isn't meant to be read front to back, the "most relevant" parts of the book for your situation aren't magically going to appear at the beginning.

Try reading it again, this time thinking of each chapter as its own, separate story.

Don't fall into the trap of "This is popular so I'm going to express criticism". If you want to, you can extract a great deal of wisdom from this book.

Don't fall into the trap of "This is criticism of something popular merely because it is popular"!

Hehe, no offense, just talking to myself.

Sounds like you may have.

I haven't read it, but I've heard a lot of praise for Refactoring by Fowler for being immediately useful during maintenance.

I read the first edition back in the days; and again, and again. Back then, during my first years working as a programmer, it was a gold mine and definitely helped push me in the right direction.

One of my favorite authors wrote that every book eventually becomes a prison for the mind. At some point you will transcend the content which means it's time to move on. But that doesn't change anything about the book, it's still as excellent as ever for others.

The only constant in this universe is change.

This book is in my opinion the most important book for professional software developers. It teaches you the craft.

Anyone with an opinion on the new edition? Worth buying if you already read the old one back when it came out?

The codingblocks podcast has a whole series discussing the various chapters: https://www.codingblocks.net/category/podcast/

I read this book -- well, twenty years ago! I wasn't a very experienced developer at that point, and I found the book extremely helpful.

What I've never been able to figure out is why it has never been updated in all that time. Does anyone know? I heard from someone who heard from someone that there was some kind of legal reason they couldn't update it, but I can't really imagine what that would be.

Obviously, lots of books don't go into multiple editions, but given what this one was about, I felt like it couldn't possibly be entirely full of "timeless advice" that wouldn't ever show its age.

Why concurrency? And why advocate a particular solution? A good solution, in my experience, isn't any particular implementation: it's to think about it, really hard, using tools that help you think about hard things... like math. "Actors," is like... soy sauce.

However there were nuggets of gold in the original. Looking forward to finding the new bits and gems again.

This book was a tremendous influence on me as a young professional programmer. I still quote from it regularly. ("SELECT isn't broken!")

One thing I have used over and over again out of this book is the concept of a “Tracer Bullet”. I find it works extremely well for not just code, but any complex system you are working to define.

I don’t think a month goes by that I don’t quote this concept to a group or individual. Really appreciate how they put all these ideas together.

Though I've never read the book, I've seen it mentioned so many times, I've gone to look at and skim pieces of it many, many times. My impression, which I agree could be completely wrong but I'd still be willing to bet money on it, is that the book is poorly organized and really just seems to be a really long rant. It's impossible to tell what a chapter or section is about from its heading. To me, that tells me the authors really didn't have a solid concept of what point they wanted to make before they started. From what I've skimmed, most of the knowledge seems like things that shouldn't need to be said, perhaps some people need to hear them. Without some sort of organization it's impossible to tell which parts of the book might be worth reading for me, I certainly don't need to read all of it.

While your at it, please update "Pragmatic Project Automation".

I should elaborate. Excellent book by Mike Clark, under the Pragmatic Programmers umbrella. Based an Ant and Cruise control. An updated version using a modern stack would be awesome.

Incomplete response received from application

That is what I got from the link.

I haven't read that book in fifteen years. Are there any interesting changes since the first edition?

Just read the DRY chapter, you can read it for free to get a feel of the book if you follow the link. Looks good to me, I will be picking this up.

https://www.amazon.com/Pragmatic-Programmer-journey-mastery-...

Buying from the pragprog site gets you a 50% discount on the hardcover when it comes out, if you have any interest in the paper version.

So, worth buying ?

I believe it is.

Not all of it may appeal to you, but if there are just a few points that help you become a better programmer then it's worth it.

I... I don't know.

I have never read this book. Ironically, I have read and enjoyed many books from PragProg. But this one always struck me as a "fufu" book, written around giving advice that one can independently reason and acquire during one's career.

Am I wrong? Is this book worth reading if you already have many years of experience under your belt?

It's one of those books that is so widely read, that most of the lessons become common knowledge.

> Is this book worth reading

If you have a day to kill, it's an entertaining read, and if you're an experienced developer, you'll find yourself shaking your head or nodding along throughout. But it's mostly just entertaining, well-written anecdotes - there's not really that much to _learn_ there.

This is exactly the type of answer I was looking for. Thank you sir.

The main lesson of value I took away from this book is to value working software above all the trendy tools and tricks and languages and processes - including what "Agile" itself has become.

I visited the link with noscript enabled, and was redirected immediately to https://pragprog.com/no_js

So I disabled noscript, which refreshed the page automatically, so of course I was still on https://pragprog.com/no_js and not https://pragprog.com/book/tpp20/the-pragmatic-programmer-20t...

...Not very pragmatic of them IMHO.

I do quite enjoy my copy of the book, however :P

If only to reassure me that I am generally doing things correctly, it didn't really teach me a whole lot.

Never hurts to brush up on the basics.

Reply on news.ycombinator.com