2010-08-30

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. We’re over half a year down. July is finished and here’s where I’m at. Expect the August post very soon afterwards!

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!

  • Share/Bookmark
2010-08-25

You may have noticed a long period of silence from me. That is, the few of you who are actually subscribed through Google Reader may have noticed. I’m sorry for that. I’ve been swamped between work, Ultimate, setting up a new computer, and my personal life that the blog has suffered the consequences.

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!

  • Share/Bookmark
2010-07-15

Last time I did a book review of what I will tentatively call a bookvertisement, Intel’s Ho w to Use VTune and Compile Better For Pentium Processors. It was a poor show and I left with but a few nuggets of knowledge. This time I gave Best Kept Secrets of Peer Code Review a shot. It was a risk, I know, but again it was free. This time, I was very pleasantly surprised. This bookvertisement promotes Code Collaborator, a code review tool by Smart Bear. However, this book has taste. It contains ten essays promoting various aspects of code review. It goes over common problems, metrics involved, best practices, and, of course, how their product solves all your problems. The first nine essays are tasteful enough to merely mention Code Collaborator in a footnote or on sentence saying something like, “This is what inspired us to write this feature.” Yes, still an ad, but at least a bit more classy.

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.

  • Share/Bookmark
Rock O' Clock
2010-07-15

I wanted to take a break from our regularly scheduled programming (get it?) and give you some of the best medicine. There are a wealth of comics out there for software engineers and here are my three favorite.

Dilbert – Buff Bufferman

XKCD – Compiling

Stuff That Happens – Simplicity

Foxtrot – BSOD I Hear Windows 7 Fixed Those...

Not Invented Here – My First Compile Good thing they're using source control, right?

  • Share/Bookmark
2010-07-13

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. June came and went (and I forgot to post this) so here’s my progress thus far.

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!

  • Share/Bookmark
2010-07-07

The game industry is immature. As an industry, we just haven’t hit our stride. We still rush licensed fluff out the door in a year and some change instead of a fully fleshed out three year title. We still crunch for insane hours, yet we’re paid less than our more stable software engineering compatriots over in normal product development. It still sometimes feels like we’re a bunch of guys making games with violence, boobs, and blood just so we can see violence, boobs, and blood. We’re still evolving. Warning: This post may be inspired by personal experience.

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?

  • Share/Bookmark
Rock O' Clock