I’ve climbed to some treacherous summits in my time. In doing so, I’ve learned a thing or two about the selection of kit and team members for life-threatening situations. When your well-being depends on the technical characteristics of your boots and the prowess of your buddies, the devil really is in the details.
As a note: I often refer to “programmers”; but, all of these lessons can usually be applied to any type of developer.
Also, this is going to be a short post, I’m trying to not write epics; so, some of the ideas might not be fully expressed or fleshed out. Please ask questions! I would love to have a dialogue about this :)
Crampons
In mountaineering, we have these wonderful pieces of equipment that strap onto the bottom of our boots: crampons. Crampons are basically teeth that allow better purchase on icy terrain--often times we encounter glaciers that require these spiked devices. There are various categories of crampons for different needs, as you’d expect. Single point crampons (having a single tooth in the front) are preferred for vertical ice, for example. Some crampons have much smaller teeth or are serrated. Some crampons use only straps while others are specifically designed to mate with certain types of boots. It all depends on the purpose.
You wouldn’t tackle a mountain in tennis shoes, would you? Well, let’s apply that same philosophy to people. Would you have a programmer specialized in weapon systems build your match 2 game?
You might, right? I’m going to briefly explore the implications.
The broad “details”
A shoe is a shoe is a shoe, just as a programmer is a programmer is a programmer. Definitely. Sure. But, as I stated above, shoes have purposes, just as programmers have specialties. If we look at the broad details of a programmer, we might consider experience (what types of platform she has dealt with) and languages (C#, Python, JavaScript, etc.).
These facets of a programmer’s persona can easily be gleamed. We have a project that is on the 360 and uses C++, which of our engineers know these technologies? That sounds fine, right?
Well, a person isn’t just a specification sheet. Indeed, saying, “this shoe is designed to tackle the outdoors” is very different from “this shoe is specifically built to climb mixed ice-rock routes.” So, delving a little deeper, what types of games has this person built in the past? Do they have any preferences? What games does she play? Is she motivated to build these types of games?
We have to look at the person’s fine details to truly understand how we can best use said person. Ideally, this involves engaging the employee in a dialogue, probing them, and so forth. The perfect situation sees an employee making decisions about what project she will work on. Obviously, if your company thrives on projects that are externally introduced, this could be difficult. What happens if no one signs up to work on that project?
It might be worth asking yourself: do we want to actually build this?
The question
Companies are frequently (and dominantly) "fiscally responsible” (in this sense, I mean focused on monetary ends). Yet, are they responsible to the employees that allow their existence? Without skilled programmers, software can not exist. That is just truth.
So, are you applying a hammer to a problem that would better be solved by a screwdriver? The hammer and the screw probably aren’t happy about it.
What are your thoughts?
Have you seen people applied to demoralizing or incorrect projects?
Where have you seen “the freedom to choose” work? Fail?
About the Author
Andrew Andreas Grapsas is a game programmer at Arkadium, Inc. developing facebook games. Previously, he was a gameplay and animations programmer at Kaos Studios|THQ, and intern systems programmer on Medal of Honor.
Andrew is actively writing and programming for various projects. You can read more at his blog aagrapsas.com. He promises to update it soon.