Programming Well with Others: Social Skills for Geeks - Google

Programming Well with Others: Social
Skills for Geeks
Google I/O 2011: Tuesday, May 10, 2:30-3:30
Speakers
Ben Collins-Sussman and Brian Fitzpatrick, engineering managers at Google Chicago
Summary
Advice for developers about interacting with people, in the form of a call-in radio show (with
scripted/pre-recorded calls): The Ben and Fitz Show.
Contents
Programming Well with Others: Social Skills for Geeks
Speakers
Summary
Notes: Introduction
1. Individuals
Harlan from Kentucky: I want to hide my code
Dan from Albuquerque: I want to code in solitude
Bill from Peoria: Midichlorians?
2. Teams
Sara from Wilmington: Mission statements?
Tom from Seattle: Which team should I join?
Reginald from Schenectady: I can’t motivate my developers
Robert (Something) from (?): Don’t collaborate too early.
Chronos from (?): Warcraft
Vern from Las Cruces: I’m spending my time giving advice
Scott from Bismarck: Dealing with new manager
Lance from Portland: Why aren’t they getting things done?
Todd from Lisle: How to deal with jerks?
Mark from Ann Arbor: You’re being elitist
Norman from Winnetka: Sawdust?
3. Working with others
Carl from Daly City: Analysts!
4. Interacting with users
Connor from Gallifrey: Marketing wants to spam users
Bill from Santa Monica: Users are unclear
Q&A

Notes: Introduction
Having to work with other people is hard. They get in the way.
The social stuff is hard; it's squishy and less deterministic than the tech stuff.
Human beings are a giant pile of intermittent bugs.
If you want to be really good, you have to do social stuff as well as engineering; doing social
stuff well also makes things more efficient.
Four main areas in today's show:
1. Individuals
2. Social dynamics of being on a team.
3. How your team works with outside contributors or people who work closely with you.
4. How you interact with others, like your users.
In each of the following sections, Q is the caller, and A is Ben and/or Fitz.
1. Individuals
Harlan from Kentucky: I want to hide my code
Q: I’m working on an OS project on Google Code; I want to hide my code and wipe my history.
Don't want people to see the screwups I made when starting out.
A: We all make mistakes, but easy to take it too far.
Everyone's insecure, and we think of people as doing miraculous things—the myth of the genius
programmer. Genius programmers do deserve credit, but they may not have done all the work
themselves.
Think about how you work with a team, not how to present yourself as a genius.
Dan from Albuquerque: I want to code in solitude
Q: I’ve been working on code for month and a half; I want my coworkers to leave me alone so I
can code.
A: He wants to live in a cave. He’s worried about being slowed down by other people.
If you're doing the wrong thing, being fast is no good. Need feedback from others.
You don't write 10k lines of code and then compile; you write some code, then compile. Same
with team: write some code, get some feedback.
Any project needs to be in a tight feedback loop: are you working on the right things, making the

ight design decisions, etc. There’s a high risk to working alone for too long.
If person in cave dies, nobody can pick up that code.
If it's the wrong code, doesn't matter how much you write.
Bill from Peoria: Midichlorians?
(Joke call.)
Q: Are there social issues from midichlorians in The Phantom Menace?
A: Phantom Menace? There are only 3 Star Wars movies.
2. Teams
Sara from Wilmington: Mission statements?
Q: My team lead wants a mission statement. And can you get me an interview at Google?
A: Google is hiring.
Engineers tend to dread mission statements as being meaningless things like “We're focused
on focusing.”
But a mission statement is really a useful way to keep you focused. A direction and a limiter:
going to do this, not going to do that.
Easy to have feature creep.
Fitz: In an Open Source group a while back, I got them to do a mission statement; discovered 2
tech leads disagreed about what they were and weren't working on.
Ben: Need to document mission statement, not just create one. If it's on a web page, it's official.
Fitz: New people in team will argue unless you point them to a web page.
Summary: Not all mission statements are bad.
Tom from Seattle: Which team should I join?
Q: I want to join Google Summer of Code. Two projects: in high-profile one, everyone insulting
each other; other one more obscure, but people seem nice.
A: (Explaining to audience:) Summer of Code is a way for students to flip bits and not burgers.
Culture is important; can't expect it to change.
Some teams are dysfunctional; others support each other.
Culture needs to be strong enough to resist being taken over by new people.

