I have never really thought of myself as a software developer in the formal sense.
I’m a duct-tape programmer.
I learned to program in an era when the basic workflow was pretty simple: write the code, compile it, see if it works, and ship it. If you found bugs later, you fixed them, compiled another version, and shipped that one too. There wasn’t necessarily a staging environment, a deployment pipeline, automated testing, infrastructure as code, or a carefully documented process describing how everything fit together.
There was mostly:
Does it work?
If yes, excellent. Move along.
That mentality has followed me through nearly three decades of playing with computers, running servers, writing scripts, and building little tools to solve whatever problem happened to be annoying me that day. I’ve always been much more interested in making something work than documenting exactly how I made it work.
Lately, though, I’ve been using tools like Codex, Claude, and ChatGPT to help with both programming and system administration. And one of the unexpected things I’m learning isn’t merely how much software development has changed.
It’s how much software development has grown up.
Modern development and system administration are filled with practices designed to make systems reproducible, testable, recoverable, and understandable. You define environments. You separate development from staging from production. You track changes. You automate deployments. You document configurations. You build systems so that another person—or Future You six months from now—can understand what happened.
And somewhere along the way, I realized:
I already believe in all of this.
I just believe in it professionally as a psychologist.
Science is built around many of the same principles. Describe your methods. Preserve your data. Document your decisions. Make your analysis reproducible. Create enough structure that someone else can follow what you did, replicate it, critique it, and hopefully improve upon it.
In research, I would never say, “Well, I ran some analyses, fiddled with a few things until they worked, and unfortunately I don’t remember exactly what I did.”
Yet historically, that is remarkably close to how I have administered some computers.
The interesting part of AI-assisted development, for me, is that it reduces the cost of doing things properly.
Documentation used to be something I knew I should write after finishing a project. Naturally, by that point I wanted to move on to something else. Now an AI assistant can help document the system while we build it. It can suggest tests, explain configuration files, generate deployment instructions, review code, identify edge cases, and remind me that perhaps editing the production server directly at 11:30 p.m. is not actually a deployment strategy.
AI hasn’t turned me into a large software team.
But it has given my team of one access to some of the practices that previously required one.
I’m still a duct-tape programmer at heart. I still want the thing to work.
I’m just discovering that good engineering means making sure it can work again tomorrow.