Programming Is Creative


I started programming at 14, though I did not know that is what I was doing at first. My introduction was writing connection scripts for BBS sessions -- the kind of thing that would dial a number, log in, navigate menus, and grab whatever I was after, all without me sitting there pressing keys. There was no documentation for this. I figured it out by poking at it. Loops, variables, conditional logic -- I did not have names for any of it yet, but I understood that I could describe a sequence of steps and the computer would follow them. That was enough. There is something particular about that first moment when you get a machine to do something new on its own. It does not matter how small the thing is. The feeling is out of proportion to it.

At 15 I found a book on Borland C at a house where I was babysitting. The family was out, the kid was asleep, and I sat there reading about compilers. Not what programs do -- what a compiler is. The idea that you could write something in text, run it through a tool, and get an executable the machine would run directly felt like a magic trick I needed to understand. I began to write programs to parse my email inbox and create an HTML archive of the "Pavement" discussion mailing list (my favourite band from the time). It was kludgy, and there were no users, but I liked being able to read the emails remotely so it served its purpose for me.

At 16 I signed up for a night class in C programming. Somewhere in that same period I found Linux, which changed everything. Suddenly I had a shell, and the shell had BASH, and BASH had shell scripts, and there was Perl, and there were more open source examples than I could have imagined. The concept that your shell could also be used to REPL develop took a minute to sink in, but it was such a lovely experience writing little shell scripts that could immediately fire. I started experimenting with procmail on my mail server to pipe mail to shell scripts which would take action on them and do little tasks for me. Now I could email myself and have my computer execute jobs.

That feeling has always been at the center of what I love about this work. Not just writing code, but connecting things. A script that pulls data from one system and pushes it into another. A config file that finally resolves and suddenly two pieces of software that had no reason to know about each other are cooperating. Different hosts, different operating systems, different protocols -- figuring out how to make them all speak the same language has always been where the pleasure lives for me. There is a specific dopamine hit that comes from getting the last piece of configuration right and watching a service come up clean. I do not think everyone feels it, but the people who do tend to become programmers.

There is also a creative side to this that I think gets undersold. Writing software that exactly fills a need -- not over-engineered, not a framework where a function would do, just precisely the right thing for the problem -- feels genuinely artistic to me. The satisfaction is similar to what I imagine a craftsperson feels when a joint fits perfectly. You knew what you wanted, you understood the material, and you made the thing. That is not a mechanical process. It takes taste.

I have been using LLMs in my work for the past couple of months. They are effective. They solve problems. They have made me faster in measurable ways -- I can prototype something in an afternoon that would have taken a day and a half before, and I can navigate unfamiliar codebases more quickly than I used to. The business case is obvious and I am not going to argue against it.

But I have noticed something I am still trying to articulate. The enjoyment is gone. Not the satisfaction of the outcome -- the outcome is often fine. But the process, which used to be where the pleasure lived, has become something I hand off. The config problem I would have spent an hour on, iterating and learning why each thing failed, I now describe to a model and receive an answer. The small elegant function that I would have revised three times to get the shape right I now accept in a first draft that is good enough. It works. I just did not make it.

I am not sure this is the model's fault exactly. It is more like -- the opportunity for the experience I value keeps getting preempted. The puzzle gets handed over before I get to feel the resistance.

What worries me more than my own enjoyment is the industry. The people who become excellent programmers are, in my experience, mostly people who started out in love with the puzzle. They stayed up late because they wanted to know how it worked, not because someone assigned them a ticket. If the puzzle keeps getting solved before anyone gets to fall in love with it, I do not know where the next generation of people who genuinely understand this stuff comes from. You can use a tool you do not understand for a long time. Until you cannot.

I do not have a solution for this. I am not even sure it is a solvable problem -- economic incentives are what they are, and velocity matters. But I find myself increasingly making a deliberate choice to sit with a problem for a while before reaching for the tool. Not because it is more efficient. Because the part that used to feel like mine keeps slipping away, and I am not ready to let it go entirely.