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.
