{"id":125411,"date":"2022-06-02T21:02:38","date_gmt":"2022-06-02T21:02:38","guid":{"rendered":"http:\/\/BungieNet_ContentItem_51422"},"modified":"2022-06-02T21:02:38","modified_gmt":"2022-06-02T21:02:38","slug":"engineering-values-handbook-teams-are-stronger-than-heroes","status":"publish","type":"post","link":"https:\/\/sickgaming.net\/blog\/2022\/06\/02\/engineering-values-handbook-teams-are-stronger-than-heroes\/","title":{"rendered":"Engineering Values Handbook \u2013 Teams are Stronger than Heroes"},"content":{"rendered":"

(Not sure what this post is about?  Check out
\nLiving Bungie’s Values as Engineers<\/a>.)<\/p>\n

Let\u2019s unpack our first Bungie value! It\u2019s a good one.<\/p>\n

\"Teams<\/p>\n

How do we live this as engineers?  Let\u2019s look at the more specific ways we try to cultivate high-functioning teams.<\/p>\n

\n

We\u2019re a culture of shepherds, eagerly helping and teaching.<\/p>\n

\n
    \n
  • Shepherd is our word for an expert operating in a knowledge-sharing or guiding capacity.<\/li>\n
  • We celebrate explaining things clearly and efficiently.<\/b><\/li>\n
  • We empathize with the challenges others face<\/b>, and recognize that offering assistance often moves us all forward.<\/li>\n
  • We value helping others<\/b>, incorporating this into our priorities and timeline expectations for our own tasks.<\/li>\n<\/ul>\n

    <\/p>\n\n\n\n
    \u201cI appreciate being in an environment where I’m praised\/rewarded for knowledge sharing and \u2019teaching people how to fish.\u2019 I don’t (generally \ud83d\ude0a) feel like I’m wasting company resources when I spend time writing up an explanation for how to do something, how things work, why things work the way they do, etc., and it makes me particularly happy to do so.<\/i><\/p>\n

    \u201cI’ve worked in an environment where it could actually hurt your career progression to do work like that. Spending time to teach someone how to solve problems on their own would end up with them being rewarded for solving the problems, while you were seen as having taken time away from your Real Job\u2122, even though it made the team more efficient overall. At review time, “This person took the time to educate these five people about how to solve certain problems” wasn’t nearly as measurable or valued as the correlated “These five people learned how to solve a particular class of problems and then solved a bunch of them.” That actively (and financially!) disincentivized helping your peers.<\/i><\/p>\n

    \u201cI feel like that might be slagging the other place more than it is praising Bungie, but even though I’ve been here for ten years, it’s still a breath of fresh air. It’s a thing I actually think about really often, particularly when acting as a shepherd\/point of escalation. I enjoy helping people, and being in a place where that’s encouraged and supported is great for me.\u201d
         <\/i>Mark Yocom, 2012-<\/b><\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

    <\/small><\/div>\n<\/div>\n

    \n

    We prioritize code clarity over brevity.<\/p>\n

    \n
      \n
    • Most pieces of code are read\/analyzed\/debugged many more times than they are written, and the writer usually has the luxury of deep mental context about the meaning of the code, while the reader is trying to build context as quickly as they can.<\/li>\n
    • We value comprehensibility and maintainability over cleverness or terseness.<\/b><\/li>\n
    • We support this with virtually universal code reviews.<\/b><\/li>\n
    • Clarity includes a lot of things, some of which are in tension.  A partial list is below.  Specific best practices vary per language\/ecosystem and are usually covered in Coding Guidelines.<\/li>\n

      <\/p>\n

        \n
      • Easy to understand core functionality<\/li>\n
      • Low likelihood of reader missing a nuance or trap<\/li>\n
      • Easy to discern side effects<\/li>\n
      • Debuggability<\/li>\n
      • Easy to discern performance implications<\/li>\n
      • Easy to discover implementation details<\/li>\n
      • Commentability<\/li>\n
      • Version diffability<\/li>\n
      • Not too verbose<\/li>\n
      • Not too abbreviated<\/li>\n<\/ul>\n

        <\/small><\/ul>\n

        <\/p>\n\n\n\n
        \u201cIn the early years of Destiny’s reward system development (2011-2014), Tristan Root, Austin Spafford, Mark Sachs, and I aligned very closely on coding standards, variable names, and best practices specific to investment systems. One day I realized I could no longer tell who had written what code. We had made it so that two reward system engineers, given the same task or spec, had a good chance of producing identical output. It was awesome. It freed us from a ton of engineering friction and made work feel like a team sport, like rowers pulling all together.\u201d
        <\/i>     Chris Chambers, 2011-2018 and 2021-<\/b><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

        <\/small><\/div>\n<\/div>\n

        \n

        We cultivate egalitarian and empathic relationships with our coworkers.<\/p>\n

        \n
          \n
        • We believe every group, discipline, and subdiscipline is full of people at the top of their fields who are essential to Bungie\u2019s success.<\/b><\/li>\n
        • We empathize with the people who built our technology. <\/b> They solved hard problems with constraints and context we may no longer fully understand. We don’t ridicule their choices or their bugs.<\/li>\n
        • We recognize the risk of being perceived as \u2018gatekeepers\u2019<\/b> to other disciplines and we strive to be worthy of the power implicit in our role as the discipline that most frequently changes what\u2019s possible.<\/li>\n
        • We show empathy to those who have to live within the constraints of our decisions<\/b>, and we\u2019re willing to spend time sharing context and hearing ideas from the customers we serve.<\/li>\n
        • We give context or suggest alternatives <\/b>when we have to tell someone “no.”<\/li>\n<\/ul>\n

          <\/p>\n\n\n\n
          \u201cOne of my favorite teams ever was the Destiny 2 Cross Save strike team. Everyone involved was passionate about making it happen and that made it feel really special. It made me feel like I was part of something much bigger than a single task.<\/p>\n

          \u201cGiven the breadth of groups required to land the experience smoothly, our sync meetings were massive. But there was so much mutual respect and excitement to deliver that\u2014instead of devolving into chaos\u2014I remember these being some of the most collaborative meetings I have ever been a part of. It felt like that mutual respect for everyone’s contribution and perspective extended to a belief that if someone had something to bring up in the meeting, it was important enough to discuss and triage at that level. Oftentimes that allowed for a bit of discussion, some humor, and a concrete answer or decision to regroup after the meeting to discuss further. It allowed everyone to be in the know and chime in if they wanted to be a part of that further discussion (even just to listen). I am sure there were times we needed to rein in all the freeform contributions, but they never felt problematic or like wasted time. Regardless of the discipline or skill level, it felt like everyone was able to contribute to nearly every problem in some way, leveling-up all aspects of the final experience.\n<\/p>\n

          \u201cI also think we did a decent job showing work early and applauding success. This was especially apparent in the UI\/UX design on Bungie.net, where that team would show their prototypes frequently and often helped the broader team spot challenges. For example, we saw an early flow of the user experience for opting in and out of Cross Save, and that allowed us to start the conversation of what information we _needed_ to show players and how the process could fail.\u201d<\/p>\n

          <\/i>
               Brian Chase, 2015-<\/b><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

          <\/small><\/div>\n<\/div>\n

          \n

          We place a premium on high-quality management with high skillset-alignment.<\/p>\n

          \n