[This fragment is available in an audio version.]
I’ve been programming and remembering how much fun it is. With nostalgia for Old Data and thoughts on my work at AWS.
What happened was, I was talking to a friend who’s in the middle of a big project; they said “Would you be interested in
bashing out a quick parser in Java?”
“Parser for what?” I asked.
I just about sprayed coffee on my computer. “You have got to be kidding. There hasn’t been any GML since the days of mainframes.”
“Exactly. They’re migrating the documents off the mainframe.”
“High-value deeply-structured stuff. They need to turn it into simple XML, we’ll enrich it later.”
I’m semiretired and suddenly realized I hadn’t done any actual code for many months, so I named a price and they took it. It’s old-school stuff; I mean really old-school; GML is actually a basket of macros for the IBM mainframe Script typesetting system, which I used to write my undergrad CS assignments back in the freaking Seventies.
Old-school it may be, but I’m learning cool new Java things like postmodern
switch because IntelliJ keeps sneering at my
Java 8 idioms and suggesting the new shiny. And
I’d forgotten, really, how nice carving executable abstractions into shape feels. Also parsers are particularly fun.
And here’s a snicker. I realized that the parser needed a config file. So… JSON? YAML? XML? Except that so far, my program had exactly zero dependencies, a single little jar file and away you go; we don’ need no steenkin’ CLASSPATH. But wait… I’d just written a GML parser. So the config file is in GML, yay!
But Should I Code? · Seriously, it’s reasonable to ask that question at this stage of my career. It’s a conversation that arose at both of my last two jobs, Amazon and Google. Should your most senior engineers, the ones with decades of experience and coding triumphs and tragedies under their belts, actually invest their time in grinding out semicolons and unit tests? Or do you get more leverage out of them with mentoring, designing systems and reviewing others’ designs, code reviews, and being the bridge between businesspeople and geeks?
There’s no consensus on the subject that I’m aware of. There are people I deeply respect technically who really believe that coding is a lousy use of their time. But then anyone who’s been in this biz for long has met Architecture Astronauts who can make a hell of a design chart in Omnigraffle but are regularly really wrong.
I’m personally in the senior-engineers-should-code faction and when I was asked to evaluate someone, would always pull up the internal equivalent of the GitHub history page. I wouldn’t expect to see a lot of action there, but I’d get serious misgivings if I saw none. On the other hand, I freely admitted prejudice on the grounds that I personally can’t not code.
Except for I hadn’t for a while. Now I realize how much I missed it.
Recently… · Now that I’m in talking-about-code mode, I want to mention my most recent excursion when I was at AWS. Coding there is terrific, with very decent dependency-management and code-review tools. And, most important, there’s a good chance that your code will end up being used by hundreds of thousands of customers or process millions of requests per second or both. Those things will turn any geek’s crank.
But I was fiddling with code in EventBridge from the month I joined (December 2014) to the last days before my exit. In particular, the stuff linked to from Events and Event Patterns in EventBridge. Words can hardly describe the intensity and fun involved in building this thing, and the thrill as customers piled on board and the flow of events through the code became mind-boggling.
The software lets you write rules and present events and have it tell you which rules matched. Simple enough, logically. It has an unusual but good performance curve and an API people seem to like. I can’t go into how it works; there’s a patent filing you could track down but that’s written in patent-ese not English so it wouldn’t help.
Other teams started picking it up and suddenly I had collaborators. There was this one feature request that I was convinced was flatly impossible until this guy I’d never heard of just made it work. He and I were chief co-authors from that point for the next several years. I miss him.
My last couple of years at AWS I was, in between all my other work, regularly chiselling away at this code. It wasn’t the best part of my job, but I liked it. At one point it became clear that AWS was serious about upping its open-source game. So I floated a proposal that we open-source my baby. That ball was still in play when I left but I’m not holding my breath. I still had lots of what-to-do-next ideas and working on it would be a great semiretirement hobby.
Advice · If you used to like to code but don’t do it any more, I suggest you see if you still do.