The End of Fun

LoneStarRuby Conf 2013

The End of Fun

by Sarah Mei

In the talk titled "The End of Fun," Sarah Mei addresses the evolution of the Ruby programming community and its growing pains as it transitions from a small, playful environment to a more serious, structured one. As Ruby turns 20, Mei juxtaposes the growth of the community with the need to maintain creativity and playfulness in software development. She highlights the importance of balancing organization and creativity to produce better software, stressing that too much structure can stifle innovation.

Key points discussed in the video include:

- Growth of Ruby and Its Community: Ruby has evolved from a niche language to a mainstream option, leading to larger teams and organizations adopting it, often resulting in more complexity and less spontaneity in project development.

- Challenges of Team Expansion: As small teams grow, the shift from individual decision-making to committee structures can lead to chaos and diluted creativity, negatively impacting the software development process.

- Creativity and Chaos: Mei argues that a certain degree of chaos is essential for creativity in software development. Rigorous processes aimed at reducing chaos can inadvertently hinder innovative thinking.

- Open and Closed Thought Modes: Drawing parallels with creative processes in other fields, she describes how software development involves toggling between narrow, focused tasks and broader exploratory thinking.

- Luck as a Skill: Mei discusses how individuals who consider themselves lucky often seek novelty and maintain an open mindset, leading to better problem-solving capabilities.

- Maintaining Fun in Development: She emphasizes the necessity of preserving joy in coding by incorporating varied experiences and interactions with diverse teams to foster creativity.

- Conclusion: The ultimate takeaway is that as the Ruby community and other organizations grow, it is crucial to not lose the essence of fun and creativity that leads to remarkable software.

Sarah Mei encourages developers to consciously create environments that facilitate inspiration, ensuring that the exhilarating aspects of programming remain integral even in the face of growth and increased structure.

00:00:20.880 Good morning! I am really thrilled to be here in Austin. I've never attended a LoneStarRuby conference before, but I've heard about it for years.

00:00:27.439 I'm really grateful to Lance Nola and Stove for pushing me to get here. I sometimes face challenges with things like returning emails and organizational tasks, which are not my forte.

00:00:32.719 I really appreciate Lance for encouraging me to come. The last time I was in Austin was during RailsConf back in April. The weather is quite different this time of year; I'm from San Francisco, so this feels like a normal July morning for me.

00:00:50.480 Yesterday, with the temperature hitting 93 degrees, I started to question whether coming to Austin in July was a terrible idea. But then I discovered this amazing drink.

00:01:02.800 This is from the Spoetzl Brewery in Shiner, Texas. It's their seasonal summer beer, made with grapefruit and ginger. Now that I’ve found this, I may never leave!

00:01:19.600 When I was practicing this talk for some of my coworkers a couple of months ago, one of them turned to me and said, 'You know Sarah, you are not wearing enough eyeliner to pull off that title.'

00:01:30.400 I was surprised and asked him why. He said, 'That title is too dramatic! This is supposed to be a fun talk, so you shouldn't scare people with such a title!'

00:01:42.159 I was expecting something dreary, like dark lipstick, gargoyles, and fear-and-loathing references. So, I thought about it for a while and realized I don’t usually wear eyeliner.

00:01:54.079 Instead, I decided to give my talk a title that truly reflects what it is about: work, play, and code. Less eyeliner for me but a more accurate description of my content for you.

00:02:10.560 So, I’m going to talk about how we think about how we work. But before diving into it, let me share a bit about who I am. This is me on all the important parts of the internet: basically just Twitter and GitHub.

00:02:21.599 I'm a Ruby developer based in San Francisco. For the last three years, I've worked at Pivotal Labs, assisting clients with their Rails projects.

00:02:32.879 Additionally, I am the co-founder of RailsBridge, which is now four years old. We strive to make our communities more welcoming to newcomers.

00:02:45.120 We’ve hosted hundreds of events worldwide and introduced thousands of people to Ruby and Rails.

00:02:50.239 In fact, we just held an event on Friday here in Austin, which was super fun. My work at Pivotal involved collaborating with clients, especially those growing rapidly.

00:03:01.599 These organizations grew primarily by adding developers to their teams. My role was to help them build both a product and a cohesive team.

00:03:13.120 Through this experience, I've found that building the product is much easier than growing an engineering team the right way.

00:03:24.800 Even being a developer on a rapidly expanding team can be quite challenging. This thinking comes from those experiences and some personal research.

00:03:30.560 To get started, I’m sure no one in this room has come to a Ruby conference on a Saturday falls into this category, but who here has fun writing Ruby code?

