Desire Paths

It’s 2005, I’m in a motorpool in Iraq, and I’m hitting keystrokes on a computer to print out soldiers' licenses one by one. I’m really annoyed.

My MOS was 92A — Logistics and Supplies Specialist. I managed all the parts and supplies, ordering and returning, and I managed soldiers' licenses and vehicle dispatches. The tool we used was this ancient thing called ULLS-G that ran in DOS, where you did everything with the keyboard. When I had to print out licenses for every soldier, I did it by hand. When I had to update qualifications, by hand. It used to take me over an hour.

Then I found an ODBC driver for the Sage database that ULLS-G used underneath, and wrote a perl script to query the information and generate the licenses in one go and print them. I was done in seconds. I only had to wait for the printer to finish printing.

I’ve been doing some version of this my whole life.

I learned programming in the era of batch files and simple BASIC programs, and I was always writing little utilities for myself. The first thing I made that felt "complicated" was a menu system in BASIC to load programs on my computer and run other BASIC programs I’d written — I got the idea the moment I learned about the CHAIN and SYSTEM commands. By sophomore year of college I had my own FreeBSD box, and anything I did manually a couple of times I’d end up automating. Samba drives, backups, whatever annoyed me twice. As a kid I always wanted to write programs that felt "grown up" and "professional," where the commands made it clear what you were doing. Self-documenting. Easy to use. Things that helped people — well, at the time it was just me — do things more efficiently.

Junior year I was the network, web, and sysadmin at ASU’s International Programs Office, running Win2K clients against a FreeBSD domain controller (yeah, you could do that), with a whole suite of scripts for the network, the website, and daily backups — diffs daily, full backups weekly.

At my first job at Intel, we had an MS Access application that took two hours to download chipset register specifications. We’d start it and go to lunch. It would spit out the specs in an Excel spreadsheet. I never understood why it took so long, so I asked the person who managed it for the query, and wrote a perl script (I was really into perl for a while, ok?) that used an ODBC driver to run the same thing and generate an Excel spreadsheet, a Word doc, and an HTML page. It took two seconds. I guess Access was slowing things down somehow.

Which brings me back to that motorpool.

Because it wasn’t just the licenses. We also had to send reports up to the TOC daily — vehicle statuses (mission ready vs. deadlined), maintenance statuses — so on and so forth. The report was a spreadsheet I edited manually. I’d look at what was in ULLS-G and then write it up in Excel by hand. It was terrible. I hated it. I messed up the data a few times and got yelled at. So I used that same ODBC driver with Excel macros to auto-fill the spreadsheet. And then I went further — I built new reports for the mechanics, like which vehicles were ready for servicing; color-coded and everything. They loved it, because it was way better than the text dump ULLS-G gave you. I ended up getting an Army Commendation Medal for that work.

These days I still automate things, but the scale has gotten much bigger. When I started building at Basata, AI coding wasn’t reliable enough yet for large projects, so I built a lot by hand — tools and workflows to enforce SDLC best practices, because quality matters to me, and the little bit of time you spend on good foundations pays off in speed later. Now I’m at the point where I can just tell Claude to do those things. But the important thing is that I’m not asking Claude to figure it out. Because I’ve been automating things throughout my career and also for fun, I have a decent first approximation of what an automated version of something should look like. I can spot a good place to start, and then slowly extend the range. That used to take months. Now it’s multiple things in a single day.

A lot of the discourse around AI coding is about how it hurts quality, and that’s true. But the tools you write to enforce quality — the systematic processes — usually aren’t that complex. The thing AI gives me isn’t the ability to build them (I already know I can do that). It’s that the gap between "I wonder if I can automate that" and actually doing it has gone to nearly zero. Before, I would have ended up on Google, hunting for an API or an integration point. Now it ends with me just doing it.

There’s a risk, of course — you can end up with a pile of scripts held together like a Rube Goldberg machine. But with a little discipline you can avoid that too. I think of tools for processes the way I think of desire paths. Where do people wish the shortcut was? What’s annoying to do? Start there. And the first person who gets annoyed is always me, so that’s my rubric. It’s been my rubric since I was a kid writing BASIC menus. The only thing that’s changed is how fast I do it now.