Why Programming Is Still Fun, But It’s Just a Hobby Now

I used to be a software developer. I even trained other software developers and gave talks at conferences. For a few years now, I’ve only been programming as a hobby. This wasn’t an active “escape” from software development, but rather a realization and a desire to learn something new again. Keep reading if you want to know what I actually find interesting about programming and why coding ("vibe" or not) is only a small part of it.

A little over a decade ago, there were a few videos all over the web showing a couple of crazy guys changing the tires on a car while it was speeding down a street on two wheels. If you’ve never seen that before, here’s one from that era: https://www.youtube.com/watch?v=cIpBpGQ0XTI

Something similar, only worse, is described by Steven in his blog post “Programming still sucks”. No, actually, Steven isn’t describing why programming still sucks. Actually, he describes the failure of leadership, driven by greed. It just manifests itself in the current environment for programmers. Go ahead and read the post; it’s worth that I wait here in the meantime. 😉

Throughout my career, I’ve seen raised eyebrows of managers whenever I’ve said that management is a service function. The only job a team lead has is to clear the runway for the members of their team and ensure that everyone takes off and soars. The catch: everyone who gave me a dirty look was a manager, but not a leader. Leadership means serving – namely, serving your team – so that it can achieve the best possible performance and reach a goal as effectively as possible. But hardly anyone wants to hear that, especially those who derive their self-affirmation from their “headcount”. And that’s exactly what’s happening again now with the topics of “AI” and “Vibe Coding” (what a stupid term, by the way).

Anyone who’s been in the IT and software industry for more than a few years knows this situation: the executive board returns from an offsite meeting or a trade show where someone showed them a demo in which a developer programmed an entire feature in fourteen minutes. Of course they believed it. They wanted to believe it, because it allows them the illusion of reducing the “meat layer” and cutting those ever-so-high personnel costs. After that, it was your job to figure out how. And you have experience with this, because it wasn’t the first time you had to clean up after the last boss who’d been sold a simple solution.

What happened was: the runway got cut.
(from Steven’s blog post)

There is no runway left. There are also no more juniors building knowledge and experience by watching the old hands and asking stupid questions (which don’t exist; there are only inadequate answers).

The days when a team of a handful (you know the pizza table rule, don’t you?) experienced developers with domain knowledge would let a learner tag along for a year or two, first asking questions, then taking on simple tasks, having their mistakes explained to them in a supportive way, and eventually creating the team’s artifacts on their own are over. Gone, however, are also the days when this former youngster then becomes an old hand himself, taking one of the seats in the cockpit and letting a new learner tag along. I don’t have to write here about how this will play out in a few years: Steven does that in much better words than I could ever write.

But programming isn’t just about writing computer code. It’s also about developing an understanding of problem-solving, the structure of a program, and communication with others, even if it’s just your future self shaking your head in a few years at the mess you’ve written. If that no longer has any value because “AI” spits out code faster than you can read it and you lack the world knowledge to recognize why some things were programmed this way, then the creative part of the work is lost. Then you’re just a slavish clerk. Why should such a job be fun?

Anyone who has seen Claude’s leaked code recognizes what “programming” probably will mean in the future. The pleading repetition of incantations, begging the LLM to please pay attention to this and under no circumstances (no, not again, and with an exception for this one thing) to please do that. Incantations are typed in all caps like a mantra, as if the stochastic parrot had any idea what these words mean. How far removed is that from thinking about how to break down a real-world program with limited resources so that it delivers the desired result, and then understanding and grasping why the code looks the way it does. The mental model of an application, of a system that spans nine or more orders of magnitude, from a single bit in a status flag to the complete system, is a creative and design-oriented achievement that makes this kind of work interesting. Maintaining and improving such a system over the years so that a small change here doesn’t cause something to blow up back there is what makes programming interesting.

On top of that is the real challenge – one I only truly became aware of after several years as a developer because developers (and I include myself here) are often more interested in the technology and their own toolbox than in solving the actual problem. 😉 It doesn’t matter a damn what language or framework you’re programming in. The latest JavaScript framework of the week or that cancerous mass of tainted modules called Node.js doesn’t matter at all. Your paychecks or your mortgage are probably processed in more than one place by a mainframe running an operating system you’ve never heard of, in an application written by people half of whose team is already retired or dead. So what? It solves the problem. And if you want to preserve this solution for the future, then someone has to understand it. Or your credit data or worse will inevitably end up on the internet because some LLM snake oil salesman supposedly told your boss that “AI” would be good enough and much cheaper.