(After analogy to sourdough starter:) Software developers are like bacteria. What you start with
is what you get.
Respect & humility among team members tend to attract others of similar demeanor.
Over long term, you may see projects move toward more aggressive.
When picking a team, think about the culture you want to be part of.
Reginald from Schenectady: I can’t motivate my developers
Q: The developers who report to me are ignoring my orders, no matter how much I yell at them.
A: Yelling and ordering may not be motivating.
Programmers want turns driving the bus, want a stake in the project.
Give them an opportunity to drive.
Your role becomes removing roadblocks so they can drive the bus.
Robert (Something) from (?): Don’t collaborate too early.
Q: Collaboration is bad. What kind of hippie freeload crap are you guys dishing out?
A: If you start collaborating from day 1, you may never get anywhere. Maybe nobody shows up,
or everyone shows up and wants to do different things.
Other end of spectrum: if you do everything yourself, you're collaborating too late. Nobody else
will want to get involved. Not much chance for people to have effect on outcome. Companies
that open-source big products sometimes have this problem.
Best approach: Design, prototype, then collaborate. Collaborate when you’ve got enough to
show it's not vapor. Still early enough that people can have a stake, but late enough that people
aren't going to be arguing about what to do.
Chronos from (?): Warcraft
(Joke call.)
Q: My girlfriend & I are playing World of Warcraft. [Rest of question garbled.]
A: Red Dragon Dynasty doesn't do any recruiting. Contact officers.
Vern from Las Cruces: I’m spending my time giving advice
Q: I have a "friend" with a serious problem: he seems to be writing less code and advising
teammates more, giving advice, etc.

A: Accidental manager, or "leadershipitis." If nobody's assigned to be manager or leader,
someone will fall into that role, whether they want to or not.
Not necessarily bad. Power vacuum, someone sees need & falls into it.
If you call that being a manager, programmers get scared; managers are scary things.
Instead, talk about being leaders, which you can do without being manager or even having a
title.
Scott from Bismarck: Dealing with new manager
Q: How get off on right foot with new manager?
A: Don't wait for orders; take responsibility. Don't come back and say "What do I do next?"
Ben: Act like an adult.
Fitz: “This is what I want to do next, what do you think about that?”
Tell your manager about your roadblocks and successes.
Act like an adult, communicate, and get your work done.
Lance from Portland: Why aren’t they getting things done?
Q: I need people to work faster and longer to meet tight deadline. Why aren't they getting things
done?
A: Carrot & stick approach to management leftover from assembly line days. Stick doesn't work
so well to motivate engineers; engineering is a creative thing, not a rote activity. Carrot and stick
don't get people to be smarter or think more creatively.
Q: What should I do? coddle them?
A: Need to give people a reason to care.
Dan Pink says autonomy, mastery, and purpose. Autonomy: Give them free rein, trust them.
Mastery: Give them a chance to improve themselves. Let the knife sharpen itself. Purpose: Give
people a reason to care, let them feel like they have a stake.
Give them the tools to motivate themselves.
Intrinsic vs. extrinsic motivation. [Mentioned but not discussed.]
Todd from Lisle: How to deal with jerks?
Q: How to deal with jerks?
A: Need to protect your culture. Most important things your team has are attention and focus.
Here to write software, not to yell at each other.

You have emotional reactions, want to spend energy fighting back. It's hard when someone
attacks you not to fight back. But that typically won't stop them. Usenet adage: Don't feed the
energy creature.
On one Open Source project, a famous person said product sucks, in bug report full of bile/
insults. Someone else in project responded with simple/formal language: "Thanks, we'll look into
it." More bile/anger from famous person; more simple/formal polite responses. They did find the
bug and fix it, instead of arguing.
Mark from Ann Arbor: You’re being elitist
Q: This talk is a recipe for [?something]. You talk about building consensus, but you're
screening people who disagree with you.
A: We're not saying get rid of the people; instead, get rid of the behavior. Can alienate good
people if you throw out baby w/bathwater.
They had one really good engineer who kept insulting people; Ben said do you realize you're
upsetting people; guy was surprised. Ben said please behave civilly and guy cut back on
behavior. It's not about who's in and who's out, it's about what behavior is tolerated.
Still, you have to know when to flip the bozo bit.
Another project: guy who's friendly but sent stream-of-consciousness emails to list, and wrong
answers, and he didn't understand when they asked him to stop. But he eventually agreed to
stop posting. Even non-trolls and nice people (such as perfectionists) can drain all attention and
energy by preventing progress.
Healthy and important to have a strong team ego, not individual ego.
Apache has policy of no names on documents/code. Contentious practice. Guy wrote a date
parser, they told him to remove his name from file (due to project policy), he said it was his
code, they didn't take his code.
More important to preserve the culture than accept this one particular contribution.
Norman from Winnetka: Sawdust?
(Joke call.)
Q: [Trying to fill something with sawdust? Garbled.]
A: I think it's a wrong number.
3. Working with others
Carl from Daly City: Analysts!
Q: I’m on an Open Source project; industry analysts want white papers/interviews. Everything's

on the website. How to get people to stop bugging us and read docs?
A: Analysts want you to do a lot of work for them. Engineers think analysts should read
documentation just like everyone else. Programmers don't trust marketing.
But perception is 9/10 of the law. If people don't know about your software, it won't do as well.
Possible to do marketing w/o being slimy.
Underpromise but overdeliver.
If you've got substance, OK to have shine.
4. Interacting with users
Connor from Gallifrey: Marketing wants to spam users
Q: Our company got user email addresses, for license keys; marketing wants to spam users.
A: It's about trust. Things have changed since 15 years ago. Users can switch to other software,
so trust is important. You can spend years building trust, then blow it all at once.
Fitz: People don't trust car mechanics. My father took over a Firestone store that was doing
badly; started to do well because they stopped trying to rip people off.
Other ways to connect to users than sending spam. You can talk to them, listen to them, put up
public bug tracker, use social media, read what they're saying about you in social media.
People love to be heard.
Spamming gives short-term sales bump but long-term hurt.
Bill from Santa Monica: Users are unclear
Q: Users ask obvious questions in forums, and aren't clear.
A: Learning to talk to non-techies is a skill. We do tech support for our non-tech families; hard to
understand in both directions; try to translate intentions, hear what they mean instead of what
they say.
Fitz: My grandmother asked if old computer is worth anything; only turns it on when she wants
to sharpen a pencil. Turns out it's attached to same power strip as electric pencil sharpener.
Learned skill. Customer relations is hard work.
Q&A
Q: Starting a project, but business and IT aren't talking. Business wants everything, IT needs to
limit that. How to get those teams to talk so as not to be in the middle?
A: Hard thing is getting someone w/power in company to drive that conversation. Need a
decision-maker who can bridge the gap. Needs to be solved, though, to get anywhere.

Q: We receive a new "final" set of requirements every few days; super frustrating.
A: Out-organize them. Point out we're glad to do this but we have to cut back on things. Not just
saying yes or no; making clear with data what the tradeoffs are.
Q: Thoughts on continuous deployment? (Run automated tests, put it live on website
immediately.)
A: Fitz: scary. Ben: Fantastic.
Fitz: Can blow yourself up,
Ben: Can spend a lot of time getting it to work. Short vs long-term investment.
Q: We have a new developer who jumped in headfirst & is making changes w/o understanding;
is introducing bugs. But he's 25 years older than me, has an attitude of this is how I've always
done things. How can I approach him? There are 5-10 developers on team.
A: Does your team have a strong culture?
Q: We try to adhere to practices.
A: Have they documented the team culture?
Q: Large project, grown over 10 years. Individuals know their parts well. Other guy's not
respecting my experience in that area.
A: He's not respecting the culture overall; multiple people need to point this out to him. And it's
not just the manager's job; everyone should tell him.
Document your culture/processes.
Get more people involved so it's not just you and him; it's him vs group culture.
Q: A developer pulled an app from Android Market 'cause bad reviews went up to the top of the
reviews, and developer got too stressed. How does a team that's emotionally tied to a product
cope with bad reviews?
A: You're not your code.
F: "Ben and I worked on Subversion years ago; sorry about that."
You gotta learn how to let go and move on.
Are the complaints legitimate? If it's just trolling and griefing, then it's just noise. But look for
constructive criticism.
If you’re going to do Open Source software, buy a rhino skin & wear it for a while.
Q: I'm the new younger guy coming in to an older team; to them I'm a maverick, to me they're
dinosaurs. I want to move fast, they want to move slow.
A: Culture conflict. Is there respect?
Q: Yes.
A: Then this is resolvable. If there's humility/respect/trust, can be worked out. Sit down and
talk about what the processes should be. If you document why you do things, sometimes it
makes non-obvious stuff clear. Research existing culture before deciding to overturn it. If you're
disagreeing w/someone, strive to understand their point of view. The more you listen, the more
you're listened to.
Q: A lot of the whys aren't written down anywhere; I need to document it.
A: Good opportunity to help drive bus.

Q: Other tools to define culture?
A: Wikis. Wearing lab coats. There's a lot of stuff in culture; we focus on social aspects, but
there's other stuff. Beers on Friday. Nerf guns. Eating lunch together, and not necessarily
talking about work. You get to know people as people and not just on a tech level. Makes it
easier to have project discussions.
Q: How do you get people to focus attention on details in design? The people I’m working with
are too basic; you give them a mockup and they give you a mockup back instead of a working
system.
A: When you're most afraid to rock the boat is when you should do it. “This is what I expect of
you and this is where I'm not getting it.” Hard data, at least two examples. They might not know
that they’re not doing what’s needed. Communication is good.
Q: What's right thing to do when the group culture is skewed toward things like spamming? I'm
just an engineer; hard to be persuasive.
A: In other words, how does one engineer change a culture? Find a new company. But you can
make attempts; try to change what you can. Ask people if they've thought about it this way. If
you've tried and failed, you can either stew about it or leave.
Also, reach out to others in company who feel the same way. But remember that companies
aren't democracies. But you can have political movements in them.
Q: Teammate is capable developer who doesn't share things w/rest of team. Boss likes him, he
gets special assignments, etc.
A: Can give boss data—if we could get more info, we could do more. Quantify impact of guy not
collaborating. But if manager and lead want to run things that way, you don't have much option;
they're defining culture top-down.
Also try to figure out psychology of person; are they insecure, egotistical, what? How to get
them to open up? Take social routes if you can.
(End of session.)