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: All done! I read Practices of an Agile Developer and wrote my review. I finished, Software Optimization Cookbook and published a review for that as well. Finally, I completed Best Kept Secrets of Peer Code Review and wrote a review. Goal accomplished! Everything from here on out is extra credit.

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: Maybe it’s time to change my goal! I’ve been learning ASP.Net for work and it has been coming along very well. Seems like cheating to change my goal, though.

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: Not much architectural work to be done here. Move along.

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

Stick it out, though. I promise there are more articles on the way. I’ve got some drafts started on some objective c code, my monthly updates, a projects page, and a post mortem on a small project. More to come soon. Thanks for sticking with me!

All About Format

A Collection of Essays

The book really is a collection of various essays. Ten of them, in fact, if you count the Code Collaborator User Manual at the end. Most of the essays are written by someone who occupies a position at Code Collaborator. This reads just as you’d imagine. Each essay covers a topic that was probably pulled from a hat full of code review topics, but since they’re all basically an aspect of code review there is a bit of overlap. This isn’t too bad, but it definitely is noticeable.

The Content

Or How I Learned to Stop Worrying and Love the Collection of Essays.

Okay, have I driven that point home, yet? There are a range of topics, however. Most of them are very interesting and contain a good deal of information. There is a case study reviewed in great depth, an essay on the collection of code review metrics, a brief coverage of the Personal and Team Software Process, and more. Even though some of the articles do overlap a little bit, they each have a body of knowledge in their own right. My personal favorite is a discussion of the social effects of code review.

The only thing that I really feel is missing is HOW to code review. I’m sure there are great debates on the subject. Still, it would be nice to get something on the subject even if it’s just another opinion.

My Take

The Summation

Do I recommend this book? Definitely. It is an interesting read, even though it is a nudge towards the Code Collaborator tool. (Side note: Code Collaborator isn’t bad. I’ve used it and it works, but it just didn’t fit with our process.) Like the book, I’ll keep this brief. There are interesting articles. For a free booklet, the value proposition is favorable! Get your copy today.

Dilbert – Buff Bufferman

XKCD – Compiling

Stuff That Happens – Simplicity

Foxtrot – BSOD

Not Invented Here – My First Compile

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: All done! I read Practices of an Agile Developer and wrote my review. I finished, Software Optimization Cookbook and published a review for that as well. Finally, I completed Best Kept Secrets of Peer Code Review and I’m almost finished writing the review. As for blogs, my Reader is to the brim with new items. It is 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: More python scripts. Still no Perl scripts. The usual. Implemented a few more things in Python.

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: Hrm. As always I have trouble defining this one. I have moved something from a tool to a platform. I also completed a project where I think the code base we ended up with was much more stable than how it started. We introduced a very healthy separation of UI and logic.

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

At my current company, we don’t crunch often. However, you may have noticed quite a bit of silence. If you’re at a game company or into games you may also have noticed the correlation between that and E3. Yes, correlation is causation in this case. I’m not bitter or anything. Crunch was pretty light, especially compared to other game companies, and I was mostly staying at work late the other week only due to the time zone difference between Austin and Los Angeles, where the convention was held. My friends were not so lucky. We all know the tales you hear about living at work can be true and for some of my friends, workload was heavy and stress levels were high. People were pretty grumpy. There were many complaints. I almost felt guilty.

This reminded me of an article I read about the game industry maturing. How long is it going to take for the game industry to mature? What happens when we do? As much as I yearn to make a really awesome game, I also yearn to play Ultimate Frisbee, and see my wife among other things. Although I’d be hard pressed to choose work over Ultimate, Ultimate has no say in the matter. Work can put the pressure on you. My wife, on the other hand, can voice her opinion. Apparently she wants to spend time together. Huh. Who’d have thought? It’s like she expected to see me. (I told her I wanted to make video games before we got married! Fair is fair, right?) If Rockstar San Diego is any indication, there are plenty of wives who agree. How come we don’t hear about the Steel Worker’s Union up in arms?

Can video games break out of this rut? The falsehood exists that crunch is an acceptable part of life. It’s less common to see a senior level developer actually be a senior citizen since they’ve all long burnt out on the industry. We tear through young blood for the meat of the development effort. Why? How much are people worth?

What happens when we as an industry mature, however? Movies take a year to make and we can’t and won’t lengthen that process. Can we make games faster? I doubt it. Either the team needs to somehow quadruple in size and we need to find some magic bullet project management techniques or we just need to stop rushing bad licensed material out the door.

Will crunch go away? Driven by milestones, we rush to show off our work. Will we be able to schedule with bugs and found work in the original estimate without bloating the schedule? (Can we just write games without bugs?) It’s a case of the devil you know. I can’t imagine a world void of crunch, but you can hope, right?

I’m going to cut this short because it’s sounding like a rant. My main point is this: can you imagine a “mature” game industry? What does it look like and what has improved?

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!

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!

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.

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.)