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...
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.
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...
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.
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.
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.
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.
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.
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.
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.
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:
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:
✦ 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:
✦ 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.
✦ 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.
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.
✦ 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?
✦ 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?
✦ 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...
✦ 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.
(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.
✦ 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...
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.
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.
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.
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:
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,
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 ...
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,
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.
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.
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.
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.
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...
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.
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...
✦ 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.
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.
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.
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:
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.
sarahmei
kazuya_araki_tokyo
cybozuinsideout
tomorrowkey
inductor
lycorptech_jp
yuyatakeyama
konifar
baseballyama
yasumuusan
ham0215
ks91
nakasho
keithpitt
zakiyama
jonrohan
maltzj
tammyeverts
kneath
andyhume
denniskardys
aki_iinuma
aleyda
speakerdeck
lauravandoore
