Elsewhere > On Confidence and Real-Time Strategy Games
Posted 2011-06-30 on viget.com
I want to talk about confidence and how it applies to being a successful developer. But before I do that, I want to talk about Z, a real-time strategy game from the mid-’90s.
In other popular RTSes of the time, like Warcraft and Command and
Conquer, you collected /(gold|Tiberium|Vespene gas)/ and used it to
build units with which to smite your enemies. Z was different: no
resources, only territories that were held by either you or your
opponent. The more territories you held, the more factories you had
and the faster each of your factories was able to manufacture units.
If you spent a lot of time playing a Blizzard RTS (and of course you did), your instinct is to spend the first portion of a match fortifying your base and amassing an army, after which you head out in search of your enemy. Try this strategy in Z, though, and by the time you put together a respectable force, your opponent has three times as many units and the game is all but decided. Instead, the winning strategy is to expand early and often, defending your territories as best you can before pushing forward.
So What
As developers, our confidence comes from the code we’ve written and the successes we’ve had. When we find ourselves in unfamiliar territory (such as a new technology or problem domain), our instinct is to act like a Starcraft player — keep a low profile, build two (ALWAYS TWO) barracks, and code away until we have something we’re confident in. This will get you pretty far against the Zerg swarm, but it’s a losing strategy in the realm of software development: the rest of the team isn’t waiting around for you to find your comfort zone. They’re making decisions in your absence, and they very likely aren’t the same decisions you’d make. Your lack of confidence leads to poor implementation which leads to less confidence, from both your team and yourself.
Instead, I contend that real-world development is closer to Z than it is to Starcraft: show confidence early (despite lacking total understanding of the problem) and your teammates and clients will be inclined to trust your technical leadership, leading to better technical decisions and a better product, giving you more confidence and your team all the more reason to follow your advice. Just as territories lead to units lead to more territories, confidence leads to good code leads to more confidence.
In short: display confidence at the beginning of a project so that you can have confidence when it really counts.
Do you agree? I’d love to hear your thoughts. Best comment gets my personal copy of Z from 1996. You’re on your own for the Windows 95 box.