00:03:43.120 Okay, just checking! I do talk occasionally at non-Ruby conferences, and you'd be surprised at the responses I get.

00:03:49.280 So, I love Ruby! It’s such a beautiful language. A few months ago, Ruby turned 20 years old. At the Nautilus Ruby Conference, Matt said that 20 is the legal age of adulthood in Japan.

00:03:56.000 So, that means Ruby is now a grown-up! What he didn’t mention is that 20 is also the legal drinking age in Japan. As far as I’m concerned, the most significant aspect of this milestone is that Ruby is now old enough to enjoy a beer.

00:04:12.879 Although, to be clear, it can't have any of mine! What I love most about being a Ruby developer, perhaps even more than the language itself, is the community.

00:04:23.840 Matt has talked about this in various talks over the past year. Rubyists really love events, and we love interacting with each other.

00:04:31.040 That’s something unusual in a technical community! Personally, I just love hanging out with all of you. I've never been part of a developer community that's been as creative and social.

00:04:43.759 Many of us here have a problem, and it looks something like this: although Ruby has become incredibly successful, evolving from a fringe language to almost a mainstream language.

00:04:55.199 As a result, many of the things that were once small have grown larger. One symptom of this growth is that in the past year, we have started to see conference talks, blog articles, and even books discussing what happens when your Rails app grows up.

00:05:15.199 We are talking about Rails engines, software architecture, services, and object design. Even DHH, who typically dislikes what he calls 'over-design,' is engaging in this conversation because it’s relevant to many of us right now.

00:05:39.280 These topics may not have been necessary in a small codebase, but the increasing complexity is indicative of many of us experiencing the same growing pains at the same time.

00:05:50.880 Our codebases that began small have now expanded. Another symptom: does anyone in this room remember when Twitter had only 12 engineers?

00:06:03.759 Thank you, Josh! Okay, a few others remember—that was a long time ago! And Twitter isn’t the only company that has grown. Companies that made their money with Ruby products are now expanding, are going public, or being acquired.

00:06:16.720 As a result, we are finding ourselves working in larger teams within larger organizations. You can see this shift in the way we discuss topics like remote work.

00:06:35.759 Small companies are getting bigger!

00:06:39.680 The third symptom is that very large companies have begun adopting Ruby.

00:06:43.680 I have spoken to individuals from HP, IBM, and GE. These companies are introducing thousands of engineers to Ruby, which is quite remarkable. On a personal level, I've encountered countless people sharing similar stories.

00:07:03.120 Typically, these individuals start working for a smaller company creating a Ruby product. Initially, they experience total freedom to set technical direction and make changes as necessary.

00:07:20.960 As the business grows, they can keep the entire codebase in their head, but as the product starts making money, they hire additional engineers.

00:07:32.160 What happens? Their single decision-making power shifts to a committee—first of two, then three. Eventually, as the product gains traction and more engineers are hired, the team continues to expand.

00:07:45.120 They start experiencing so much chaos within the company that the need to split teams arises, leading to an attempt to reduce the complexity of managing relationships between teams.

00:08:02.160 They experiment with adding processes to diminish chaos, but every addition seems to irritate their colleagues and push away rather than improve the situation.

00:08:16.000 Some even hire managers who don’t code to oversee their teams, and the outcomes are often not positive.

00:08:22.639 Many are afraid they can see the inevitable outcome approaching: a workplace where excessive processes lead to a week-long timeline to make a decision that used to take ten minutes.

00:08:40.960 The once pleasant environment of experimentation and spontaneity could quickly be replaced by structured research and endless meetings.

00:08:55.440 If not managed thoughtfully, the growth of an organization can stifle creativity and inventiveness in developers’ jobs, which in turn diminishes the quality of solutions produced.

00:09:06.720 Organizations pursue this structure for a reason; after all, creativity and inventiveness are inherently chaotic.

00:09:14.240 As a team expands, development processes are often added in response to chaos; for instance, when someone accidentally drops the production database, a process is implemented for accessing it.

00:09:27.919 However, it is vital to be cautious, as software development requires a certain amount of chaos. We are tackling difficult problems that are significant to our society, which poses the need for creative thought.

00:09:41.120 Unfortunately, much of the guidance provided by business schools regarding the growth of engineering teams often leads down the path of suppressing chaos in all its forms.

00:09:53.479 So, the question I’m interested in is: for organizations that are still small, how do we prevent ourselves from becoming overly structured? And for those that are already growing, how do we as individual developers maintain the fun and creativity in our jobs as the organizations expand around us?

