(Not sure what this post is about?  Check out Living Bungie's Values as Engineers.)
Value #4, we’re past the halfway point!


This value raises a classically challenging tradeoff in engineering—we’re always trying to strike the right balance between idealism and pragmatism, haunted by the twin specters of overengineering and hacking. Unpacking this value turned out to be a wonderful opportunity for us to define our target balance in as concrete and nuanced a way as we can. Even beyond that, as we pondered this space, we discovered other critical parts of our culture that (as far as I know) we’d never written down.
We always close the loop.

• We do what we said we would, or we let people know.
• We close meetings with clear statements of alignment and clear action items.
• We generally treat (targeted and work-goals-related) e-mail as a contract—responses are expected within a few days, even if it's "sorry, I'm swamped and can't look at this for a few weeks, please let me know if it's urgent" or "this is tricky—can we discuss it in a meeting?"

We pull out of the weeds and seek rational overall strategies.

• We are pragmatic—it's one of the engineering capabilities in our job level definitions!
• We remember that sometimes problems aren't worth fixing because of opportunity cost, side effects, etc.
• We remember that sometimes good ideas aren’t worth doing, for the same reasons as the previous bullet.
• We remember that something going wrong doesn’t necessarily mean someone did something wrong or that something needs to change. Rational risk management means accepting that things sometimes go wrong even with an optimal strategy.
• We deliberately adopt a triage mindset where appropriate, setting aside local idealism to prioritize a more critical overall goal.
• We strive for expected-value-oriented decision-making, including appropriate costing of risks.

We're consistently conscientious.

• When we break something, we fix it, we try to take related work from others, and we apologize to people we've disrupted even if we don't think we made a mistake per se.
• We embrace and envelop new challenges related to our work rather than seeking to defend or justify ourselves.

“I feel like this is a really unique value to Bungie and extremely strong in Bungie Engineering culture. I feel like at other places I’ve worked there are some engineers, usually one or two, who actually go the extra mile to actually make sure the work is done. The crazy thing about Bungie is it feels like this is every engineer. I see people test their work thoroughly, think deeply about edge cases, carefully create error messages, and generally just be the most conscientious engineers I’ve worked with. And it doesn’t end with the code. In my experience Bungie engineers tend to do an amazing job following up with the person who asked for the code to be written to make sure it’s doing what the person expected and they can use it.”      Adam Pino, 2013-

We prefer to solve problems over passing the buck to a better expert.

• On large games/projects/teams, many issues cut across multiple areas of expertise. It's easy to fall into a pattern of investigating one's own narrow area of expertise and then handing off the issue when it seems to cross into unfamiliar territory. That misses learning opportunities and can lead to bugs or features bouncing around between people for days or weeks.
• We'd rather actively venture into unknown systems to investigate a problem holistically than passively kick around responsibility between teams.
• We seek help from the experts early and often, leveraging our culture of shepherds, but we try to retain personal driver responsibility as long as we can be reasonably effective, especially if the affected customer/user/player is primarily supported by our team.
• This doesn't mean that we will dig deeply into any problem that comes our way—it's still critical that we prioritize our work intentionally, in alignment with our manager/team/etc.

“Just yesterday (May 23rd), Laura Robinson resolved an issue with a tool she had never used before, in code she had never seen before, because I'm on vacation and there were no other experts available. The marketing page for Season 17 was blocked from shipping because localization wasn't complete, and localization was blocked because of a bug that existed between the translation software the Localization team uses and the import/export tool for ContentStack which we wrote for them. She was able to familiarize herself enough to find a solution so that she could unblock the Localization team and ensure we could ship the page on schedule!”      Jake Lauer, 2013-

We build the simplest thing that could possibly work, within reason.

• In general, the simpler option is quicker to prototype, cheaper to maintain, easier to debug, and much faster to upgrade when our needs inevitably evolve.
• We’re careful not to take this too far—if a system has known scale requirements, or is about to have its design baked into a ton of content or other code, we do the heavy diligence up front to make sure the foundation will meet our needs.
• We look for bang-for-buck sweet spots—how can we get 80 percent of the value someone wants with 20 percent of the work? Can we change the problem definition to make the solution more simple/maintainable/robust?
• We seek the right level of diligence. We’re wary of discussing a proposal to death when it would be faster to just try it.
• We make compromises mindfully. We often implement non-ideal solutions, but when we do so, we want to understand what we're giving up, what our choice boxes us into, and how or whether revisiting the solution fits into our long-term roadmap.
• We don't let the perfect become the enemy of the good. A system may be a big mess and in need of a massive refactor, but in the meantime, if adding a little bit of documentation or better error handling saves a bunch of people time, we'll do that. We know that looking at what is and doing the next right thing is often higher impact than pursuing a dream of what could be, especially in complex and mature systems.

“So way back when, a designer was looking for some way to have what ended up becoming Moments of Triumph back in Destiny 1: an in-game progression that resulted in being able to buy an IRL physical product reward. At the time, the only reliable and exploit-free way of making such an integration with our vendor looked to be tying it in with discount codes. That seemed feasible but felt disheartening at first because what we really wanted was to just prevent the item from being purchasable outright without some kind of gating. The discount codes felt like a terrible hack, and we thought it’d look and feel bad. But then another engineer, Jake Lauer, brought up that we could make the jankiness part of the feature: pricing it to be a “Bungie-themed” but impossible price ($777,777) and then having the discount code bring it down to its actual cost. “That alternative framing of the problem and the solution made us realize that it might look odd to us, but could be spun as something fun and even intentional-appearing and playful to the outside, while letting us build what we wanted to build. So we went ahead and implemented it that way, and Moments of Triumph ended up being successful and eventually turned into Bungie Rewards which was even more successful. And now we have the more direct implementation that we’d always wanted to have… but we might never have done the latter had we not made that earlier and jankier-to-us version that was able to prove the concept despite the apparent flaws, and I feel like Jake’s ability to frame the downside in a positive light made converts of the rest of the team such that it ended up being created.”      Alex Loret de Mola, 2011-

“I learned the spirit of Closing working with Eric Hanke (then a senior tester) in 2014. We had to make DLC purchases function end-to-end on ten title IDs across four platforms, and we had little time. The platform setups were grueling, the bugs and misconfigurations were strewn across a dozen locations, and few of them were in "our area." We made progress by not caring about area, by triaging bugs carefully, and by finding ways to get closer to done every day. We fixed so many things! Afterward, I realized I liked the mindset... closing felt like a welcome antidote to perfectionism and rabbit-holes. Also, shoutout to Eric for giving me some seriously great support, getting bugs up in the debugger on the target platform so all I had to do was alternate between diagnosing bugs and writing code / changing configurations to fix them!”      Chris Chambers, 2011-2018 and 2021-

See you next time for value #5 – Widen Your Perspective!

-Bungie Engineering

Want to work at Bungie?

We’d love to talk with you. Here are some of the tech roles we’re hiring for, with many more on our careers page!

• Senior Mobile Platforms Engineer
• Unannounced Project Commerce Engineering Lead
• Distributed Systems Engineering Lead