I want to take a break from the disruption warnings for a minute.

No pipeline anxiety. No existential threat to your business model. Just a story, and an open invitation to the old guard to remember something with me.

Pull up a chair. This one’s for the builders.

Nellis Air Force Base, 1987

I was a Communications Officer at Nellis AFB in Las Vegas, home of the Fighter Weapons School, the Thunderbirds, and more F-16s than you could shake a BNC connector at. I was 23 years old, freshly commissioned, and already completely obsessed with building things on computers.

My “day job” involved serious technical work. We’re talking CDC Cyber mainframes running NOS (the Network Operating System), serious government-grade iron that the Air Force used for computational work. Fortran was the language of record. Batch jobs. Time-sharing. Job control language. You submitted your code and waited. Turnaround wasn’t instant, which meant you read your code carefully before you submitted it, because mistakes were expensive in ways that would feel completely foreign to anyone who grew up with an interactive debugger and a hot reload button. That discipline, think before you execute, is still running somewhere in my background processes today.

But the Cyber wasn’t where the interesting stuff was happening. The interesting stuff was happening on the IBM PCs and PC clones that were showing up everywhere, running a remarkable piece of software called dBASE.

The Phone Book That Nobody Should Have Been Making By Hand

Here’s the thing about a military base: it runs on information. Who’s where, what their number is, how to reach them. And at Nellis, that information lived in a telephone directory, a physical book, printed and distributed base-wide, updated periodically as people came and went.

The process for producing that book was exactly as painful as you’d imagine. The Chief Operator had to manually enter every single telephone entry, all 10,000 of them, into a mainframe application. Not the Cyber. A different mainframe system, purpose-built for this kind of administrative work, and completely inflexible. When the data was finally in, the base printing office took over and physically printed the book. Start to finish: two to three months of grinding manual labor, every single edition.

I looked at that process and thought: this is a data problem. And I have dBASE.

dBASE III+ was a fourth-generation language, a 4GL, that let you work at a dramatically higher level of abstraction than anything procedural. You defined your data structure, wrote logic that read almost like plain English, and built working applications fast. USE phonebook. SEEK lastname. REPORT FORM directory TO PRINT. The tool handled the engine. You described the outcome. Sound familiar? That’s the same core proposition Claude Code is making today, forty years later.

I built a dBASE application that replaced the entire mainframe workflow. The Chief Operator entered data once, in a clean interface on a 386 PC, and the system handled the rest: formatting, sorting, generating the output ready for print. We cut the production time from two to three months down to a couple of weeks. Bam. The mainframe didn’t get a vote.

That was the first lesson: the right tool at the right level of abstraction doesn’t make you less of a builder. It makes you a more effective one. We knew this in 1987. We’re apparently still learning it.

The Thrift Shop, the Wives Club, and the Best Project I Ever Built

The phone book was satisfying. But the project I’m still proud of, the one I think about when people talk about what “outcome-driven development” actually means, was the Base Thrift Shop system.

The Officer’s Wives Club ran the Nellis Thrift Shop. (If you were ever stationed on a base with one of these, you know exactly what I’m talking about: a volunteer-run institution, open to base families, stocked with donated items, operating entirely on good will and organized chaos.) Before I got involved, the whole operation was manual. Items came in, got tagged by hand, got tracked by hand, and the accounting was a paper-and-pencil exercise. For a high-volume thrift operation run by volunteers, this was genuinely painful.

I volunteered to fix it. On my own time, completely outside my official duties.

What I built was a full multi-user system on a Novell NetWare network, and if you ran one of those in the late 80s, you know what I mean when I say this was not a trivial undertaking. Configuring NetWare meant IRQ settings, I/O base addresses, NIC driver configuration files, all by hand, all from documentation, all on hardware where the interrupt assignments were a puzzle you solved by trial and error and a lot of rebooting. And the cables? I ran those too. Physically. BNC connectors, RG-58 coax, termination resistors at each end of the segment. Get the terminator wrong and the whole network went down. Every machine. Gone. You learned to check the terminators first.