00:10:04.800 As a community, we actually have these conversations often—albeit implicitly—when we discuss various topics. One conversation that arises frequently involves dichotomies in developer roles.

00:10:18.000 There are typically two groups: the established company people who prefer a structured process and know what they are building, and startup individuals who are more creative, appreciate disruption, but sometimes face accusations of immaturity.

00:10:32.800 Different headers can frame these discussions depending on who is speaking; for instance, Paul Graham—founder of Y Combinator—commonly presents this dichotomy.

00:10:44.000 However, regardless of the framing, it's evident that these categories often suggest an individual developer naturally fits into one group or the other. Some will even go so far as to claim that both types need to coexist within an organization to strike a balance between stability and growth.

00:10:57.440 But right now, I'd like to introduce a perspective we've not fully explored yet: science.

00:11:07.440 Many blog posts reflect one person generalizing from their own experiences, which can be helpful.However, this leads to an important reminder from my father, who held a PhD in chemistry: 'A collection of anecdotes does not equal conclusive data.'

00:11:15.599 Let’s delve into some data. Let's start with creativity. Typically, the narrative suggests that the stable side is uncreative, while the volatile side is deemed fun and creative.

00:11:28.000 Insights and judgments from these perspectives flow from this generalization. In the 1970s, scientists conducted fascinating research on the characteristics of creative individuals.

00:11:35.840 They divided participants into two groups: those identified by their peers as creative and those labeled uncreative. They sought statistically significant differences between these groups.

00:11:49.280 Surprisingly, they found several traits that had no correlation with creativity: intelligence—people with high IQs were not more likely to be creative than those with average IQs; age—older individuals were no more likely to be creative than younger ones; and gender—men were not more creative than women.

00:12:03.200 They discovered no statistically significant innate differences between creative and uncreative individuals, but they did uncover differences in behavioral habits.

00:12:15.200 Let’s return to those behavioral differences later, but first, let’s define creativity. We all have an intuition about what creativity entails, but scientists have studied it too.

00:12:28.560 Psychological literature distinguishes between two thought modes: closed mode and open mode. In closed mode, you accomplish specific, focused tasks, often called being executive.

00:12:40.320 Conversely, in open mode, while your goals may be broader, your approach lacks specificity. In this mode, you remain open to new ideas and possibilities, which enables creativity.

00:12:55.200 To be a creative person, you must consciously navigate between these modes. At this point, you might recognize that these categorizations seem familiar.

00:13:06.160 They echo the categories we often use in our community to describe our roles. Am I a big company person or a small company person? Am I stable or volatile?

00:13:21.279 It turns out that those who attempt to pigeonhole us into these categories have tapped into a genuine dichotomy of human thought. However, it is important not to confuse distinct categories of individuals with modes of thought.

00:13:34.880 The critical error arises when labeling a person as either one or the other. Each person may feel more comfortable in one mode of thought or another, but we all have the capacity for both.

00:13:47.680 We engage in both modes more than we realize, and it is valid to assert that we need both modes in software development. As developers, we should strive to be able to operate in both modes effectively.

00:14:00.640 However, a technical leader should not simply hire archetypes to maintain a tension between them; instead, their goal should be to empower their team members to switch between modes where appropriate.

00:14:09.120 At this point, it remains reasonable to query what creativity has to do with software development. After all, isn’t what we do essentially computer science?

00:14:23.040 That’s what my degree states—my brother, who is a pharmacist, primarily views what I do as typing. Is it fair to compare our work to other creative endeavors such as art, poetry, music, and dance?

00:14:38.559 In my experience, I have never been a professional artist, but I do appreciate art as a consumer. For a long time, I believed that artistic work resulted from an artist separately creating a masterpiece.

00:14:56.399 However, this notion is fundamentally flawed. Consider Twyla Tharp, an American dancer and choreographer who, at 71 years old, remains a significant creative force in contemporary dance.

00:15:04.000 She wrote a compelling book titled 'The Creative Habit,' which explains her creative process when developing new dances. This method unfolds over several months.

00:15:17.680 Each morning, she practices her standard routines for several hours, moving her body in familiar ways she has done for 30 or 40 years.

00:15:30.640 Afterward, in the afternoon, she explores new movements that are built off those morning routines, using them as raw material to craft something innovative.

00:15:50.000 Her process methodically transitions between closed mode in the morning and open mode in the afternoon. She requires both states to conceive a new dance.

00:16:06.560 If she solely practices the old movements, she risks stifling creativity. Alternatively, if she only plays around with new ideas, she depletes the foundational basis for genuine innovative changes.

00:16:16.640 Her creativity is not the result of sporadic life-changing inspirations. Instead, it is a consistent and methodical approach that prepares her for moments of inspiration.

