I'm not sure what I think of this. (I started programming around 1985.)
I don't think the older generation of programmers were any better than the younger generation in terms of skill. I think they were, generally, more practical -- they don't generally engage in language wars or programming evangelism, but when they do, they speak directly from a massive body of experience that's hard to argue with.
I think that the problems that they spent most of their time on were generally simpler. The most challenging bit of magic I ever worked on a mainframe was convincing COBOL to do variable interpolation on what was essentially punchcard-data-on-disk. (COBOL has no string operators or variable types, for those that are unfamiliar.) That was challenging, but it was a tiny problem in terms of scope compared to, say, building a scalable web application with a database backend.
I've worked with and hung out with greybeards, and generally prefer their company to that of hyperactive younger programmers. (For one thing, they don't talk about programming much!) They built things the same way we do -- by thinking about it and then banging it out one line at a time. They just used different tools.
Documentation was better back when. That's one thing I really don't appreciate about the Google Era; now, if I need information on some function or language feature, I usually end up reading some incomplete community-submitted documentation and a stack of opinions from people who may or may not know what they're talking about. For anybody that got to use those lovely old massive 3-ring binders (they came in sets!) with professionally-written and compiled in-depth documentation covering every single aspect of whatever you were using, there's just no modern replacement.
Otherwise, I don't really think the field of computer programming has fundamentally changed in all these years. The people are about the same. (Greenblatt was a pretty annoying, hyperactive young programmer once.) Some things are different. Some things aren't.
When I started programming properly ('84, '85?) it began with being issued the full shelf of IBM 3060 manuals - and when I mean shelf, I mean 3 feet. All my reference material was for the version I was using - relevant, complete, practival. We used to say RTFM and we meant it, you had an M to RTF.
To add to your list I like the PostgreSQL manuals. They always seem detailed and clear.
I find the Rails documentation awful lacking a lot of detail with an expectation that you read the source which in places is fairly hard to follow through several layers and even if you find the relevant part without good documentation you can't tell if it is a bug or intended behaviour in some cases.
Some people may have been blessed with access to good documentation, however for me the Internet was a godsend, because as a child I wasn't living near a tech hub or CS/math university.
Imagine being restricted to a computer with DOS 6.22 / Windows 3.11, with a QBasic interpreter and a pirated Turbo Pascal compiler that couldn't compile binaries in 386 protected mode and with access only to books describing high-school level data structures and algorithms in Turbo Pascal.
I was getting some extras from a local PC magazine that was sometimes bundling the provided CD with stuff useful for developers, like I remember an issue that came with some old tutorials on stuff like how to do graphics with double buffering in Mode-X 320x240 with 256 colors and on how to override the keyboard interrupt to get better input in games. But if I had a problem with any of the described functionality, I had no search engine to turn to.
See "Go To Statement Considered Harmful" and "Why Pascal is Not My Favorite Programming Language". Of course, less of this kind of stuff survives from that day than we see online now, but most programmers didn't even have access to Usenet 30 years ago, much less things like blogs and twitter. If you wanted to communicate something about programming to the world, you had to get somebody to publish it. Unsurprisingly, it was easier to get useful things like algorithms and data structures published than rants.
Maybe this is it? Even before reading this article, I've spent much of last week wondering why I spend valuable lifetime discussing trailing whitespace on github, instead of simply solving problems. Did programmers of past decades have other pointless battles to fight? Does anyone remember?
I've spent much of last week wondering why I spend valuable lifetime discussing trailing whitespace on github, instead of simply solving problems. Did programmers of past decades have other pointless battles to fight?
They have been fighting that one for longer than you know. :-)
There's something amusing about the source code to a pretty printer not conforming to its own defaults.
Also, from the README:
| Some history. Way back in 1976, the project I worked on at the
| University of Illinois Center for Advanced Computation had a huge
| battle about how to format C code. After about a week of fighting, I
| got disgusted and wrote a program, which I called indent, to reformat C
| code. It had a bunch of different options that would let you format
| the output the way you liked. In particular, all of the different
| formats being championed were supported.
Trailing whitespace on GitHub is only a problem if your editors treat it differently across the team and it generates a herd of rampaging git farts that obscures your commit history - that is a real problem that you do need to solve.