To be a career software engineer, one skill is paramount: the ability to learn new things. Not a language, not an editor, not a methodology — the willingness to put down the one you know and pick up the one the work now needs. I have had to learn a new way to do something so many times in this career that, laid end to end, the list is the career. TBT #1 started in 1972 with a horse race in APL on an IBM mainframe. This post draws what came after it, category by category, as timelines.

Resource Link
Where it started TBT #1: My First Program Was a Horse Race — APL, 1972
Some of the stops Welcome · IBM 1130 · Pipelines on OS/390 · BASIC on the TRS-80 · Mass Compile and PL/EDIT · reg-rs, four regression tools · Six wikis · APL\360 Revisited · The IBM 5100’s APLSV
The newest bars Saw #13: A Second Host in the Cloud
Prior post TBT #12: The IBM 5100’s APLSV
Comments Discord

How to read these. One bar per tool, 1972 on the left, today on the right; a gap means I stopped and a second bar means I came back. The bars are drawn from memory and rounded to the year — the point is the number of hand-overs, not the exact dates. Hover a bar for its years.

Where I was

The row everything else hangs from. The dates on the right half are the ones I am least sure of, and the ones that matter least: the pattern is the point, and the pattern is a new employer meant a new stack. The startups, in order, were LogiCoy, Likestream, Guidewire, Illumio and Signifyd.

Machines

Every row here is a different idea of what a computer is: a room you reached through a typewriter, a machine you fixed with an oscilloscope, a briefcase with a CRT, a kit on the kitchen table, a box under the desk, a rack in the garage, a VM in someone else’s building. Each one changed what “running a program” meant, and that was always the first thing to learn.

Operating systems

Time-sharing on a mainframe, a single-program loader on a microcomputer, UNIX and MINIX and then Slackware on a PC — and Linux has been one bar ever since, Slackware to Knoppix to SUSE to Debian to Ubuntu to Arch, six distributions and one kernel. This year adds two operating systems of my own.

Programming languages

The longest list, and the one where “learning a new way to do something” is most literal: every hand-over here is a different way of writing the answer down. APL has a second bar fifty years after the first.

Editors

A line editor inside APL, a keypunch, the two mainframe full-screen editors, and then one editor that has now outlasted every operating system on the page but one.

IDEs

In 1985 IDEs were a Macintosh and Smalltalk lab curiosity; the big Java IDEs made them an expectation; the current ones are a keystroke away from being agents. Emacs had a few years as one too.

Version control

IBM had version control before most of the industry had the phrase: CLEAR through the 1980s, then CMVC, both of them change-control systems as much as source control, where a change had a number and an owner before it had a diff. Every tool after that made a different promise about who could change what, when — CVS, RCS at Forte, Subversion, then Mercurial at Sun — and git’s promise, everyone, always, sort it out later, is the one that stuck. GitHub is where the lab now lives.

Terminals and shells

The 2741 was a typewriter; the 1130 had switches and lights; the 3270 was a form; the VT100 was a glass teletype that has never gone away. Everything I use today — mosh into an Arch box, tmux, a shell inside Emacs — is still pretending to be the last one.

Build and run

JES2 batch first: a job is a deck, a step is a program, and a dataset is a contract between them. Mass Compile sat on top of it. Everything since has been some way of saying “run these, in this order, only if needed.”

Tech stacks

The tools above rarely arrived one at a time. They came as stacks — a machine, an operating system, a language, a store, a server, a build — and each employer or project meant learning the next bundle, from the mainframe stack through LAMP and MEAN to the one I use now, where the build runs in the cloud and an agent does half the typing.

Debugging and testing

Dumps, an oscilloscope, a debugger, Chrome’s DevTools, a regression report. I have written the same regression tool four times in four languages, and a unit-test framework for each language that arrived without one — Forte 4GL, Gosu, sw-MLPL — which says something about what stays constant when everything else on this page changes. Not on a bar of their own, but in use the whole way: fuzzed input, and error injection to test the recovery paths.

Documentation

How the writing got done, which is its own list of hand-overs: markup that ran on the mainframe, a word processor and then its open-source successors, twice, the web, the wiki — I read Ward’s original in the late 1990s and installed my own for teams at Sun — and finally the plain-text formats that let documentation live next to code.

Working with other people

Memos, then office mail, then the wiki, then the video call in three generations, then the closed chat rooms — and, this month, IRC, because that is where the people who write operating systems still are.

AI tools

The steepest timeline, with one early outlier: an IBM expert-system shell in the 1990s, then nothing for twenty-five years. Three years ago the row restarted; today an agent works one side of an operating system port while I work the other, and I have written tooling of my own to keep several of them on the rails at once.

What the bars say

Count the hand-overs. Not the tools — the edges, the places where one bar ends and another begins and there was a week, or a month, or a year of being bad at something I used to be good at. There are more of those on this page than there are years in the career, and every one of them was the job. The languages changed what I could say; the editors and version control changed how fast I could say it and how safely; the operating systems and machines changed what “it runs” meant; and the last row changed who was typing.

A few bars never end. Emacs since 1989. APL, which came back after forty years: I build APL interpreters for education, use APL to test microprocessors, and design new APL-inspired languages for problems in machine learning and embedded work. A regression tool I have rewritten in every language I have settled in. Those are not exceptions to the rule; they are what learning the next thing looks like when the old thing was worth keeping.

None of the tools was the skill. Learning the next one was.