Code Like a Little Old Lady
On the speed of development
We can generate code faster than we can understand it.
That’s new.
Or at least it feels new.
With AI, we hear about 10x gains. 100x gains. 1000000000x gains.
Maybe not a billion, but it starts to feel like that.
And the thing is, our brains don’t scale that way.
We still want to understand what we’re building.
We still want to think about the design and the impact of those changes.
So the bottleneck didn’t go away.
It just moved.
These days, it’s often code review.
To be fair, code review has always been a bottleneck. For a long time, mostly because people just didn’t want to do them. Now it’s something different. Now it’s about throughput. The system is producing more than we can comfortably reason about.
It got me thinking about the speed of development over the course of my career.
And honestly, you can’t even compare it.
My first job after college was for a big old company. An oil company owned by a steel company. I have so many stories from that place. Luckily, many of them blurred by time.
What I remember clearly is the pace.
Development had moved past punch cards, but just barely. You would make a code change, submit it to a batch job, and then wait for the next mail run from the computer room.
The results came back on paper.
The people who had been there a long time were used to it.
And honestly, it felt like a good speed.
We talked more than we coded. We spent time deciding what to change before we changed it. There was space to think.
There were other options. We had a CICS system. Real online transaction processing. It felt incredibly fast. No paper, no waiting.
But most of our work wasn’t there yet.
That’s also where I first learned about Adabas, Natural, and databases in general. I remember being excited about it. The idea that data could be live, changing, interactive.
We also had one PC on the entire floor. Big floppy disks. Hardly anyone used it.
Our days had rhythm. Morning coffee break. Afternoon coffee break. Lunch. The whole company showing up in the cafeteria at the same time. Fifteen minutes, officially. Often longer.
I was stressed sometimes, even then.
Which is funny to think about now.
A lot of the code we worked on was already old.
Some of it was machine-generated COBOL. There was a tool that took requirements and produced code. It used every character possible to name things. Dense, unreadable, and incredibly hard to reason about.
It was a nightmare.
If that sounds familiar, it should.
A few years later, I moved to an electronics publishing and data analytics company.
They were in the middle of a major technology transition. Moving from mainframe to client server.
This is where things started to speed up.
I was still doing mainframe work, but now I had CICS terminals I could use more interactively.
I also had a Sun workstation. Oh my goodness, it was awesome. My first time with a GUI. I still spent most of my time building scripts to run from the command line, but the visual file structure felt magical.
I could try things and see results without waiting for a full batch cycle.
Projects that used to take years were now measured in a year. Sometimes less.
I moved from hierarchical databases to relational databases.
I bought the first version of Microsoft Access and started building small databases on my own. I showed my boss what we could do with smaller, more focused systems instead of the large, monolithic ones we were used to.
For the first time, I could start from an idea, design tables, build a UI, and have something working in what felt like real time.
It felt like lightning speed.
I also started using Perl on SunOS. My first Perl manual was the man page, printed out and kept in a binder. I held onto that binder for years.
There was joy in that stretch. Not because it was faster, but because I could think, try, and see.
When I moved to Seattle, I joined a small multimedia company.
We made CDs of cookbooks. It was genuinely fun. I wrote processes to convert cookbook text into a recipe database. You could resize recipes, adapt measurements, interact with the data.
I had a ball.
Well, mostly.
It was my first startup, and it was brutal.
Development time was now measured in months. From idea to shipped product in a matter of weeks or a couple months. I couldn’t believe how fast we were moving.
And it was the first time I really understood what that speed costs.
The job almost killed me.
There wasn’t space anymore. Not the kind we had before. Not the kind that let you breathe between changes.
At the same time, the web was emerging. Everyone was excited about building websites. I had already been working with SGML and XML, so HTML was a short jump.
It all felt new.
But it also felt familiar.
Fast forward again.
I worked in the Windows org when Windows Vista was being built.
Five years.
Five years to ship a product.
It felt long even then. Today, it feels unimaginable.
Even two years ago, you wouldn’t expect that kind of timeline.
Now, with AI, the speed of change is measured in months. Sometimes weeks.
If you tried to take five years to release something, you’d be laughed out of the room.
We live in a world that prizes speed. Productivity. Throughput.
We moved from letters to the phone, to fax, to email, to text.
Always faster. Always tighter loops.
And now, if you aren’t immediately available and responding, something must be wrong.
But we should probably ask, at what cost.
Because our brains haven’t changed.
Early in my career, I had two coffee breaks and a long lunch, and I still felt stressed.
Now I often eat lunch at my desk.
Even when I step away to eat, I don’t sit for long.
The clock didn’t get shorter.
The expectations did.
We have machine-generated code again.
We have natural language interfaces again.
We are asking machines to turn intent into implementation at scale.
And we are still the ones who have to understand what comes out the other side.
Code review is where that shows up now.
Not because people don’t want to do it.
Because there’s just so much to look at.
There’s a kind of engineering that comes from doing this long enough.
You start to see the cycles.
The tools change.
The speed changes.
The pressure changes.
But the work doesn’t.
We can generate code faster than we can understand it.
That still feels new.
But the part that matters isn’t.
We have always made the loop tighter.
And we have always hit the same limit.
We still have to think.
And thinking has always been the slow part.
Alison + Wiggins
Alison, I love this. Walking through your experiences, feeling the slow pace speeding into the fast pace.
My parents had a PC when I was young, it must have been younger than 6 years old because it was before my parents were divorced, and I remember my mom at the computer staring at green lines and a giant printer with so many holes up and down the outsides of the paper and making god-awful noises when it printed.
I love the idea of taking work slower. I love the idea of a company that is profitable and “winning” but goes at a slower pace to let ideas really grow and breathe.
I sometimes shake my head at the crazy “must move faster” AI pace. I wish we would embrace better the idea that we can breathe more because we just accomplished months’ worth of work in weeks.
I am creating these apps at work I never could have even dreamed of making before without AI. And the dev that I can create it just by saying to something “make this app”, that’s incredible.