The perils of having fun at work

As with everything, there are three main reasons why someone would become a software developer:

  • to make money
  • as a means to some other end
  • because it’s fun (l’art pour l’art)

The first one is the simplest: Programmers make good money. Becoming a programmer means being able to get a piece of the cake, too. The problem here is that if you write programs only because of the money, chances are you aren’t that experienced. If you treat it like a 9-to-5 job, and don’t even think of writing code when not at work, you won’t get deeper insights into technologies you aren’t directly confronted with at work. That’s why I’m not a big fan of all those year-of-coding efforts: People may learn pretty quickly how to stack together big pre-made components, but as soon as they need to dive a little deeper, they’re lost. There is a big difference between stacking a few Lego bricks and designing a skyscraper. On the other hand, for lots of jobs out there, that’s just good enough, and it often becomes a stepping stone:

The second kind of programmer got into it because they needed to solve some repetitive problem. Lots of programs originated from the need for a simple, specialized app to address some problem “until a real programmer can take care of it”, or because having a shitty, thrown-together app is still better than doing everything by hand. Good ol’ Visual Basic was what turned lots of people into programmers. From Excel macros to data base backed store management stuff, lots of small and large programs have been written, with horrible source code, but they work. They solve problems. And the people who wrote them had to sit down and think. They learnt something, even if they stayed right within their problem domain.

This is the kind of team I love taking over: People who know their code could be better, but who also know that they solved some problem by themselves. They’re motivated to learn more. And I love teaching. All that stuff you thought was boring? Think about it again. And again. And again. See how others are struggling with that boring stuff? Maybe you could teach it some other, simpler way. Maybe you haven’t really understood it, too. It’s a very interesting, sometimes humiliating experience to revisit stuff you hadn’t thought about anymore, only to find it more complicated than you remembered.

The third kind of programmer is often the next evolutionary step. Programming becomes a hobby, or even more. In the extreme case, programming is a reason for existing:

Thus spake the master programmer:

“After three days without programming, life becomes meaningless.”

From The Tao Of Programming

It doesn’t always have to be this extreme, but you get the point. For some of us, writing programs is simply plain fun. I like making a machine do my bidding. I like the fact that, barring hardware failures, computers do exactly what I tell them to do, which isn’t necessarily what I want them to do. The fun lies in figuring out how to solve a problem. If I were rich enough not to have to work anymore, I’d still write programs.

And that is my biggest problem.

Sometimes, the need for new problems to solve takes over. Banging my head against some hard problem is fun only as long as I haven’t solved it yet. As soon as I see the solution, the problem becomes boring. It’s solved, but only inside my brain: I still have to write the actual code. It has to be tested. Documented. Deployed. And that, to me, is stupid busywork. While I’m sitting at the keyboard hacking away at some source code, my thoughts wander to some other problem that could be interesting to attack next. As soon as a piece of code is good enough, it’s on to the next one. I’m a starter, not a finisher. And I constantly have to keep myself from re-inventing the wheel over and over, just to find out how some piece of technology works. Nothing bad about this by itself, it’s always good to learn something new; but when there’s a deadline looming, the last thing the boss needs is me experimenting with green threads in Forth, just because I found some quirk in the architecture of the .NET runtime and decided to hack away at a stack heavy language.

Which is another reason for me to keep updating lbjScheme from time to time: It’s not finished yet. It’s good enough for me, so it’s in the most dangerous state right now. The code needs some heavy refactoring. Documentation. More tests. Continuations don’t work yet. The compiler/vm combo is slower than the interpreter. And so on. Boy do I hope that continuations will be harder to do than I estimate right now. In theory, it looks so easy that it might be the death of my little side project. And for once, I don’t want to add another good-enough-yet-unfinished code base to my portfolio. This time, I’ll pull through.

As soon as I get those green threads done.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s