Secrets of the Masters - An Algorithm for Learning to Program

http://all-things-andy-gavin.com/2011/09/11/video-game-programmer-method/

by agavin • 15 years ago

71 10 15 years ago

wccrawford• 15 years ago

I guess I expected something more secret. That's pretty much what I do, except for the 'don't leave the computer if the program doesn't run' bit. When the program doesn't run, and I'm pulling my hair out that's the -best- time to leave the computer. Go get some fresh air, a soda, maybe a nap... Anything to take your mind off it long enough to think straight again.

agavin3• 15 years ago

There are no magic bullets here. Becoming a great programmer takes a LOT of time and effort. It's fun and rewarding, but not exactly easy. :-)

sophacles• 15 years ago

If you don’t like to read, either learn to or find yourself a new career.

This is so true. About two years ago I realized that a significant chunk of my time was reading. I would read howtos, api docs, in depth analysis of things, both directly related to my job that day and programming in general. I did an analysis and realized that I was easily reading the equivalent of a 1000 page book a week. I have since taken efforts to both increase the quantity and quality of my reading, and it has paid off. I actively seek out topics I am ignorant of, and deeper articles on topics that have interested me. I also try to look at tools I don't expect ever to use. In all these cases I just read. This has given me a breadth I hadn't enjoyed before, and I suddenly have access to a whole new understanding when I and my co-workers encounter problems -- "hey let's look over here for ideas, that field has encountered similar problems"

DO NOT EVER LEAVE THE COMPUTER IF YOUR PROGRAM DOES NOT RUN.

I disagree with this. There is a point at which I need to just be done with an issue for now. This give me a chance to background process the problem. The number of times the answer "just comes to me" while doing something else has given me a certain amount of faith in temporarily walking away from the problem. A lot of people call this the "shower solution".

agavin3• 15 years ago

If you are truly banging your head against a wall getting some distance can help. I'm just a stubborn mofo and can't relax if I have series ongoing bugs. They haunt and torture me -- so I prefer to terminate them before moving on to something else.

Goladus• 15 years ago

I have, on occasion, intentionally left a program in a state that would generate a compile error to give me a place to start the next day.

Edit: Incidentally, I do agree with the sentiment in the article, though, which is that you should develop in manageable chunks and avoid derailing so far from a working program that you can't see the results of your work within a reasonable amount of time.

pointyhat• 15 years ago

I tend to replace them with assertions that blow up the tests. I never leave a compile error.

Usual format:

   Assert.Panic("not finished");

Terry_B• 15 years ago

Yeah, the idea of deliberately leaving something unfinished so you know exactly where to start from next time you sit down has helped me greatly. http://www.lifehacker.com.au/2011/01/leave-your-tasks-unfini...

agavin3• 15 years ago

I just put my "place" on top of my todo list, or leave the editor up there.

dmbaggett• 15 years ago

I coded the first two Crash games with Andy (and, on Crash II, with two other really awesome coders as well). I couldn't agree more with the recommendation of picking an old-school game and setting out to copy it. When it comes down to it, I pretty much learned to program games by, uh, programming games. Crappy ones, initially, but eventually pretty good ones. Then, an "A+" title at Naughty Dog.

I remember "discovering" double-buffering in high school when my friends and I were creating an Archon clone for the Atari ST (a 68000-based machine). My sprite was tearing and flickering all over the place; I then realized that's what double buffering was for. Sort of in the spirit of the modern (and massively overhyped) hackathons like the one that's going on in NYC this weekend, we'd stay up for 48 hours straight coding. Snow days were the best: you might get 4-5 whole days of hacking in! Man, we learned a lot coding clones of old games.

We made a PacMan clone with 100 levels. Sure, it was just a PacMan clone, but we had incredible fun making it, and it ended up being not only a great lesson for me in game programming, but an early lesson in how to structure a "big" program. ("Big" in quotes because it was only big relative to other stuff I'd written.)

And lest you think this kind of thing went out with the 16-bit era, I met a 13-year-old earlier this year who made a very convincing Pole Position clone in Flash. I'm totally hiring this kid when he's old enough for me to legally do so... unless PG funds his first startup when he's 15. :)

So, yeah -- if you want to learn how to code games, start coding a 2D sprite classic from the 70s or 80s and, most importantly, finish it. It might take you a year or more, but by the end you will have learned a lot. Then do the same thing with a more modern 3D game (a Doom-style POV game, for example). You will reinvent a lot of stuff, but you'll really know it cold. And these little games make great portfolio items that will help you land a job on a good game development team.

astrofinch• 15 years ago

I'm really glad to see someone discussing the actual mechanics of how they program. We need more arguing about which mechanics are the best and less arguing about which tools are the best. I'm sure the top 1% of programmers are the top 1% because of their awesome mechanics, not their awesome tools.

In my experience the quality of your debugging facilities determines a lot of how important it is to program by accretion. If you are getting really high quality tracebacks when there is a bug, it tends to be safer to add a lot of code at a time.

For me the Holy Grail has always been for my program to run on the first go without any bugs. I have achieved this for small Python scripts. To write conceptually correct code on the first go requires a much higher level of mental engagement, but it is far more satisfying than working by trial and error. (I guess it is probably all right to have trivial bugs like a forgotten import statement or a misfired library call.)

Secrets of the Masters - An Algorithm for Learning to Program

Related Stories