At some point, I realized why my skills will still be needed in the future; I just have to apply them in a different place. In the very place where the promise of “programmerless programming” has been whispered about for decades, long before “Vibe Coding”. Simply describing a requirement and the desired solution in precise detail. Guys, I’ve spent thousands of hours in workshops where members of the very same department couldn’t even agree on how to describe their own process. Not to mention things that were casually brushed off as “implementation details” and then turned out to be critical obstacles to project success.

“Just describe exactly what you want in plain language”. I’ve been laughing at that line for decades. It’s not about programming, we’re nowhere near that yet. I quickly learned that it’s about working with people. With business processes and the fact that there are organizations that can run an excellent CRM in a text editor, and others that will never manage it even with two behemoths of CRM systems from market leaders. Those are the truly interesting things. Why do some teams shine and why do some teams constantly fail? Mapping it to a programming language? Yes, software can certainly do that if you manage to formulate the requirement precisely enough.

“Walking on water and developing software from a specification are easy if both are frozen”
— Edward V. Berard

That was one of the moments when I realized that software development is great as a hobby, as a learning tool, and for recognizing how important details can be. You see, I’m the kind of person who loves to design, quickly get or sketch the big picture, and then, like a design architect with a beautiful new building design, leave the tedious little details to someone else. 😎 Programming was therefore an exercise and a game for me, just as yoga, golf, snooker, or any other activity for others to realize that both the big picture and the small details cannot exist without one another.

I admired assembly code and tried, together with friends, to squeeze every byte out of a graphics routine for clearing the screen and count clock cycles. For someone who just wants the stupid screen to be blank, it doesn’t matter at all whether that happens in 2 or 4 milliseconds. But that is the actual purpose of programming. You’re solving a real-world problem. Everything else is just like the video above: showing off that you can do something cool with your talent and your tools, but that has no practical value whatsoever (except for making other people in your industry smile or facepalm 🤣).

And that brings us back to the beginning and explains why the current state of the software industry isn’t the programmers’ problem or rather, why it’s no longer fun to choose programming as a paid profession. The people who run software companies, the management, and all of Silicon Valley tech bros have forgotten what software was actually meant for: to solve a damn problem of the real world, to carry out a process as effectively as possible (and only then as efficiently as possible). No, it doesn’t matter at all how cool your code is or whether it comes from a human or a machine. If it executes the wrong process step or is completely unnecessary and only exists because someone didn’t think things through during the analysis or had their eyes on a quick buck, then it’s simply superfluous digital junk.

But once you’ve understood what’s actually needed, once it suddenly looks simple and elegant and, for example, turns a customer into a loyal one, then it doesn’t matter at all which programming language your code was written in. What does matter (and what will lead to the explosion of all these “vibe-coded” solutions): someone understands what the code is doing, it is as concise as possible (and doesn’t consist of a bunch of scattered “Please, please dear LLM” sentences in simple English). Only then is it future-proof and secure enough as an investment to be improved, ported, or expanded later on.

But that’s a task that won’t be fun until the crash (a friend recently proposed to found an “AI fuckup cleaning service consultancy” 🤣). That’s why I still enjoy programming, but only for my personal hobby projects. And should I ever have any project in a public repo again, it will read, “Folks, send me even a single pull request that smells of LLM and I’ll block your account”.

Software serves a purpose, and that purpose lies with the people making the requests. Likewise, it lies with the customers, operators, and users. The implementation at the interface between people (with all their brilliant, chaotic, and incomplete ideas that make humans being human) that is what is relevant and meaningful. Getting a dozen people from an organization in a workshop to figure out how a certain business process works, and then seeing their faces when they all stand in front of a wall plastered with hundreds of Post-its, covered in notes and more arrows than Robin Hood ever had, and say, “Yes, that’s it! Finally, someone has written it down!” And when everyone nods in agreement – this is an experience that’s way more cool than any deployment to any server.

Lizenz für diesen Post CC-BY-SA 4.0

Alle Blogposts auflisten