00:00:16.380
Hey, hi! Thank you. Good afternoon! I'm Sarah Mei, and I'm so thrilled to finally be here. I've heard about this conference from other people for years, and it’s great to be here. The last time I was in Salt Lake City was in 1998.
00:00:27.300
Things have changed quite a bit in the last 15 years. When I was last here, there were no bars, only private clubs. There weren't any visible tattoo parlors, and there were only two coffee shops in the entire city, both of which were terrible. So, given this, I'm now expecting that the next time I visit, you guys will have medical marijuana clubs or something. It just seems like that's the direction you’re going in.
00:00:47.730
I also admit that I totally forgot to email Mike Moore the title and abstract of my talk. I want to apologize for that; it has been a rough year for me and my family. I’m really grateful to be here at all. I appreciate Mike and the other organizers for inviting me, and I'm especially thankful that all of you stuck around until the end to hear a talk when you had no idea what it was going to be about. So thank you!
00:01:41.970
What I actually want to talk about today is work, play, and code. I’m curious if any of you saw Bill Chapman’s talk this morning about different ways of thinking about your work. This talk is going to build on those ideas because, to me, the most important part of work is play. But before we dive into that, let me tell you a bit about who I am.
00:02:08.580
I typically don’t introduce myself during talks since I figure Google is your friend, but it is relevant to what we’re discussing. So, here I am, on all of the important parts of the internet—Twitter and GitHub. I am a Ruby developer at Pivotal Labs in San Francisco, and I’ve been there for about three years. I work with clients.
00:02:46.319
I am also the co-founder of RailsBridge, which is now a four-year-old organization focusing on making our communities more welcoming to newcomers. Our best-known program is probably the RailsBridge workshops for women, which have introduced several thousand women to Ruby and Rails all over the world.
00:03:04.319
As mentioned, my work at Pivotal involves working with clients, most of whom are organizations that are growing quickly, specifically those adding developers to their teams. I assist them in building their product as well as their team. I have discovered that building the product is by far the easier of the two tasks; growing an engineering team the right way is a really hard problem.
00:03:31.970
Even just being a developer on a rapidly growing team is a challenge. This talk stems from those experiences and some research I have done on my own. To get back to the original concept, I’m sure nobody in this room falls into this category, but by a show of hands, how many of you have fun writing Ruby code? Thank you! You're my people; I think I do too.
00:04:10.060
I love it! I love the language, and part of it is the language itself. As Matt said yesterday, Ruby is now 20 years old, which means it’s an adult in Japan. What he didn’t mention, perhaps because he's LDS and doesn’t indulge, is that 20 is also the legal drinking age in Japan. Now that you all have brewpubs, we can enjoy a beer!
00:04:56.170
However, what I love about Ruby, even more than the language, is the community surrounding it. As Matt said yesterday, Rubyists love events, conferences, and meetups; they enjoy talking to people. Finding a developer community where people want to communicate is quite unusual but also awesome. I’ve been in many different developer communities, but I've never encountered one as creative, fun, and social, with so many interests beyond code and intriguing projects to work on.
00:05:33.630
That said, many of us in this room face a problem, and that problem resembles success. Ruby has been astonishingly successful. The language has transitioned from what was essentially a fringe language to possibly a mainstream language in just a few years. Many elements that used to be small have now grown larger.
00:06:02.500
Symptom number one: over the last year, we've started seeing numerous conference talks, blog articles, and books addressing the question of what happens when your Rails app grows. We’re discussing Rails engines, components, software architecture, and object design. Even DHH, who despises over-design, is consulting with people about this because it’s an important question at this point in time.
00:06:37.670
In small code bases, these aspects don’t matter. Your object factoring doesn't matter if all your code can fit in your head, and this situation tells us that since many of us are experiencing these growing pains simultaneously, we are running into similar problems. Our previously small code bases have certainly expanded.
00:06:57.140
Symptom number two: who remembers when Twitter was just 12 people? That was a long time ago. They’re not the only ones; many companies that profited from a Ruby product have grown significantly. Many have gone public or been acquired.
00:07:22.660
As a result, we as developers are now working in larger teams. What used to be three developers in a co-working space is now 25 developers in their own office. The way we discuss issues in our community reflects this shift. Discussions around remote work, for example, have evolved as my small companies have scaled.
00:07:50.860
Finally, we have started seeing large companies enter our Ruby community, such as HP, IBM, and GE. They are beginning to hire numerous Ruby developers, leading to significant growth among Ruby professionals. I’ve heard the same tale from many different people in the last year. It often goes like this: I was a Ruby developer, and I joined a couple of friends to build this amazing product; it was fantastic!
00:08:25.290
We all sat together in the same space, we communicated, and it was wonderful. Then we were successful, hired more people, and kept expanding. The challenge becomes figuring out what to do when there are so many people. The methods that worked with a team of three don’t work with ten, and what was effective for ten does not scale to twenty-five.
00:09:04.520
When you start to formalize processes for a growing team, you often make what was once informal into something more structured. It can be daunting because we are all concerned about the potential of growth sucking the fun out of our programming experiences. Having worked for a large company in the past, I can assure you that this is a legitimate fear.
00:09:43.560
But the interesting thing about fear is that analyzing what we fear can reveal some of the assumptions we've made about ourselves as programmers. Recently, every three to five months, there seems to be an article that pops up on Hacker News discussing two sides of the developer world. You must choose between being an established company person or a startup company person.
00:10:44.230
Established company people are associated with process; they’re focused, determined, and know what they are building, while startup people are considered creative and disruptive. Meanwhile, the established folks may be viewed as having tunnel vision. These categories have various titles, but they often boil down to the same thing.
00:11:17.750
For example, Paul Graham, who founded Y Combinator in Silicon Valley, tends to categorize developers as old and young. Anyone who participated in the Wausau conference just a month ago might remember Michael Lopp's similar headings. Regardless of how it's framed, it becomes evident that an individual developer is usually placed into one of these categories at any given time, and you may oscillate between them.
00:11:53.000
The assumption is that these are distinct types of people, and some suggest that to create balance as a company scales, you need to hire both kinds of people and let them challenge each other. I want to inject some science into this conversation because these categorizations, all of those blog articles and books written by individuals summarizing their experiences, do not represent the entirety of our industry.
00:12:44.650
My father, who had a PhD in entomology, held a saying about anecdotes. What he meant was that a collection of experiences does not constitute science. Therefore, I want to look at some of the research that exists around the categorizations we apply to ourselves. Starting with creativity, there was notable work done in the 1970s about the characteristics of creative individuals.
00:13:14.560
Researchers formed two groups: individuals identified by their peers as very creative and those labeled as uncreative. They sought to find statistically significant differences between these groups. Oddly, they found that intelligence did not correlate with creativity; incredibly intelligent individuals were no more likely to be creative than average-ability individuals.
00:13:59.190
Additionally, age, gender, and race showed no relevance in the assessment. Ultimately, researchers discovered there were no innate differences between creative and non-creative people. Instead, they identified variations in behavior and habits that distinguished them, and I'll come back to these differences shortly.
00:14:40.720
At this point, let's clarify what we mean by creativity. While we all possess an innate understanding of its concept, science has sought to define it. Scientists distinguish between two cognitive modes that humans engage in: the closed mode and the open mode. In closed mode, we complete specific tasks; it’s more about execution.
00:15:13.730
Conversely, in open mode, you may have general goals but lack strict focus, allowing for new connections. It's in open mode that creative thoughts can arise. The first aspect of being a creative person involves recognizing how to transition between these two modes intentionally.
00:15:56.070
These lists of categorized traits appear uncannily familiar, don’t they? They resemble the classifications applied in our developer community. Am I a big company person, task-oriented, stable, or am I small company, unfocused—figuring out product-market fit?
00:16:19.580
The assumption is that these represent different types of people, while they actually denote different modes of thinking. It’s a critical error to label any individual as strictly one or the other, as we are all capable of both at different times.
00:16:55.420
April is National Poetry Month, and this serves as a reminder for me to breathe. Realizing that all of us embody both modes can take a while to comprehend. A person may naturally feel more comfortable in one cognitive mode over the other, but we all possess the potential to tap into both. Creativity, therefore, is not a trait you possess or lack. It’s a skill you can cultivate and improve upon.
00:17:51.430
When people say that you need a mix of both to balance growth and stability, that assertion rings true. Each of us must be able to operate in both modes. A technical leader should not try to hire individuals based on those archetypes to create strife. Instead, the goal should be to empower your team to function in both modes at the appropriate times.
00:18:37.990
At this point, it’s worth exploring what this means for software development. What does creativity actually look like in software development? Many people believe that upon graduating from school, you receive a diploma declaring you’re a computer scientist, and those in other professions, such as pharmacy, liken programming to mere typing.
00:19:25.080
What do coding and programming have to do with art, poetry, music, humor, and dance? Those things seem inherently creative, while programming sometimes does not. I've never been a professional artist, but I realized that I perceive art as its outcome, examining the final products rather than the creative process.
00:20:02.410
For a long time, my understanding was that an artist would retreat to a cave, labor away, and emerge with a masterpiece. This idea is fundamentally incorrect. For instance, consider Twyla Tharp, an American dancer and choreographer. At 71 years old, she remains a powerful presence in contemporary dance.
00:20:55.400
She authored a fantastic book called 'The Creative Habit,' which outlines her creative process for developing a new dance. Over several months, each morning she practices standard routines and moves honed over 40 years. This rehearsal engages her body in familiar actions that require little thought. She is effectively executing.
00:21:41.240
In the afternoon, she focuses on creating new movements, while the morning practice becomes raw material for the innovations she develops later. She deliberately transitions between closed mode in the morning and open mode in the afternoon. Both are critical to her creative process.
00:22:23.240
Her creativity isn’t some spontaneous burst of inspiration. Instead, it’s a structured habit that primes her for those moments of insight. This aligns with scientific findings that suggest creative individuals have cultivated habits to transition between closed and open thinking.
00:23:09.600
The key is movement between these cognitive modes, for each one nourishes the other. I want to relate this idea back to the coding process. I hope this pattern resonates with you. When coding, we often go through cycles of red, green, refactor. You write a failing test, write the code to make it pass, and then refactor.
00:23:55.350
In practice, it often looks more like a cycle of red, green, red, green, and so on. Eventually, you achieve a standalone portion of your feature and begin to refactor. Let me illustrate this using an example—imagine adding a method to a Rails model.
00:24:32.540
You have a model for a bus and need a method to determine how many iPads are in the passengers' bags. First, you write a model spec that fails, then you write a method, and when the model spec passes, you realize the story specifically asks for registered iPads and not just regular iPads.
00:25:11.040
You add a new line to the spec, which subsequently fails. Once you implement that in the model, everything passes green. Your code might not look great, but at least the tests are passing. At this point, you have multiple options on how to improve the code.
00:25:52.490
You could leave it as is; the tests are green. Alternatively, you could refactor it into a class or parts of it, or even rethink your entire domain model. You have a plethora of options, and this is where you enter the refactoring phase.
00:26:31.120
First, what’s fascinating about this is the vocabulary we use to discuss code transitions between these modes. If you're pairing, you might verbalize concerns about functionality when in red-green mode, saying, 'I think we're missing a condition here.' Yet when refactoring, the conversation shifts significantly.
00:27:11.140
Now we’re discussing broader aspects, such as where the code belongs: 'That method had a name that made sense, but now it feels like it’s doing too much. Should we split it, or perhaps move it to another class?' The way we utilize our keyboard also changes. While inputting code in the red-green phase, we're intent on typing.
00:27:56.150
Once we shift to the refactoring mode, we become more casual, taking our hands off the keyboard for a while and simply reflecting on the code. More fundamentally, the way we think about code differs between these two modes. In one approach, we’re focused on specifics; in the other, we’re considering larger context.
00:28:37.840
Just as Twyla Tharp structures her process to alternate between open and closed modes, the red-green-refactor methodology provides a structured way to flow between these modes while writing code. We have a habit that allows us to creatively explore every time we write code.
00:29:23.170
Aside from these processes, we must also ask how we proceed when we enter the open mode where all is possible. How do we ensure that creative lightning strikes? Often, it requires a shift in context and considering the code within a larger framework.
00:30:09.720
This context shift is the germ of creativity, regardless of the creative endeavor—be it painting or comedy. All creative works harness the power of presenting the viewer with newfound context that they may not have recognized before.
00:30:56.560
For instance, how many folk singers does it take to change a light bulb? '51: one to change it and 50 to sing about how much better the old one was.' Humor often works because of the setup and punchline's contrast. Emerging from this lighthearted thought, I conclude that switching context is critical for creative insight.
00:31:37.890
Thank you, everybody!
