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:

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:

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!

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

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.

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.

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

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.

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

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.

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.

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.

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.

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.

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.

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

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:

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

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.

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.

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:

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

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

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.

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?

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?

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

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.

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.

✦ 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"?

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

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

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.

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.

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.

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

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

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,

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

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,

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.

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.

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.

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.

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

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.”

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.

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

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

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

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

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:

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

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

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

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.”

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

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

The End of Fun - Lone Star Ruby

The End of Fun - Lone Star Ruby

More Decks by sarahmei

Other Decks in Technology

Featured

Transcript