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 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.
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 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!
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.
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.
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.
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.
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!"
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.
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.
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)
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.
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.
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?
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.
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.
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.
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.
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...
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.
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.
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.
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.
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.
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...)
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.
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.
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.
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.
>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!"
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.
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...
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.
I understand just fine, it just sounds like software is too hard for some folks, and while that's okay, but there are those of us who aren't burned out by doing our jobs.
Since many of us have vastly different jobs in practice (no matter similar in principle), your continued insistence that people being burnt out by their jobs means that software is too hard for them is obnoxious and blatantly untrue.
Do you not enjoy greenfield projects? Many programmers prefer them. If you never get to do greenfield projects all the time and are instead stuck doing maintenance, that doesn't sound like a lot of fun right?
Maybe you are someone who enjoys maintenance. Glad you've found your niche. But don't insult people who are good at what they do, but don't enjoy the parts they don't enjoy.
The attitude you're presenting is a huge problem in software development, and I firmly stand by what I've been saying -- if you're unwilling or do not like maintaining software, get the hell out of the industry.
A developer without a mind for writing maintainable code is a bane to the existence of everyone who works with him/her, and a developer who constantly builds new projects and does not have to stick around to keep them running will never grow that mind.
You actually said 2 things. I thought your first point was perfectly reasonable, as you misinterpreted it.
> Whats with companies constantly throwing people in the trenches and forcing them to be in constant maintanence mode all the time?
> Because companies like to make money, and they can't make money when systems fail.
The second issue you raised is a nonsequitor, because you clearly misconstrued the initial point. Your refusal to acknowledge there was a different interpretation, pretending you meant something nonsensical on purpose, has compounded the optics.
GL with that.
> 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.
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.
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.
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.
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.
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.
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?
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.
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'd love to see more people pick them up.
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.
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.
> 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.
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.
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.
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.
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.
Fortunately there is no opposition to version control in their group, it's just momentum keeping them from changing.
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 :-)
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)
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.
There, I fixed that for you. ;)
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.
Can you recommend a book akin to Desi...Things that you feel better describes "modern" design?
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.
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.
20 years ago this stuff wasn’t prevalent, and now people should at least be able to make educated decisions. But, alas...
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.
In 1989? Lots of RCS shops who had recently moved to CVS and were excited about the "C" part...
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.
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.
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...)
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.
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.
My own thoughts on this btw: https://mcconnellsoftware.github.io/struggle-design-balance/
This is probably not what you meant, but: The last thing I want in those types of discussions is "But book X says this!"
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.
Most of the time, you're just throwing crap together at the last minute. Doing things without saying no.
My first dev job was so terrible, I almost quit this career entirely.
If maintaining a codebase causes burnout, maybe software isn't for you.
If you make them well enough for the job, you haven't succeeded at your job.
If you make them well enough for the job and you don't need to constantly watch for failures, you have succeeded at your job.
If you can't say "this is as good as it can be done" for a given piece of software, you might have room to grow.
I said that if maintaining software burns you out, then maybe software is too hard for you.
So the only blatantly untrue and obnoxious comments right now are yours. Seems like this might be hitting too close to home!
Maybe you are someone who enjoys maintenance. Glad you've found your niche. But don't insult people who are good at what they do, but don't enjoy the parts they don't enjoy.
A developer without a mind for writing maintainable code is a bane to the existence of everyone who works with him/her, and a developer who constantly builds new projects and does not have to stick around to keep them running will never grow that mind.
If my attitude was one sided, it's because I was responding to your comment in kind.
> Whats with companies constantly throwing people in the trenches and forcing them to be in constant maintanence mode all the time?
> Because companies like to make money, and they can't make money when systems fail.
The second issue you raised is a nonsequitor, because you clearly misconstrued the initial point. Your refusal to acknowledge there was a different interpretation, pretending you meant something nonsensical on purpose, has compounded the optics. GL with that.
I have that problem with a few unfortunately good albums, but never would have thought that might apply to someone with a book.
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.
Hehe, no offense, just talking to myself.
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.
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.
However there were nuggets of gold in the original. Looking forward to finding the new bits and gems again.
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.
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?
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 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?
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.
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.