I've been reading Gerald Weinberg's "The Psychology of Computer Programming," written in 1971 (!), which is considered something of a classic. It's written as a textbook and meant to be used in a higher-level programming course for both programmers and their managers.

Chapter one has some interesting passages. First, there are the potential HR violations. At a previous employer, the in-house code of conduct included this gem:

Examples of unacceptable behavior include:
  • The use of sexualized language or imagery and unwelcome sexual attention or advances,

Weinberg is big on learning by example. Even in 1971, he wants you to read other people's code to get used to it. But his examples are laden with randy imagery: "Late at night, when the grizzled old-timer is curled up in bed with a sexy subroutine or a mystifying macro, the young blade is busily engaged in a dialogue with his terminal." In a passage about learning how to read other people's code, he writes,

[Programs] are unlike novels, and the best way to read them is not always from beginning to end. They are not even like mysteries, where we can turn to the to the penultimate page for the best part — or like sexy books, which we can let fall open to the most creased pages in order to find the warmest passages.

Now, in 1971, Weinberg was definitely having a bit of a wink with his audience. The "professionalization" (read: the ejection of women) from the white-collar job of programming was more or less complete, and if there was the odd woman in the room (in many senses of the word "odd," as far as Weinberg's cohort was concerned), well, she'd just have to suck it up, honey. Guys are like that.

And yet, I'd like to push back on the idea that no degree of carnal language is acceptable in the software development space. I mean, in neither case does Weinberg discuss the gender of the participants; there's no unwelcome attention here. Besides, we talk about "slaying bugs" and "crushing the spec" and "burning down the backlog," and I find that kind of violent language crude and offensive, but it's perfectly acceptable.

Secondly, Weinberg is hip to "slow learning." He bemoans the age of "the terminal," and that people don't learn to read programs anymore, they just write them. He cites "a young novelist who claimed he never read as his work was too original to find inspiration from other books. His career misproves his claim." He talks a bit about how COBOL was meant to tell executives they could not only read code, but that they might someday write it, eliminating expensive and quirky programmers altogether.

I can't help but wonder what Weinberg thinks of the modern IDE with all its bells and whistles. I find myself liking LSP-enabled editors, and writing in Rust or Python is much better now that we have these tools. Instant feedback that the code is syntactically incorrect or has type errors or, in the best case, that there might be a cleaner way to write something, is awesome.

Weinberg would probably have mixed feelings about GitHub. He absolutely wants you to read other people's code, but sometimes you do so not out of an intersest in learning, but as an exercise in mockery. The Daily WTF lives strictly to do the latter. But there is a lot of high-quality code on there, which brings me to the questions at the end of the book:

  • When was the last time you read someone else's code? What took you so long?

The last time I read someone else's code was two days ago. I was reading the inside of the Rustlang image library in order to better understand how those developers thought about image processing, so that the code I as writing could fit into their development process witohut too much difficulty. I didn't read any yesterday; I had runaround appointments and other priorities, which in the evening were hijacked by my partner getting food poisoning.

  • When was the last time you read code you, yourself, wrote that was more than six months old?

Yesterday. While "upgrading" an old project, I discovered that the latest revision of the compiler throws a ton of maths warnings and, you know, maybe I should investigate those. What I learned was that, six months later, better decompositions than the ones I first used are now available to my mind, and I should think about a refactor that will save me grief and pain.

In all, my summary of chapter one is this: Time has moved on. Programming languages have gotten more ergonomic. When Weinberg was writing, GOTO was still a perfectly acceptable way of managing a subroutine. LSP and IDE assist in maintaining an ambient awareness of the correctness of code. Repositories like GitHub provide an enormous library of code, some of which is highly readable, and it's always good to point out when you find some code that makes great sense. The discipline of test-driven development means that, if followed well, you end up with highly readable code because Step Three is always "clean up the mess you just made" and make it fit the "Context, Container, Component, Code" model.

I'll probably enjoy the other chapters just as much. There's just something fascinating about delving into a book 48 years out of date about the work I do every day and seeing what's still relevant, and what has changed.