00:16:31.279 Creative individuals have established habits that facilitate their transition between closed and open thought modes.

00:16:37.840 This movement is key because each thought mode nurtures the other. Let's consider how this relates to writing code.

00:16:44.160 Hopefully, this will feel familiar. Generally, you start by writing a failing test. Next, you write the code that makes it pass, followed by a refactoring phase to improve the code.

00:16:53.600 In practice, this typically expresses itself as alternating between passing and failing tests—a red-green cycle, developing portions of your feature, then refactoring.

00:17:03.600 For a concrete example, imagine adding a method to a Rails model representing a bus. You need a method to indicate how many iPads the bus holds.

00:17:18.640 You begin by writing a model spec that fails, then implement the method that allows it to pass. After achieving green, you may realize that the requirements actually ask for registered iPads.

00:17:29.920 So, you add new specs, causing your tests to fail again. Subsequently, you develop the implementation, resulting in everything passing.

00:17:44.640 Now, you take a moment to reflect and realize this type of logic may not belong in the model after all. At this moment, you have countless options for your subsequent actions.

00:17:59.680 You could leave it alone since it’s working, or you could extract parts into a new class, reconsider aspects of your domain model, or even rewrite the entire component in Elixir.

00:18:11.680 At this stage, you've transitioned into the refactoring phase. Now, let's contrast what's distinct about the two phases of this cycle.

00:18:25.119 First, our spoken language alters. If you're pairing, it reflects in what is said aloud, but if you're programming solo, it manifests as your inner dialogue.

00:18:35.920 Initially, discussions revolve around specifics of functionality, such as addressing a missing end or indicating that a context may be unnecessary.

00:18:49.600 As you shift to refactoring, the conversation broadens to more significant concerns, like the appropriateness of a method's name.

00:19:05.760 Next, the keys pressed on the keyboard change; you initially focus on logic and functionality before moving to code restructuring,

00:19:18.080 and finally, the physical posture shifts. When in the red-green phase, you hover closely over the keyboard, immersed in the code. But during refactoring, you lean back—a more reflective approach.

00:19:33.919 Ultimately, in these two modes, you are engaging with the code in distinct ways.

00:19:42.720 During red-green, you operate in closed mode, focusing on achieving results. In contrast, refactoring places you in open mode, allowing for exploration.

00:19:59.200 Similar to Twyla Tharp's process, red-green-refactor serves as a structured method for constructing thoughtful transitions between closed and open modes in coding.

00:20:06.080 Every time we write code, it recognizes the importance of fostering creative thought. Now, another piece of the puzzle remains unaddressed: within the open mode, how do we proceed?

00:20:22.720 Once you have created a space for creativity, how can you ensure those illuminating insights come forth? It often requires context shifts, allowing you to view your code in broader terms.

00:20:36.240 This shift prompts creativity; whatever the medium—painting, comedy, poetry—the power lies in uncovering contexts previously unseen.

00:20:49.520 Consider humor as an example. Who doesn't enjoy a good light bulb joke? How many folk singers it takes to change a light bulb? The answer is five: one to change it and four to sing about how much better the old one was!

00:21:05.440 How many anarchists does it take to change a light bulb? None, because everyone knows they never change anything. And lastly, how many enterprise developers does it take to change a light bulb? The answer: we are not changing it; we believe it works!

00:21:17.679 Notice that the humor derives from the context shift between the setup and punchline. Once you enter a creative space, the first step is acknowledging the importance of being able to switch contexts.

00:21:32.800 Different developers possess varying levels of aptitude for this kind of creative thinking. Over the last three years, I have pair-programmed with around 150 different individuals.

00:21:45.840 Some developers consistently find solid solutions to challenges we face when we refactor, almost as if by sheer luck. In reality, they are often referencing code patterns from entirely different parts of the project.

00:22:00.640 This led me to discover some intriguing research about the differences between those who view themselves as lucky and those who perceive themselves as unlucky.

00:22:13.440 Initially, researchers assessed whether those who consider themselves lucky are, in fact, luckier. They conducted an experiment where they asked participants to count photographs in a newspaper section.

00:22:22.720 On the second page, there was an advertisement containing no pictures, but with large text stating there were 16 pictures in that section. They found that self-identified lucky individuals were more likely to see it.

00:22:38.560 Establishing a distinction between these two groups, they went on to find differences in behavior rather than intrinsic traits. Similar to creativity, luck can be viewed as a skill that can be refined.

