Google I/O 2009 - The Myth of the Genius Programmer

despite other slides to the contrary,
"The Myth of the 'Genius Programmer.'"
And before we get started...
Collins-Sussman: Should we do some introductions?
Fitzpatrick: Should we do-- Your mic--can't hear your mic.
Collins-Sussman: Can't hear my mic at all.
Well, let's fix that.
Hey. So let's do some introductions.
Who are we?
Fitzpatrick: My name is Brian Fitzpatrick.
I usually go by Fitz.
Collins-Sussman: My name is Ben Collins-Sussman.
I usually go by Ben Collins-Sussman.
Fitzpatrick: And we're basically a couple
of long-time Version Control geeks.
We worked on Subversion years ago.
Collins-Sussman: And we have a lot of experience
in the Open Source world,
so we tend to speak about things that are related to Open Source,
but not necessarily related to Open Source.
Fitzpatrick: Right. When we started at Google,
we worked on code.google.com.
We still work with Google Code, actually.
Collins-Sussman: Absolutely. And if you're interested
in the project-hosting service, which is what my team works on,
we're doing a talk tomorrow
about our Mercurial implementation
on top of Google infrastructure,
which is a new feature on Google Code.
So come see that.
Fitzpatrick: But enough about us.
Who are you?
So we have a couple questions for you,
so we can get an idea about the audience.
Collins-Sussman: Survey. Fitzpatrick: Survey.
So how many people in this room write code
entirely by themselves only?
Never with other people.
Collins-Sussman: Or how many people
like writing code by themselves?
Fitzpatrick: All right, yeah.
Collins-Sussman: All right, that's great.
Fitzpatrick: So how many people work in teams?
Okay, that's good. Everybody's awake.
How many people in this room do code reviews
as part of your development process?
Collins-Sussman: Wow.
Fitzpatrick: Is that good or bad?
Collins-Sussman: I'm impressed. That's great.
Fitzpatrick: All right, one last question.
Who is afraid of looking stupid in front of other people?
All right, we're in the right place.
Excellent.
Collins-Sussman: So before we go on,
we should let you know these are very opinionated talks
that Fitz and I give every year.
They're really based on our own subjective experience,
and that's fine.
You know, if we say things that upset you or anger you,
we've done our job. Fitzpatrick: Right.
Collins-Sussman: And we encourage you,
if you don't like it, you can...
Fitzpatrick: If you have different opinions,
please get your own talk at your own conference.
[laughter]
So before we go, though,
we're gonna have you do a little more work.
You're gonna have to read a few slides
and check out some of our quotes here
that we've got.
Collins-Sussman: What is this talk about?
Fitzpatrick: We're not gonna read them to you,
so here's the first one.
All right. The second one.
Okay, and now for a really good one.
Collins-Sussman: Okay.
So what do these all have in common?
You guys, any ideas here?
All right, it's a rhetorical question, but...
Right, so what's going on here,
there's a lot of insecurity going on, right?
This is a common feeling that we all have.
So we're gonna go off of this.
We're actually getting these responses last year at I/O.
People were coming up to me and saying these sort of things.
So it got us thinking about,
"Well, what's going on with psychology here?
"What's going on in people's heads?
"Why do they want to hide their code so much?
What's really at the bottom of this?"
Which is how we came up with this talk
and where we get this idea
of the myth of the genius programmer.
Let's do one more quote.
Fitzpatrick: Okay.
Collins-Sussman: Interesting. "Pervasive elitism."
Fitzpatrick: This is rooted out of a general desire
to not look stupid.
It's sort of a-- you know, everybody, I think,
wants to look like a smart developer.
I know I certainly do, to some extent.
And--but there's a lot of different reasons
behind why people do this, and we're gonna start
with something a little almost seemingly unrelated.
But why do people buy products endorsed by celebrities, okay?
Michelle Obama wore this dress to the Inauguration, okay?
Boom, suddenly, it sold out, all right?
Collins-Sussman: Or Michael Jordan
wears Nike shoes, right?
Everyone wants to buy Nikes
'cause they love Jordan or basketball.
What's really going on here?
Like, do you actually believe that if you buy Air Jordans,
you're gonna be as good as Michael Jordan?
Fitzpatrick: Yes. Collins-Sussman: No.
But there's something going on, right?
There's some nugget of human psychology going on here,
where it's in our instinct to find celebrities,
find people to idolize and want to be like those people,
and we sort of latch on to whatever simple behaviors
or materialistic pieces that remind us
of this celebrity or this behavior.
Fitzpatrick: That's true in the world of programming as well.
I mean, we have our heroes.
We have Linus Torvalds, to some extent, Bill Gates even.
Guido here at Google--
you know, I mean, he wrote Python himself, right?
Not quite true, you know?
Collins-Sussman: Did Linus write Linux all by himself?
Fitzpatrick: Right. We have Kernighan and Pike
and Kernighan and Ritchie.
I mean, these guys don't always deserve all the credit.
They certainly deserve some of the credit.
They're the leaders, right?
Or they sort of started something,
but they're mythologized.
So the personas that they become
are bigger than life, to some extent,
and, to some extent,
rooted in a little nugget of truth or fact
and a whole lot of myth.
Collins-Sussman: So that's why we have this myth.
When we say "the myth of the genius programmer,"
we're talking about the myth of, "Hey, here's a genius,
"and genius goes off in a cave and writes this brilliant thing
"and then reveals it to the world
and, 'Oh, my gosh, this person's famous forever,'" right?
Reality is, that's not really how it works at all.
They're--In fact, geniuses...
they are so incredibly rare that, I mean, it's almost--
it's kind of a meaningless term, right?
Fitzpatrick: Right. Collins-Sussman: Those folks--
That myth just isn't true.
Fitzpatrick: So, yeah, the ultimate geek fantasy
is to go off into your cave and work and type in code
and then shock the world
with your brilliant new invention, you know?
You--It's a desire to be seen as a genius by your peers.
Collins-Sussman: But there's a flip side to that too, right?
It's not just about, "I want everyone to--
I want to be a genius and shock the world."
It's also, "I'm insecure."
And what I mean by that is, you know,
"I also don't want people to see my mistakes.
"All right, maybe I won't be a genius.
"Maybe I won't shock the world with my brilliance,
"but at least I don't want them to see my trail
"of failures and mistakes,
and I'm gonna cover my tracks," right?
Fitzpatrick: Well, they want to be seen as being clever, right?
Collins-Sussman: Clever people don't make mistakes.
Fitzpatrick: Right, exactly.
So the result is people wind up working in a cave.
A classic example of this is,
how long will you drive around before asking for directions?
Okay?
How long are you gonna be completely lost
before asking for directions, you know?
I mean, you're not gonna say, "Oh, I'm lost.
I'm immediately gonna ask for directions."
Collins-Sussman: Well, it's hard to admit
that you've made mistakes sometimes,
especially publicly, right?
So that's why we showed these quotes in the beginning
with people saying, you know, "Can you erase my history?
Can you hide my project until it's perfect?"
Right? I mean, it's more of this,
"I don't want to show everybody what I'm doing
till I think it's perfect."
Fitzpatrick: Right. So you may be thinking, "Well, big deal."
Collins-Sussman: Why do we care?
Fitzpatrick: Why is this a problem?
Why should I care about this?
The primary reason is it inhibits progress
and not just personal progress, but project progress, okay?
It's sort of the "many eyes make all bugs shallow" quote.
But if everyone's off working in a cave
and just occasionally throwing code out to the project,
code quality remains low,
and your bus factor remains low.
How many people here have ever heard of the bus factor?
Collins-Sussman: We talk about it every year.
Fitzpatrick: Weren't you here last year?
No, okay.
Bus factor is the number of people
on your software project
that have to get hit by a bus
that are gonna leave you in a world of hell, okay?
All right? So if there's only one person
that knows that really obscure file-system code
and they get hit by a bus,
whether that bus comes in the form of an actual bus,
or they get married,
or they have a kid, or they change jobs,
or they move away, or they get bored...
Collins-Sussman: It happens all the time.
So this is one of the things
we talk about all the time in teams,
whether it's a team at work or a team on an Open Source,
is to not get so territorial that you have low bus factor
on different components, right?
It's a common thing, right?
You know, you can't touch that code.
It belongs to Joe.
Well, wait a second, you know.
What happens if Joe's gone, right?
Now you're in trouble.
So one of the things you should be watching out for
is you should have as many people touching
and getting familiar
with as many parts of the code as possible.
You want that redundancy on your team.
But if you're off working in a cave
and you're hiding your tracks,
well, no one knows what you're doing.
Fitzpatrick: You could be working
on the wrong thing entirely, actually,
if you're off doing some really big feature
or big piece of code.
Collins-Sussman: Well, here's a nice analogy
that we like to talk about, which is, you know,
think about the way you interact with your compiler, right?
You have a really tight feedback, right?
You write a function, you compile it,
make sure it at least compiles, right?
Maybe you write a UniTest if you're doing great, right?
But nobody sits down and writes,
you know, thousands and thousands of lines of code
and then runs their compiler for the first time.
It just doesn't happen.
Fitzpatrick: Not anymore. Collins-Sussman: [laughs]
Fitzpatrick: Maybe 50 years ago, right?
Collins-Sussman: Right. In the mainframe days maybe.
So, you know, it's the same way--
if you're working on programming in any way,
you should not be doing it all in a cave
and then sort of waiting to spring it and see what happens.
You want other people seeing what you're doing
as soon as it makes sense, right?
We'll talk about what that is.
Fitzpatrick: Right. But I mean, in addition,
if you're off in the cave, you don't learn as quickly.
It's harder for you to improve your skills, right?
There's a balance between spinning your wheels
and being lost
and asking the person next to you
every question that comes into your head, right?
But I mean, this problem isn't unique to computer science.
It pervades all sciences, you know, math, anthropology,
especially when you get into hard research,
you know, you see this sort of thing.
Collins-Sussman: Well, I think if any folks
are in the academic world,
and computer science is part of this,
there's this constant tension probably caused
by the "publish or perish" philosophy, right?
Where, gee, you're all supposed to be in academia.
You're supposed to be sharing knowledge
and collaborating and helping each other
and cooperatively advancing the state of the art,
but everybody has to hold their research to their chest
and not show anybody what they're doing
until they're published, right?
And what happens?
Oh, you end up publishing a paper
which is redundant with somebody else's paper, right?
Or maybe you worked on the wrong thing and didn't realize it
'cause you never told anybody what you were doing.
Or maybe if you had collaborated with this other person,
you guys could've written a better paper together, right?
Same exact tension, just in writing software, right?
The sooner you get your idea out and other people looking at it,
you can find out, "Am I working on the right thing?
"Do I have the right idea?
"Should I go back to the drawing board?
"Should I be collaborating with this person
'cause they're working on it too?"
I mean, it's the same issue.
Fitzpatrick: Right. So a little bit of more bad news
to this for you, okay?
Is that you're not a one-of-a-kind, right?
Okay?
The, uh...
If you're one-in-a-million, right?
That means there's over a thousand people just like you
out there right now, okay? Collins-Sussman: It's true.
[laughs]
Fitzpatrick: Glad you guys liked that. Thanks.
But even if you're a genius,
working well with others may make or break you, okay?
Like attracts like.
And we work hard to hire really smart people at Google.
And I don't care how smart you are.
If you can't sit there and communicate with someone else
or work together in a team and achieve consensus,
you're not gonna be successful working on a team of people.
Collins-Sussman: This is one of those things
that I always try to communicate,
especially to students
who are just starting out in computer science
is that software,
even though it's fun to write code alone,
you know, late at night in your basement, whatever,
actually writing software that's successful--
it's an inherently collaborative activity.
And it actually forces you to deal with people
and talk with people, and that's why we encourage people
to get involved in Open Source, because it's sort of like,
"Okay, well, maybe you're still in college,
but here's your chance to actually work with people
and work on a team and see what it's gonna be like.
I mean, one of the things I always ask people is,
"Can you name a piece of software
"that's really successful,
"really widely used by a lot of people,
and was written by one person?"
Fitzpatrick: And before anybody yells out Metafont,
that's not widely used, okay?
But anyway, so this is a trap, okay?
Of this sort of wanting to be a genius.
So how do we avoid this, okay?
Quite frankly, the first step is to drop the ego, okay?
Instead of having a large personal ego,
which actually impedes collaborating on a project,
have a strong collective ego around your project
or the piece of software you're working on.
A great example in the Open Source world
is the Apache Software Foundation, okay?
Community is the essence of every project
in the Apache Software Foundation.
That's what's most important to them, more so than code.
Companies call Apache up all the time and say,
"Hey, we want to give you guys a billion lines of code.
Blah, blah, blah."
Collins-Sussman: And then walk away.
Fitzpatrick: And then, yeah, "Have a nice day."
And they're like, "We don't want it.
"We don't want a pile of code by itself
"that it's just gonna bit rot.
We want to build a community around this."
And so, as a result, people working on the projects
tend to be proud of--I mean, I don't know about you guys,
but I want to be proud of the stuff that I'm working on.
Collins-Sussman: Absolutely.
It's a good way to keep your project healthy too.
Fitzpatrick: So you don't want to be this guy.
Collins-Sussman: Not on your project.
Next thing to think about
is how you interact with people.
How do you give each other feedback?
And it involves, you know, actually being a nice person.
Fitzpatrick: What? Collins-Sussman: I know.
It's crazy.
But it is--actually, it is a learned skill
to give constructive criticism,
whether it be a code review or just a design,
discussion of design.
And to take criticism as well.
If you work in Open Source, you learn to be pretty thick-skinned
so that you can take nonconstructive criticism
along with the constructive criticism,
but it's something that we should all aspire to do, right?
Is how to do it in a nice way.
Fitzpatrick: Right. The way to look at it is that
your code isn't part of you, right?
You want to work for the best piece of software as a whole,
not to sort of get your one little clever bit in.
Here's an anecdote.
A friend of mine left Apple a few years ago,
went to work at a smaller company
that had been around for a while as an engineering manager.
And he went in and saw that they were using Version Control,
and he set up so it would send out code-review emails,
'cause they weren't sending out code-review emails.
And he started doing code reviews.
And, you know, he thought,
"Okay, you know, I'm gonna try and get these guys
"a little, you know, more rigorous engineering.
We'll have some better practices here."
And a week and a half later,
the director of engineering calls him in and says,
"You know, I'm getting a lot of feedback
"that you're really bringing people down
with all this negative criticism of everybody."
He's like, "What are you talking about?"
"Yeah, these code-review things you're doing,
you know, people are getting really upset by that."
And, you know, how do you respond to that?
This is something that is really integral, I think,
to writing good software.
Collins-Sussman: That's a cultural problem, too,
in some companies, right?
Some people really--
Especially in a lot of corporations,
you'll see not only territorial--
You know, "This is my code. You can't touch it."
But also, "How dare you tell me what to write
"or make comments on what I just wrote?
Mind your own business."
I mean, that is a very common behavior,
and it's hard to get companies to break out of that cycle,
increase the bus factor,
do code review all the time.
At Google, we actually--
We're not allow to submit code
into our Version Control system until there's code review.
Like, it will reject your change
until there's proof that some peer
has looked at what you've done and given it a thumbs-up,
which is a great thing.
Fitzpatrick: Right. So criticism is actually good.
And the next important thing is that you have to learn
to sort of embrace failure, okay?
People, I mean-- I'm afraid of failing.
Certainly, I think most people are, okay?
But, you know, the whole NASA "failure is not an option" thing
is a load of crud, right?
Failure is an option, except in one case.
It's failing on the same thing repeatedly.
That's never good, because you're not learning, right?
Collins-Sussman: And it's embarrassing.
Fitzpatrick: Well, it's embarrassing,
but if you're failing-- You try something and fail.
Try something different and fail,
and you try something different.
Every time you fail, you learn something.
And for many people, that's the best way
that they learn how to do things.
Some people learn by sitting in a room
and hearing two other guys yammer on forever.
Some people learn by reading a book.
And some people learn by looking at pictures.
Some people learn by trying and failing.
Collins-Sussman: Well, this is also important--
I mean, it's another cultural issue here,
is when failure does happen, be ready for it.
Don't freak out.
Document what happened, what did you learn from it.
What are you gonna do different next time, right?
That's why we do postmortems on--
you know, when something crashes,
or there's some-- some bad thing happens.
We write it up and learn from it.
Fitzpatrick: Right. And the point is not to assign blame.
It's to look at what you did,
have everyone else look at what happened
so that we don't do this again.
Collins-Sussman: I think a big issue also around failure
is just natural human fear.
I have a--You know, I can relate to this personally.
I started learning banjo a few years ago,
playing in bluegrass jams.
And, you know, they would occasionally try to call on me
to do banjo solos, right?
Which is really, really hard to learn,
and I just wouldn't do it, or I--you know, bow out.
And someone took me aside, and he said, you know,
"You realize that 50% of learning to solo
"is just not caring how good you sound
and just losing the fear."
It was totally true.
I was like, "All right, these are my friends.
If I sound terrible, who cares?"
And sure enough, I mean, he was absolutely right.
I just started playing really bad solos,
but it got better and better, and I kept learning,
and that was a huge step.
So I mean, if you can just make that mental shift
and say, "It's all right.
I'm gonna fail, and it's not a big deal."
No fear. That's fine.
You move on. You learn.
You've got a better anecdote, actually.
Fitzpatrick: Well, this is a complete anecdote.
It's a story about the executive
who makes a bad business decision,
and the company loses $10 million for the company.
The next morning, comes into work.
His secretary says, you know,
"The CEO wants to see you in his office."
And the guy hangs his head down.
He's like, "This is it. I'm gonna get fired," you know?
Walks into the CEO's office, and he's like,
"So I guess you want my resignation."
The CEO looks at him and says, "Resignation?
"I just spent $10 million training you.
Why would I fire you?"
[laughter]
But again, I mean,
I bet you that's a mistake that guy never will make again.
I lived in Italy for three years, okay?
I moved there, and I had been studying Italian,
and I was really proud to use my Italian.
I went into a cafe, and I ordered a sandwich,
and they give me this massive sandwich,
and I wanted a knife to cut it with.
So I thought I'd be cool and use my Italian,
and I promptly asked them for a toothbrush to cut my sandwich.
[laughter] The guy just looked at me.
And I'm like, "Toothbrush." And he's like, "No."
Collins-Sussman: That's true.
Fitzpatrick: But never made that mistake again.
Collins-Sussman: Speaking languages
in a foreign country is very intimidating.
I mean, you're just so scared of looking like a fool,
but you don't learn otherwise.
Fitzpatrick: Well, it's the easiest way to learn, I think.
That sort of hot-white fear you get going up your neck
'cause you asked for something embarrassing.
Collins-Sussman: So failing is--
It's not just about embracing failure,
but it's also failing fast, right?
We're talking about iterating as quickly as we can.
This is something we actually talk about a lot at Google,
was don't just fail, fail quickly
and pick up and try something different as fast as you can.
And that's why we've got sort of, like--
We got this Google Labs site now, right?
Where are people are experimenting
with different projects.
And if they fail, that's fine.
They'll just put something up
or change it the next day and try it again, right?
The faster you can fail and the faster you can iterate,
the faster you will learn and get better.
Fitzpatrick: And you don't have to hide it if you fail.
It's okay, you know. You don't have to hide your tracks.
We talk about, you know, in a Version Control world,
you know, people use Subversion versus Mercurial
versus Git, et cetera.
Git Rebase is something
that people use often to sort of hide their tracks.
There are some legitimate uses, I think,
if you want to clean things up a bit.
Collins-Sussman: Or maintain a vendor branch.
Fitzpatrick: Maintain a vendor branch, et cetera.
But people are typically looking to say,
"Oh, you know, I was working on all this stuff.
"I made all these sort of false starts
"I don't want anybody else to see,
"you know, my stupid mistake here,
where I forgot to check the type of something."
Collins-Sussman: Rewrite my history so it's perfect.
Fitzpatrick: That's right. Yes, exactly.
Just like the history of the world.
But what it comes down to is--
One of the ways of making this problem better
is to practice, okay?
If you practice,
it makes your iteration-failure cycle faster, okay?
And it basically--
it's sort of less scary to fail,
because you'll tend to have smaller failures.
Collins-Sussman: This way, the failures
tend to get smaller over time,
and the successes tend to get larger,
and that's a trend you'll see,
especially if you're learning as you fail fast.
Fitzpatrick: Right.
And the next thing is sort of to be a small fish, all right?
If you were the senior developer
on a team or in a company or something
and everyone looks to you and you're sort of the teacher
or the king/queen bee, whatever,
if you're only working with people junior to you,
you are gonna learn things from them,
but it's gonna be harder to improve your skills
than it would be if you were working with someone else
who is smarter than you, who is a better engineer than you.
Collins-Sussman: Actually, you know,
in my experience, when you're a big fish in a pond,
it's very comfortable,
but you're not really learning very much, right?
You feel safe, but you don't get much better.
And when you are a small fish in a huge pond,
it's very scary, right?
Fitzpatrick: Sometimes you get eaten, though.
Just kidding.
Collins-Sussman: That's what it was like
when we started at Google, right?
It was very like, "Aah!"
You know, it's just so many people.
But you get better really quickly, right?
Again, it's all about the reward of facing that fear.
Fitzpatrick: It's like the old Emacs joke, you know?
It's got a really steep learning curve,
but that just means you learn a whole lot
in a short period of time, right?
But beyond being a small fish, the other thing is to sort of--
And this has to do with not only being successful,
but also being a leader, which is to be influenced, okay?
'Cause the more that you're open to the influence of other people
who might have a really good idea
or a novel way of looking at something
or accomplishing something--
The more actual influence that you bank and have on others,
the more likely they are to listen to you.
Collins-Sussman: Or it's respect is a two-way street, right?
I would say it's not just about respect being a two-way street.
It's about vulnerability,
in that if you can show yourself
to be open to change and willing to admit mistake--
I guess being vulnerable
is another form of being influenced, right?
It's an extreme case.
If you can admit your mistakes in front of your peers
and say, you know, "I was wrong. I made the wrong choice.
I had the wrong opinion."
A lot of people are afraid to admit that,
'cause they're afraid, you know, in the short term,
it's gonna make them look weak
or like they don't know what they're doing.
But in fact, you know, if you think about people
that you really admire, you may have worked with,
they make themselves vulnerable a lot.
And over the long term, they get perceived
as big figures, big strength figures, right?
Wow, that person is so strong
that they're not afraid to admit mistakes and failures.
Fitzpatrick: Oh, and it's not just about their ideas
or their way of doing things.
It's a way also to sort of cement people's dedication
to what your project is or what you're doing,
'cause, you know, we like to talk about buses a lot, I guess,
but it's the difference between being the person driving a bus
and a whole bunch of people as passengers
that are following you
and taking turns driving the bus, right?
If you're working on a project,
whether it's an Open Source project or within a company
where different people take the lead at different times,
you're gonna attract a different caliber of person,
or different type of person,
who wants to participate and carve out the path
as opposed to somebody following you.
Collins-Sussman: Absolutely. So let's talk about--
A little diversion here and talk about software tools,
since that's--our background is in software tools--
and talk about, specifically, how they affect
your collaboration and your social habits.
One of the classic Internet sayings, right, is,
"You can't fix social problems with technical solutions" right?
And there's all sorts of classic examples of, like--
For example, you know, the whole DRM issue, right?
Or if we just keep inventing
more and more complicated DRM technology restrictions,
they don't fix the problem, except most people will say,
"Well, really, there's some kind of social issue here."
What is intellectual property? What is fair use?
What is--you know, what is the nature of--
Fitzpatrick: Isn't that problem solved yet?
Nobody downloads music anymore, right?
Collins-Sussman: Clearly, it's a societal, cultural issue, right?
Not something that can just be papered over
with evermore complex DRM technologies.
Or another one I've talked about is, in Version Control,
I see a lot of people--
A lot of administrators will start, you know--
especially in Open Source projects,
they'll start trying to do path-based access control
and say, "This person's allowed to commit to this branch,
"but not this one.
And this person can only commit to this file, but not this one."
They start creating all these complicated rules,
and I sort of say, "All right, well, what's going on here?
Why are you creating all these technological restrictions?"
"Oh, we got to make sure people
don't commit to the wrong places."
And they're like, "Well, if they did, what would happen?"
You would all notice it. You'd roll it back, right?
'Cause it's a Version Control system.
You can undo, right?
You'd ask the person what happened.
If it was a mistake, they apologize.
If it wasn't a mistake, they're in trouble, right?
Or you tell them to leave the project or something.
So it's sort of, like, okay, it's a social problem.
You don't need this technological restriction
to solve it.
It's not a good solution.
Fitzpatrick: Or the endless spams arm race, right?
I mean, that's--that's-- it goes back and forth, right?
Collins-Sussman: The social problem being
the world is full of jerks.
Fitzpatrick: Right, exactly. Yeah, exactly, that's the thing.
You know, the Internet-- That's what I was saying.
The world is full of jerks, but the Internet makes it seem
like they all live right next door to you, right?
[laughter]
So you can't use technology
to solve these sociological problems, right?
Well, not always, okay? Collins-Sussman: Usually.
This is--this is a--
It's sort of a-- it's a false truth,
insofar as there are things you can do to encourage people
to "do the right thing," right?
For example, on Google Code,
if you want to comment on an issue on the issue track,
if you want to create an issue or something or file a bug,
you have to sign in, right?
There's a very simple reason for that.
First of all, we want to limit spam a little bit,
but more importantly, if someone reports a bug,
it's nice to have a way to get back to them.
I can't tell you how many times in the past
people have reported bugs out there,
and they leave no contact information,
or they screw up their email address or something like that.
Collins-Sussman: Right. So that's an example
of a small technological change having a big social impact.
Fitzpatrick: It doesn't solve the problem.
Collins-Sussman: But it definitely changes behavior.
Another example is on Google Code project hosting,
we only allow a small number of licenses,
which angers a lot of people, right?
They want to come in and use some Open Source license
that's fairly obscure,
and they say, "Why isn't it on the site?"
And our answer is, "Well, because we want to stop
"proliferation of Open Source licenses.
We think it's bad for the Open Source world."
And that's fine, you know.
Either they'll choose one of the standard licenses,
or they'll go host their code somewhere else,
which is okay, but we've had a definite impact,
a social impact, through that small technological choice.
Fitzpatrick: Right. Collins-Sussman: So, yeah.
Sometimes you can affect--
You may not be able to solve gigantic social problems,
but you can have--
Small technological choices
can have big social, behavioral changes, right?
Fitzpatrick: So defaults are important, okay?
I mean, you want to examine
how do tools behave out of the box, okay?
This doesn't actually fix the core social issue at hand,
but it does influence people's behavior quite heavily.
Collins-Sussman: So let's look at some--
how some software tools behave.
What's their default behavior,
and how does it affect the way you collaborate?
One example is--
How about, you know--
On your software team, when somebody commits a change,
maybe you do code review beforehand,
but certainly in the Open Source world,
it's pretty common to do code review
after somebody submits a change, right?
In a lot of projects, an email will go out with the diffs,
and it'll go into all the mailboxes
of all the participants.
And what's cool about that is that it makes it
almost effortless to do code review, right?
It's like, their changes are being pushed right to your face,
and you're reading your email, and you're like,
"Oh, looks like they got a typo here or a bug.
Let me reply really quick," right?
As opposed to projects that don't do that,
there's almost no code review at all, right?
Big social change for a small technological trick.
Fitzpatrick: Right.
So sort of set the Wayback Machine
before the Internet was really popular
and Open Source was really huge.
How many people here have heard of CVS?
The Version Control system, not the pharmacy.
Okay, good.
Collins-Sussman: We actually asked a bunch of students.
We gave this talk a few weeks ago to a bunch of students,
and we asked, "How many people have heard of CVS?"
And they all raised their hands. Fitzpatrick: I was blown away.
Collins-Sussman: We were like, "Well, you're only, like, 19."
And they're like--
"How many people have heard of the Version Control...?
Nobody raised their... Fitzpatrick: No one at all.
Which is good, really.
Collins-Sussman: Change that slide.
Fitzpatrick: You know, people talk
about Open Source getting big.
They talk about Richard Stallman.
They talk about Linus Torvalds.
But CVS actually played a really important role,
insofar as it cre--
There was a feature created in it in the mid '90s
called Anonymous Pserver.
It was anonymous network access,
where any random one of these jerks on the Internet
could download your source code
into a CVS working copy,
fiddle with it, and then send you a nice, small,
concise patch that could fix a bug,
add a new feature, et cetera.
Collins-Sussman: That was a huge social event, right?
Fitzpatrick: It had a huge impact,
insofar as it made it virtually effortless...
Collins-Sussman: ...Mercurial?
A few. Okay.
Darks.
Fitzpatrick: Bizarre, anyone?
Collins-Sussman: Monotone. Fitzpatrick: No, just kidding.
Collins-Sussman: Okay, so...
But distributed versions was kind of interesting.
What are the default behaviors of distributed Version Control?
It's sort of a double-edged sword, right?
On the one hand, it's kind of not so great,
because the default behavior, when you start off,
is to fork, right?
You start off grabbing the entire history
and crawling into a cave, right?
And it's actually a little bit more work
if you want to contrib-- get your code back.
You have to find someone else to talk to,
find a server, do a push, right?
I mean, it's actually--
You know, there's a little more effort involved.
So in one sense, it discourages collaboration,
but in another sense, it also encourages collaboration,
because--excuse me--
it lowers the barrier for everyone to participate, right?
Instead of just, you know, "the official committers"
on a project having access to the history,
having the ability to do checkpoints of their code,
now everybody in the world has the exact same tool set,
and everybody can checkpoint their code
and do whatever they want, and there's no--
Being a committer really just becomes a social title, right?
It becomes a branding job rather than
a "I have special tools, and you don't" kind of thing.
Fitzpatrick: And I think this is really great,
but I think it does concern us a little bit
that, you know--
What are people gonna do in four or five years?
Is this gonna sort of tilt the dial
back in the other direction for collaboration?
Collins-Sussman: But like you said,
you know, it lowers the barrier for people walking by
to participate, right?
I mean, in the old days, you had to check out the code,
email a patch,
wait for somebody on the list to review your patch.
Maybe they liked it, maybe they didn't.
And then you were kind of helpless.
Now you don't have to wait for that,
so it might be a good thing too.
Fitzpatrick: Right. So there's a moral to this story, right?
Which is you need to pay attention
to the default behaviors of the tools that you have.
And you need to ask yourself,
"What is the social behavior of this--
this tool is encouraging for-- I mean, to use?"
And that can vastly affect the dynamic of your team, basically.
Collins-Sussman: So there's one more thing
we want to talk about, which is how to--
Right. So we're talking about--
We want to collaborate. Collaboration's important.
Don't be afraid. Pay attention to what your tools are doing.
But here's the big question--
When is a good time to collaborate, right?
Do you do it early on? Do you do it late?
So we have done some wonderful research...
Fitzpatrick: Minutes of research.
Collins-Sussman: Minutes of research
about the evolution of a project, right?
I mean, it starts out as an idea in your head, right?
And then after a little while, you make a prototype
just to sort of show other people
or maybe just to satisfy yourself that it's gonna work.
And then you say, "Hey, come take a look at this."
You show one person or a few friends.
Aah. Ooh, sorry. Nice.
And then you write a lot of code--code, code, code.
And then you dominate the Earth, and everything's fine.
So the real question is, while you're doing this phase--
First of all, you don't have to hide, right?
I mean, you can do all of these phases in the public eye.
It's really a question of,
at what point do you start advertising yourself, right?
Like, even if you've just--
If you're still working on a mock-up,
it's not like you need to be in a cave to do that, right?
Chances are, most people aren't gonna know you're working
on that mock-up, even if you're doing it
on an Open Source repository.
They're not gonna see you until you start screaming
and mailing lists and saying,
"Hey, come look at what I'm doing."
Fitzpatrick: But the real question here is,
where does the third milestone go, right?
You don't want to start involving people
too early or too late.
For good or for bad,
people typically involve people too late.
It's rarely that someone
involves people too early, you know?
If you're done, it's too late, okay?
Collins-Sussman: [laughs]
Fitzpatrick: But there's a huge risk of wasting your own time.
You know, you might be trying to come up with a project
to change the world.
It might be doing something Open Source.
You might be just coming up with sort of something
in your spare time you want to pitch to your team
that you work with at the office, right?
But if you go off and you just make a whole lot of progress
without talking to the people, getting some feedback,
there's a huge risk of just wasting your own time, you know?
You could have really bad design choices
that are undoable without starting over.
You know, anyone--Those of you guys who do code reviews,
if you ever get somebody that gives you
a 5,000-line code review,
what can you really do with that other than check it for syntax?
Or check it and say, "Oh, you forgot.
This is two spaces here. It should be one."
Collins-Sussman: Well, I mean, it's too late to really go back
and make significant changes. Fitzpatrick: Right.
And you're not gonna want to digest all that.
To digest what that amount of code would do,
you really want to see a design doc
or talk to the person about it.
Collins-Sussman: The other issue is that a lot of people
aren't gonna be interested in your project,
because there's no opportunity for them to take a stake, right?
If your project's 95% finished,
why would I want to get involved when it's mostly done, right?
There's very little opportunity
for me to come in and make a mark
and feel like I'm really affecting the direction, right?
So, uh... [laughs]
Talk about brain crack.
Fitzpatrick: Brain crack.
Yeah, so anybody here ever watch the Ze Frank on the Web?
He had this thing called "The Show" a few years ago.
He had this one episode where he talked about brain crack.
It's these ideas people have. People have ideas all the time.
You have an idea, and you think, "This is a brilliant idea."
You sort of nurture it in your head,
and you think about how wonderful it is,
and there's angels around,
and it's the greatest thing ever.
You never act on it,
because as soon as you try and implement it or act on it,
you usually find out that most of them are garbage, okay?
But, you know, you keep these ideas to yourself,
and they're sort of, like-- He calls them brain crack,
you know, 'cause you just feed on them.
So the point is to try to get things out
as quickly as possible.
Collins-Sussman: Well, let's look at the opposite scenario.
What happens if you start getting collaborators
working with you too early in the process?
And the answer to that-- I think a good example
is go look at a huge number of projects
on SourceForge or Google Code,
where there's, like, one author, and there's nothing up there
but, like, maybe a Wiki page that says,
"Dudes, we should write this cool software
and take over the world.
Let's talk about it," right?
And, like...
you know, one of two things happens.
Either nobody cares, and nobody comes, nothing happens,
'cause there's no prototype.
There's nothing to look at, right?
Or, even worse, 50 people come, or 100 people come,
and they all want to do different things,
and you end up sort of having this endless discussion
about what it could be,
and you get into sort of this design by committee
where nothing happens, right?
And the whole thing just kind of stalls.
Fitzpatrick: Well, you--you're the great--
You run the risk of attracting a lot of people
that don't want to do what you want to do, okay?
You want to go there,
and somebody shows up and wants to go here.
And you didn't really communicate
that you wanted to go there in the first place.
So they're not wrong.
You're just gonna waste a lot of time and energy.
Collins-Sussman: So what you want to do
is you want to go for the sweet spot.
What we call the sweet spot is you have a coherent design
and a mission statement, right?
Clearly written out on your Website, goals and non-goals.
What the purpose is-- exactly what you're gonna do.
So people can't show up and completely derail
the direction that you've chosen, right?
And you got to have some amount of running code.
It doesn't have to be a lot,
just enough to say that you're serious
and to get the idea going in other people's heads--
Just a proof of concept, right?
Or just a mock-up or something
so that it's far enough along
that it feels like there's some inertia, right?
But not so far enough along that people feel like,
"Oh, I can still get in and get involved
and really influence this project," right?
"Make a mark. There's a lot of work to do still."
Fitzpatrick: Right, but you have to be ready to make revisions.
You have to be ready for that, for the criticism
and, you know, it might be to make some changes
and discuss and backtrack...
Collins-Sussman: And document your failures.
Fitzpatrick: Don't hide the history.
I mean, that's really-- It's a really important thing.
One thing that we've noticed a lot in Open Source projects
is that there's a lot of documentation
about what they're gonna do and what they'd like to do
and sort of what they've done that's worked for them.
But rarely do you find any documentation
of stuff that they've tried that they failed at, you know?
People have a design doc that didn't work.
They just delete it.
They're like, "Oh, I'm gonna pretend
like that never happened," right?
Collins-Sussman: That whole branch never happened.
Fitzpatrick: Right, exactly.
But in a lot of cases, this can be a huge time-saver,
because let's say that you're having a huge discussion
about something, and you go off and you try it,
and it doesn't work, so you delete the code and whatnot.
A year later, someone comes up and has this huge discussion.
They want to try this great idea
that you did last year and failed, okay?
Now, it's easy enough if you can point them
to the change list where it happened.
Collins-Sussman: What if you've left the project, right?
What if you've left the project,
or the person who tried the experiment is gone?
They're not there to remember
or even point you to the deleted branch to read the docs.
Fitzpatrick: It's good to have that mailing list
that's read there that that happened.
It's not bad. It's okay.
The world is full of false starts
that eventually rot away.
But we have a couple case studies here to talk about.
First of all is Subversion,
which is--you know, was our project many years ago.
And, uh--Well, you go ahead and tell it.
Collins-Sussman: Well, I mean,
I don't know if this is the model,
but we think we did a pretty good job
with starting this project.
I mean, it started out with three guys in an office
writing a design doc together, just the three of them.
Took us maybe two weeks,
three weeks to actually get it right.
And I think three's kind of the sweet number.
Like, one person writing a design doc
is gonna make a lot of wrong choices.
Two or three people is great,
because they can call each other.
They can say, "That's a bad idea. Here's why."
And there's enough perspective.
If you get more than three people,
then it starts to become a circus, right?
It's the same reason, like, why meetings
with more than five people never accomplish anything.
Yeah, never converge.
Fitzpatrick: Everybody ever travel with a group of people,
like travel around Europe or backpack or something?
You get more than six people, you can't go anywhere.
[laughter]
You go to the next corner, and it's a big discussion.
Collins-Sussman: That's true of a business meeting too.
Fitzpatrick: Exactly. It's also true about meetings.
Collins-Sussman: So with design docs,
I think two or three people is sort of that perfect number.
And then after we got the design doc,
we went, and we brought it to a larger forum.
We gave a presentation about it.
We invited comments, and we put it up on a web site,
and we started getting feedback.
And then we just started coding,
and, amazingly, about a month or two later,
we had some working-- very basic working code.
And suddenly, as soon as we had working code,
suddenly all these people started showing up.
We didn't even advertise, but somehow,
it was like we crossed this magic threshold,
and we said, "It's okay now. Come on, come on, come on."
Fitzpatrick: We have to remember nine years ago,
it was CVS in the Open Source world.
Collins-Sussman: It was only CVS.
Fitzpatrick: It was only CVS in the Open Source world.
That was it.
But the other thing-- You're erasing history here.
You forgot to tell them about us going into a cave.
Collins-Sussman: It never happened.
Fitzpatrick: There was a lot of people
that showed up a little bit early almost,
and we said, "All right, we're gonna create
"this private mailing list
"and have our design discussions there,
because these people are distracting us."
Collins-Sussman: Well, we were embarrassed.
Fitzpatrick: Yeah, but Brian Behlendorf
was outraged.
Anybody who knows Brian Behlendorf,
the guy is never outraged.
But he was very angry,
and he told us to cut it out, basically,
and get our butts back out there.
Collins-Sussman: Stop talking in private, right?
If they're bored by what we're saying, they can leave.
Fitzpatrick: Right. And we were pretty indignantly angry
about it at the time.
But, you know, four years later,
you know, we're laughing about it.
He was totally right.
Collins-Sussman: So what's our other...?
Fitzpatrick: Our next case study--
Collins-Sussman: Well, you talk.
Fitzpatrick: All right, next case study is the two of us.
So we've given dozens of talks together
over the past, I don't know, four years, five years,
and we've known each other for about 10 or 11,
but sort of the case study is how we write our talks.
I mean, what we've done over the past five years is we take--
we put the phones away, leave the laptops at the office,
take a couple notebooks, and go to a cafe.
And then they close the cafe.
Collins-Sussman: Paper notebooks, made of tree.
Fitzpatrick: Then they close the cafe, and we find another cafe,
and they close that cafe.
So if we show up in your cafe, you might want to throw us out.
But we sit down there and--
Oh, I forgot to plug in the laptop.
Collins-Sussman: Good thing we're almost done.
Fitzpatrick: Yeah, good thing we're almost done.
Collins-Sussman: Except we lost our...
Fitzpatrick: Lost our...
Is there power? Collins-Sussman: There it is.
Fitzpatrick: Oh, uh, grab it.
It's over here, sorry.
Collins-Sussman: That's it.
Fitzpatrick: So this is a great example of failure.
This is why we did this.
[laughter] This is completely intentional.
You got the plug over there? Thank you.
Collins-Sussman: There we go.
Fitzpatrick: All right, that's much better.
Collins-Sussman: Awesome.
Fitzpatrick: Gosh, I feel stupid.
So case study is forgetting to plug your laptop in.
But so we sit down with-- on paper and we just brainstorm.
One of us usually has an idea for what we want to talk about.
And we'll brainstorm or sort of riff on that idea.
And we act as filters for each other.
"Oh, we think that's a good idea.
Let's go in that direction. Let's not."
What we wind up with at the end is a whole bunch of ideas,
and then once we get the ideas together,
we put it together in an outline
and try and make it a little bit more coherent
and group like things together.
Collins-Sussman: And then someone else goes
and puts it into slides and then gives it to the other person.
Then they change the slides.
It sort of bounces back and forth, right?
But it's a nice gradual evolution.
At no point are we hiding from each other or--
Fitzpatrick: But another thing we learned
is that if you're gonna give a talk at an event like this,
you want to actually not walk in here completely fresh
and never having spoken this before.
So we can stand at home
or in the office and do it in a conference room,
but we decided to give a presentation
at the local user group in Chicago,
and we learned some things about what did and what didn't work.
For example, when you're speaking
to a room full of 19-year-olds, they don't know what CVS is.
Then we also gave it to the engineers
in our office in Chicago,
and we got some great feedback from them.
And then we gave it here, and we learned to plug in the laptop.
Collins-Sussman: Which you're reading quickly.
Fitzpatrick: Yes, exactly.
That's the first time I've made that mistake,
and hopefully I won't fail that way again, at least.
Collins-Sussman: All right, so let's just back up really quick.
We have our obligatory summary,
just in case you forgot what we were saying.
So there are no geniuses.
Fitzpatrick: There are very few geniuses.
Is Jeff Dean here? Collins-Sussman: Okay.
[laughter] Fitzpatrick: Okay.
I was told by another Googler
if Jeff was here, we're gonna be in deep trouble.
Collins-Sussman: So right. So there's no geniuses.
It's our natural instinct to try and want to be a genius,
but we should fight that
and actually try to collaborate as much as we can, early, often.
Don't be afraid of collaboration.
And pay attention to what your tools are doing to you
and the people you work with,
'cause they do affect your collaborative behavior.
And finally, make sure you're paying attention
to when you collaborate, right?
Not too early, not too late.
It all is sort of--
There's a critical sweet spot for success in collaboration.
Fitzpatrick: Right.
And of course, there's actually a secret to all this
that you probably shouldn't share outside of this room,
but believe it or not, if you actually do all these things,
people will think you're a genius.
So--'Cause it's not the typical thing that people do.
People don't make themselves vulnerable.
They don't sort of-- They're not open to influence.
And, uh...
Collins-Sussman: That's it.
Fitzpatrick: But that's it. Thanks.
[applause]
Collins-Sussman: We got 15 minutes.
Fitzpatrick: Yeah, we have some time for questions and answers.
So if anyone has any questions or preferably answers,
there are some mics in the center of the room.
If you could get up there and...
Collins-Sussman: Uh-oh, two at once.
Fitzpatrick: Protocol. Okay.
man: Two questions-- one for the audience, actually.
Who would consider themselves a pair programmer?
Fitzpatrick: See, they can't get their hands all the way up.
[laughter]
man: And the same question to you guys, really.
What do you think about pair programming,
kind of formally?
Fitzpatrick: I personally think it's ideal
if you're working on something really difficult.
When I wrote CVS to SVN,
which is probably one of the hardest things
I've ever worked on in my life--
I learned more about CVS and RCS than I wanted to learn ever.
Karl Fogel and I did a lot of pair programming.
It was really good,
because it was really grungy, difficult problems.
But for sort of day to day,
I prefer more of the write-code-review process.
Collins-Sussman: It creates social stress, right?
If you're pair-programming with somebody,
you better be really-- know each other really well
and be very tolerant of each other's quirks, right?
Otherwise, it can actually-- you can start arguing
about whoever's driving, right?
"Don't format the code that way."
Or, "Don't you know that shortcut?"
Or, you know, it can get a little maddening.
Fitzpatrick: There's a number of really good engineers at Google
who pair-program all the time, and they do a great job of it,
and they're amazingly productive.
man: Thanks. Fitzpatrick: Yeah.
man: So advice on dealing with egos,
'cause I agree with you guys,
but there's definitely people on the team
that, you know, their ego is always in the way.
Fitzpatrick: Advice on dealing with egos.
Collins-Sussman: What is the advice?
Fitzpatrick: How do you deal with people that have a big ego?
Is that the question? Wow.
Um...pass.
No, I'm kidding. [laughter]
That's a hard question, because...
typically if they're running the project, they'll--
Again, like attracts like, okay?
People who are sort of the friendlier, nicer,
consensus-building people
are gonna attract people that like to work with that.
People who are the big, you know, ego--
"It's about me. Let's be aggressive here.
I'm the alpha male. Let's fight about things."
Collins-Sussman: They attract other alphas.
Fitzpatrick: Exactly. They're gonna attract other people
that either want to follow them and be like,
"Oh, yes, you're right. Wonderful."
Or they're people that just want to fight them,
because that's what they want to do.
So I don't know I'd have a particular recipe--
We have another talk that you can find on YouTube,
if you look for "poisonous people,"
that talks all about how to protect your project
from poisonous people.
So there's a little plug for that.
We gave it here last year, actually.
Collins-Sussman: That's actually probably the best prescription
we have is that talk.
It's just how to deal with difficult people in general
on your project.
Fitzpatrick: Yeah.
Next question. man: Hello.
Fitzpatrick: Hello.
man: Let's see if we can deal
with some constructive criticism here, if it's okay with you.
Fitzpatrick: Yeah.
man: It sounds to me like what you're saying
is almost like humanistically programming,
which is fine,
except what it relates--
you have to be in a certain kind of environment.
And maybe your company has set up a certain kind of environment
at a certain stage in time
that this kind of way of dealing with things works.
But in a different kind of environment--
that is, the majority of the world--
I feel that a lot of the things you're talking about,
people are gonna get crucified.
And I'm not saying that's bad or good.
I'm just saying that's the reality of things.
It's like when I talked to Kent Beck,
what, eight years ago about extreme programming,
the problem with all the guys in the class was,
"Nobody's gonna--I'm gonna take this back to my company,
and nobody's gonna want to do this."
So my first thing is that you have to be very careful
about applying these things,
because you go back and do these things,
and you're gonna get in a lot of trouble
in a certain environment.
Secondly, the no-ego thing is great.
We'll just send everyone off to a Zen center for a year.
[laughter] You know?
People have egos. I'm a psychologist for 30 years.
I deal with people, and that's real.
That's an ego thing.
Thirdly, there's plenty of evidence that there are geniuses
in the world.
I think that's obvious.
And there's plenty of evidence that there's a whole range
of people that are good at programming.
Some people are good. There's a fair amount of research
that talks about the great programmers
can write 100 times better--
Fitzpatrick: I'm gonna stop you there.
I don't disagree with you on that--Can you hold on a second?
I don't disagree with you.
I'd be glad to talk to you a little more offline.
"The genius is a myth" thing
is definitely a straw man that we're setting up.
There are geniuses,
but the point we're trying to make precisely
is that there are remarkably few.
There are far fewer than most people realize.
And I think our talk is much more aimed
at people who are able to control their project
or their environment.
If you're in a corporate environment
or something where you have no control
over the actual way the software is developed,
you're gonna have a very hard time doing that.
And you're right. You might get crucified.
And our legal staff has asked me to say
this is not medical advice.
[laughter] And please be careful.
But please, we'd love to talk to you more
about it afterwards in person. Thanks.
Collins-Sussman: We're describing the ideal here,
right?
Getting from the ideal, actually implementing that,
making it happen, is a whole separate problem.
Fitzpatrick: Right. I mean, we deal with the Open Source world,
for starters.
And then coming to Google,
it's run inside like a whole bunch of Open Source projects,
to some great extent.
So it's a similar sort of gestalt.
Collins-Sussman: Right. Fitzpatrick: Next question.
man: Hi. I hope this will be interesting to many people.
So you mentioned being a small fish.
Do you have any advice of--
So if you're in an environment where you're not a small fish,
so how to change that,
without leaving the environment, of course.
Or how to find other ways
to improve your skills.
Collins-Sussman: So the question is, "If you're a small fish,
how do you deal with-- how do you become a big fish?"
Sorry, if you're a big fish, how do you become a small fish?
Fitzpatrick: You hire bigger fish.
Collins-Sussman: That's it.
If you're talking about in a corporate environment,
if I were in that situation,
I would start looking around for bigger fish, right?
"Where are the really hard projects?
"Where are the people who are much more knowledgeable than me?
How can I somehow get involved with what they're doing," right?
And maybe it's just slow involvement at first,
but try to sort of creep your career in that direction,
because if you're not being challenged,
if you're not a little bit scared all the time,
just a little bit, then you're not gonna improve.
Now, I mean, I--
That's not a guaranteed solution.
Sometimes you may be trapped,
in which case, I guess I might just go look for another job.
If I were truly bored at my job, right?
Fitzpatrick: Right. In the Open Source world,
you know, you typically want to attract
these kind of people and projects.
So if you're-- If it's built on consensus
and other people can still come in and have an influence,
that's typically what will attract the bigger fish.
man: So you're saying if you can change
your corporate environment,
start an Open Source project, basically.
Fitzpatrick: Again, corporate environments--
it's really risky.
If you are one of the small fish
or, like, you're just an engineer on a large project,
you know, you have no power to change that necessarily.
You can do what you do,
but you're not gonna be able to guide a project
from that seat that you're in.
Collins-Sussman: If you're a big fish in a corporation,
you probably do have a lot of power
to start migrating your career
towards other bigger fish, right?
Fitzpatrick: Right. Collins-Sussman: It's possible.
Fitzpatrick: Next question, please.
man: Hi. You talked about avoiding a low bus factor
and having as many people look
at as many pieces of code as possible.
And you talked about it in the context
of people being egotistical and wanting to own a piece of code
and no one else touch it.
But I think there's a practical factor there.
When you have a big project with few people,
that the more proficient someone is with a component,
the more quickly they can implement features
or solve bugs.
And if everyone spreads themselves too thin, maybe...
maybe development would slow down.
I don't know.
I feel like this is true on my project
and my work experience.
I feel like when bugs come in, we want to assign it
to the person who knows that component best.
They can fix it fastest.
But we've thought about maybe purposely assigning bugs
to people who know it less to help spread knowledge.
Is that a good idea, or is this concern completely false
and just coming out of ego?
Collins-Sussman: I think there's a tension there,
like you said, right?
The fastest thing to do
is to have the people who know the code best work on it, right?
But you need to sort of find a balance, right?
Where you're balancing short term versus long term.
In the short term,
it's best to have the experts work on the code they know,
'cause it'll get done faster, right?
In the long term, though, you want to occasionally,
like you said, maybe have someone
who doesn't know that code as well
pair-program a bug fix with somebody who does,
or give somebody a small task in that foreign area of code,
which isn't particularly time-critical,
but will give that person some experience with the code
so that if the expert does get hit by a bus,
you'll be covered for the long term.
So, yeah, it's about risk management, right?
Short and long term.
Fitzpatrick: And we're certainly not advocating
that everyone on your project
knows how to do absolutely everything in the code base.
There's ways of improving your bus factor
without actually making everyone into a generalist,
and that is good solid documentation
in code and comments, design docs,
and then just general documentation.
Collins-Sussman: And code review, right?
If one person--If there's code review going on,
then it's really pretty much impossible for one person
to know an area of code.
Somebody must've reviewed that code
that went in there, right?
At least have a cursory knowledge.
Fitzpatrick: Next question, please,
in front.
man: Uh, yes.
You were talking about technological solutions
for social problems.
And you mentioned that Git
and other distributed systems have this problem
where the first thing you do is fork.
But I wonder if--And I don't want to put you on the spot,
'cause I think this must be some sort of competitor of yours,
but GitHub has taken that model
and sort of mushed it together, so it's both--
You fork, but when you fork,
somebody else can see that you forked their code.
And we've had cases where I work lately
where we have fixed something, and the next day
it would get pulled back into the main branch.
So I wonder, you know, how you think about that.
And maybe even if you could-- if Google Code was thinking
about going somewhere in that direction.
Collins-Sussman: Well, Google Code
actually supports Mercurial now.
And, yes, we are working
on the whole sort of server-side clones, much like GitHub.
I think that's gonna be coming.
[man speaking indistinctly]
It's not deployed yet, but, yeah, it would be--
it's definitely on our road map to sort of have, you know--
having users be able to clone repositories on the site
and do polls from them the same way GitHub does.
But I was saying there's a balance, right?
Yeah, people start out forking, but on the other hand,
it's a much lower barrier to participation
than with a centralized system.
So I think it balances out, right?
Or maybe it's even better in the long run
for participation.
Fitzpatrick: We have one last question it looks like.
man: Hi.
You did give a very nice talk--
Fitzpatrick: Into the microphone, please.
man: Yeah. You did give a very nice talk
about how you should be to pick up team enrollment.
But usually what when you're working on one reserve,
when you start implementing what you just talked about,
it's not just someone becoming a genius,
but you become a guinea pig.
Your manager wants you to write more code.
Your peers look up to you, even though you are a small fish.
Just out of college, you know, they expect you--
You know all this, and I'll just bring up
a magical solution and, of course--
It's like a little bug trying to pull an airplane.
And then you're kind of in that limbo,
where you want a code, but you're afraid of coding.
And the more you code, your manager wants you to code more,
and then suddenly, you start to dream code.
Your girlfriend becomes angry at you
because you forget about her.
Your mother complains because you're not calling her.
So all these psychological problems come up.
So how do you actually think about this?
Fitzpatrick: We have another talk in five minutes
on how to replace your manager.
[laughter] No, I'm just kidding.
Collins-Sussman: Hmm. I don't think I've seen that situation.
Are you talking about the general pressure
to write more code?
I mean, I guess I don't quite understand.
Fitzpatrick: I think it's a pressure from management
to behave in one way
when it's not necessarily better for the team.
Is that the general gist of what you're talking about?
man: It's just a matter of becoming a guinea pig.
You are the one--
You become a victim of experimentalization.
Fitzpatrick: Right. So...
Collins-Sussman: Wow. I don't know.
Fitzpatrick: We don't have a solution for that.
Collins-Sussman: I think we're out of time.
Fitzpatrick: I think we're out of time.
Collins-Sussman: Darn. Rats.
Fitzpatrick: Thanks to everybody for comi