We gained extraordinary power—and lost some of the satisfaction of building the whole thing ourselves.
There was a time when programming felt a lot like building something in your garage.
You had an idea. You opened your development environment. You wrote some code. You ran it. It didn’t work. You figured out why. You changed it. Eventually, you had a finished program sitting in front of you.
You built it.
That doesn’t mean programming was better back then. Today’s programming languages, frameworks, libraries, cloud services, APIs, and development tools are enormously more powerful. They let us build things that would have been difficult, expensive, or simply impossible for an individual programmer a few decades ago.
But I’m increasingly convinced that we lost something along the way.
Programming used to be more rewarding.
When the Saw Was Just a Saw
Think about programming as a tool.
If you’re building a house and need to cut a piece of wood, you grab a circular saw, plug it into the wall, and make the cut.
The saw isn’t the project. The house is the project.
You don’t spend the afternoon studying the architecture of the electrical grid, researching which outlet framework your saw supports, downloading three dependencies for the extension cord, discovering that the latest version of the plug isn’t compatible with your saw, and then searching the Internet for somebody who encountered the same error six months ago.
You plug in the saw and cut the wood.
That’s what programming used to feel like more often.
The languages and development environments were certainly more limited. But once you knew your tools, they tended to get out of the way.
You could concentrate on what you were trying to create.
Being the Alpha and the Omega
There’s also something satisfying about understanding the entire thing you’ve built.
With a relatively small program in BASIC, Perl, Visual Basic, or any number of older environments, you could often hold most—or even all—of the program in your head.
You knew where it started.
You knew what happened in the middle.
You knew how it ended.
You were the alpha and the omega of your little creation.
That’s an incredibly rewarding feeling.
Modern software development frequently gives us vastly more capability, but at the expense of that sense of ownership. Your application may depend on frameworks built by thousands of contributors, libraries built on other libraries, APIs running on somebody else’s servers, package managers, containers, authentication systems, build systems, and layers upon layers that you may never completely understand.
And that’s okay. In fact, it’s necessary.
Nobody is going to build the modern technological world by insisting on personally writing every function from scratch.
But there’s a psychological difference between building something with a tool and spending most of your time figuring out the tool you’re supposed to be building it with.
The World’s Greatest Circular Saw
Modern programming can sometimes feel like being handed the greatest circular saw ever invented.
It can cut anything.
It’s incredibly fast. It’s precise. It’s safer. It can make cuts your old saw couldn’t dream of making.
There’s just one problem.
You can’t figure out where the hell to plug it in.
By the time you’ve installed everything, configured everything, figured out which versions work together, read the documentation, found out the documentation is outdated, and searched for the error message produced by the thing that was supposed to save you time…
you haven’t cut any wood.
And that’s frustrating because the reason you became a programmer probably wasn’t that you loved configuring circular saws.
You wanted to build things.
Could AI Give Some of That Back?
There’s an interesting possibility that AI could make this problem considerably worse.
It could become yet another abstraction layer separating us from the software we’re supposedly creating.
But I wonder if it could also do exactly the opposite.
Maybe AI can figure out where the damn plug is.
If AI can handle some of the syntax, configuration, boilerplate, framework peculiarities, and other machinery surrounding modern development, perhaps the programmer gets to move back toward the part that was always the most rewarding:
I have an idea. Let’s build it.
That’s not a return to BASIC or Visual Basic. We aren’t giving up everything we’ve learned over the last several decades.
It’s using extraordinarily sophisticated technology to get back to an extraordinarily simple relationship between a person and a tool.
Every Once in a While, Get Out the Hand Saw
We desperately need modern development tools.
We need the frameworks. We need the libraries. We need the abstractions. We need thousands of people contributing their expertise so the rest of us can build things that no single programmer could ever create alone.
That’s how we get all the incredible technology around us.
But every once in a while, get out the hand saw.
Write a little program where you understand every line. Build something without worrying about whether it scales to ten million users. Use an old language you haven’t touched in years. Make something completely unnecessary just because you want to see it work.
There’s nostalgia in that, certainly.
But it’s more than nostalgia.
There’s something remarkably relaxing about picking up a simple tool, making the cut yourself, and knowing exactly how you got from the beginning to the end.
For a little while, you’re not depending on thousands of contributors who built an enormous framework around you.
It’s just you, the tool, and the thing you’re trying to build.
And sometimes that’s what made programming so rewarding in the first place.