00:22:56.720 Ultimately, fortunate individuals tend to deliberately seek novelty in various aspects of their lives. Given two paths, they choose the one less traveled or opt for unfamiliar dishes on a menu.

00:23:05.920 These small actions accumulate over time, leading to an open mindset, allowing them to recognize connections they may otherwise overlook.

00:23:19.760 Consequently, they become more skilled at identifying context shifts which enhances their creativity and equips them with unique problem-solving abilities.

00:23:27.440 This practice sets them up for those illuminating moments of inspiration! We want to enjoy the richness and diversity of thought.

00:23:38.080 You may wonder how red-green-refactor will help me achieve all of this. It's important to recognize that additional methods can introduce creative space into your projects.

00:23:51.760 My past experiences at Pivotal Labs, where I worked for three years, reveal parallels with extreme programming practices. On any given day, developers pair up and take the top story from the backlog to work on.

00:24:08.080 They engage in the standard refactor cycle and churn through many stories in a manner that feels rewarding. However, once a week, we conduct a one-hour retrospective to assess our process.

00:24:20.640 This meeting serves as an opportunity to evaluate the efficacy of our process and discuss potential changes at a meta level.

00:24:35.760 I couldn't maintain this structure for three years without those retrospectives, as the story mill operates in a very closed mode. Retrospectives represent the open mode needed to balance the process.

00:24:56.960 It is essential to remember that no process fits identically for two different organizations, and the nuances often evade clarity while immersed in the day-to-day.

00:25:03.840 Thus, conducting retrospectives once a week provides a structured means of introducing creative thought into our process, just as the refactoring stage does for our coding.

00:25:12.480 Effective processes encourage creativity, just as creativity enables the development of exceptional software. Processes should instill the habits of creative individuals.

00:25:30.080 If your process fails to make this conducive, it may warrant a refactor in that direction.

00:25:39.680 If you're at a growing or already large company, and start needing to bolster structure in your development process, many approaches can be employed.

00:25:44.800 The best approach depends significantly on your company’s people, market, and financial structure. Yet the fundamental takeaway is ensuring any additional processes enable rather than suppress creativity.

00:26:03.840 Ensure what you introduce doesn’t squeeze the fun out of development. It’s that creativity and playfulness that empower us to craft remarkable software.

00:26:22.720 As developers, it's our responsibility to create an environment where those moments of inspiration can arise. This requires integrating enough diversity into your life to leverage the creative periods offered by your process.

00:26:37.040 You don’t need to pursue an art degree or anything extravagant; small changes can promote openness. For example, explore parts of your codebase beyond the immediate scope.

00:27:01.280 If you come across a method and don’t know its implementation, take the time to inspect it. Dig into areas of the code that you haven’t engaged with recently, filling your mind with the raw materials necessary for creative inclination.

00:27:16.479 Engage with people from outside your programming bubble. Spend lunchtime with sales colleagues or others to widen your perspective.

00:27:32.000 Likewise, strive to introduce variety into your daily routine. If possible, switch projects every few months or try diversifying your skillset, whether that means writing JavaScript if you're primarily back-end or optimizing SQL as a front-end developer.

00:27:43.680 The rule of thumb is that when you begin to feel comfortable, it’s a signal to shift directions.

00:27:58.080 Similar logic applies to your daily activities. Avoid sitting still at your keyboard for eight straight hours. Spend some time outside at lunch, take breaks, and walk around.

00:28:07.600 Incorporating variety into your day can enhance productivity when you sit back down to code.

00:28:15.360 Lastly, seek teams that comprise individuals who differ from you. Research has shown that when two problem-solving teams face a creative challenge, the one that appears less qualified on paper tends to outperform a seemingly superior team, provided they have diversity in their backgrounds.

00:28:34.720 The foundation behind this success links closely to creativity and luck. By consciously placing yourself in diverse teams, you encourage your brain to adapt to new interaction dynamics.

00:28:45.760 This adaptability fosters a more open mindset that will assist in generating imaginative solutions.

00:29:01.760 Finally, discover ways to maintain creativity and enjoyment in your profession; solving complex problems hinges upon it.

00:29:15.440 I recall a client, relatively new to the process, prioritizing an important story that needed to be completed by day’s end to present to his manager.

00:29:39.200 The task involved laying the groundwork for an API for a mobile application—something presented as critical to get right. So, a pair of developers commenced working on it for an hour.

00:29:56.960 Then, they stepped away to play ping pong. At that moment, the client came over, visibly disturbed, and expressed concern over whether they had enough time to complete the task.

00:30:09.520 I reassured him, stating, 'Yes, that is why they are playing ping pong.' Thank you very much!

LoneStarRuby Conf 2013