Fitzpatrick:
Hello, and this is, 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 coming. [applause]
As a live sound guy, that ringing drove me absolutely insane. Google - if you need a competent audio engineer, I'm available.