Chad Stewart: Game Programmer

At the end of last year I made a blog post entitled New Year’s Resolution? Be A Better Coder. In that post, I detailed three key areas in which I hoped resolved to improve. This is the end of the month three and here’s my progress. Hope I’m not too late!

1. Read More
The Idea: There is so much knowledge in both books and online. It would be a worth the effort to take in some of this collective knowledge.
The Goal: My goal is to read three books this year (one every four months) and subscribe to ten good blogs.
The Progress: I finished Practices of an Agile Developer and wrote my thoughts in a review. I finished, Software Optimization Cookbook and wrote a review for that as well. Luckily, a plane ride to Denver gave me some time to make my way through most of Best Kept Secrets of Peer Code Review.
On the blog front, my Reader is always overflowing with new items. It’s almost hard to keep up!

2. Learn a New Language
The Idea: Every language is a tool in the toolbox. Learning more tools and maintaining a repertoire of them would be most beneficial.
The Goal: My goal is to learn and implement a few solutions in Python and in Perl.
The Progress: The same as usual. I’ve been doing more and more with Python. Importing more modules, making new scripts and breaking things up. Did some GUI work with matplotlib and got some pretty charts started. Pretty soon I’ll really have to get started on that Perl thing that’s been going around.

3. Be an Architect
The Idea: Where a programmer applies some duct tape to stop a leak, an architect replaces the pipeline with a better one. This is most essential to career advancement.
The Goal: My goal here was a little more extract. It was a promise to leave things in a better state than when I found them.
The Progress: Aha! I can’t say much about this, but my idea from last month seems to be going well. Why bring water to a horse when you can bring the horse to water? Why give a man a fish when you can teach him how? That was the latest pipe replaced.

As always, I’m open to feedback. Leave some!

“Protect your morning burst. That’s what psychiatrist Ned Hallowell, M.D., calls the rush of energy and focus most of us have in the early part of the day, and he says we should be ruthless about shielding it from interruptions.” Excerpt from Men’s Health.

Do you have a morning burst? When polled, most people seem to say that they do. I’ve felt this personally. It seems like in the morning without all the distractions and commotion, I can get stuff done. And I mean serious stuff. My most productive hours are before most other programmers even enter the office. I know well, the secret of the morning burst. How can you protect it?

Get in before core hours start! If you work the same type of programmers I do, a lot of them probably get to the office right at the start of core hours or a half hour after that. That’s hours without an interruption if you come in a bit earlier than most. That’s hours of heads down programming where you can really get into the zone and type with fury.

Block out the time with a meeting. If your company uses Outlook or any other calendar type program, try scheduling a meeting in the morning so no one will try to interrupt. This may not always work, but it’s a good first line of defense against those who would try to schedule into a meeting while you’re able to get in the zone.

Let your computer work with you. Don’t let it distract you. Don’t open your browser. Don’t open your email. These are all distractions that will be available later in the day, when you’re not as productive anyway. Not that I condone browsing youtube all day, keeping up on your facebook, and sending pointless emails. I’m just saying, “Don’t distract yourself when you’re at the top of your game.” The morning RSS feed will still be available as the lunch break RSS feed. Check out this article on Lifehacker about eliminating distractions on your computer.

If you don’t feel you have a morning burst, and you’ve given it an earnest try, then perhaps it’s time to use heatmapping to find what hours you need to protect. Regardless, protect it at all costs. As a programmer, you’ve probably realized that an hour in the zone is roughly equivalent to two or even three hours outside of it. When you can train yourself to get into the zone, you have to fight to protect it. If you have any other useful tips for me and others, please leave a comment!

You might be thinking to yourself, “The Software Optimization Cookbook? Awesome. Another of those O’Reilly Cookbook formatted reads where each ‘recipe’ is a problem and solution.”

Wrong!

This is a book about Software Optimization and a Cookbook. If you want some slightly outdated information on optimization and a killer recipe for Turkey Lasagna, this is the book for you. That’s right. I am not joking when I tell you that part of this book is a collection of recipes for food, not software optimization. The book is broken down into sections based on bona-fide recipes starting with appetizers, moving to entrees, and then finishing up with desert. Let me give you a piece of advice. This book is like one of those restaurants with sub-par meals. Skip dinner and get dessert!

Let’s start with the appetizers. In the first 57 pages, you’ll find a few nuggets of optimization knowledge and an obvious advertisement for vTune. This makes sense, considering the book is published by Intel Press. Let me save you a bit of reading. Benchmarks are repeatable, representative, easy to run, verifiable measurements of a program. Also, hotspots are the worst (slowest, most memory usage, most cache misses, etc) spots in the program and must be fixed before optimizing much else, because they are the biggest potential gains. Not much else is in this section of the book besides the recipes for a soup, a salad, some crab cakes, and meatballs.

Now on to the main course. There must be some juice optimization information here, right?

Wrong!

Yes, it does explain some of the reasons performance could be slow. Does it go into depth about how to fix it? Not really. Does it show you how to identify these situations with screenshots from vTune Performance Analyzer? Of course! Does it show you Intel chipset specific compiler flags that you can use for optimizing some of these situations for Intel processors? Of course! This makes sense, considering the book is published by Intel Press.

