Ruby
The End of Fun
Summarized using AI
The End of Fun
by Sarah MeiIn 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!
Explore all talks recorded at LoneStarRuby Conf 2013
+21