Programming Commandments (not just for juniors)

by Seanba on March 25, 2010

Fellow game developer Chad Stewart has written up a list of 10 commandments for junior game programmers to follow:

  1. Thou Shalt Learn
  2. Thou Shalt Learn Some More
  3. Remember the Code Review to Keep It Holy
  4. Understand Thy Code Base
  5. Honor Knowledge, Keep Reading Books
  6. Thou Shalt Ask for feedback
  7. Thou Shalt Be Wrong
  8. Liketh Nike, Just Do It
  9. Thou Shalt Comment
  10. Thou Shalt Not Break The Build

That’s not a bad list at all, although I have to wonder … what’s with this junior programmer business? This is the kind of stuff that programmers at all levels should be thinking about no matter what their title is.

And really, is there anything more annoying than a senior-level programmer that gave up learning and reading and improving his craft years ago? The kind of person that thrives on being viewed as the smartest guy in the room, so much so that he won’t ask a question that just might betray him? The kind of person that doesn’t want other people reviewing his work?

That kind of person drives me absolutely crazy. Have some damn humility.

Lego Moses

Yeah, um, anyway, I recommend reading Chad’s full post. I think it’s telling (and appropriate) that a full five of his commandments (1, 2, 5, 6, 7) are really just about the general act of learning. It’s good stuff.

But that doesn’t mean I don’t have some constructive feedback. 🙂

Chad writes …

8. Liketh Nike, Just Do It

I read this one in Game Developer. When you have some great idea, don’t let it get lost in the chain of command. Spend a few hours on Saturday and get it done. If it takes multiple weeks, so be it. Spend the time and get it done. That’s step one. Step two? Let everyone know how great you are!

I recommend strong caution with this, especially for people new to the business. Enthusiasm and initiative are fantastic qualities but trust me, if you go a bit rogue on the weekend putting something cool you just learned into the codebase then there’s a good chance your fellow programmers will explicitly not want to hear about how great you are once they sync up on Monday morning.

A long time ago I worked with a guy who, equipped with the first Game Programming Gems book, had littered our project with a dozen or so Singleton classes over the weekend – and he was crushed when his work, once discovered, was met with, “What the fuck is this shit?” instead of celebration.

If you have a decent lead then he’ll work with you to channel your intensity, and even find a way to put it into a task that excites you. So find more constructive ways to earn those atta-boys.

Further, Chad says …

9. Thou Shalt Comment

Get into the habit! It’s a good habit. Comments make life better.

I would first stress that it is far more important to write code that makes sense on it’s own and is therefore self-documenting. But failing that, yes, please do comment.

Otherwise, I can’t find much wrong with those commandments. If only it wasn’t written for just the junior programmer audience. 😉

{ 2 comments… read them below or add one }

Chad Stewart April 7, 2010 at 5:50 pm

Hey Sean!

I like the article! (I wonder why.) I got a lot of healthy debate on that post, and I’m really glad! Guess it goes to show that it should be labeled a rough draft now! There are definitely a lot of gotchas and tidbits that I took for granted when originally writing it. Commandment for every programmer: Assume no one else knows!

On number eight, I guess I kind of assume that everyone is working with source control! :p But really, I guess I should have advised caution. No one wants to be the guy who confused a need for a singleton for needing only a single instance. Also, if it takes too much time, it’s obviously too risky. Good call.

I completely agree with you on writing better code before commenting as a crutch. I probably should have mentioned directly that commenting should not be about how and should only mention the why.

“If only it wasn’t written for just the junior programmer audience.”
Perhaps there is a better set for senior level programmers that includes mentoring and a few other points. I don’t know. Just saying. Perhaps I have an unfinished draft somewhere.

Thanks for the mention!

Jen Bullard June 14, 2010 at 9:20 am

From a producer’s point of view I like #8 to a certain degree. This is the good part of “Just Do It”. After two hours of listening to two engineers snipe back and forth I went out and asked them how long it would take to implement each version. One answer was 15 minutes and the other was 30 minutes. (Kid you not) I ordered both of them to implement, we (as a team) would evaluate the outcome and then choose. Yes, they wasted 1.5 hours arguing semantics, and it was caused by #7, because the lead programmer didn’t want to admit he was wrong!

On the other hand I’ve had an engineer stay up all night to replace the animation system that would require all of the animations to be re-tweaked *by hand*. He was instructed to undo that – on no sleep.

Leave a Comment

Previous post:

Next post: