BRIAN FITZPATRICK: My name
is Brian Fitzpatrick. Most people know me as Fitz. BEN COLLINS-SUSSMAN: And my name
is Ben Collins-Sussman. Most people call me Ben
Collins-Sussman. BRIAN FITZPATRICK: And we're
here to talk about working with human beings. A couple little notes,
first of all. We're using the experimental
service called SpeakerMeter so that you can talk all about
this show on the SpeakerMeter site. BEN COLLINS-SUSSMAN: As we
speak, you can rate us up and down, which could be
very exciting. BRIAN FITZPATRICK: Exactly. So good or for bad, we would
love to hear feedback. But thanks to everyone for
coming to this live taping of the Ben and Fitz show. As all of you hopefully know,
we talk a lot about things related to working with people
in computer science, in software engineering. Human beings, otherwise known
as a giant pile of intermittent bugs. BEN COLLINS-SUSSMAN: Right. Good way to put it. Really, probably one of the
hardest things that we don't acknowledge about writing
software is having to work with other people. Right? We study and study how to use
our languages and our compilers, and then you get
to sitting down to writing software with other people, and
you discover that they are in the way as much as the
programming language, or perhaps more. BRIAN FITZPATRICK: Right. Well, the social stuff is
really hard, right? It's more squishy, it's a
lot less deterministic. I mean, your compiler is
incredibly consistent. It's going to do the same thing,
no matter what kind of garbage you throw at it. Go ahead. BEN COLLINS-SUSSMAN:
If you want to be a successful engineer-- this is what we tell our
friends, we tell our family. If you want to ship software
and be really good at engineering, you need to also
focus on the social, and not just the technical. BRIAN FITZPATRICK: But it's also
key to being an efficient engineer, so you don't waste a
lot of your energy bickering and arguing and yelling, et
cetera, that sort of thing. So let's get started here. We're going to talk about-- there's four main areas that
we're going to focus on in the show today. BEN COLLINS-SUSSMAN:
By the way. We're not actual doctors. We should put that out. BRIAN FITZPATRICK: We're
not actual doctors or chemists of any sort. These are just remarkably
comfortable, and we think everyone's going to be wearing
white in the future. So to start off, we have four
different areas we're going to talk about. One is just general personal
behaviors, right? You sort of have to get
an idea of, how do you like to work? What are you good at working
with other people, and where are you bad, and that
sort of thing? BEN COLLINS-SUSSMAN: And then
we're going to talk about social dynamics of being
honest-- oops, did we lose a mic? BRIAN FITZPATRICK:
Check, check. Did you turn your mic off? BEN COLLINS-SUSSMAN: I
turned my mic off. BRIAN FITZPATRICK:
OK, talk's over. Thank you for coming. BEN COLLINS-SUSSMAN: You
just talk while I-- BRIAN FITZPATRICK:
Oh, there you go. You're back on. OK. All right. Well done. OK. Number two. BEN COLLINS-SUSSMAN: Number two,
we're going to talk about the social dynamics of
being on a team. This is, how do you interoperate
with your team, how do they interoperate
with you. BRIAN FITZPATRICK: And next,
we're going to talk about how your team operates with outside
contributors, or folks that work with you that are
not in your core team. BEN COLLINS-SUSSMAN: But may
work closely with you. BRIAN FITZPATRICK: Exactly. BEN COLLINS-SUSSMAN: And then
finally, we're going to talk how you interact with other
people who are not on your team at all, probably
your users. Probably the most important
group you need to work with at some point. BRIAN FITZPATRICK: So we're glad
to have all of you here today on this live,
taped show. We're going to go to
the phones now and take some calls. We're going to start with some
questions, possibly work with the way that you sort of work
with your team, or the way you're sort of used to
working, et cetera. BEN COLLINS-SUSSMAN: Yeah. So questions about personal
behavior. BRIAN FITZPATRICK:
We have a caller. We got Harlan from Kentucky. Go ahead, Harlan. CALLER: Hi, I'm Harlan
from Greenup. I have an open-source project on
Google Code, and I want to hide it until it's totally ready
to take over the world. How can I do that? Oh, I also need to wipe
all the history before revealing it. Can you tell me how
to do that? BEN COLLINS-SUSSMAN: So Harlan
wants to hide his source code before it's ready. Until it's ready. BRIAN FITZPATRICK: Well, Harlan,
why do you want to hide all of your history? CALLER: Well, I don't know. I don't want people to see all
the screw-ups I made when I was starting out. BRIAN FITZPATRICK: Well, that's
understandable right? You don't want people to see a
lot of the mistakes you make in that sort of thing. BEN COLLINS-SUSSMAN: And we all
make mistakes as we work. The problem is, it's easy
to take it too far. Right? So everyone's a little bit
insecure to some degree. And part of it is the fact that
we have this concept in our head of people doing
miraculous things with software development. That someone like Linus Torvalds
just woke up one day, and the Linux kernel sprung
out of his head, fully formed, right? And I want to be
just like that. And so maybe if I cover up my
mistakes, everyone will realize what a genius I am. BRIAN FITZPATRICK: Right. And there's a lot of heroes that
we have like that, right? And in reality, these guys, they
may be really good, and they may have done something
incredible, but they're mythologized to an extent. They don't necessarily deserve
every last bit of the credit that they were given. BEN COLLINS-SUSSMAN: They do
deserve a lot of credit. BRIAN FITZPATRICK: They
do, absolutely. BEN COLLINS-SUSSMAN: So I would
say, the thing that you should credit these folks
for aren't just-- yeah, sure, they started
a project. They may not have done the
entire project by themselves, but they actually led a team. They created a team, they
organized a team, and started something big, and coordinated
something big. And so it had a huge impact. So I think the moral here is
that you should be thinking about, how do you work with a
team, not how do I present myself as a genius. BRIAN FITZPATRICK: Right. You don't have to hide
all your mistakes. Mistakes are OK. Everybody makes mistakes. Let's move to our next caller. We have Dan from Albuquerque. CALLER: Hi. I've been working on this
amazing piece of code for a month and a half, and my
co-workers keep bugging me to show them what I've
got done so far. I totally know they're just
going to slow me down. How do I get them to leave
me alone so I can code? BRIAN FITZPATRICK: OK. So he wants to live in a cave by
himself and write code, and just show up with this sort
of finished product. BEN COLLINS-SUSSMAN: Well, he
sounds like he's worried about being slowed down
by other people. BRIAN FITZPATRICK: Right. But you can be making really
great progress super fast, but if you're doing the wrong
thing, this isn't really worth it, right? So if you're working with other
folks, you need to sort of have that interaction, that
tight feedback loop. When you're writing code, you
don't write 10,000 lines of code and then hit Compile. Does anybody here do that? Because I don't do that. I don't think you do that. BEN COLLINS-SUSSMAN: You have
a tight feedback loop. BRIAN FITZPATRICK: Right. You write some code and
you compile it. Then you write some code
and you compile it. Same way with your team. You write some code and you get
some feedback on not just the style of what you wrote, but
the design of your code, and that sort of thing. BEN COLLINS-SUSSMAN:
That's all right. The question is, any project
needs to be in a tight feedback loop of, are you
working on the right thing? Are you solving the
right problems? Did you make the right choice? If you go too far without
getting any feedback, you may wake up and discover you've
created something that's redundant, or you made
a bad design decision that you can't undo. So there's a high risk to
working alone for too long. BRIAN FITZPATRICK: There's
also, it's a low bus factor, right? If this person in the cave gets
hit by a bus, or giant rock falls and covers the
entrance of the cave, nobody can pick up that bit
of code, right? But more than anything, I think
there's just a risk of wasting time. It's one thing to sit down and
write a whole bunch of code. But if it's not the right code,
it doesn't matter how much you get written. Right? Great. All right, let's take
a new question. We have Bill from Peoria. CALLER: I was wondering how you
guys feel about the social issues implied by the use of
mitichlorians in Star Wars: The Phantom Menace. BRIAN FITZPATRICK: I
think there's only three Star Wars movies. Sorry. Let's take some calls about
working with your team. BEN COLLINS-SUSSMAN:
Stay on topic? BRIAN FITZPATRICK: Yeah. Problems with working your
teammates, concerns about, that sort of thing. So we've got Sarah
from Wilmington. CALLER: Hey there,
I love you guys! We have got a new team leader. He wants us to write a freaking
mission statement. What the hell's with that? Can you get me an interview
at Google? BRIAN FITZPATRICK: Well,
Google is hiring! BEN COLLINS-SUSSMAN: So it
sounds like she doesn't like the idea of a mission
statement. BRIAN FITZPATRICK: Well, when
most people hear mission statement, you think of
smarmy, giant, big corporations saying stuff like, we're focused on focusing. BEN COLLINS-SUSSMAN:
We empower people. BRIAN FITZPATRICK: We empower
people to do the things that they do. BEN COLLINS-SUSSMAN:
Or Kumbaya. Hold hands, let's
have a mission. BRIAN FITZPATRICK: A mission
statement is actually, I think, really important
for a team. Because it's a way of
keeping you focused on what you're doing. It typically has got a direction
and a limiter. So you know we're going to go
this way, and we're going to do this, but we're not going to
do all these other things. BEN COLLINS-SUSSMAN: The limiter
is also important, like you say. It's not just about
what you're doing. It's also about what
you're not doing. That's just as important. Because it's very easy to sort
of have feature creep. And it's important-- well,
actually, you have a cool story about this, I remember. BRIAN FITZPATRICK: We worked a
lot of different projects at Google when we were
open sourcing. And there was one product, about
five years ago, that was going open source. And actually wanted to do their
development in the open. And I talked to them about
the importance of a mission statement. And the team lead was really
enthusiastic, and they got the whole team together
to do this. And a lot of people on the
team weren't really interested in it. But one of the things that
became really obvious quickly is that two of the tech leads
on the team actually didn't agree on what the product
was doing. And I mean, this isn't like
completely unusual here. BEN COLLINS-SUSSMAN: But nobody
realized it, right? BRIAN FITZPATRICK: They had
never actually codified what they were doing and what they
weren't doing and working on. So you know, years later,
I talked to this guy. I'm like, thanks so much for
supporting me when some of your team members weren't
excited about this. He's like, well, I thought it
was a waste of time, but I figured, what's an
hour, you know? We'll give it a try. But like he said, he discovered
really quickly that this was something that they
actually needed to do as a team to be more efficient,
to get everybody on the same page. BEN COLLINS-SUSSMAN: We
should point out. You should do more than just get
everybody to agree on what the mission is. You need to document it. If you simply all agree on what
something is, and it's not written down anywhere, it's
not on a web page, you will still find other people
coming in and arguing with you about it, or trying to question
what's going on. But if it's on a web page,
it's official, right? People get amazed. Oh, it's there on a web page! I guess it's real. BRIAN FITZPATRICK: So whether
it's a new person, an open source project, or someone
coming to join your team, they'll show up and they'll
ask a question. You respond by email, say, well,
this is why we do this. They will argue with
you for a week. But if you say, it's right on
this web page, which is maybe an easily editable wiki,
for all we know. They're like, oh, it's
on a web page. Somebody thought about
this, you know? Maybe we should move on. It's a very serious business. BEN COLLINS-SUSSMAN: But you
know, put it in the same place where you'd put your other
documentations. Your design decisions, your
goals, your failures. Right? You keep a trail of
documentation so people know where you've been and
where you're going. BRIAN FITZPATRICK: Right. So documentation, important
element of communication. Mission statements,
not all bad. BEN COLLINS-SUSSMAN: We
have another caller. BRIAN FITZPATRICK: We've
got Tom from Seattle. CALLER: Hi guys, this is Tom. I'm thinking about submitting
a proposal for Google Summer of Code. I found two projects that
look pretty interesting. One is super well-known, but I
poked around on their mailing list, and they were basically
all insulting each other and being jerks. The other project is more
obscure, but their committers seemed pretty cool. Which one do you think
I should go for? BEN COLLINS-SUSSMAN: All right,
so he's asking which Summer of Code open source
project he should join. BRIAN FITZPATRICK: Well,
Summer of Code. Everybody here knows Google
Summer of Code? Who has never heard
of Summer of Code? So Summer of Code is a way for
students to flip bits and not burgers in the summer. They get paid to work
on open source. That's a huge thing. Culture is really important,
though, and you can't really expect it to change. BEN COLLINS-SUSSMAN: Yeah. So what you'll find is a lot--
and this is not just true in open source, pretty much any
team in a corporation-- you'll find that certain teams
are slightly dysfunctional in the way they interoperate with
each other, and some are really smooth and everyone
respects each other. And you don't see a single team
flip-flopping back and forth, week to week, between
those behaviors. They tend to perpetuate. And in fact, I guess you could
think of it as a culture, just like a yeast culture. It perpetuates. BRIAN FITZPATRICK:
Right, right. So we're in San Francisco,
home of fabulous sourdough bread. Go to any baker that
makes sourdough bread, and talk to him. How do you make your
sourdough bread? The first thing they're
going to put in there is the starter. So the starter is yeast and
bacteria that happen to get together and do some really
awesome stuff for bread. So they take this, and then they
put it into the new flour and whatnot, they make a loaf
of bread out of it. That starter culture inoculates
this loaf of bread, and you get more of
what you want. As opposed to, you know, the
bread just getting taken over by wild yeast and another junk
that gives bad taste. BEN COLLINS-SUSSMAN: And the
culture needs to be strong enough to resist other cultures
that may come floating by. BRIAN FITZPATRICK:
Right, exactly. So what we're saying is that
software developers are a lot like bacteria, right? BEN COLLINS-SUSSMAN: No. But what you start with
is what you get. Right? So if you start a project with
a few people who are all very respectful, and they trust each
other, and there's some humility, that tends
to perpetuate. They tend to attract more people
of the same behavior into the project. And if you start the project
with people being angry and screaming and one-upping each
other, that tends to perpetuate, as well. BRIAN FITZPATRICK: Right. Over the long term, you can
see projects go from more quiet to more aggressive. But you really see a project
go from aggressive to more peaceful and quiet. But so beyond that,
obviously, I think interest is really important. But you've got to find a style
that matches your-- BEN COLLINS-SUSSMAN: Oh,
we're answering his question, that's right. Yes. Think about the culture that
you want to be part of, not just what project. BRIAN FITZPATRICK: So if you're
OK with the big rah-rah fight and aggressive culture,
then go for that. Right? So OK. All right. We have another caller here. Reginald from Schenectady. CALLER: I just hired a bunch
of really good software engineers for my project, but
they're not following directions the way I'd hoped. They don't really seem to
care about the product. How can I get them to
really kick ass? BRIAN FITZPATRICK: Well, OK,
Reginald, do they understand the vision of what you're trying
to do in your product? BEN COLLINS-SUSSMAN:
Are they excited? CALLER: Well, we've got a
product plan from the sales guys, and I told everyone
how important this is. It just seems like they're
ignoring my orders, no matter how much I yell at them. How can I get them
to listen to me? BEN COLLINS-SUSSMAN:
Well, clearly you need to yell at more. No. BRIAN FITZPATRICK: Beatings
will continue until morale improves, right? BEN COLLINS-SUSSMAN:
So the problem is-- I mean, maybe this is
self-evident to a lot of programmers, but maybe not to
all managers, is that way to motivate people is not
necessarily to yell at them and bark orders. That may be good for factory
workers, may not be the greatest thing for knowledge
workers. Programmers want
to have turns. We talk about driving
the bus, right? They want to all feel like they
get a turn to drive the bus and have a stake
in the project, decide where it's going. BRIAN FITZPATRICK: If you give
them the opportunity to drive, and not just sit in the bus and
do what you tell them to do, they're going to
do a lot more. You're going to get a lot
more out of them. They could possibly do some
amazing stuff that you didn't think of. BEN COLLINS-SUSSMAN: Right. In which case, your role becomes
not barking orders, but instead, just removing
roadblocks so they can drive the bus whatever way makes
sense most to them. BRIAN FITZPATRICK: Right. We talk about sort of servant
leadership where your job as a leader isn't to bark orders and
yell at people what to do, but to sort of clear the road. Clear the path for them. Help them out. Get them what they need to
get their work done. So thanks. BEN COLLINS-SUSSMAN: There's a
lot more to say about that. Well, let's keep going. BRIAN FITZPATRICK:
So we have a call from Larry from Hartford. CALLER: That one guy who was
working in a cave before didn't want anyone to bug him. But you told him it's
important to work with the team. But surely, you can't do
that from the start. If he did, he'd never
get off the ground. What kind of hippie free
love crap are you guys dishing out here? BEN COLLINS-SUSSMAN: So he's
saying, if you start collaborating from day one,
you'll never get anywhere. Which is kind of true. BRIAN FITZPATRICK: If you
start too early-- I mean, you can look at, what,
Google Code, GitHub, SourceForge. And there is just tons of
projects where someone comes out and says, I have
this great idea! And then nothing happens. BEN COLLINS-SUSSMAN: Here's my
readme file describing how I'm going to take over the world,
and nobody shows up. BRIAN FITZPATRICK: Or a bunch of
people show up and want to do a whole bunch of
different things. BEN COLLINS-SUSSMAN: Yeah. And they all argue forever, and
they never do anything. BRIAN FITZPATRICK: So that's
what too early looks like. BEN COLLINS-SUSSMAN: But if you
go to the other end of the extreme, the other end of the
spectrum, which is, if you do everything yourself, not only do
you have this risk of doing the wrong thing, but if you
just sort of reveal to the world something that's
mostly done, that's collaborating too late. And nobody wants to get
involved, probably because it's done. Right? Or there's no chance to
make a mark on it. BRIAN FITZPATRICK: Even if it's
not done, it's so far past the mark, I guess, that
people just aren't going to come and take your orders. There's not a lot of chance for
them to have an effect on what they do. BEN COLLINS-SUSSMAN: And you
see that sometimes with companies that take gigantic
products, open source them, throw them over a wall. Nobody comes because it's
finished and too hard to figure out. BRIAN FITZPATRICK: So I think
the real answer for Larry is design, prototype,
then collaborate. That's when you bring
other people in. Because you've got something to
sort of show and work with and chew on. BEN COLLINS-SUSSMAN: That's
a sweet spot, we call it. So if there is a prototype, sort
of a proof of concept, that's enough to show people
that it's not vapor. And it's still early enough that
people can get involved and feel like they have a stake,
but it's late enough that people aren't going to be
arguing about what to do. BRIAN FITZPATRICK: And that
doesn't mean you shouldn't talk to anyone about it. Talking to friends or something,
or getting advice from people, hey, what do you
think about this, and getting feedback is a good thing. But sort of opening the
floodgates for help and collaboration is what we're
talking about there. BEN COLLINS-SUSSMAN:
All right. So our next caller is Chromos
from Azjol-Nerub. CALLER: My girlfriend and I have
been playing Warcraft for seven years, but the last couple
raids, things have started to get rocky. I found out from her friend
she's been talking about joining another guild, and I'm
not sure my 25 men will be able to run anymore. What can I do to patch
things up? BRIAN FITZPATRICK: Is that
a Warcraft question? BEN COLLINS-SUSSMAN: I can tell
you that the Red Dragon Dynasty doesn't do any
recruiting at all, except in the realm forums, strictly. And if you see someone doing
that, you should contact one of the officers. But not during raid times. BRIAN FITZPATRICK: OK, thanks. So let's try and focus a little
more on topic here. Let's go back to the calls on
our teams here, please. Now we've got Vern
from Las Cruces. CALLER: Long time listener
and first time caller. I have a friend who has
a serious problem. He hasn't told anybody
about it yet. BRIAN FITZPATRICK: What
kind of a friend? Tell us more about
your friend. CALLER: Yeah. Well, he seems to be writing
less code lately, and advising my-- his-- teammates more and more. It's not like he's their
manager, but people keep looking to him to fix arguments,
and decide stuff, and give advice and things. Should I get him to see
a doctor or something? BEN COLLINS-SUSSMAN: Well, we
only look like doctors. BRIAN FITZPATRICK: Well, your
friend sounds like they're suffering from what we call
accidental manager, or leadershipitis. BEN COLLINS-SUSSMAN: So you
have this situation. And anytime you have a group
of people working together, even if there's nobody assigned
to be the manager or the leader, somebody will fall
into that role, whether they like it or not. They'll start advising
people, resolving-- BRIAN FITZPATRICK: Well, it
might not be they'll go kicking and screaming. But they'll see a need, and
determine that I'm the person who's going to step into this. BEN COLLINS-SUSSMAN: It's not
necessarily a bad thing. I think it's just
human nature. There's a power vacuum. Somebody falls into it. And it's scary. If you call that
a manager, then programmers get very scared. Because the word manager
is a dirty word. We hear the word manager, we
think of pointy-haired Dilbert characters. Manager is a scary thing, which
is why we like to talk about leaders instead
of managers. People can be leaders without
being managers. People can be leaders without
having a title. BRIAN FITZPATRICK: Right. So the answer to Vern's
question, it's OK. And it's not a bad thing,
necessarily. All right. So that was good. Let's talk a little more
about leadership. Is there anyone out there who's
leading teams that has some questions? Scott from Bismarck. Go ahead, Scott. CALLER: We have a new manager
starting next week. I haven't met the guy yet,
but I want to get off on the right foot. Do you guys have any
tips for me? BEN COLLINS-SUSSMAN: So the
question is, how to get off on the right foot with
a new manager. BRIAN FITZPATRICK: Don't
wait around for orders. Basically, I'd say take
responsibility. If your team lead says, you
know, I want you to go in and look at a particular treatise
having an issue, don't just deal with that and come back. Go out in the forest and find
other similar issues, and come back, and say, look. I found this, and this is
what I'm going to do. I mean, I think the worst thing
to do is come back and say, what do I do next? BEN COLLINS-SUSSMAN: You're
saying, so, act like an adult. BRIAN FITZPATRICK: Oh,
well, that's crazy. But if you come to your manager,
or your leader, and you say, you know, this is what
I think I'm doing next. What do you think about that? As opposed to, what do
you want me to do. BEN COLLINS-SUSSMAN: So
there's a proactive communication. Don't wait for orders. Proactively pursue some
responsibility. Go out and figure out what you
think you should be doing. Don't just be a yes man. Have some opinions. Express what you really think. Tell your manager about
your roadblocks. Tell your manager about
your successes. BRIAN FITZPATRICK:
Communicate. Act like an adult, communicate,
and get your work done, right? There's a guy who started to
work with me few years ago, and he'd been in the industry
for like 20 years at this company, And the first day he
comes to me, and it's quarter to five, and he's like, look. I've got to leave early. I had an appointment that
I couldn't change. I'm really sorry. But I'll be here late tomorrow,
it's no problem. And I said, look, man, I don't
care when you come and go. As long as you put in your
85 hours a week, you're fine, right? And he's like, well, what am
I going to do with all my spare time now? BEN COLLINS-SUSSMAN: Poor guy. BRIAN FITZPATRICK: But
seriously, it's like it's, you don't need to stamp
a time clock. You know what your
responsibilities are. You know what you need to do. You know how much you need
to do to get it done. BEN COLLINS-SUSSMAN: Act
like a grown up. BRIAN FITZPATRICK: Exactly. OK. We have our next caller. Lance from Portland. CALLER: Hi, guys. Just like that other caller, I
work under a tight deadline. I need people to work
faster and longer. I've even threatened to fire
folks if they can't get their performance up. What's wrong with
these people? Why aren't they scared? Why aren't they getting
more done? BEN COLLINS-SUSSMAN: So he's
threatening to fire people unless they get their
performance up. Stick. Shake a giant stick. That doesn't work so well. BRIAN FITZPATRICK: Especially
not with engineering people. Engineering is a
creative thing. I think that it's not just
a matter of some rote activities. I think managers really came
into prevalence during the industrial revolution. You have your assembly line. You have your workers who are
stuffing cans with meat. And you know, you shake the
stick at them, you give them the carrot, et cetera. You want to get things
going more quickly. There's not a lot of independent
thought there. BEN COLLINS-SUSSMAN: But if I
shake a carrot or a stick at you, you're not going to be
smarter, necessarily. BRIAN FITZPATRICK: Or think
more creatively. BEN COLLINS-SUSSMAN: Think
more creatively now or I'll fire you! You need to nurture
people, right? I mean, really sort of help them
to get their job done. CALLER: So what am
I supposed to do? Coddle them? Offer them raises and bonuses
to meet their deadline? Kiss their asses? Fluff their pillows? You guys are useless. [DIAL TONE] BRIAN FITZPATRICK: Thank you. Thank you for calling. Either way. I think you need to give people
a reason to care. I mean, tell your-- BEN COLLINS-SUSSMAN: Well, so
there's this great guy named Dan Pink who talks on the
internet and other places. He talks about, all right, well,
here's how to actually encourage people to
be productive in the knowledge industry. Right? You should give them autonomy,
mastery, and purpose. I love these three things. Autonomy means, treat them
like a grown up. Let them do their job the way
they want to do it, what makes sense for them. Give them some free rein
in making decisions. And trust them. Mastery means give them a chance
to improve themselves and learn new things so
they stay engaged and they stay sharp. You don't want to take your
sharpest knife and grind it in the sidewalk. You want to let the knife
sharpen itself. And finally purpose, meaning
you want to let the people actually feel like they have a
stake in what they're doing. Give them a reason to care. So it's really important
to them. BRIAN FITZPATRICK: To summarize,
I think there's no way that you can actually get
someone more motivated than they can motivate themselves. So give them the tools that
they need to do that. BEN COLLINS-SUSSMAN: Intrinsic
versus extrinsic motivation. BRIAN FITZPATRICK: Right,
absolutely. That's an excellent question. OK. We have Todd from Lisle. Go ahead, Todd. CALLER: I've got to say,
that last guy seemed like a total jerk! There's a guy on my team who
acts like that, too, almost all the time! How do you guys usually deal
with people like that? BEN COLLINS-SUSSMAN: That's
a good question. He's asking, how do we deal
with people who are jerks. BRIAN FITZPATRICK: Well, we see
this with people not only in your team, but outside
of your team, as well. BEN COLLINS-SUSSMAN: Which is
a good segue to the next section, right? Talking about working with
people closely who aren't necessarily on your team. BRIAN FITZPATRICK: Right. Well I mean, you need to protect
your culture, right? And the most important thing
that your team has is attention and focus. And what you're doing, you're
here to write software. You're not here to get in
a giant yelling contest. BEN COLLINS-SUSSMAN:
Although it's hard. Because people will
push your buttons. You'll want to have these
emotional reactions. If they're trolling you, or
they're just being mean in some way, you want to spend a
lot of energy fighting back, or hurting them back, and it's
easy to get carried away. And then you suddenly realize
you've wasted your whole day, you're emotionally drained,
you've not written any software at all. BRIAN FITZPATRICK: It's really
hard when someone verbally or in an email or whatever
attacks you, not to fight back. You want to give them that
little zinger that puts them in their place and all, but
typically, it's not going to affect them. They're going to keep going. So there's an old
Usenet adage-- remember Usenet, around
about 700 years ago? Don't feed the energy
creature, right? And really, I think that's
really important. BEN COLLINS-SUSSMAN: We were on
an open source project for many years, and a rather famous
person came to the mailing list and said, oh,
this product sucks. It's terrible. What's wrong with you people? He was basically there to give
a bug report, but the email was full of just incredible
bile and insults. It was ridiculous, right? And I was so proud, because we
didn't actually respond. Somebody else in the open source
project responded with the most simple, formal
language, like, oh, looks like you found a bug. Thanks. Can you try doing
this instead? We're going to look into it. And of course, he responds back
with just more anger and bile, and [GROWL]. And you know, every time
somebody else from our community just responds very
calmly, as if there was nothing wrong-- BRIAN FITZPATRICK: We found
the bug and we fixed it. BEN COLLINS-SUSSMAN: But it's
funny, because the guy kept looking like more and more
of an idiot the more he responded, and the less we
responded to the bile. But we did find the bug. BRIAN FITZPATRICK: But if we'd
just tried to argue, we could have easily gone off into a
giant argument with the person, right? All right. That's excellent. We have Mark from Ann
Arbor on the line. CALLER: Hi. I've heard you guys give
this speech before. And as far as I can tell, it's
just a recipe for elitism. You talk about building
consensus-based teams, but you're just looking for
a bunch of pushovers. All you guys want to do is
screen out people who disagree with your team. BRIAN FITZPATRICK: He's saying
we're being elitists. BEN COLLINS-SUSSMAN: Well. Maybe he should go away. BRIAN FITZPATRICK: Well, I
think it's an important distinction to make here. We're not talking about throwing
the people out, or getting rid of the people. We're talking about addressing
the behavior. There's a huge difference. I mean, you can actually wind
up alienating really good people if you sort
of throw the baby out with the bathwater. We had one guy who was working
with us who was really an amazing engineer. But he pissed everybody off. He just constantly said things
that were insulting. He'd go along, work, work, work,
boom, say something, and people would be like,
what the heck? And so one of us, I
think it was you-- You pulled him aside on chat
or something and said, you know, hey, do you realize that
when you do this, you're having this effect on the
rest of the team? And he was shocked, wasn't he? BEN COLLINS-SUSSMAN: I did
think he was surprised. But the point was, we didn't
say, get out of here, you're a jerk. We said, please behave
in a civil manner. I don't think you realize that
you're not being civil. BRIAN FITZPATRICK: Right. And I don't think he quite
realized it, but he cut back on the behavior. And things did smooth
out quite a bit. BEN COLLINS-SUSSMAN: Right And
so that's what say for people who are moderating mailing
lists, any kind of lists, right? It's not about who's
in and who's out. It's about what kind of behavior
is tolerated by anybody, whether they're
on the list or not. BRIAN FITZPATRICK: But on that
same note, you do also have to know when to flip
the Bozo bit. You get some people who
just don't understand. We did have one guy who wasn't
actually writing code, but he was really enthusiastic, and
really friendly, and he would answer other people's questions
all the time, incorrectly. He would also just sort of free
associate on the mailing list. Hey, did you ever think
about putting this in? BEN COLLINS-SUSSMAN: It
was like his stream of consciousness kept emailing
the list every hour. BRIAN FITZPATRICK: We should put
a list of Star Trek reruns in the documentation. You're like, what? And we actually talked to him
a couple of times about it, and he didn't quite get it. We finally sort of said, look,
you need to stop doing all this stuff. And he really didn't
understand. But he did agree to actually
stop posting about all this. That was one of the harder
things, right? BEN COLLINS-SUSSMAN: Well, I
think what that proves is that there could be people who are
disrupting your team's attention and focus who are not
trolls, who are the nicest people in the world. One example is just people who
are perfectionists don't realize they're being
perfectionists. And they can actually drain all
the attention and energy by never letting anybody start
because the design doc is not perfect yet. So that's an example. BRIAN FITZPATRICK: But to turn
all this around into a different way of looking at it,
it's really healthy and important to have a good
team ego, as opposed to individual egos. BEN COLLINS-SUSSMAN: I know
that's the Apache Software Foundation's-- BRIAN FITZPATRICK: Right. Apache is about building
communities. If anyone has ever looked
through a lot of the Apache code, you rarely find
someone's name at the top of a file. This is a practice that
is very contentious. It's almost as contentious
as vi versus Emacs. How many people here use vi? Anyone? How about Emacs? All right, fight! No, I'm kidding. There was this one guy came to
our product who wrote a whole date parser module. It was a pile of code. It was actually great. It was pretty well written. When we went through and gave
him the code review. We said look, you know, here's
our style guide. You did great on
this and this. But take your name out of
the top of the file. We don't have anyone's names
in the source code. BEN COLLINS-SUSSMAN: It's
just project policy. BRIAN FITZPATRICK: We have other
ways of acknowledging people helped out. And he's like, no, I wrote
this code, I'm putting my name on it. And we went back and forth him
him, trying to explain, look, this isn't about trying
to take away credit. But I mean, where does
it stop, right? I wrote three lines of code. Do I get my name in there? You wrote ten lines of code,
but I rewrote them. BEN COLLINS-SUSSMAN: Or what
if I delete some code? Does that mean the
name comes out? BRIAN FITZPATRICK: It's just a
lot of wasted energy, right? There's other ways to
recognize people. You do want to recognize
people. It's very important. It's a way of increasing
intrinsic motivation, I would argue. But we wound up not
taking this guy's code, and he went away. BEN COLLINS-SUSSMAN:
Which is sad. But it's also one of those
cases where it was more important to preserve the
culture than to accept this one particular contribution. BRIAN FITZPATRICK:
Yeah, excellent. All right. We've got Norman
from Winnetka. CALLER: I've been a long time
listener, Click and Clack. You guys do just an absolutely
amazing job. Long time fan. Anyway, I've got this
[UNINTELLIGIBLE] cream. It's an '84. Yeah, so anyway, the
transmission makes this da, da, da. I've tried to fill it with
sawdust, but I just don't know what to do about it. BRIAN FITZPATRICK: Have you
tried rebooting it? That fixes a lot of problems. BEN COLLINS-SUSSMAN: Think
it's a wrong number. BRIAN FITZPATRICK: Yeah. All right. Well, let's go back
to working. Let's move on to people who work
with your product, right, as opposed to people
on your team. Users. Yeah, take a couple
of calls from-- we have Carl from Kansas City. CALLER: I've been listening
forever. I'm on an open source project,
and it's been doing really well. And lately, a bunch of industry
analysts have been asking us for whitepapers,
and bugging us for interviews and things. Everything about our software is
up on the website, clearly. And the mailing list is archived
and everything. These analysts and reporters,
these guys just don't get it. How do we get them to stop
bugging us and read the same docs as everybody else? Have you ever had to deal with
these kind of people? BEN COLLINS-SUSSMAN: So the
question is about how to deal with industry analysts. Do they wear white coats? BRIAN FITZPATRICK: They don't. But they do expect you to do
a lot of work for them. So I was VP of public
relations for Apache for a while. And we would get analysts who
would show up and say hey, you know, we're doing this
enterprise report on blah blah blah software, can you get this,
this, this and this? Because they're used to going
to big companies and saying, give us all this stuff. And people go, yeah, right
away, here it is. Can I get you a cup of
coffee with that? Because they want them
to write good things. And then engineers, thinking
very logically, think, well, this jackass should go read
the documentation. BEN COLLINS-SUSSMAN:
Like everyone else. BRIAN FITZPATRICK: It's
all answered in the mailing list somewhere. Go search for it. Right? That doesn't fly so well. BEN COLLINS-SUSSMAN: Well,
programmers don't like anything to do with marketing,
I think. In general, they distrust
marketers. BRIAN FITZPATRICK: How many
people here love marketing? Other than the marketers? No, I'm kidding. But the point is, is that I
think perception is important. I could say perception is
nine tenths of the law. You could have a great
piece of software. If people don't know about it,
if you don't shine it up a little bit, you're not going
to do as well as you could have. BEN COLLINS-SUSSMAN: I think
also a lot of folks don't realize that it's possible
to do marketing without being slimy. BRIAN FITZPATRICK: No! BEN COLLINS-SUSSMAN: It's
possible, I mean, you can underpromise and overdeliver. Make that your policy. BRIAN FITZPATRICK: So if you've
got substance, it's OK to do some shine. I think where it comes into
problems is that people expect that you just get a lot
of shine, right? BEN COLLINS-SUSSMAN: All
shine, no promise. So what's the answer
to the question? I think the answer is play
the game a little. BRIAN FITZPATRICK: Play
the game a little bit. I don't think you have to
really, like, fall over to do everything for them. But you do need to, I think,
play a little bit along there. BEN COLLINS-SUSSMAN: Don't
discount it completely. BRIAN FITZPATRICK:
Right, right. So our next caller is Connor
from Galifrey. Go ahead, Connor. CALLER: My company
has the email addresses of all our customers. We got those mainly so we could
send out license keys. We promise not to spam our
users, but now some of our marketing guys are begging to
email the customers with-- they call it the occasional
product update. I don't think it's worth pissing
our users off for a quick bump in sales. What's your take on this? BEN COLLINS-SUSSMAN: So the
question is, is it worth getting a bump in sales to
spam the users, I guess? Sounds like spamming to me. BRIAN FITZPATRICK: No. Next question. No, it's about trust, really. And it's interesting, because
we're in a different place than we were 15 years
ago, thank God. Nowadays, in the software world,
it's really easy to switch and try other software. People can use your
software easily. They can just as easily
try someone else's. BEN COLLINS-SUSSMAN: So having
a trust reputation, your company's reputation, how much
people trust you, is really, really important. And it's dangerous, right? We always say trust is
like a bank account. You can spend years building
up trust with your users. But one night in Vegas,
it's all gone. You blow it all, you blow
all the trust at once. It's very scary. And doing things like sending
spam, it's a slippery slope. It's a way to blow your
trust right away. BRIAN FITZPATRICK: Well,
I have an example. My grandfather managed
a Firestone tire store for 35 years. How many people in this
room own a car? Leave your hands up. How many people own
a car and have a mechanic that you trust? Wow. That's got to be nine
people with their hands up in the room. BEN COLLINS-SUSSMAN:
Why is that? BRIAN FITZPATRICK: That's
an example. I think mechanics are typically
an industry where people take advantage of you. You go in with a flat tire, and
they're, oh, you need to, your flux capacitor is a little
bit too slow, and you're going to do a complete
radiator flush, and fluids check, and don't forget-- BEN COLLINS-SUSSMAN: They call
it mailboxing, right? BRIAN FITZPATRICK: Exactly,
yeah, sort of selling people other things. My grandfather, for 35 years,
he took over this store. And when he took it over, it
lost more money than any other store in Louisiana, and within
three years, it was the number one grossing store
in the state. And that wasn't just because
they did great stuff. It was because he didn't
try and rip people off. 95% of his business
was return. It came back. It very quickly paid
for itself. There's no real point
to doing it. Short term benefits, but
in the long term, it's going to kill you. BEN COLLINS-SUSSMAN:
But getting back to the question, right? I mean, clearly, this guy's
company, they want to connect to their users. There's other ways to do it
besides sending product updates unsolicited. I know it's possible. You can have a relationship
with the users that isn't just spam. For example, you can talk
to them directly. BRIAN FITZPATRICK: No! BEN COLLINS-SUSSMAN:
I know, it's crazy. You can listen to them. Give them an outlet
to communicate. For example, put up a
public bug tracker. We've got social media
now, where you can communicate updates. You can read what they're
saying back about you in social media. BRIAN FITZPATRICK: You
see this with a lot of startups, actually. A lot of really successful
startups that have user-facing products. They are in the trenches every
day, helping their users, supporting them, answering their
questions, listening to their feedback and implementing features based on that. BEN COLLINS-SUSSMAN: They
love to be heard. BRIAN FITZPATRICK: People
love to be heard. I mean, I know that I like to
be heard when I'm using a piece of software. To answer the question,
is it OK to spam customers like that? I think you're going to get
a bump from it in sales. It's going to be a short term
thing, and I think it will hurt you in the long term. Let's get another call. We have Bill from
Santa Monica. CALLER: My company does
listen to users. They're always asking totally
obvious questions in our forums. Half the time, they're
unable to explain their problem, so it's almost
impossible to help them. BEN COLLINS-SUSSMAN: So he's
saying he's having trouble understanding users when
they do talk to him. BRIAN FITZPATRICK: It's
a skill, right? BEN COLLINS-SUSSMAN: For
example, learning to talk to non-techies is a skill. I feel like probably everybody
in this room talks to their parents at some point, or
relative on the phone. BRIAN FITZPATRICK: Who does tech
support for your parents on the phone? BEN COLLINS-SUSSMAN:
Tech support for your family, right? And you're on the phone, and
you're trying to understand what the heck they're talking
about, because they're using language you don't understand,
and vice versa. And so it becomes this skill you
cultivate where you try to read what they mean,
not what they say. BRIAN FITZPATRICK: You have
to translate intentions. The most extreme example
I have of this, my grandmother, OK? My grandmother, I love
her to death. We're sitting down one day
talking, and she asked about my grandfather, who died years
ago, asked about his computer. Is that computer still
worth anything? And it's like a Mac
Classic, you know? And I said, well,
no, not really. She said, oh, OK. I only ever turn it on when I
have to sharpen a pencil. And I'm like, wait. I know I'm going to regret
hunting this down, but I've got to figure this out. So it turns out that the
computer is plugged into a power strip, and there's also
a pencil sharpener plugged into this power strip. So every Saturday, she goes in
with her three pencils, turns the computer push on, the little
Mac goes beep, and starts whirring up slowly. She sharpens the pencil,
and then boom! Kills it. Once a week, every week. BEN COLLINS-SUSSMAN: For
a Mac, never efficient. BRIAN FITZPATRICK: I assure
you, I liberated the computer quickly. It's safe. BEN COLLINS-SUSSMAN: You put
it out of its misery? BRIAN FITZPATRICK: I put
it out of its misery. But I mean, talk about,
like, holy cow. What are they thinking, right? And so I think it's really
important to make an effort. And it's a learned skill. You can actually
cultivate that. And the people who do it, I
think, full time, should win some sort of award. BEN COLLINS-SUSSMAN: Developer
relations people? BRIAN FITZPATRICK: Man, that's
some of the hardest work. Not just developer relations,
like customer relations. I think developers typically
understand more. So OK. That is it. Thank you all for coming to this
live taping of our show. We'll switch over to live Q&A
in just a second, but that's all we have today. Thank you. We have microphones, if
you have questions. If you do have a question,
please step up to the microphone and ask it, so
we can all hear you. Or maybe no questions at all. Anyone? We scared everyone away? Have we answered all your
questions already? BEN COLLINS-SUSSMAN: Maybe
they don't want to be on the air. BRIAN FITZPATRICK: No? This part isn't taped, I
don't believe, anyway. So all right, first question. You can go right ahead. AUDIENCE: [UNINTELLIGIBLE] BRIAN FITZPATRICK:
Whoa, no, wait. Speak a little bit
more slowly. Sorry about that. Go ahead. It's not on? It should be on. Check? AUDIENCE: I don't think
so There it is. So I'm starting a project right
now, and my business and my IT are just talking. I'm the developer. How do I drive that discussion
so we can develop requirements and actually get this project
off the ground? BRIAN FITZPATRICK: So business
and IT aren't talking, you said? AUDIENCE: That's right. Business wants everything. IT needs to limit that. How do I get those two teams to
talk so that I don't have to be in the middle? BRIAN FITZPATRICK: That's
a really hard problem. BEN COLLINS-SUSSMAN: I think we
need to know what they're arguing over to be able
to answer that better. BRIAN FITZPATRICK: Well, I mean,
I've seen this, before where business, like, you know,
we need everything and we need today. Right? And tech, you're like, well, we
can only give you so much. And there's a big disconnect
there. So I think the hardest thing to
do is getting someone who has actually the power in the
company to drive that conversation. You can't drive the conversation
if you're just sort of an observer, or not
somebody who's actually running one team or the other. BEN COLLINS-SUSSMAN: Which is
a case where you need a decision maker who can
bridge the gap. I think some things can't be
entirely fixed through discussion. BRIAN FITZPATRICK: But if you
can't find help for that, I would say that I don't see you
going anywhere soon, except for the wrong way. Thanks. Next question? AUDIENCE: Yeah. A company I've been working for
lately, they'll put out about a new final set of
requirements every few days. And it's just super
frustrating. So can you give any advice
about how to kind of cope with that? BEN COLLINS-SUSSMAN: The
question is about how to deal with constantly changing
requirements. BRIAN FITZPATRICK: I like
to deal with that by organizing, right? So as an engineering team, if
you've got a roadmap that goes out for a year for your product,
which I know, it's hard to really predict
anything past three or four months. But if you've got this roadmap,
and the team comes back the next day, and
say, OK, we need you to do all this stuff. You could sit down
and say, OK. Look, we can add this, this, and
this, but all this other stuff is going to have
to move back. Because we can't hold
space and time. So that's a really good
strategy, is to out-organize them. And then when they come back,
you can just sort of very plainly point out,
that's fine. I'm glad to do this. And then suddenly, they're
the bad guys. They have to think of this. Oh, well, I don't want you
to get rid of that! Well, look, I've only
got six guys. BEN COLLINS-SUSSMAN: Right. So I guess the difference there
is that you're not just saying yes to everything,
or no. You are making it extremely
clear what the tradeoffs are every time with data. Nothing scares people
like data. Fantastic. AUDIENCE: Thank you. BEN COLLINS-SUSSMAN:
Should we take a question from over here? BRIAN FITZPATRICK: Over
here, please. AUDIENCE: I wanted to know what
your thoughts were on continuous deployment. The idea when you check in some
code, you're going to run some automated tests, with no
human intervention, just put it live on your website. Who should use it and
who shouldn't? BRIAN FITZPATRICK: Oh, that
scares the crap out of me. BEN COLLINS-SUSSMAN: So the
queston is about, when is continuous deployment
a good thing? I think it's fantastic. We use it at Google. BRIAN FITZPATRICK: Depends
on what it is. BEN COLLINS-SUSSMAN:
Well, all right. So what are the downsides of
using continuous deployment? BRIAN FITZPATRICK: You could
blow yourself up. BEN COLLINS-SUSSMAN: Well, you
could also spend a lot of time getting it to work. That's my personal experience,
is that it's a big time investment up front, but it
saves a huge amount of time in the long term. So I would say it's an
investment of short versus long term time. And are you willing to
make that investment. I think it's appropriate for
everyone, if they're willing to make that tradeoff. They have the luxury of making
that initial investment. BRIAN FITZPATRICK: And another
way of doing that is to have things go out into test servers
and then move on. Or if you're running multiple
servers, you can check it out on one, et cetera. There's a lot of different
ways of doing that. BEN COLLINS-SUSSMAN: Cool. BRIAN FITZPATRICK:
Over here, yes? AUDIENCE: We have a new
developer on our team. We're part of an extremely
large software project. And he kind of jumped in head
first and has been making a lot of changes without, I think,
really understanding. And it's kind of introduced
a lot of bugs. And I tried to point
this out to him. And the problem is, he's almost
25 years older than me. You know, I'm only 23. So he has kind of this attitude
of this is how I've always done things, and who
are you to tell me that I should or shouldn't do this? So how can I approach him and
talk to him without it sort of becoming a defensive-- because I have more experience
in the project, in the code, while he may have
more experience professionally, long term. BRIAN FITZPATRICK: How many
people on the team? Is it just you and him? AUDIENCE: I would say
developers, five to ten. BEN COLLINS-SUSSMAN: This is a
case of cultural invasion in some way, right? Does your team have a strong
culture of code review, or this is how we do things? AUDIENCE: Not of code
review, but. BEN COLLINS-SUSSMAN: But is
it a culture of specific development practices that you
all adhere to, all ten of you? AUDIENCE: We try to. BRIAN FITZPATRICK: Do
you have any of them documented, by chance? AUDIENCE: Unfortunately, it's
an extremely large software project that's grown over
about ten years. So there are people, he
understands this part really well, and I understand
my part really well. So when he kind of comes in and
makes changes to my part that I spent a long time working
on, and it introduces problems, and when I try to
talk to him about it, he doesn't really-- you know, I
guess I would say, doesn't give me the respect of being
someone who's on the same level as him, even though I have
a lot longer experience in the actual, what
we're working on. BRIAN FITZPATRICK: I think
anything more than anything, it sounds like a cultural
invasion. BEN COLLINS-SUSSMAN: It's not
about disrespecting you. It just sounds like he's not
paying attention to the culture overall. And so I would argue this is a
case where multiple people point this out to him, perhaps
a manager or someone, to say look, it's not just this
one young guy who's trying to get your way. You're actually disrupting
the whole team. BRIAN FITZPATRICK: And it's
not just the job of the manager of the team
to do that. I would say it's the job
of the whole team. When it's four or five people
who are telling him all this, and he hears it from everyone,
it's one thing. But also, again, I'd say
documentation is-- if you had your culture, I'm not saying the
product, but your culture documented. Processes. We do this, we write a design
doc, and then we get an approval on that, and then
we move long, et cetera. That, I would argue, is
pretty important. BEN COLLINS-SUSSMAN: But get
more people involved so it's not just about you and him. It's about him and the whole
team realizing that he's sort of going against the
grain of everybody. Then it's not about personal
conflicts. It's about everybody agreeing
on what the process is. BRIAN FITZPATRICK: Next
question, please. AUDIENCE: So I read about this
developer that actually pulled his app from the Android
market because he kept noticing only the bad reviews
people gave him. Even though supposedly the app
was great, and it worked great on many phones. But still, really bad reviews
kept creeping up to the top, and so he just couldn't
take it. So he took the-- BRIAN FITZPATRICK:
Was it a bad app? AUDIENCE: No, it was supposedly
a really good app. BRIAN FITZPATRICK: Competitors
trolling? AUDIENCE: So what are your
thoughts on that? How can a team that is probably
emotionally tied to a product they just made, and made
available for free, and then, you know, you keep getting
these bad reviews? I'm asking because it might
happen to me if I put out a product for free and keep
getting bad reviews. BRIAN FITZPATRICK: I
think there's two parts to this answer. BEN COLLINS-SUSSMAN: You
are not your code? BRIAN FITZPATRICK: Well, yeah. You're not your code. I mean, you've got
to be ready for-- Ben and I worked on Subversion
years ago, right? Sorry about that. We've gotten past-- and people
are like, you know-- we actually will joke because we
use Mercure, and I'm like, oh, yeah, whatever
with Subversion. Somebody's like, how can you
talk bad about your product? And we're like, you've
got to learn how let go and move along. So I would say, first of all,
you're not your code. But second of all, if they're
legitimate, you've really got to look to see-- are there
legitimate complaints there? If it's just people trolling,
or griefing, or just people complaining or whatever,
it's just noise. I mean, if it really is a great
product, I think you'll get more good reviews than
you will bad reviews. But if there really are
legitimate bad reviews there, you've got to look for
constructive criticism. Constructive criticism is,
in my opinion, gold. And that's why, actually, we
should move along to this. That's why I'm a huge fan
of getting feedback. So back to the SpeakerMeter
thing. Getting constructive criticism
is a way for us to improve and get better. We gave us talk a couple of
weeks ago, and we asked people, you know, what
can we do better? And I think we learned some
things, and I'm hoping that we'll get some more feedback
today that we'll learn. So that's what I would-- BEN COLLINS-SUSSMAN: I was going
to say, the other wisdom is, in terms of dealing with
trolls, or people who are just criticizing for no reason-- what was that saying,
the internet is full of crazy people? BRIAN FITZPATRICK: The world is
full of crazy people, but the internet, it's like they
all live right next door. BEN COLLINS-SUSSMAN: You
just have to learn to ignore the noise. That's just how the
internet is. BRIAN FITZPATRICK: The first
thing I recommend people who are working in open source is,
go buy a rhinoceros skin and wear it for a while. Thicken your skin as
much as you can. AUDIENCE: To go along the same
vein as the previous question with the younger developer and
the new older guy coming in-- I am the younger
guy coming in. And so to me, a lot of
management types are sort of gray beard tech guys. They grew up on Visual Basic-- BRIAN FITZPATRICK: Hey, hey,
be careful there, buddy. AUDIENCE: And so to them,
I'm a maverick. To me, they're dinosaurs. And so there's a little bit of
head-butting with new tech. I want to do things,
do it live, document it, send it out. They want to test it for
two weeks, see what happens, stuff like that. What do you guys recommend? BRIAN FITZPATRICK: Sounds
like a culture conflict. BEN COLLINS-SUSSMAN: Again, get
another culture conflict. Well, here is the biggest
question. Is there respect going
both ways? AUDIENCE: Absolutely,
I'd say definitely. BEN COLLINS-SUSSMAN:
Absolutely. Then I think this is a
resolvable issue, right? If people have humility and
respect, and there's some mutual trust, then it sounds
like it's something you can work out. But again, it sounds like this
is a case where people need to sit down and talk about, well,
waht should our processes be? And if you want to change the
culture, that's fine, but you should be able to have a
discussion about that, and not have a series of conflicts
over it. BRIAN FITZPATRICK: But
it's hard sometimes. One of the interesting things
about documenting why you do things, is if you can go in a
little bit of detail, in some cases, you can show-- there's
often a lot of reason and wisdom behind some choices and
decisions that may seem not obvious or archaic. But if you can dig in
and be like, oh, that's why we do that. Or maybe it's because something
really bad happened in the past here, we're guarding
it a little more carefully an trying
to avoid risk. BEN COLLINS-SUSSMAN: So
it sounds like you're recommending research of the
existing culture before deciding to overturn it. BRIAN FITZPATRICK:
Yes, exactly. And really try and understand. I mean, that's one of the
biggest things to do when you're having a disagreement
with somebody. If you can really, really,
really strive to understand what their point of view is-- especially if you're married-- then it makes it a lot easier
to carry that conversation. BEN COLLINS-SUSSMAN: The more
you listen, the more you are listened to. BRIAN FITZPATRICK:
Yeah, exactly. So thank you. AUDIENCE: Just to follow
up on that. Unfortunately, it was a small
company, it's a startup. And so a lot of that apocryphal
wisdom about why we don't reboot the server on
Wednesday morning, for example, it's just
not anywhere. So it comes to me, actually,
to document that stuff. So there's a good sort of
feedback, learning, getting it all committed to digital
ink, so to speak. BRIAN FITZPATRICK: Well, it
sounds like you got an opportunity to drive the bus a
bit there, so that's good. AUDIENCE: Definitely, yes. BRIAN FITZPATRICK: Excellent,
thank you. Next question. AUDIENCE: You guys spoke about
some specific tools to define your culture, like documentation, the code itself. Are there any other tools that
you use on a regular basis to kind of define your culture? BEN COLLINS-SUSSMAN: Wikis. BRIAN FITZPATRICK: Wearing
lab coats. I mean, there's a lot of
different stuff in culture. We focus a lot on the social
aspects of it, of interacting. I know some teams, it's like,
4:30 on Friday, and everybody sits around and has
a couple of beers. Right? BEN COLLINS-SUSSMAN:
Nerf guns. BRIAN FITZPATRICK:
Nerf guns, right? There's a team in Pittsburgh
at Google. They used to be right
next to a train. It was so loud you couldn't
even think. When the train would go buy,
everybody would jump up and shoot each other Nerf
guns, right? BEN COLLINS-SUSSMAN:
Go back to work. BRIAN FITZPATRICK: That
was kind of cool. It was kind of fun. There's a lot of different
things you could do. Like eating lunch together. I mean, Google's sort of known
for having free food. There is an incredible benefit
by getting your team to eat lunch together and not
necessarily talk about work. You suddenly realize that this
guy who I strongly disagree with for programming issues
is a human, right? He's married. He's got kids. He's a nice guy. Wow, you know? BEN COLLINS-SUSSMAN:
It really helps. BRIAN FITZPATRICK: It makes it
a lot easier for you to have these hard discussions, and
accept constructive criticism, that sort of thing. AUDIENCE: Thank you. BRIAN FITZPATRICK: Thank you. Yes, please. AUDIENCE: Attention
on details. I mean, how do you get people
to really focus attention on details? It's not just you give them a
visual spec, and they give you like very basic of what
you have given them. Such as round corners, drop
shadow type of things. BEN COLLINS-SUSSMAN: You're
talking about attention to details in the software. How do we get developers to
pay attention to details. Are you having a particular
problem with certain developers just being
sloppy, or--? AUDIENCE: Not being sloppy. It's just like being
very basic. It's like, whatever
you give them-- you give them a mock-up, and
then the product comes back exactly as a mock-up. BEN COLLINS-SUSSMAN: Sounds
like people are simply not meeting job expectations
in that case, right? BRIAN FITZPATRICK: There's a lot
of different things that could be wrong with
that, I think. It is tricky, but I think
communicating more about expectations-- I mean, flat out. there's a lot of cases I know
where people had someone that worked with them, or worked for
them, who wasn't meeting expectations. And they don't say anything,
because they don't want to rock the boat. And that's exactly when you
should be rocking the boat. When you're most afraid
to rock the boat. So it's like, boom. That's when you start
communicating. If you just flat out say, look,
this is what I expect of you, and this is what
I'm not getting-- BEN COLLINS-SUSSMAN: And here
are two or three examples of where I expected something-- BRIAN FITZPATRICK: Two
exampels minimum. At least two. BEN COLLINS-SUSSMAN: Give
them hard data. Say, I expected X, Y,
and Z, and you gave me this other thing. And you did it two
or three times. So we're going to
have to either-- BRIAN FITZPATRICK: You can at
least be sure, in that case, that they know it. Because quite frankly, they
might not know it. So I would say communication
there is pretty important. We can take two more
questions. AUDIENCE: Hi. A while ago, you talked about
the ethical issues of, for instance, spamming people
and whatnot. And what would be the right
thing to do when the general culture of the place
seems to be skewed towards that direction? And you did mention that that
would cause financial damage in the long run, but I am
not the bean counter. I am just the engineer, and I
doubt that would be persuasive from my part. BEN COLLINS-SUSSMAN: That sounds
like a question of how does one engineer change an
entire culture of a company. That's a really hard problem. We get this question a lot,
actually, and our answer is usually, find a new company. BRIAN FITZPATRICK: Well, no. Wait, wait, wait. Our first answer is, is
that you can make attempts at this, right? Try to change what you can,
and look into it, and make attempts to ask people
about it. Have you thought about
it this way? But yeah. If you try and are unsuccessful,
you can just sit there and stew about it. You can learn to deal with it. Or you can get the heck out. BEN COLLINS-SUSSMAN: I find,
also, reaching out to other people in the company who feel
the same way, you can start to sort of build a movement
within the company. I mean, it's politics, right? But you can actually form a
movement within your company so that there's a single voice
saying, we don't like this. We think we should
change this. And the louder you become,
the more the dialogue is likely to happen. BRIAN FITZPATRICK: But do keep
in mind that companies aren't democracies. BEN COLLINS-SUSSMAN: They're
not democracies. But you can still
have political movement within them. BRIAN FITZPATRICK:
That's right. Alice's Restaurant. Go ahead. AUDIENCE: I work on a team
where there's another guy who's a very capable developer,
but he often holds his cards real close to his
vest, doesn't share things with the rest of
the team often. And furthermore, my boss looks
upon him with great favor. Do you guys have any tips or
strategies that you might suggest for dealing with
both him and my boss? BEN COLLINS-SUSSMAN: Well,
what's wrong with him holding close to his chest, that he's
not sharing, or he's not-- AUDIENCE: Right. That often times, he
won't engage other members of the team. Or often times, he'll maybe
get that super-special assignment or whatever before
others are considered, that sort of thing. BEN COLLINS-SUSSMAN:
Interesting. BRIAN FITZPATRICK: That's
another hard problem. I mean, again, you can
give him data. Like with your boss in
particular, if we got more information, we could do more. But that tends to be one
of the things that's really hard to change. BEN COLLINS-SUSSMAN: If you can
quantify the impact of him not collaborating with people,
then you'd have an argument to make, saying, well, we should
get him to open up. That gives us an argument to the
manager, right, or other members of the team. BRIAN FITZPATRICK: But if the
manager and the lead both think this is the way we're
going to run things, you don't have much of a way
to change that. It's really hard, because
they're defining the culture top down, and you're just
sort of following along. BEN COLLINS-SUSSMAN: Also, if
I were on the team, I would also try to figure out the
psychology of this person. Are they just insecure? Or are they egotistical? What's going on, right? How do you get them open up? And there may be the social
route, social engineering, to get in there and get them to
open up, figure out what's really going on. AUDIENCE: Sure. Thank you. BRIAN FITZPATRICK: All right. Thank you all for coming. We appreciate it. We'll be around for a bit,
talking a little more.