The system itself handled everything: item intake and cataloging, barcode sticker generation (escape sequences sent to a dot matrix printer, and yes, getting those escape sequences right for barcode output on a dot matrix in 1988 was its own adventure), inventory tracking, and integration with the accounting system so the volunteer staff could see the books in something approaching real-time. What had been a fully manual process became, by the standards of the day, a sophisticated operation.

Here’s the part I want to be precise about: I didn’t build this in isolation. I worked with the Wives Club team throughout the year. They told me what they needed. I built it, showed it to them, adjusted it, built it again. They were, without knowing the term, the Product Owners of the day. Requirements came from real users with real problems and real stakes. Iterations happened based on actual feedback, not assumptions. The system worked because they were embedded in the process, not handed something at the end.

That’s not a new idea. That’s 1988.

An Angel Pin and an F-16

When the system was done and running, the Wives Club nominated me for recognition. I received an Angel Pin, the Air Force community’s volunteer award, presented at a formal ceremony for exceptional service to the base community. A physical pin, a signed certificate, and the kind of handshake that meant something because it came from the people you’d actually helped, not from the chain of command.

And then the General offered me a ride in an F-16.

I said yes. Obviously.

Sitting in the back of an F-16 over the Nevada desert at Nellis, where the most proficient fighter pilots in the world go to get better, is not a subtle experience. That flight was the Air Force’s way of saying: what you built mattered. Not to your unit. Not to your mission. To the community.

I left Nellis in 1990 and handed the system off to others. It kept running. The design was good enough, and the Novell network solid enough, that the Air Force ultimately distributed the system to other bases. Other thrift shops ran it. Other volunteer teams used it. Something I built in my spare time, on a 386, with dBASE and Clipper and a dot matrix printer and escape sequences for barcodes, traveled farther than I did.

What That Era Gave Us

I’ve been thinking about this a lot lately, not with nostalgia exactly, but with genuine appreciation for what building in that era actually taught.

We learned pre-flight discipline. When your development cycle involves a mainframe batch queue or a compile-link-execute loop on slow hardware, you read the code before you run it. That habit, think first and execute second, is worth more than most developers who grew up with hot reload will ever realize.

We learned full-system ownership. There was no “that’s an infrastructure problem.” The infrastructure was your problem. The network, the cables, the IRQ conflicts, the barcode escape sequences, the dot matrix driver, all of it was yours. You owned the outcome end to end because there was no one else to hand it to.

We learned that the tool is in service of the outcome, not the other way around. dBASE and Clipper weren’t the point. The phone book that took two weeks instead of three months was the point. The thrift shop that ran smoothly for the volunteer ladies who gave their Saturdays to it was the point. We were outcome-oriented before that was a methodology. It was just how you worked.

And we learned, maybe most importantly, that dramatic productivity gains from better tools don’t diminish the craft. They amplify it. Clipper didn’t make me less of a developer than someone writing the same application in C. It made me a faster, more focused one, because the tool handled the parts that didn’t require my judgment, and I could spend my judgment on the parts that did.

Sound like any conversation you’ve been having lately?

For the Old Guard

This post isn’t an argument. It’s a reunion.

If you built real things with dBASE and Clipper, ran your own cables, configured your own NetWare servers, and figured out IPX/SPX packet collisions at 6am because your multi-user app was corrupting records, you were doing something that mattered. The tools were limited by today’s standards. The hardware was slow. The documentation was a physical manual you ordered by mail. And you built working systems anyway, for real users, with real impact.

That generation of builders has more pattern recognition than it gets credit for. We’ve seen what it looks like when the right tool at the right abstraction level changes what a small team can accomplish. We lived it. We were the proof of concept.

The tools are different now. The altitude is higher. The things a small team can build have expanded in ways that would have genuinely seemed like science fiction in 1988.

But the instinct? The discipline, the ownership, the outcome focus, the willingness to let the tool do what the tool does so you can do what only you can do?

That’s the same instinct we built in the first place.

It’s good to remember where it came from.

If any of this rang a bell, if you have a dBASE war story, a Clipper compile you’re still proud of, a NetWare network you nursed back to health at midnight, I’d genuinely love to hear it. Find me on LinkedIn or drop a comment. The old guard deserves a moment.