$30 off During Our Annual Pro Sale. View Details »

Work, Play, and Code

sarahmei
April 05, 2013

Work, Play, and Code

Mountain West Ruby Conf 2013 closing keynote

sarahmei

April 05, 2013
Tweet

More Decks by sarahmei

Other Decks in Technology

Transcript

  1. Sarah Mei Pivotal Labs
    To Be
    Announced
    1
    Hello! Good afternoon. I'm Sarah Mei. And I am so thrilled, after hearing about this
    conference for years, to finally be here for the Mountain West Ruby Conf.
    The last time I was in Salt Lake was 1998. Y’all have changed quite a bit in 15 years. The last
    time I was here there were no bars, only private clubs, there were no tattoo parlors, at least
    not that you could see from the street, and the entire city had two - two! - coffee shops, and
    they were both terrible. So given this, I am expecting that the next time I visit, you’ll have
    medical marijuana clinics, because y’all seem to be heading in that direction.
    Now, as you can see...I totally did NOT forget to email Mike Moore the title and abstract of
    my talk. Yeah. I really have to apologize for that. It’s been a rough year, or so, for me and my
    family. So I’m grateful to be here at all, I’m grateful to Mike and the other organizers for
    inviting me, and I’m especially grateful to you, for sticking around to hear me finish this out.
    Also: hellloooo to the internet! I love you guys too.
    Now what I actually want to talk about today...

    View Slide

  2. Sarah Mei Pivotal Labs
    Play,
    Work,
    Code
    &
    2
    ...is Work, Play, and Code. Bill Chapman had a great talk this morning, did you all see that? All
    about different ways of thinking about how you work. This talk is going to expand on those
    ideas a bit because to me, the most important part of work is play. But before we get into it,
    let me tell you a little bit about who I am first.

    View Slide

  3. @sarahmei
    3
    This is me on all the important parts of the internet, meaning just twitter and github.
    I am a Ruby developer at Pivotal Labs in San Francisco, I’ve been there about three years
    working with clients. 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 best-
    known program is the RailsBridge workshops for women, which have introduced several
    thousand of them to Ruby and Rails in cities all over the world.
    So that’s me. My work at Pivotal has been, as I mentioned, working with clients. Most of my
    clients have been organizations that are growing rapidly. And specifically, adding developers
    to their team. And so what I do with them is help them build a product, and I help 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 Slide

  4. Sarah Mei Pivotal Labs
    Play,
    Work,
    Code
    &
    4
    I’m sure nobody in this room 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 Slide

  5. @sarahmei
    5
    And part of that is the beautiful Ruby language. As Matz mentioned yesterday, Ruby is now
    twenty years old. He said that this makes Ruby an adult in Japan. What he didn’t mention,
    maybe because he’s LDS and does not indulge himself, is that twenty is also the legal
    drinking age in Japan. So now that y’all have brewpubs...cheers to that.
    But what I love about Ruby, maybe even more than the language itself, is its community. Like
    Matz said yesterday, 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 it looks like this.

    View Slide

  6. http://www.flickr.com/photos/library_of_congress/2369111942
    6
    It looks like success! Ruby has been amazingly successful! We've gone from a fringe language
    to a - dare I say it, almost mainstream language? In the course of just a couple of years. And
    so many things that used to be small, have gotten bigger.

    View Slide

  7. http://www.flickr.com/photos/jeffhester/77728574
    7
    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, 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 Slide

  8. http://www.flickr.com/photos/katherine_kirkland/4478696790
    8
    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 Slide

  9. http://www.flickr.com/photos/nswmaritime/2963653026
    9
    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 Slide

  10. 10
    I've heard a lot of people in the last year or so tell me the same story. They were a developer,
    and they went to work for a little company with a couple of friends, building a product in
    Ruby. Then they started making money and hired more developers. Suddenly ways of working
    that were fine with three people don’t work anymore. Then they keep making money and they
    keep hiring and it’s not the same company anymore and they’re afraid! They’re afraid of this.

    View Slide

  11. http://www.flickr.com/photos/geodanny/37532418
    11
    They're afraid of becoming a cube farm. They’re afraid that their company's growth will suck
    all of the fun out their programming.
    Having worked for a big company myself…I know this is a legitimate fear. But the interesting
    thing about fear is that it surfaces some assumptions that for a long time we’ve
    unquestioningly made about ourselves as programmers. Here’s what those assumptions look
    like:

    View Slide

  12. Established Startup
    ✦ Process
    ✦ Focus
    ✦ Determination
    ✦ Tunnel vision
    ✦ Creativity
    ✦ Ideas
    ✦ Disruption
    ✦ Immaturity
    @sarahmei
    12
    This happens every three to five months or so. There’ll be a blog post. It’ll probably be at the
    top of 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 Slide

  13. Old Young
    ✦ Creativity
    ✦ Ideas
    ✦ Disruption
    ✦ Immaturity
    ✦ Process
    ✦ Focus
    ✦ Determination
    ✦ Tunnel vision
    @sarahmei
    13
    At the Waza conference a month or so ago, one of the speakers, Michael Lopp, better known
    as @rands, gave them these headers:

    View Slide

  14. Stable Volatile
    ✦ Creativity
    ✦ Ideas
    ✦ Disruption
    ✦ Immaturity
    ✦ Process
    ✦ Focus
    ✦ Determination
    ✦ Tunnel vision
    @sarahmei
    14
    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 Slide

  15. http://www.flickr.com/photos/ueharashogo/37532418
    15
    These categorizations are based on one person generalizing from their experience. And that
    can be useful. But it reminds me of something my dad used to say a lot:

    View Slide

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

    View Slide

  17. Stable Volatile
    ✦ Creativity
    ✦ Ideas
    ✦ Disruption
    ✦ Immaturity
    ✦ Process
    ✦ Focus
    ✦ Determination
    ✦ Tunnel vision
    @sarahmei
    17
    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. There is clearly a “right” side to be on
    here. All of the other properties in the lists, though, flow from that judgement. So let’s look at
    the science around at creativity for a moment.

    View Slide

  18. Creativity Factors
    Intelligence
    Age
    Behavior
    Gender
    Race
    @sarahmei
    18
    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 Slide

  19. Closed Mode
    ✦ Executive
    ✦ Task-oriented
    ✦ Focused
    Open Mode
    ✦ General goals
    ✦ Open to chance
    ✦ Unfocused
    @sarahmei
    19
    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 Slide

  20. Closed Mode
    @sarahmei
    @sarahmei
    ✦ Executive
    ✦ Task-oriented
    ✦ Focused
    ✦ General goals
    ✦ Open to chance
    ✦ Unfocused
    Open Mode
    20
    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 Slide

  21. Stable Volatile
    ✦ Creativity
    ✦ Ideas
    ✦ Disruption
    ✦ Immaturity
    ✦ Process
    ✦ Focus
    ✦ Determination
    ✦ Tunnel vision
    @sarahmei
    21
    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 Slide

  22. Closed Mode Open Mode
    ✦ Creativity
    ✦ Ideas
    ✦ Disruption
    ✦ Immaturity
    ✦ Process
    ✦ Focus
    ✦ Determination
    ✦ Tunnel vision
    @sarahmei
    22
    ...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 Slide

  23. 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
    23
    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 all do a decent amount of switching between them without even realizing it.
    We contain multitudes.

    View Slide

  24. Closed Mode Open Mode
    ✦ Creativity
    ✦ Ideas
    ✦ Disruption
    ✦ Immaturity
    ✦ Process
    ✦ Focus
    ✦ Determination
    ✦ Tunnel vision
    @sarahmei
    24
    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 should be enabling
    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?" My piece of paper that I got when I graduated from college says...

    View Slide

  25. http://www.flickr.com/photos/horiavarlan/4273968004
    25
    Computer “Science” on it. My brother, who’s a pharmacist, thinks of what I do...

    View Slide

  26. http://www.flickr.com/photos/ccpixel/4913826800
    26
    ....as typing. :p

    View Slide

  27. http://www.flickr.com/photos/fotosmanuela/8038512015
    27
    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. As a consumer of art, all I see 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.
    Turns out that is a common, and romantic, but completely wrong conception of how art is
    made.

    View Slide

  28. 28
    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.
    This happens over the course of several months. Every day, 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 Slide

  29. http://www.flickr.com/photos/ueharashogo/37532418
    29
    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 Slide

  30. @sarahmei
    30
    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 Slide

  31. @sarahmei
    31
    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 Slide

  32. 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
    32
    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 Slide

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

    View Slide

  34. 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
    34
    so you add another line to the spec which goes red again,

    View Slide

  35. 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
    35
    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 thousands of options for what you could do with this code. You can
    leave it where it is. I mean, it’s working. The tests are green. 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 Slide

  36. Red-Green Refactor
    ✦ Talking syntax ✦ Talking factoring
    ✦ Entering code
    ✦ Leaning close
    ✦ Moving code
    ✦ Sitting back
    36
    First, the words we say change. 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 way we use the keyboard changes. We go from entering code, entering logic,
    putting in our eaches and injects, and instead, we’re moving code around, between files,
    between classes.
    Third, our physical presence 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 in these two modes is that we are thinking differently about
    the code.

    View Slide

  37. http://www.flickr.com/photos/amytakespictures/6077476547
    37
    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 Slide

  38. http://www.flickr.com/photos/lkbm/100494509
    38
    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, 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 Slide

  39. http://www.flickr.com/photos/morphicx/8409632077
    39
    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 Slide

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

    View Slide

  41. http://www.flickr.com/photos/romtomtom/4382603005
    41
    First they studied whether people who think they are lucky are, in fact, luckier than people
    who think they’re not. They gave the two groups a section of the newspaper and told them to
    count the number of photographs in that section and return to the researcher with that
    number.
    On the second page of the paper, there was a big half-page advertisement with no photos
    that said “STOP. THERE ARE 37 PHOTOS IN THIS SECTION. GO BACK TO THE RESEARCHER
    WITH THIS NUMBER.” And lucky people saw that significantly more often than unlucky people,
    saving themselves the tedium of paging through and counting.
    So having established that lucky and unlucky people do actually experience the world
    differently, scientists then tried to find differences between those two groups 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 Slide

  42. http://www.flickr.com/photos/creativelenna/4387546703
    42
    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. They do these little
    things - but the theory is that by deliberately exposing themselves to things that aren’t in
    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 that make them unusual, creative, and effective
    problem solvers.
    They’re setting themselves up for that lightning strike.
    So you can practice being creative and you can practice being lucky. And that...

    View Slide

  43. Closed Mode Open Mode
    ✦ Creativity
    ✦ Ideas
    ✦ Disruption
    ✦ Immaturity
    ✦ Process
    ✦ Focus
    ✦ Determination
    ✦ Tunnel vision
    @sarahmei
    43
    ...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. But red-green-refactor is not the only way
    that you can introduce creative space into your projects.

    View Slide

  44. @sarahmei
    44
    The development process we do at Pivotal has a lot in common with extreme programming.
    On a typical day, we pair up, we take whatever story is on the top of the backlog, whatever it
    is and we work on it. We do the red-green-refactor cycle, we finish it, we deliver it. And then,
    we pick up the next story at the top of the backlog and we start working on that. We call this
    the “story mill,” because we’re just churning through stories. And it feels amazing. It feels
    fantastic to get so much stuff done.
    Once a week, though, we do something different. We don’t do too many meetings - most
    days we actually spend 8 hours on the story mill. But once a week, we do a one-hour
    retrospective, which is meeting that is our chance to consider how our process is working,
    and how we'd like to change it.

    View Slide

  45. @sarahmei
    45
    I could not do this process without the 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 Slide

  46. Process, done right,
    enables us to be
    creative.
    @sarahmei
    46
    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 Slide

  47. ✦ Dig into your code
    ✦ Switch projects
    ✦ Work with people not like you
    At work
    @sarahmei
    47
    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.
    Second - 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.
    Third - 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.

    View Slide

  48. http://www.flickr.com/photos/chovy/2698182370
    48
    And finally - make sure you’re having fun. Because you cannot write good software without
    it. And that’s all I got. Thank you everybody.

    View Slide

  49. Thanks!
    Sarah Mei
    Pivotal Labs SF
    @sarahmei
    49
    Have a great evening and don’t forget to join me at the Pivotal Labs drink up tonight,
    7-10pm at Squatters.

    View Slide

  50. Most image credits are on the relevant slide. Others:
    • Slide 1: http://www.flickr.com/photos/chovy/2370517548
    • Slide 2, Ruby logo: copyright 2006, Yukihiro Matsumoto
    • Slide 2, Beer: http://www.flickr.com/photos/eklektikos/49390580
    • Slides 40 & 41: copyright 2012, Pivotal Labs
    • Slide 45: http://www.flickr.com/photos/peggyq/3555683011
    50

    View Slide