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.
