Strategy in Your Coding Career

Strategy in games

Most people are more familiar with strategy games than they are with strategy. They bear the superficial similarity of needing to plan ahead, but the differences are critical.

I’ll use the language of James P. Carse’s Finite and Infinite GamesA finite game is played for the purpose of winning, an infinite game is played for the purpose of continuing the play:

“Strategy in games offers you infinite runs of a Finite Game, where you have almost perfect information and the rules don’t change.”

Strategy in life

Strategy in life gives you one run of an infinite game, where misinformation outnumbers information, and the rules are constantly in flux.

How is real-life strategy relevant to your coding career?

Work on the right problem

Working on the right problem dominates the speed of execution in solving a problem. The “10x engineer” is a popular term, but widely debunked. Large variations in engineer impact do exist. Yet if you look at code metrics, high-impact engineers don’t stand out by lines of code or the number of commits.

In the words of one Googler:

For those who work inside Google, it’s well worth it to look at Jeff Dean, head of Google Brain and Sanjay Ghemawat (cocreator of MapReduce) commits history and code review dashboard. They aren’t all that much more productive in terms of code written than a decent SWE3 who knows his codebase. The reason they have a reputation as rockstars is that they can apply this productivity to things that matter. They’re able to pick out the really important parts of the problem and then focus their efforts there so that the end result ends up being much more impactful than what the SWE3 wrote.

Engineering leaders

Engineering leaders can make disastrous decisions. This sounds obvious in the abstract, but in the workplace, it is common to accept the HIPPO (Highest Paid Person’s Opinion) with no critical thought. This has direct implications for your career; you want to work on projects that will be successful.

Imagine working under Vic Gundotra on Google Plus. Or on Digg’s v4 rewrite following a Google algorithm update. Or the thousands of other less dramatic failures that get swept under the rug in tech. You need to understand the larger context your coding lives in, to push back when appropriate (tactful pushback is a GREAT career skill), and to ask for reassignment when you are being pushed into unsalvageable failure.

Agency

You own your career when you start being aware of what’s around you and taking control of what you work on. Agency = Resourcefulness + Initiative. A decent programmer used to be able to work at IBM for thirty years, with the expectation that IBM would take care of their career if they just stayed long enough. Those days are long gone.

Jobs today are bifurcated: you either tell a machine what to do (you live above the API), or a machine tells you what to do (you live below the API). You can choose to take control or be controlled. Act, or be acted upon. A good manager will be your ally in your journey, while a bad manager will only see you as a tool to accomplish their goals. However, even with a good manager, you bear ultimate responsibility for your career. Never them.