Honestly, if your program is slow enough that you need an Intel compiler flag, or you need to start writing inline assembly, you need to refactor or rewrite something a bit. In this day and age, readability is important as well. As our processing power advances, so does our ability to write clear and concise code. We rely more and more on high-level scripting languages. What we don’t need in our code is some cryptic, archaic _asm blocks. I learned much more about avoiding cache misses in these slides, than I honestly did from the entire book.

Now on to the delicious part, dessert. Dessert in this book consists of gooey brownies, grilled bananas, mixed berry cobbler, and a dash of how to apply any of this stuff we’ve been learning. This time, you will actually get a great use case of how to use vTune Performance Analyzer. Here, it goes over a use case and in some cases, the author actually optimized the algorithm instead of adding some inline assembly.

Unfortunately, it feels a little late. Honestly, how does this book have five star reviews? Check this one out at the library or spend an hour at the Starbucks at Barnes and Noble. Text books are entirely too expensive to be taken lightly! I don’t think you’re missing out on much if you skip this one.

At the end of last year I made a blog post entitled New Year’s Resolution? Be A Better Coder. In that post, I detailed three key areas in which I hoped resolved to improve. This is the end of the month three and here’s my progress. Hope I’m not too late!

1. Read More
The Idea: There is so much knowledge in both books and online. It would be a bountiful effort to take in some said knowledge.
The Goal: My goal is to read three books this year (one every four months) and subscribe to ten good blogs.
The Progress: I finished Practices of an Agile Developer and wrote my thoughts in a review. I recently finished, Software Optimization Cookbook and am writing the review. As for my next book? I’m not sure. I have a Game Business book I’d like to read, but I feel like that’s cheating since I’ve already skimmed it for what I needed. Note to publishers and authors: Now accepting free books!
On the blog front, my Reader now has thirteen programming blogs and three game studio blogs. Goal extra complete. (Also, I’m still open for suggestions for other good game-specific programming blogs!)

2. Learn a New Language
The Idea: Every language is a tool in the toolbox. Learning more tools and maintaining a repertoire of them would be most beneficial.
The Goal: My goal is to learn and implement a few solutions in Python and in Perl.
The Progress: Not too much progress here. I’ve fixed up my own and helped a friend with his python scripts. I learned a very valuable lesson when switching Notepad++ to insert 3 spaces instead of a tab. You can’t mix and match white space like that. I’ve got my python script doing what it needs to, but now it’s time to clean it up and parameterize it to be called by… a Perl script! That’ll be so money.

3. Be an Architect
The Idea: Where a programmer applies some duct tape to stop a leak, an architect replaces the corroded pipes with sturdier ones. This is most essential to career advancement, I’d say.
The Goal: My goal here was a little more extract. It was a promise to leave things in a better state than when I found them.
The Progress: Not much on this front. One initiative I started at work got a thumbs up from the higher ups and is now prioritized on schedules somewhere. Tomorrow, however, I have a trick up my sleeve.

Always open to feedback, by the way, so leave some! (Even if it’ll be about how I forgot to hit the Publish button on this one a few days ago.)

You may or may not have seen my article on commenting, or my 10 Commandments article in which I listed Commenting as one of the 10 Commandments. Well, there was a little noise in some places about comments being distraction or white noise. Everyone is entitled to be wrong once in a while. (I’m not talking about me, I’m talking about the dissenters among the ranks.) I have many friends toiling in a rotting, comment-free code base. However, it does bring up a valid point. Sometimes comments are useless.

But Chad, I thought you said, “When in doubt, comment.” I did. I just didn’t mean to do it poorly. I did not mean comment on the how. I did not mean to comment about how great you are. I did not mean comment with a giant ASCII image of your face. Side note: I have done that before.

Comment about why the code is doing something, not how. I trust, unfortunately, that clear and concise method names exist. I believe variables should describe themselves. I should not have to discern that a + b really means a + b. Don’t leave a comment telling me that a and b are added together. Leave me a comment stating that a and b must be added together because we want the count of errors AND warning together. Remember, why and not how. Why and NOT how!

That doesn’t mean you can comment about why your algorithm is so great. Sure, you can leave a note like, “This is a no-op for empty strings, so this gives us a 33% speed increase.” Just don’t comment about why you’re so smart for writing the algorithm the way you did. “This first came to my on the 1st of July in a session I taught after first getting my doctorate in Programmatic Awesomeness. I don’t know why no one else thought to copy [1] and [3] with a bit shift instead of a memcpy. Those two indices are obviously not filling up the entire 64 bit long long.”

Don’t be afraid to leave comments as a forewarning to other developers. There are plenty of instances where you might want a one-off comment that tells Jim about the upcoming changes Joe is going to make.

You CAN remove comments. They are not immutable. You CAN fix comments. They are not in cement with the specific line of code they were born upon.

In closing, place comments wherever. Make them useful, though.

Update:

Sometimes, in the videogame industry, people work some late nights. You may not have heard about the wives of EA or the Rockstar San Diego debacle but “crunch,” the family friendly way to say “working way fucking later than you should,” is a dreaded and yet somehow accepted cog in the inner workings of our industry. Here are some ways to tell when you’ve worked too late.

• You feel safe blasting that embarrassing music throughout the office.
• The bathroom lights go off automatically.
• The coffee stops brewing itself.
• You have to make “that call” to your wife.
• You’re learning Spanish from the janitor.
• Your cookies start expiring.
• You start finding edge-case bugs deep in commonly used code.
• You missed the obvious bug in yours.
• (= == ==) evaluates to true.
• Even Wes is gone.
• People start coming into work.