The End of Fun - Lone Star Ruby

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 ﬁnally 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 Slide

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 Slide

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 Slide

Sarah Mei
End
of Fun
The
4
When I was ﬁrst 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 Slide

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 Slide

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 Slide

@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. Speciﬁcally, 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 Slide

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 Slide

@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 Slide

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 Slide

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 Slide

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 Slide

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 Slide

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 ﬁrst it was amazing. Total freedom to set
technical direction and then change it, quickly, as needed, as the business ﬁgured 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 Slide

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 Slide

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 Slide

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 Slide

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 ﬁrm that backs small groups of twenty-
somethings garages, these are your headers...

View Slide

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 Slide

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 Slide

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 Slide

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 Slide

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 ﬂow from those
judgements. So let’s look at the science around at creativity for a moment.

View Slide

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 Slide

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 Slide

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 Slide

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 Slide

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 Slide

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 Slide

✦ 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 Slide

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

View Slide

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

View Slide

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 Slide

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 Slide

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 Slide

@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 Slide

@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 Slide

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 Slide

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 Slide

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 Slide

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 Slide

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 ﬁles, between classes.
We cut & paste. I'm giving us the beneﬁt 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 Slide

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 Slide

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 ﬁnally, 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 ﬂashes 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 Slide

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 Slide

46
... that examined what’s different about people who consider themselves “lucky,” and people
who consider themselves “unlucky.”

View Slide

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 ﬁgure 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 ﬁnd
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 Slide

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 Slide

✦ 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 Slide

@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, ﬁnish 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 Slide

@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 Slide

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 ﬁnancial
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 ﬁnally: 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

✦ 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 Slide

✦ 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 Slide

✦ 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 Slide

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 Slide

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

View Slide

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 Slide

The End of Fun - Lone Star Ruby

The End of Fun - Lone Star Ruby

sarahmei

More Decks by sarahmei

Other Decks in Technology

Featured

Transcript