I didn’t learn to program until the university. I’d written some BASIC as a kid but that was more sequences of commands, on the level of “What are subroutines good for anyway?”. I wasn’t very much into computers or programming, and I only took computer science at the university because I figured that’s a topic I should know about, not out of any interest.

Even at the university, the programming classes weren’t what interested me. I was more into algorithms and theoretical computer science (I was a math student, eventually specializing in mathematical logic, so that was quite natural). What interested me was a side project not related to my classes. My dad had a thing that was nicely suited for automating. I wrote with my beginner skills a small program that automated a little bit, and as I learned more, I kept extending that program until it did mostly everything that was needed.

Looking back, I think the reason why that project captured my interest was that it was useful. I could see actual value in what I was doing, and it was nice to convert a manual process piece by piece into a program since I could see quickly the new features in action. The program that began life as my first, 50-line, C program, grew to several thousand lines of Perl that I never grew tired of working on, adding new little features when they were found useful. At one point I was converting it to an Excel spreadsheet (it was that kind of program) but the benefits of doing that turned out to be not great enough that I would have bothered to finish the work. Still, I enjoyed learning Excel and VBA when trying to do something meaningful.

I occasionally tried some other programming side projects during my earlier working years, but nothing much came of those. I had “learned” that I should make some sort of a plan, a design for the whole program. And that meant I would need to spend several sessions just setting up the data structures before being able to get the program to do anything. Which led to not getting anything meaningful done because working on data structures and infrastructure was not very rewarding to me without being able to see the computer doing something that I wanted.

When I switched to working as a developer, my first major project used Scrum with a good scrum master and product owner. The agile mindset of doing small increments that provide user value worked well for me, making it an enjoyable project to work on. We did small design work, but only to get the next things working, refactoring the design when further requirements needed it.

Over time, I learned to get pleasure from things other than just making the computer show something on screen. Refactoring, cleaning up code, simplifying the architecture, all of these give me joy when I’m finished with the code looking nicer and all test cases still working fine. But even here my impatience at not making progress comes into play: If an architecture cleanup needs days before I can even make it compile, I’m likely to abandon the whole thing in frustration. Small steps that each produce something useful, with an eye towards the eventual goal, is the way that I work best.

Understanding this about myself has also made me better at doing side projects. I may have grand plans for what I want to build, but I’ve learned to satisfy my need for constant visible progress. I begin by just making the computer do something useful in a short time, no matter how far it is from what I want. This is a skill I’ve actively cultivated, the ability to take a big thing I want and split it into small pieces of useful functionality that can be implemented one after the other. And even if my grand plans never materialize, I still get something useful out of the work.

My need to build something useful feels like it hurts me in my professional development. If there is a new technology that I “should” know about, I simply can’t get a handle on it without doing something real with it. I can go through a tutorial and maybe learn to work with it but there is no useful purpose, I don’t see any benefits of the technology that way. It’s just a piece of code with no value. I need a meaningful project that uses that new technology, and such a thing is usually a lot more time-consuming than just reading some Web pages or going through a simple tutorial. So I often feel like I don’t know enough about all the current hot topics, which is not so nice in the consulting business.

In summary, this is why I’m still a developer. The feeling of joy I get when the computer does something useful I told it to hasn’t lessened any during my career, I’ve learned to expand the concept of “telling the computer what to do” to get that feeling from things other than just showing stuff on screen, and I’m always trying to organize my work in a way that I get those little successes all the time. It doesn’t always happen that way, I still can get frustrated at things, but I’m managing it well enough to still enjoy programming as a profession and occasional hobby.