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

00:55:16
https://www.youtube.com/watch?v=0SARbwvhupQ

概要

TLDRBrian Fitzpatrick and Ben Collins-Sussman discuss the myth of the 'Genius Programmer', emphasizing that collaboration is key in software development. They argue that programmers often feel insecure and hide their work, fearing judgment and mistakes. This results in low 'bus factors', which jeopardizes project stability. They advocate for early and frequent collaboration, transparency in sharing progress, and the importance of community in projects. They highlight that knowledge sharing and feedback are crucial for growth and innovation within teams, dispelling the notion that individual brilliance leads to success. The talk encourages embracing failure and iterative learning in programming.

収穫

  • 👥 Collaboration is crucial for success in programming.
  • 😓 Fear of judgment leads programmers to hide their work.
  • 🚌 The 'bus factor' indicates project vulnerability.
  • 📜 Documenting failures can prevent future mistakes.
  • 🌟 There are very few true 'genius programmers'.
  • 📆 Get feedback early to avoid wasted effort.
  • 🛠️ Use code reviews to spread knowledge and skills.
  • 👀 Transparency helps improve code quality.
  • 🤝 Embrace failure as a learning opportunity.
  • 📈 Foster a community around projects for better results.

タイムライン

  • 00:00:00 - 00:05:00

    The speakers, Brian Fitzpatrick and Ben Collins-Sussman, introduce their talk titled 'The Myth of the Genius Programmer,' providing insights based on their extensive experience in version control and open source.

  • 00:05:00 - 00:10:00

    They engage the audience in a survey to gauge their coding habits and introduce the idea that insecurity in coding leads individuals to hide their mistakes, which hinders collaboration.

  • 00:10:00 - 00:15:00

    The speakers explore human psychology, explaining how people idolize individuals like celebrity programmers and often associate success with solitary genius, which is a myth.

  • 00:15:00 - 00:20:00

    They challenge the notion of genius, emphasizing that real progress in technology and software development comes from collaboration rather than from individual, isolated genius efforts.

  • 00:20:00 - 00:25:00

    The importance of collaboration is highlighted, with references to the 'bus factor'—the risk if key individuals leave a project without shared knowledge among the team.

  • 00:25:00 - 00:30:00

    The speakers discuss that programming should involve constant feedback like compiler checks, advocating for early involvement of peers to enhance learning and collaboration.

  • 00:30:00 - 00:35:00

    The talk emphasizes that while some may have exceptional skills, everyone's contributions matter in a team dynamic, leveraging collective intelligence for better outcomes.

  • 00:35:00 - 00:40:00

    They stress dropping egos, sharing credit for team success, and that community is vital for healthy project development, drawing examples from the Apache Software Foundation.

  • 00:40:00 - 00:45:00

    Communication and feedback are reiterated as essential tools for improvement, advocating for kindness in criticism and learning from mistakes as necessary parts of the development process.

  • 00:45:00 - 00:55:16

    The final proposal encourages practicing collaboration routines and a mindset open to learning from others, learning from failures, and adjusting approaches to deepen understanding and growth within teams.

もっと見る

マインドマップ

ビデオQ&A

  • What is the main myth discussed in the talk?

    The myth of the 'Genius Programmer' who works alone and creates masterpieces.

  • How does fear affect programmers according to the speakers?

    Fear of looking stupid leads programmers to hide their work and avoid collaboration.

  • What is the 'bus factor'?

    The bus factor is the number of team members that need to be incapacitated for the project to face serious issues.

  • What should developers focus on instead of individual genius?

    Developers should focus on collaboration and building a community around their projects.

  • How does ego affect collaboration?

    Ego can inhibit teamwork and open communication, leading to territorial behavior.

  • Why is it important to document failures?

    Documenting failures helps others learn, prevents repeated mistakes, and contributes to collective knowledge.

  • What is the 'sweet spot' in collaboration?

    The sweet spot is involving others in your project at the right time—not too early or too late.

  • How can teams ensure knowledge is shared across members?

    Code reviews, documentation, and encouraging multiple team members to work on different parts of the project.

  • What makes a software project successful according to the speakers?

    Successful projects involve collaboration, shared ownership, and an open attitude towards feedback and mistakes.

  • What should developers do if their project environment hinders collaboration?

    They should seek to create or influence a better collaboration culture within their team.

ビデオをもっと見る

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