Level Up

Good programmers continously learn. The defining characteristic about the top coders I’ve met is their complete and never-ending thirst for knowledge of almost any kind. The best way I can think of to describe them would be to say that they’re “interested“.

In the games industry especially, multi-talented people tend to be the ones that rise to the top. The people who essentially pulled Battlefield: Bad Company together during its darkest moments in production were the coder with an eye for game design, the ex-programmer designer, the artist with a feel for level design… and so on.

Looking at the famous people in the industry they tend to have been brilliant hackers that coded a game for the early PCs or Amigas in a basement somewhere, only to go on to become a lead designer for a massive latest-generation console game, not even touching the code. I firmly believe this is because of a never-ending desire to expand their skill set, explore new things, and as such not only aquire a view on how lots of things work, but also on how lots of people think.

Becoming a better programmer has a lot to do with a deep desire to learn, a thirst for knowledge. People often find me curious when I get stuck to a documentary about some esoteric subject like a World of Goo gooball to a cliff… but it’s yet another manifestation of this desire. It doesn’t have to even come remotely close to a subject about code or computers. So in a way, it’s no surprise that the best coders I know tend to also be musicians, artists or have other creative hobbies. World of Goo was made by just a few multi-talented people.

But a good programmer doesn’t stop at learning about things by passive reading or watching… they’ll inevitably have a deep desire to do stuff, and to keep exploring possibilities. And they won’t stop at doing stuff either, they’ll strive to perfect the art of whatever they’re doing.

At the same time, one of the first things one needs to learn is that perfection is ultimately unattainable. It’s this inherent conflict between “refactor” and “hack” that leads to systems improving in iterations, and each step towards perfection is a manifestation of the sum of the learning that’s happened this far.

On the flip side, one of the worst programmers I’ve ever worked with was a guy who (openly) refused to learn, and had lost all interest in learning. He said he just wanted to make cool games, and wasn’t interested in education. The result was that when the rest of the coding team would learn something about the system and advance a small bit, he’d remain behind.

The problem with programmer skill is that it’s incredibly hard to judge without at least peripherally working with the person in question and reading their code. The result of this was that this guy would be given a task, implement it quickly with no regard to all the rules and guidelines everyone else had learned to apply to prevent bugs — in essense he’d do what the rest of us would always consider as hacks. He was well regarded among designers and producers — almost seen as a miracle worker, because he was so quick at getting things done.

Then he left at 5 pm and the rest of us spent late evenings fixing his bugs by essentially removing what he’d done (which was always causing bugs that were hard to track down and pinpoint) and re-implementing the features.

What’s the lesson to take away from this story then? Well, first of all, keep learning! Don’t let yourself fall into a trap of thinking you’re pretty good at what you do, thinking that there’s no reason to learn C#, to look at functional programming or to learn to build levels or even that there’s nothing interesting about Penguins.

And, second, most of the people you work with have no idea whether the coders on your team are all excellent coders or if some are really bad. Shocking as it may sound, it’s up to you to tell them, because in the end you’ll inevitably be the one fixing the bugs at 11 pm as your ship date approaches.

Go Tinker

“Scratching the itch”

That concept is thrown around quite a lot. It’s used as a warning of a bad way to work rather often, to illustrate the reason for reinventing the wheel rather than going with an available library. Still, nothing is as important for the development of a coder as that simple curiosity of wanting to do something for yourself, to see what happens and to see if you can do it better. You usually can’t, but at least you learnt why in the process. Or maybe you strike gold and get fortune and fame.

It all comes down to what coding actually is. There’s a lot of preaching for reading books out there. Nearly every programming blog has a recommended reading list somewhere in its archives. Not that this is a bad thing inherently, I definitely think reading programming books is a good thing to do (and something I should definitely do more), but there’s a couple of problems with it:

1. Just because it’s printed doesn’t mean it’s true. There’s lots of opinions when it comes to coding practices, and lots of people seem to take things as factual just because they’ve been printed on paper made from a nice chunk of rain forest.
2. It all becomes very theoretical and very one-sided. I can learn a lot from reading, but there’s only so much I’ll actually remember unless there’s some way for me to sooner or later use what I’ve learnt.

This focus on books does make it clear that programming is very much based on science and technology. But it completely misses out on the fact that coding is also an art, or craft and that in order to write good code you need something akin to artistic inspiration. In fact, just as many other artists go about exploring, a programmer needs a healthy dose of curiosity.

There’s also quite a few posts out there on programming practice, or code kata. While related, it’s not entirely the same thing as just going after whatever programming itch you may have.

In the crunch periods where all my time has been sucked into work leaving no time for anything other than the very basics of life outside work, one of the things that goes away is my desire for tinkering around with technical stuff. It’s clear to me once it comes back how vital it is for a continued development of my abilities.

In fact, I’d go so far as claiming that setting yourself a new challenge of something interesting and then going about it longer in the evening than you really should is absolutely vital to any coder. Maybe it comes down to making that application that you want, in just your own way without care to the coding standards of your team, trying out a new language. Maybe it’s doing something that’s too dangerous for your work or just out of your field.

My current tinkering has taken me down a path towards experimenting with API call spying, inserting my own code between applications and the OS or their utility libraries to perform various tasks. I’m running into walls left and right, getting through some and having to give up other tracks. Most of it may not come out as anything very solid at all, and even if none of it does, I’ve certainly learnt a lot. Just by doing something much more difficult or far separated from than my day to day bug fixing at work I’m sure to sharpen the skills I have.

So take some time once in a while to ignore all the negative comments, abandon all thoughts of having to produce something and just scratch. What’s your itch?