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

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)

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.

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

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

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.

You missed the (clever) point.

For goodness sake. Casting pearls before swine.

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.

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.

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

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

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

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.