Introduction
Generalism
There's a lot in this issue about the difficulties generalist software engineers have in finding a home on software engineering teams. I'd love to say that it comes to a conclusion, but it doesn't: I think that there's a common playbook for hiring e.g. programmers (and not even e.g. programmers but e.g. front-end Javascript programmers or C++ financial modellers), testers, business analysts but not one for hiring software engineers. Many people who say they hire software engineers actually mean some subset of programmers.
The real way for generalists to thrive is to band together in consultancies/agencies and pick their projects/clients carefully, and not try to get hired as perms. But for the many "generalists" are software engineering generalists, not small-business generalists, and who (like myself) don't particularly want or thrive in the indie lifestyle, this is a risk/challenge too far.
Writing
You say “cave dweller debugging”, I say debug logging
One of those "I don't remember when I started doing this, but I do know that I haven't always done this" things.
On interviewing and generalist software engineers
This post follows on from the podcast episode in this issue.
Even more on generalist software engineering
It's become a bit of a theme this issue to talk about generalism in software engineering! Here I contrast a software engineering generalist with a polyglot programmer.
Video
Episode 40: more on XCake and buildtools
This really is turning into a "Mac build tools with Ruby" stream but I'm OK with that. Making Xcode projects portable to other platforms will be of great benefit to many.
Audio
Episode 53: Specialism versus generality
Is a generalist truly general? Did a specialist choose a good specialism? Some will be revealed.
Around the web
The golden rule of software distributions
I'm going to paraphrase the golden rule to check whether I understood it: whatever I can install from the distribution using its package manager had better be compatible with whatever else I can install from the distribution using its package manager.
Given an industry-wide lack of inter-package acceptance/contract tests, this is a problem that can grow combinatorially with the number of packages exposed. A distribution like Debian simplifies satisfaction of the golden rule through a set of packaging standards and filesystem rules that limit the scope of certain incompatibilities; they also "vendor" every component and take responsibility for packaging, testing, and distributing the whole system.
Increasingly distributors are taking a route more akin to the flatpak approach: isolate every component from everything else so there is no change for incompatibility, but install the same dependencies multiple times for everything that needs them.
The rise in interest in software supply chain security and software bill of materials that comes from being burned by vulnerabilities like the recent log4j vulnerability will I think push people more toward the Debian-like route, where for anything to get in it needs to be audited and tested.
Drop Whatever You’re Researching and Start Working on Crypto!
If this newsletter had an "And finally" section, this article would make the cut.
Agile and the Long Crisis of Software
Strong "outsider looking in" vibes from this thoughtful history and critique of Agile software development. I have previously written, and spoken, about how the Project Managers' Declaration of Independence was management killing Agile by claiming that management was Agile. I have even written, in agreement with this author, that another revolution is overdue.