So I Learned To Code

I taught myself to code. Sort of. I taught myself to code after reading a book on Perl about 11 years ago, part of a book on Perl, and not understanding it. I wanted to make games and Perl was only useful, in my eyes, for text adventures. I’m still somewhat of the opinion that Perl is only useful for text-based stuff, but not for lack of the ability to do graphical things. At any rate, after I tried to learn Perl using a book, I taught myself to code.

Well, no, I read other people’s code and learned how to code from that. I read books that dissected good code, but mostly I read books on things that weren’t specific to code (e.g., 3D maths used in games). I taught myself to read code and write code like the code I read. I read the Quake 1 source code,1 I read the Quake 3 SDK’s source code, I read Ruby scripts, I read Lua scripts while I worked on a game that used Lua,2 and so on.

I asked myself how others did it and I read how others did it to answer the question. I was curious what code written by people who really knew how to code looked like. So I learned to read code, but I still wrote bad code probably for a long time, and maybe still do, but I leave that up to others to decide. After that, I taught myself to code.

Except really, it’s more like I taught myself to use a debugger before I learned to really code. I couldn’t write code if I didn’t know what it did. So, I wrote code or took other folks’ code and I stepped through it and saw how it worked. I read code while it executed, and this let me know how things worked even if I didn’t and sometimes still don’t know how everything works at the lowest level. I know how conditionals work, for example, in assembly, but I couldn’t tell you why the assembly worked with the hardware.3

I was curious about what code did and had to know how it worked before I could really code. So, I learned how it worked and what it did, and after that, I taught myself to code.

When I taught myself to code, I never really started small, I just started esoteric or weird, whatever prodded me just enough to raise questions that seemed out there. My idea of fun wasn’t writing blackjack for a terminal, though I wrote blackjack programs, it was always more along the lines of modifying virtual method tables at runtime or building code to automate other tasks in programming, like writing code to generate Lua bindings.4 I was curious about how I could handle any given situation and what different ways I could approach it.

The whole key here — to how5 I learned to code — is curiosity. Curiosity killed the cat, sure, but the cat had nine lives, and before it touched the capacitor in the CRT, it got a pretty good look at how things worked. Because of my curiosity, I want and need to solve problems. I see puzzles in the crevices between ideas. Programming is not a job, but a strange search for new problems, one part learning to learn, one part problem solving, and one part borderline-obsessively-curious tinkering. A self-taught programmer must necessarily have all three of those parts to survive as a programmer.

Without those parts, that programmer will never seek knowledge, never fix anything, and never try anything new. He or she will be the programmer you don’t want to know, self-taught or not.

But with them? With them, that programmer will never feel limited, never stay bored, and never grow tired. With these things, that programmer will always enjoy programming. With these things, you’ll be a great programmer.

(Addition 2014: In retrospect, I left out the intervening years where I initially practiced making game art, so there’s a gap between Perl and other stuff where I did game art, but the point of this post is less everything and more that curiosity’s pretty useful.)

  1. For those who have wanted to read the Quake series’ source code but haven’t had the time to sit down and do it, I do recommend reading Fabien Sanglard’s fantastic code reviews. As of this writing, he’s done Another World, Quake 1, Quake 2, Quake 3, Doom, Doom 3, Duke Nukem 3D, and others. [return]
  2. Lua’s a fantastic language for programming fun little experiments in. When I first ended up learning it, I was working as an artist on a small game called Bioscythe. As far as I know, it was never released, and I went my own way after the project seemed to more or less die as everyone on the team went off to do their own things. I learned a lot from seeing how we used Lua, however, and I’ve since remained convinced that it’s the best scripting language for game development. [return]
  3. That is, I know the assembly but not how the mainboard works, and given the complexity of modern computer hardware, I’m prepared to forgive myself for this for a while even if I’ll have to figure it out sometime. On the upside, knowing what a compiler might produce is pretty handy at times. I say “might” because the compiler might optimize things away and so on, so there’s no guarantee that I’d always see the input in the output. [return]
  4. Which actually ended up landing me a small contract to do exactly. I wrote some experimental code to do at-runtime bindings of Lua code, someone liked it, and gave me a contract to do it again but without the speed hit of the original experiment. [return]
  5. Why I learned to code is another sort of thing altogether, though from the code I read, you can probably guess what set me on the road to code, as it were. Basically, though, I started out as a game artist, and still make game art, but wanted to make a game. Mods were one avenue but it’s difficult to find a good team making one (and the mod scene is mostly dead now, at least for modern titles, due to the amount of work involved). Finding a programmer willing to follow your lead is even more difficult. So, the solution was to write code myself.

    This altered my career path significantly and made me an anomaly in some respects since I’m both a relatively competent artist and a programmer (debatable on the competency part there as I’m a lousy judge of my programming skills), but it made life a whole lot more fun.