5 ms·

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 seem

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.

jkmcf 7y ago
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...
16bytes 7y ago
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 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.
WalterBright 7y ago
When I finally read Romeo and Juliet, I was surprised at how many cliches and tropes were in it.
- billforsternz 7y ago
  First time ever I've wanted to upvote multiple times on HN
- gridspy 7y ago
  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. ;)
  - deleted 7y ago
    [deleted]
  - narcindin 7y ago
    That is the joke gridspy, the parent comment was being sarcastic and comparing Romeo and Juliet to the Pragmatic Programmer.
  - billforsternz 7y ago
    For goodness sake. Casting pearls before swine.
  - loco5niner 7y ago
    You missed the (clever) point.
- volkadav 7y ago
  With a nod to Fallout: "Teenagers. Teenagers never change." ;)
SloopJon 7y ago
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.
jsperson 7y ago
> 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.
- Godel_unicode 7y ago
  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".
  - Jtsummers 7y ago
    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.
    - roland35 7y ago
      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!"
  - mandeepj 7y ago
    > 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 :-)
samlents 7y ago
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?
hyperpallium 7y ago
Like reading a novel that created a stereotype/trope - so derivative!
steveklabnik 7y ago
This effect happens in a lot of ways: https://tvtropes.org/pmwiki/pmwiki.php/Main/SeinfeldIsUnfunny https://tvtropes.org/pmwiki/pmwiki.php/Main/SeinfeldIsUnfunn...
irrational 7y ago
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.
- ska 7y ago
  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...
- tannhaeuser 7y ago
  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.
  - sedachv 7y ago
    > 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.
- greyhair 7y ago
  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.
Evanbenn 7y ago
Redis seems like an example of a modern 'blackboard', what do you think?
deleted 7y ago
[deleted]
thebouv 7y ago
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.

jkmcf 7y ago

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...

16bytes 7y ago

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 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.

WalterBright 7y ago

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

billforsternz 7y ago
First time ever I've wanted to upvote multiple times on HN
gridspy 7y ago
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. ;)
- deleted 7y ago
  [deleted]
- narcindin 7y ago
  That is the joke gridspy, the parent comment was being sarcastic and comparing Romeo and Juliet to the Pragmatic Programmer.
- billforsternz 7y ago
  For goodness sake. Casting pearls before swine.
- loco5niner 7y ago
  You missed the (clever) point.
volkadav 7y ago
With a nod to Fallout: "Teenagers. Teenagers never change." ;)

SloopJon 7y ago

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.

jsperson 7y ago

> 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.

Godel_unicode 7y ago
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".
- Jtsummers 7y ago
  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.
  - roland35 7y ago
    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!"
- mandeepj 7y ago
  > 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 :-)

samlents 7y ago

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?

hyperpallium 7y ago

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

steveklabnik 7y ago

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

irrational 7y ago

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.

ska 7y ago
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...
tannhaeuser 7y ago
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.
- sedachv 7y ago
  > 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.
greyhair 7y ago
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.

Evanbenn 7y ago

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

deleted 7y ago

[deleted]

thebouv 7y ago

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.