Jump to content

Software engineering is a team sport: How programmers can deal with colleagues and non-programmers

+ 2
  Jenn Webb's Photo
Posted Jul 19 2011 04:59 AM

<p>Programmers need more than great coding skills to succeed in today's tech world. In the following interview, <a href="http://www.oscon.com/oscon2011/public/schedule/speaker/6771?cmp=il-radar-os11-programming-well-with-others">Ben Collins-Sussman</a> (<a href="http://twitter.com/sussman">@sussman</a>), tech lead and manager at Google, and <a href="http://www.oscon.com/oscon2011/public/schedule/speaker/17195?cmp=il-radar-os11-programming-well-with-others">Brian Fitzpatrick</a> (<a href="http://twitter.com/therealfitz">@therealfitz</a>), engineering manager at Google, discuss the importance of maintaining relationships with non-programming colleagues. </p>

<p>Ben and Brian say (while dishing a bit on the topic of their upcoming book) that humility, respect and trust are key tenets to cultivating an enjoyable and productive work environment. The duo will expand on how programmers can work well with others at <a href="http://www.oscon.com/oscon2011/public/schedule/detail/19752?cmp=il-radar-os11-programming-well-with-others">next week's OSCON</a>.</p>

<br />
<p>Your OSCON session description mentions the "<a href="http://www.oscon.com/oscon2011/public/schedule/detail/19752?cmp=il-radar-os11-programming-well-with-others">art of mass organizational manipulation</a>." What is that?</p>

<p><img src="http://assets.en.oreilly.com/1/eventprovider/1/_@user_17195.jpg" alt="Brian_Fitzpatrick.jpg" width="75" style="float: right; margin: 3px 0 10px 10px;" /><strong>Brian Fitzpatrick:</strong> I claim to have a degree in "Organizational Manipulation." That means I have a pretty good understanding of how Google works, and subsequently, I can navigate the company to "make good things happen." </p>

<p><strong>Ben Collins-Sussman:</strong> I suspect that Fitz may be referring to the fact that companies don't always have a power structure that matches the org chart. It takes some real investigation and friend-making to discover where the true nexus of power lies. </p>

<p><strong>Brian Fitzpatrick:</strong> I know of exactly zero companies that have a power structure that matches their org chart. Unless they have fewer than two people.</p>

<br />
<p>How should programmers communicate with non-programming colleagues?</p>

<p><img src="http://assets.en.oreilly.com/1/eventprovider/1/_@user_6771.jpg" alt="Ben_Collins-Sussman.jpg" width="75" style="float: right; margin: 3px 0 10px 10px;" /><strong>Ben Collins-Sussman:</strong> First, look at their eyes, not their shoes. Second, remember that most people don't run on pure logic. (Neither do you, of course, but sometimes it's easy to forget that.)</p>

<p>It helps to add some emotional sensitivity to the mix. For example, when something controversial is being discussed or critiqued, most non-engineers don't appreciate the "raw truth." Engineers like pure information, and tend to expect unadulterated feedback — on code reviews, design plans, and so on. It turns out just stating "facts" doesn't always help when you're with non-techies. You need to wrap facts (or opinions) in a way that makes them easier to swallow. Be a bit roundabout in your feedback, and make sure the other party doesn't construe your response as a personal criticism. Most people tend to be a lot more sensitive than programmers.</p>

<p><strong>Brian Fitzpatrick:</strong> Having respect for the abilities of people who aren't programmers is key. Just because the folks in your company that do marketing, sales, or PR don't know how to code doesn't mean that they're idiots. There's a reason they have their jobs and you have yours — there's a tremendous amount of skill and nuance required for non-engineering jobs. We're honestly pretty lucky to work at a place where we're surrounded by brilliant non-engineer types.</p>

<div style="float: left; border-top: thin gray solid; border-bottom: thin gray solid; padding: 20px; margin: 20px 2px;"><a href="https://en.oreilly.com/oscon2011/public/regwith/os11rad?cmp=il-radar-os11-programming-well-with-others"><img style="float: left; border: none; padding-right: 10px;" src="http://radar.oreilly.com/oscon-code-os11rad.png" /></a><a href="https://en.oreilly.com/oscon2011/public/regwith/os11rad?cmp=il-radar-os11-programming-well-with-others"><strong>Geek Lifestyle at OSCON 2011</strong></a> — From fine-tuning your setup to taking the geek approach to growing your own food, we'll celebrate and explore hacker culture in all its richness in the <a href="http://www.oscon.com/oscon2011/public/schedule/topic/Geek+Lifestyle?cmp=il-radar-os11-programming-well-with-others">Geek Lifestyle track</a> at OSCON (July 25-29 in Portland, Ore.)<br /><br />

<a href="https://en.oreilly.com/oscon2011/public/regwith/os11rad?cmp=il-radar-os11-programming-well-with-others"><strong>Save 20% on registration with the code OS11RAD</strong></a></div>

<br />
<p>How about when collaborating with other programmers — any recommendations for those interactions?</p>

<p><strong>Brian Fitzpatrick:</strong> This is a broad question, and really hits at the core of what our upcoming book is about. We advocate adopting three main tenets: Humility, Respect, and Trust (HRT). If you're humble, respect your colleagues, and trust them to do the right thing, then you're going to have a much better chance at having a productive and enjoyable working relationship. </p>

<p>Certainly, your coworkers will need to earn your respect and trust, but we've always found it best to give people the benefit of the doubt first. If someone can't be trusted or doesn't deserve your respect, you'll figure it out pretty quickly.</p>

<p><strong>Ben Collins-Sussman:</strong> These principles don't just apply to yourself, but in fact can become the basis for a strong team culture. We've said over and over that software engineering is actually a team sport, not an individual one; cultivating a team culture around HRT is the key to some amazing productivity and long-term success when writing software.</p>

<br />
<p>How should disagreements about projects be handled?</p>

<p><strong>Ben Collins-Sussman:</strong> I think the best strategy is to discuss and come to an agreement quickly on a single direction (or set of techniques), even if it means a compromise. What's critical is to have a single set of standards and practices to live by. Nothing messes up a project faster than a mish-mosh of coding styles, organizational practices, or design techniques. Choose them and stay consistent.</p>

<p><strong>Brian Fitzpatrick:</strong> This is really where trust and respect come into play, as well as a strong team culture. Beyond that, establishing a set of programming mores for your team and actually sitting down to design your product before starting to write code can help clarify what exactly you want to do and how you want to do it.</p>

<br />
<p><strong>Related:</strong></p>
<ul>
<li> <a href="http://radar.oreilly.com/2010/08/geeks-at-work.html">Geeks at work</a></li>

<li> <a href="http://radar.oreilly.com/2008/11/lessig-on-culture-and-change-1.html">Lessig on Culture and Change</a></li>

<li> <a href="http://radar.oreilly.com/2010/11/why-delivering-happiness-is-a.html">Why "Delivering Happiness" is a must read</a></li>

<li> <a href="http://radar.oreilly.com/2011/02/it-organization-culture.html">The impact of IT decisions on organizational culture</a></li>
</ul>

0 Replies