Upgrade to Pro — share decks privately, control downloads, hide ads and more …

The End of Fun - Lone Star Ruby

The End of Fun - Lone Star Ruby

I hate to break it to you, guys, but Ruby is old enough to drink. What started out as a small community full of fun, silliness, and connection has been growing. Our small codebases are now large. Our small companies are now large. And the large companies have finally figured out that they want in, too.

So maybe it’s time to start tackling Real Problems and Real Solutions in the world of Real Innovation. Maybe it’s time for the community to grow up, stop playing around, and get Serious™.

But…that’s not who we are. Our community thrives on creativity, play, and luck. And those things aren’t just a weird perk like not having to wear shoes in the office – creativity, play, and luck, when present, actually produce better software. As we grow our projects and our teams and invade the corporate cube farm, there are some things we can lay aside, and there are others we must hold on to as if our very identity depended on them.

Because it does.

sarahmei

July 20, 2013
Tweet

More Decks by sarahmei

Other Decks in Technology

Transcript

  1. End
    of Fun
    The
    Sarah Mei
    1
    Hello! Good morning. I'm Sarah Mei. And I am so thrilled, after hearing for years about the
    fun people have had here, to finally be in Austin for Lone Star. I’m super grateful to Lance
    and Nola Stowe for working hard to get me out here.
    The last time I was in Austin was when RailsConf was here, which was in the month of April,
    and, ah...your weather is a bit different this time of year. I’m from San Francisco, where this is
    a normal morning in July:

    View full-size slide

  2. http://www.flickr.com/photos/bringo/117718
    2
    So yesterday, when it was 93 degrees outside, I was beginning to doubt the wisdom of
    coming to Austin in July. But then, I found this:

    View full-size slide

  3. 3
    !!! This is from the Spoetzl brewery in Shiner, Texas, and it’s their seasonal summer beer. It
    has grapefruit and ginger in it, and now...you might never get rid of me. Anyway!

    View full-size slide

  4. Sarah Mei
    End
    of Fun
    The
    4
    When I was first practicing this talk for some of my co-workers, I ran through the whole
    thing, and one of them turned to me and said, “Sarah...you are not wearing enough eyeliner
    to pull off that title,” and I said, “uh, pardon?” and he said “that title is too goth. It’s a fun
    talk! You shouldn’t...

    View full-size slide

  5. http://www.flickr.com/photos/pinksherbet/244969697
    End
    of
    Fun
    The
    5
    ...SCARE people like that! I mean, this is what I was expecting. I was expecting dreariness and
    black lipstick and gargoyles and fear and loathing! That, and more eyeliner. You should be
    wearing more eyeliner.” And I thought... “huh.” And then I realized that I don’t really do
    eyeliner, so I decided to give my talk a title that describes what it’s actually about.

    View full-size slide

  6. Play,
    Work,
    Code
    &
    Sarah Mei
    6
    ...which is Work, Play, and Code. Less eyeliner for me, more accurate description of content
    for you. I’m going to talk about how we think about how we work. But before I get into it, let
    me tell you a little bit about who I am.

    View full-size slide

  7. @sarahmei
    7
    This is me on all the important parts of the internet, uh, meaning I guess just twitter and
    github.
    I am a Ruby developer in San Francisco. For the last three years, I was at Pivotal Labs working
    with clients on their Rails projects. I am also the co-founder of RailsBridge. We are now a
    four-year-old organization and we try to make our communities more welcoming to
    newcomers. Our workshops for women have introduced several thousand people to Ruby and
    Rails in hundreds of events all over the world. In fact we just did one on Friday, here, which
    was super fun.
    So that’s me. My work at Pivotal, as I mentioned, was working with clients. Most of my clients
    were organizations that are growing rapidly. Specifically, adding developers to their team.
    And so what I did with them was help them build a product, and I helped them build a team.
    And of those two things - team, and product - I’ve discovered that building the product is by
    far the easiest. Growing an engineering team the right way is a really hard problem. Even
    being a developer - not a manager, but just a developer - on a team that’s growing rapidly is
    a really hard problem. So this talk comes out of those experiences as well as some research
    I’ve done on my own. So! Getting back to it...

    View full-size slide

  8. Play,
    Work,
    Code
    &
    Sarah Mei
    8
    To get started, I’m sure nobody in this room who came to a Ruby conference on a Saturday
    falls into this category, but show of hands -- how many of you currently have fun,
    sometimes, writing Ruby code?
    Ok, great! You’re my people. I do too.

    View full-size slide

  9. @sarahmei
    9
    And part of that is the beautiful Ruby language. A few months ago, Ruby turned twenty years
    old. Matz said at the Mountain West Ruby Conf last month that since 20 is the legal age of
    adulthood in Japan, Ruby’s now a grownup. But what he didn’t mention is that 20 is also the
    legal drinking age in Japan, so as far as I’m concerned, the most important part of this
    birthday is that Ruby is now old enough to have a beer. Although to be clear, Ruby can’t have
    any of mine.
    So the language, the language itself is awesome. But what I love about being a Ruby
    developer, maybe even more than the language itself, is its community. Matz has mentioned
    this in a bunch of talks over the last year - Rubyists love events! They love talking to each
    other! That’s pretty freaking unusual for a technical community. And personally I love
    hanging around you guys, I’m just going to put that out there. I've never been in a developer
    community that was more creative, more fun, more social, had so many other interests
    besides code, or had so many interesting projects to work on.
    But many of us in this room have a problem. And of course it looks like this.

    View full-size slide

  10. http://www.flickr.com/photos/library_of_congress/2369111942
    10
    It looks like success! Ruby has been amazingly successful! We've gone from a fringe language
    to almost a mainstream language in the course of just a couple of years. And as a result,
    many things that used to be small have gotten bigger.

    View full-size slide

  11. http://www.flickr.com/photos/jeffhester/77728574
    11
    Symptom #1 - In the last year, we've started seeing conference talks and blog articles and
    even books start to appear around “what happens when your Rails app grows up.” We're
    talking about rails engines, we're talking about software architecture, we’re talking about
    services, and we're talking about object design.
    Even DHH, as much as he hates "over-design", is engaging the question because it is
    important right now. These things aren't important in a small codebase. What this tells us is
    that many of us are hitting the same growing pains at the same time. Our codebases that
    started small have gotten big.

    View full-size slide

  12. http://www.flickr.com/photos/katherine_kirkland/4478696790
    12
    Symptom #2 - Who remembers when Twitter was 12 people? Yeah, that was a long time ago.
    And they're not the only one. Companies that made their money on a Ruby product - many of
    them have grown, IPOd, been acquired…we're working on larger teams. And you can see that
    in the way that we discuss remote work, for example. Our small companies have grown large.

    View full-size slide

  13. http://www.flickr.com/photos/nswmaritime/2963653026
    13
    Symptom #3 - big companies, and I mean the big ones, have started to realize that they want
    in on this. I've talked to people at conferences from HP, IBM, GE, who are bringing Ruby into
    their portfolio.

    View full-size slide

  14. 14
    I've heard a lot of people in the last year or so tell me the same story. There are variations on
    a theme but it goes something like this. They’re a developer, and they went to work for a
    little company building a product in Ruby. At first it was amazing. Total freedom to set
    technical direction and then change it, quickly, as needed, as the business figured out what it
    was going to be when it grew up. They could keep the whole codebase in their head. Then
    product started making a little money so they hired another engineer. Single decision-
    making power turned into a committee of two, and then three, and then the product made
    more money, and the team just kept growing.
    That little company is becoming a big company, with a big codebase. One day they realize
    that they have so many engineers that it’s too chaotic. They start thinking that maybe
    splitting separate teams would reduce the overhead of managing the many-to-many join.
    They experiment with adding process to reduce chaos, but everything they add seems to
    irritate people and push them apart instead of making things better. Some of them hire
    “managers” who don’t write code to “manage” people, and that never ends well.
    They can see it coming. And they're afraid. They're afraid of turning into this.

    View full-size slide

  15. http://www.flickr.com/photos/geodanny/37532418
    15
    They’re afraid of becoming a place where there’s so much process that it takes a week to
    make a decision that before they would have made in 10 minutes. Experimentation and chaos
    are replaced by research and meetings. The growth of an organization can, if it’s done
    thoughtlessly, suck all of the creativity and inventiveness out of developers’ jobs and when
    that happens, the quality of the solutions drops. Now companies do this for a reason, of
    course.

    View full-size slide

  16. 16
    And that’s because creativity and inventiveness are chaotic forces. As a team grows, you
    often add development process in response to too much chaos - someone accidentally
    deletes the production database so you add a process for accessing it. But you need to be
    careful, because software development needs some chaos. We’re solving difficult problems
    that are important to our society. We need creative thought. We need this chaos.
    Now unfortunately, much of the advice that business schools have to give you about growing
    an engineering team lead you down this path of...

    View full-size slide

  17. http://www.flickr.com/photos/zenmama/5095801624
    17
    ...suppressing chaos in all of its forms. So the questions I’m interested in are: for
    organizations that are still small, how do we keep ourselves from becoming this? And for
    organizations that are already growing, how do we as individual developers keep the fun and
    creativity in our jobs, as our organizations grow around us?
    As a community, we talk about this a lot. Not explicitly, often, but this conversation is implicit
    in a lot of the other conversations we have. Here’s one that happens a lot:

    View full-size slide

  18. Established Startup
    ✦ Process
    ✦ Focus
    ✦ Determination
    ✦ Tunnel vision
    ✦ Creativity
    ✦ Ideas
    ✦ Disruption
    ✦ Immaturity
    @sarahmei
    18
    There’ll be a blog post. It’ll probably be at the top of reddit and hacker news. And it’ll say
    there are two sides! And as a developer, you are on one side or the other! If you're an
    established-company person, you like process. You're focused and know what you're
    building. You're determined and unwavering. And the other side will say you have tunnel
    vision.
    If you're a startup person, you're creative. You have a lot of ideas. You value disruption and
    the other side will say you're immature.
    Now these categories have lots of different headers. If you're talking to Paul Graham, who
    founded Y-combinator, the Silicon Valley VC firm that backs small groups of twenty-
    somethings garages, these are your headers...

    View full-size slide

  19. Old Young
    ✦ Creativity
    ✦ Ideas
    ✦ Disruption
    ✦ Immaturity
    ✦ Process
    ✦ Focus
    ✦ Determination
    ✦ Tunnel vision
    @sarahmei
    19
    At the Waza conference earlier this year, one of the speakers, Michael Lopp, better known as
    @rands, gave them these headers.

    View full-size slide

  20. Stable Volatile
    ✦ Creativity
    ✦ Ideas
    ✦ Disruption
    ✦ Immaturity
    ✦ Process
    ✦ Focus
    ✦ Determination
    ✦ Tunnel vision
    @sarahmei
    20
    No matter who's talking about it, though, it's clear that they mean that you, as an individual
    developer, at any given time in your life, are in one of these categories or the other. You may
    move between categories. Paul Graham seems to think that you do as soon as you hit 30. But
    the assumption here is that these are different types of people.
    Some folks will go so far as to assert that you need both types of people in order to balance
    stability and growth in a company. Now we'll come back to that later.
    But right now I want to drop something into this conversation that we haven't had before. I
    want to drop some science in here.

    View full-size slide

  21. http://www.flickr.com/photos/ueharashogo/37532418
    21
    These categorizations are based on one person generalizing from their experience. And that
    can be useful. But I'd like to remind you of something my dad, who had a PhD in chemistry,
    used to say:

    View full-size slide

  22. The plural of
    ‘anecdote’ is not
    ‘data.’
    @sarahmei
    22
    And that is that a collection of anecdotes does not add up to conclusive data. So let's look at
    some data! Let's start with creativity. Because...

    View full-size slide

  23. Stable Volatile
    ✦ Creativity
    ✦ Ideas
    ✦ Disruption
    ✦ Immaturity
    ✦ Process
    ✦ Focus
    ✦ Determination
    ✦ Tunnel vision
    @sarahmei
    23
    If you look at these lists, the generalization here is that the stable side is boring and
    uncreative and the volatile side is fun and creative. All of the other properties flow from those
    judgements. So let’s look at the science around at creativity for a moment.

    View full-size slide

  24. Creativity Factors
    Intelligence
    Age
    Behavior
    Gender
    Race
    @sarahmei
    24
    In the 1970s, scientists did some fascinating work on the qualities of creative people. They
    took two groups - people identified by the peers as creative, and people identified by their
    peers as not creative, and they looked for statistically significant differences. Here are some
    things that completely did not matter:
    1. Intelligence
    2. Age
    3. Gender
    4. Race
    In short they found there were no statistically-significant innate differences between people
    who were creative and people who weren't. What they found were differences in behavior and
    in habits.
    Now I'll come back to what those differences are in a moment, but I think it might help, at this
    point, to define creativity, because we all have a feeling for what it is, but science has been
    thinking about this for a while. Let's see what they think.

    View full-size slide

  25. Closed Mode
    ✦ Executive
    ✦ Task-oriented
    ✦ Focused
    Open Mode
    ✦ General goals
    ✦ Open to chance
    ✦ Unfocused
    @sarahmei
    25
    Scientists distinguish two modes of thinking that humans engage in: “closed” and “open.”
    When you’re in the closed mode, you are getting specific things done, what psychologists call
    “being executive.” Your goals are very specific, and typically you’re very focused on them.
    Contrast that with open mode, in which you may have general goals, but what you’re doing
    typically isn’t very focused. You’re open to new connections. It’s in open mode where creative
    thought can occur, and so the first part of being a “creative” person is just knowing how to
    move between these modes deliberately.
    Now do these lists look at all familiar?

    View full-size slide

  26. Closed Mode
    ✦ Executive
    ✦ Task-oriented
    ✦ Focused
    ✦ General goals
    ✦ Open to chance
    ✦ Unfocused
    Open Mode
    @sarahmei
    26
    Yeah. It looks a lot like the categorization we’ve been doing in our community, and that we do
    to ourselves. Am I a big company person? Or a small company person? Am I a stable, or a
    volatile?

    View full-size slide

  27. Stable Volatile
    ✦ Creativity
    ✦ Ideas
    ✦ Disruption
    ✦ Immaturity
    ✦ Process
    ✦ Focus
    ✦ Determination
    ✦ Tunnel vision
    @sarahmei
    27
    It turns out that the people who would like to put us in one of these categories have hit upon
    a real dichotomy in human thought. But these aren’t different types of people. These are
    simply...

    View full-size slide

  28. Closed Mode Open Mode
    ✦ Creativity
    ✦ Ideas
    ✦ Disruption
    ✦ Immaturity
    ✦ Process
    ✦ Focus
    ✦ Determination
    ✦ Tunnel vision
    @sarahmei
    28
    ...different modes of thought. The critical error comes when we say that a person, an
    individual, is one or is the other. Because we are all both at different times.

    View full-size slide

  29. Do I contradict myself?
    Very well then I contradict myself,
    (I am large, I contain multitudes.)
    Walt Whitman
    http://www.flickr.com/photos/87782047@N03/8034112763
    29
    When I realized that, it took me a while to understand the implications there. A person might
    be more comfortable in one mode of thought or the other, but we are all capable of both.
    And we alll do a decent amount of switching between them without even realizing it.
    We contain multitudes.

    View full-size slide

  30. Closed Mode Open Mode
    ✦ Creativity
    ✦ Ideas
    ✦ Disruption
    ✦ Immaturity
    ✦ Process
    ✦ Focus
    ✦ Determination
    ✦ Tunnel vision
    @sarahmei
    30
    So when people they say that you need both to balance against each other…that's actually
    true. Because we do need both of these modes of thought in software development. Each of
    us needs to be able to do both. But a technical leader shouldn’t be trying to hire these
    archetypes and keep them in tension with each other. A technical leader’s goal should be to
    allow their people to do both of these things at the right time.
    Now at this point, it’s still fair to ask, "what does being creative have to do with software
    development?" Isn't what we do computer "science"?

    View full-size slide

  31. http://www.flickr.com/photos/horiavarlan/4273968004
    31
    Isn't this "typing"?

    View full-size slide

  32. http://www.flickr.com/photos/ccpixel/4913826800
    32

    View full-size slide

  33. http://www.flickr.com/photos/fotosmanuela/8038512015
    33
    What does it have to do with art, or poetry, or music, or humor, or dance? Those things are
    creative. Isn’t what we do kind of mechanical, by comparison?
    I’m not, and have never been, a professional artist. All I see as a consumer of art is the result.
    I see the sculpture. I see the painting. And as far as I could tell, these were produced by an
    artist who would go into a cave, do things I didn’t understand, and then emerge with their
    work of genius.

    View full-size slide

  34. 34
    This lady is an American dancer and choreographer named Twyla Tharp. She is 71 years old,
    and still considered one of the most creative forces in contemporary dance. She wrote a
    fantastic book called "The Creative Habit," and the core of it is the process she uses comes up
    with a new dance.
    And this happens over the course of several months. First, in the morning, she dances her
    standard routines and moves for several hours. She's moving her body in very familiar ways
    that she’s done for 30 or 40 years. She’s executing. She’s comfortable. Then in the
    afternoon, she works on coming up with new movements. The movement she does in the
    morning serves as the raw material and gives her a base that she can then to refactor into
    something completely new.
    Her process moves her deliberately between the closed mode, which is the morning, and the
    open mode, which is the afternoon. She needs both to come up with a new dance. Because if
    all she does is dance the old moves, she’ll never come up with anything new. But if all she
    does is noodle around with new stuff, she lacks the base from which creative changes can be
    made.
    Her creativity isn’t a lightning strike out of nowhere. It’s a repeating, methodical habit that
    gets her in the best situation for the lightning to strike.

    View full-size slide

  35. http://www.flickr.com/photos/ueharashogo/37532418
    35
    And that lines up with the science. People who are creative have simply developed habits that
    deliberately move themselves between the closed and open modes of thought. And it’s the
    movement between them that’s key, because each one feeds the other.
    Let me show you what this looks like when you’re writing code.

    View full-size slide

  36. @sarahmei
    36
    This should look familiar! Red-green-refactor. First you write a failing test. Then, you write
    the code that makes it pass. Then, you refactor the code to try to make it better. Now in
    practice, it's more like this:

    View full-size slide

  37. @sarahmei
    37
    red-green-red-green-red-green - get some somewhat standalone portion of the feature
    done - then refactor. To give you a concrete example, just in case you’ve never seen this
    done before...

    View full-size slide

  38. it “computes the number of ipads” do
    b = create(:bus)
    create(:passenger, bus: b)
    create(:ipad_passenger, bus: b)
    b.ipad_count.should == 1
    end
    unit test for a new
    method
    RED!
    @sarahmei
    38
    Think about adding a method to a Rails model. You have a model for a bus, and you need a
    method that tells you how many iPads are on the bus. So you write a model spec that fails,

    View full-size slide

  39. def ipad_count
    passengers.inject(0) do |result, p|
    result += 1 if p.has_ipad?
    result
    end
    end
    GREEN!
    code for the new
    method
    @sarahmei
    39
    then you write the method, and the model spec goes green. And then you realize the story is
    asking for registered iPads ...

    View full-size slide

  40. it “computes the number of ipads” do
    b = create(:bus)
    create(:passenger, bus: b)
    create(:ipad_passenger, bus: b)
    create(:unregd_ipad_passenger, bus: b)
    b.ipad_count.should == 1
    end
    add to unit test
    to cover new
    requirement
    RED!
    @sarahmei
    40
    so you add another line to the spec which goes red again,

    View full-size slide

  41. def ipad_count
    passengers.inject(0) do |result, p|
    if p.has_ipad? && registered?(p.ipad)
    result += 1
    end
    result
    end
    end
    def registered?(ipad)
    AppleService.is_registered?(ipad)
    end
    oh god this got terrible
    GREEN!
    @sarahmei
    41
    and then you implement it in the model and then everything's green and then …
    you sit back and look at it for a moment, and you realize that maybe all this stuff doesn’t
    really belong in the model.
    At this point you have literally thousands of options for what you could do with this code.
    You can leave it where it is. You can extract it into a class. You can extract parts of it and
    leave parts of it in the model. You can re-imagine your domain model, you could rewrite the
    whole thing in node.js - you have LOTS of options.
    You’ve gone into the refactoring phase. Let’s talk about what’s different about these two
    phases of the cycle.

    View full-size slide

  42. Red-Green Refactor
    ✦ Talking syntax ✦ Talking factoring
    ✦ Entering code
    ✦ Leaning close
    ✦ Moving code
    ✦ Sitting back
    @sarahmei
    42
    First, the words we say change. Now if you're pairing these are the words you say out loud,
    but if you're on your own, this is your internal monologue.
    Either way, we go from discussing the nuts & bolts of the functionality: "oh hmm, I think we're
    missing an end. Maybe that context doesn't need to be there. That looks like a variable we
    could inline." …and we start discussing considering larger concerns: "this method started out
    with a name that made sense but now it's not quite right. Maybe it doesn't belong in this class
    any more. Or maybe we could rename it to be more appropriate."
    Second, the keys we press change. We go from entering code, entering logic, putting in our
    eaches and injects, and we change to moving code around, between files, between classes.
    We cut & paste. I'm giving us the benefit of the doubt that we're not cutting & pasting up
    here.
    Third, how we sit changes. When we're red-green-red-green, we get close to the screen. Even
    if it's a big screen - ever notice that? But when we're refactoring, we sit back. We take our
    hands off the keyboard. We put our hands behind our head. We look at the code without
    changing it.
    Fundamentally what's happening is that in these two modes, we are thinking differently about
    the code. How we are thinking has changed.

    View full-size slide

  43. http://www.flickr.com/photos/amytakespictures/6077476547
    43
    Red-green-red-green - you're operating in the closed mode. Refactor, and you've move to
    the open mode. Just like Twyla Tharp’s process is a structured way for her to spend some
    time in open mode and some time in closed mode, red-green-refactor is a structured way of
    moving us between the closed and open modes when we’re writing code. It's a habit that we
    have that gives us room to think creatively every time we write code.
    Now there’s one piece of this puzzle that we haven’t talked about, and that is:
    When you're in that open mode, and everything is possible, how do you proceed? The process
    has given you this creative space. How do you get the lightning to strike?
    It’s often a matter of being able to shift your context appropriately - to consider the code you
    just wrote in a larger context. That shift is the germ of creativity, no matter what type of
    creativity we’re talking about. Painting and comedy and poetry all of these creative works -
    they all gain their power by showing the viewer a context that they hadn’t noticed before. Let
    me give you another example.

    View full-size slide

  44. http://www.flickr.com/photos/lkbm/100494509
    44
    Humor! Everyone loves a good lightbulb joke, right? How many folk singers does it take to
    change a light bulb. Answer: 5, 1 to change the bulb and 4 to sing about how much better the
    old one was.
    How many anarchists does it take to change a light bulb. Answer: none, because everyone
    knows that they never change anything.
    Find me at the drinkup tonight and I’ll tell you Shane Becker’s followup to that one.
    And finally, I’m going to take the cheap shot: how many enterprise developers does it take to
    change a light bulb. Answer: we're not going to change it, we think it works.
    It’s the shift of context between the setup and the punchline makes jokes funny. So once you
    get in to the creative mode - that’s step one - but then if you want to be able to come up with
    these flashes of insight, if you want to write the jokes - you need to be able to make that
    context switch once you’re there. If I were a management consultant, which I’m not, I’d call it
    “thinking outside the box,” and then you’d have to shoot me, but really it’s just context
    shifting that allows you to see an brilliant and unintuitive solution to the problem at hand.

    View full-size slide

  45. http://www.flickr.com/photos/morphicx/8409632077
    45
    I’ll state the obvious and say that different developers have different levels of skill with this
    type of thinking. I’ve been pair programming full-time for more than three years at this point,
    and I’ve paired, I counted it up, with about 150 different developers. And some of them, when
    we’re sitting there together looking at a refactoring, seem to always come up with a pretty
    decent solution. It often feels a lot like luck.
    It’s a big project, there’s lots of code and no one person knows all of it, but the “lucky” people
    always seem to have just been looking at some code in a completely different part of the app
    that had a pattern that might work here if you changed certain things about it.
    So then I ran across a really interesting piece of science...

    View full-size slide

  46. http://www.flickr.com/photos/ueharashogo/37532418
    46
    ... that examined what’s different about people who consider themselves “lucky,” and people
    who consider themselves “unlucky.”

    View full-size slide

  47. http://www.flickr.com/photos/romtomtom/4382603005
    47
    First they studied whether people who think they are lucky are, in fact, luckier than people
    who think they’re not. They did this by giving both groups a section of the newspaper, and
    telling them to figure out how many photographs are in it, and to bring that number back to
    the researcher.
    On the second page of the newspaper was a half-page advertisement with no photographs
    but huge type that said, “STOP. THERE ARE 26 PHOTOGRAPHS IN THIS SECTION. BRING THIS
    NUMBER BACK TO THE RESEARCHER.” And the people who thought they were lucky did indeed
    see this advertisement, and save themselves the tedium of actually counting the photographs,
    much more often than the people who thought they were unlucky.
    So having established that there *are* differences in people’s luck, they then tried to find
    differences in the people that explained it. And it turns out, just like the science around
    creativity, there are no intrinsic differences between these two groups of people. But - there
    are differences in behavior. And that means that just like creativity, luck is a skill that you can
    practice & get better at.
    The difference? People who are lucky deliberately seek novelty in all parts of their lives.

    View full-size slide

  48. http://www.flickr.com/photos/creativelenna/4387546703
    48
    Given the choice of two paths to walk, they will pick the one they haven’t gone down before.
    Presented with a menu, they’ll choose the dish they haven’t eaten before. These are little
    things - but by deliberately exposing themselves to things outside their comfort zone, they
    are changing the mode in which their brain works. It becomes more open, and that means
    they notice things they wouldn’t normally notice. The end result is that they are more able to
    see the context shifts, and that makes them unusual, creative, and effective problem solvers.
    They’re setting themselves up for inspiration to strike.
    So you can practice being creative and you can practice being lucky. And that...

    View full-size slide

  49. Closed Mode Open Mode
    ✦ Creativity
    ✦ Ideas
    ✦ Disruption
    ✦ Immaturity
    ✦ Process
    ✦ Focus
    ✦ Determination
    ✦ Tunnel vision
    @sarahmei
    49
    ...sets you up to take best advantage of both of these modes of thought. Because we want all
    of these things. Even the tunnel vision and the immaturity - we want the whole richness of
    human thought brought to bear on our problems. And red-green-refactor is not the only way
    that you can introduce creative space into your projects.

    View full-size slide

  50. @sarahmei
    50
    The development process at Pivotal Labs, which is what I did for the last three years, has a lot
    in common with extreme programming. On a typical day, developers pair up, take whatever
    story is on the top of the backlog, whatever it is and they work on it. They do the red-green-
    refactor cycle, finish it, and deliver it. And then, they go back to the backlog and pick up the
    next story that’s at the top and start working on that. I call this the “story mill,” because when
    you do this process you just churn through stories. And it feels amazing. It feels absolutely
    fantastic to get so much stuff done. You do this eight hours a day and you get a LOT of stuff
    done.
    Once a week, though, in this process, we do something different. We a one-hour
    retrospective, which is a meeting that is our chance to consider how our process is working,
    and how we'd like to change it. It’s meta-level - it’s considering the process itself.

    View full-size slide

  51. @sarahmei
    51
    I could not do this process at all, let alone continuously for three years, without those
    retrospectives. The story mill is closed mode, and it is really freaking closed. Retros are the
    open mode that balances that. No process ever works the same for two different
    organizations. But it’s usually not obvious, when you’re in the thick of it, exactly what needs
    to be changed. So doing these retros once a week is a structured way to introduce creative
    thinking into our process, just like the refactor stage is a structured way to introduce creative
    thinking into our coding.

    View full-size slide

  52. Process, done right,
    enables us to be
    creative.
    @sarahmei
    52
    Because, process, when it's done right, is what enables us to be creative. And being creative is
    what enables us to build great software. The process gives us that space. It teaches us the
    habits of creative people. If that's not what yours feels like, you should think about
    refactoring it in that direction.
    And if you're at a company that is growing, or already big, and you start needing to add more
    structure to your development process, there are a thousand ways to do it. I can’t tell you the
    right things to do because they depend on your people, your market, your financial
    structure...but there is one fundamental thing that you must remember: make sure the
    process you add is enabling creativity. Make sure it’s not squeezing all of the fun out of your
    development. Because it's that fun, that play, that serendipity, that makes it possible to write
    great software.
    And finally: it’s your job to set yourself up so that lightning can strike when it needs to! You
    need to introduce enough novelty in your life for you to take advantage of that time. Here are
    some things you can do when you're working that will make you more open:

    View full-size slide

  53. ✦ Dig into your code
    ✦ Talk to non-programmers
    At work
    @sarahmei
    53
    First - look at parts of your codebase beyond what's just immediately in front of you. If you
    see a method being used and you don't know how it's implemented, go look. Spelunk
    through parts of the code that you haven't seen in a while. Fill your mind with the raw
    material for creative thought.
    In that same vein - talk to other people in your company. Get out of the engineering bubble.
    Have lunch with some sales folks, god forbid.

    View full-size slide

  54. ✦ Dig into your code
    ✦ Talk to non-programmers
    ✦ Switch projects
    ✦ Vary your days
    At work
    @sarahmei
    54
    Next - try to vary what you do as much as possible. Switch projects every few months if you
    can. If you can't, spend some time writing javascript if you're a back-end developer, or do
    some SQL optimization if you usually do javascript. When you start feeling comfortable, it's
    time to move on.
    And in that same vein - vary your days. Don’t spend 8 hours every day sitting at your desk.
    Get up and take a walk. Get out of the building. Eat lunch in different places.

    View full-size slide

  55. ✦ Dig into your code
    ✦ Talk to non-programmers
    ✦ Switch projects
    ✦ Vary your days
    ✦ Work with people not like you
    At work
    @sarahmei
    55
    Finally - seek out teams that have people who don't look like you. This is an interesting hack.
    There's been some research that tells us that if you have two problem-solving teams and
    what they do requires creative thought, and one team is better qualified on paper but they all
    look the same, and the other team is less qualified on paper but the members have some kind
    of visual difference - height, race, gender, ability, and so forth - then the team that is less
    qualified on paper consistently does better.
    The theory here is very similar to that of creativity and luck. By working with people who don’t
    look like you, and whose interaction patterns are different from yours, you are making your
    brain more open and that means you’ll be more creative.

    View full-size slide

  56. http://www.flickr.com/photos/chovy/2698182370
    56
    And finally finally - find ways to keep creativity and fun in your job. It’s so crucial. We will not
    solve these important problems without it.
    I had a client once who was new to the agile process. We had a story that was important to
    finish that day, because he needed to show the results to his higher-ups the next morning. It
    wasn’t something particularly easy, either, so we needed to get it right, and we needed to get
    it done that same day.
    A pair picked up the story, and they worked on it for an hour or so, and then they got up and
    went off to play ping pong. I happened to be in the kitchen, near the ping pong table, and the
    client came over to me with a very concerned look on his face.
    He looked at the guys playing ping pong, and he looked at me, and he said, “You know,...
    this is a very important story. I really want to make sure we have enough time to get it done
    the right way today.”
    I said, “Yep. That is *why* they are playing ping pong.”

    View full-size slide

  57. Thanks!
    Sarah Mei
    @sarahmei
    57
    And that’s all I got. Thank you for coming! Have a fantastic rest of the day.

    View full-size slide

  58. Most image credits are on the relevant slide. Others:
    • Slide 1, 4, 6, 8: http://www.flickr.com/photos/chovy/2370517548
    • Slide 3: my photo, which btw you can license under Creative Commons
    Attribution 3.0 Unported. If you really want to.
    • Slide 5: http://www.flickr.com/photos/scotbot/7931463454
    • Slide 9: Ruby logo is the copyright of Yukihiro Matsumoto.
    • Slide 9: Ruby Redbird bottle is the copyright of the Spoetzl Brewery.
    • Slides 50 & 51: copyright 2012, Pivotal Labs
    • Slide 57: http://www.flickr.com/photos/peggyq/3555683011
    58

    View full-size slide