00:00:00.000
Oh yeah, I think we're gonna go ahead and get started. Thank you all for coming.
00:00:12.450
Welcome to RubyConf! I appreciate you all being here. So, my name is Megan Teal, and I'm a senior software engineer at CallRail.
00:00:18.720
I'm also one of the co-organizers of the Atlanta chapter of Rails Girls. You can find me on Twitter and GitHub as Megan Tu, and on most other internet platforms.
00:00:28.470
Today, I’ll be talking about finding beauty in the mundane. This phrase can mean a lot of different things, but for us as software developers, we can't love every part of our job. As much as we'd like to, some tasks are just less fun than others—they can be boring or tedious.
00:00:41.340
Regardless, we have to get these tasks done. So how can we love our jobs more? How can we find joy in those mundane parts of our work? I believe that in order to fully relish our work, we must understand our frustrations with these aggravating aspects of software development and shift our perspectives towards them.
00:00:57.329
One of the best shifts in perspective we can embrace is empathy. When we are constantly mindful of the people interacting with our code and our software, and what their needs are, we will build better systems for everyone. At the end of the day, all computer problems are essentially people problems. If we solve our technical issues with the same care and attention we give to human concerns, we will create better software and build stronger connections with our teams. When you love your team, you ultimately love your work.
00:01:39.540
It's crucial for us to address our feelings about the mundane aspects of development in order to combat technical debt. When you move quickly and create rapidly, you may not be doing your best work or using the best methods, and things can slip through the cracks. Like financial debt, technical debt tends to pile up when left unaddressed.
00:01:52.710
Most of us have it, but often we feel we don’t have time to manage it. How we cope with the reality of technical debt is a spectrum. On one end, there are those who are unfazed by it. You know it exists, but you don’t actively think about it. On the other end are those who feel it gnawing at them constantly, prompting thought about improvements. Unfortunately, I fall more on the latter end of the spectrum. I’ve had countless sleepless nights worried about untested code and classes that need restructuring, because I know we can all do better.
00:02:42.090
The truth is, many tasks in development aren’t flashy. Constantly churning out massive new features isn’t sustainable, and we face harsh realities when our applications start failing under the weight of technical debt. As developers, it's essential to acknowledge the value in addressing this debt.
00:03:01.859
In the book 'Apprenticeship Patterns,' David Hoover and Adewale Oshineye provide valuable guidance. They suggest identifying the most grungy task you’ve been putting off—the one that everyone complains about and no one wants to tackle. See if you can creatively solve this problem in a way that exceeds expectations and makes it enjoyable for you.
00:03:12.719
Ultimately, what we do is far more than just code, best practices, or prestige. It's about respect for our teammates—both current and future—and for our users. It's about respecting ourselves. When we learn to love our work, hopefully, it leads to happier teams that work better together. So, how can we change our perspective on these mundane tasks? I’ll cover five different things we could all improve upon, along with ways to enjoy these tasks more.
00:03:39.540
The first topic is updating dependencies, whether that be packages, gems, or libraries. All applications rely on others' code to function. But why do we often resist upgrading gems and other dependencies? Perhaps you have a complex Gemfile, or running ‘bundle update’ results in an avalanche of errors. It may seem overwhelming, and if your code is working, there’s a temptation to think, ‘Why change anything at all?’ This mentality is common.
00:04:12.659
For one, we achieve more secure applications through these upgrades. Our users desire security and outdated dependencies pose significant risks. Vulnerabilities could be lurking in old versions of gems that you're using, and you may not even be aware of them. On the other hand, updating patch versions is low-risk and usually leads to high rewards, as they only contain fixes. This means you can be confident that things won’t break with minor upgrades, giving you added stability.
00:04:54.960
Also, upgrading is a great chance to engage with the open-source community. While tracking down issues with new versions, you’re reading changelogs and seeing if support for a new Rails version will be added to the gems you rely on. This process gets easier over time, allowing you to contribute back when you're ready. Furthermore, upgrading gives you valuable debugging experience. When you dig through your system to identify breakages, you can do so in a safe environment. If a test fails, your users won’t see it until the problem is resolved, reducing the urgency and stress of the situation.
00:05:44.420
I often recommend that newer developers engage in this practice. They can gain invaluable debugging experience without the pressure of needing immediate fixes for production issues. Additionally, upgrading also allows us to use supported versions. You don’t want to discover a bug in a gem only to find that its version is no longer supported. You could end up forking it and maintaining the fork on your own, which is tedious. Staying up to date means help is usually available.
00:06:28.160
For instance, Rails 4.2 is only receiving severe security patches—no minor or moderate fixes. Given that Rails 5.1 is the only version currently receiving bug fixes, being out of date puts you in a precarious position where you’re not receiving timely updates or support.
00:06:54.620
I understand that for some, upgrading feels like pulling teeth. But I find it helpful to approach upgrading as if I'm playing a video game. Each gem that I successfully update feels like defeating a minor boss, progressing towards a larger goal. When I finally upgrade Rails itself, I view it as defeating the ultimate boss. The satisfaction of seeing all green text after a successful bundle update is incredibly rewarding. You learn so much in the process, feeling more connected to your system and the greater community.
00:07:40.000
Next, let’s talk about writing documentation. We all know we should have documentation, but often we lack sufficient resources. In this talk, I'm focusing on internal documentation for your code and systems—comments in your code, or a wiki. This documentation expresses how your company’s technology works to your colleagues. Why do we often avoid writing documentation?
00:08:16.420
Consider this scenario: you’ve just completed a big feature, it’s tested, and QA has approved it. But then, there’s no documentation. If another developer wants to join the project and work on this feature, they’re left reading code without a straightforward way to understand it. You wouldn’t want that to stall the feature release.
00:08:57.670
Transitioning from thinking in programming languages to human languages for documentation can be a challenge. I could easily give a full talk on writing effective documentation, but I’ll try to keep this brief. One of the many benefits of documentation is knowledge-sharing. Knowledge is power, especially in complicated systems requiring collaboration and understanding. Documentation also prevents knowledge silos; without adequate documentation, knowledge becomes concentrated in the minds of those who built the features.
00:09:59.650
With good documentation, anyone can understand how a feature works, which is empowering. Documentation simplifies onboarding for new developers. They can spend significantly less time searching for answers and can quickly locate the information they need to be productive. It supports team members throughout your organization too, helping them diagnose and resolve issues without always relying on a developer's input. Documentation empowers independence in a team.
00:10:41.060
I've found that if I insist everyone else knows the code better than I do, I run the risk of forgetting crucial details unless I document them. Writing documentation now will prevent future frustration when revisiting parts of the codebase. It serves as a tangible way to help those who interact with our code and systems.
00:11:23.450
Empathy drives documentation—it allows us to provide direction and purpose. By sharing knowledge through documentation, we empower others to feel like they own a piece of the code. If your organization lacks documentation, where can you start? I suggest creating a glossary of common terms—especially any domain-specific jargon at your company.
00:11:51.720
In our company, for instance, we work significantly with telephony. There’s a module in which users can purchase phone numbers from us; we call it the ‘New Number Modal’ (or NNM). A new employee wouldn't know right away what NNM means, so including that definition in our glossary makes it easier for them to understand.
00:12:20.540
Another helpful step is to include links in your glossary to the corresponding codebase sections where those terms are heavily used, like database models. In this way, you define the term in simple language, then connect it to the code. This helps bridge the knowledge gap, allowing newcomers to follow along in discussions and be productive faster.
00:12:57.720
It's also beneficial to comment your code as you write it. Many of us assume documentation means revisiting entire sections of code, which can feel daunting and time-consuming. However, if you write comments as you go, integrating documentation into your workflow becomes much easier. For example, if you're creating a new class, add a comment at the top describing its purpose and usage. It simplifies the process and makes documentation feel less burdensome.
00:13:38.580
There are tools, like Yard, that turn your code comments into navigable documentation—super helpful for new developers. When you have a specific place to guide new team members, they feel more at ease finding their way in the codebase. Our jobs revolve around solving complex problems, not deciphering tangled systems, so establishing these foundations can streamline the process significantly.
00:14:29.110
Additionally, new developers appreciate having tests readily available when exploring an application for the first time. Writing automated tests as part of software development ensures that we’re not passing it off onto QA and helps newcomers understand how parts of the system operate.
00:15:10.290
Diving into a codebase without tests can be nerve-wracking. You might wonder if changes will maintain existing functionality and have to just hope for the best, which is not ideal. While we all recognize the importance of writing tests in the Ruby community, a persistent mindset that deemphasizes their value exists. Some believe it's quicker to write code instead of testing it.
00:16:07.810
However, tests lead to more reliable software. They help pinpoint actual failure points during development, as you can only manually test so many pathways a user might take. Automated testing diminishes the time spent on repetitive validation, ensuring quicker feedback loops and greater confidence when deploying code.
00:16:59.570
Additionally, tests allow for peace of mind during refactoring. Following the red-green-refactoring approach, if you commence refactoring with a green test suite, any changes you make can be tested quickly to verify they didn't introduce problems. This approach safeguards against breaking existing functionality and ensures smoother transitions.
00:17:31.820
Throughout my development career, I’ve never felt a sense of accomplishment quite like the first time I got a group of tests to pass. It's incredibly rewarding because you know that your creation works as intended. This sense of assurance extends beyond just our code; it encompasses the broader responsibility we have to our users to deliver quality software.
00:18:03.330
Moreover, like chefs at fine dining restaurants, we don't create menu items on the fly or serve poorly tested dishes. We must meticulously verify our software before releasing it to users. Properly tested applications foster a calm work environment, allowing us to feel in tune with our applications.
00:18:36.940
Another way we can enhance our systems and foster happier developers is through linting. Linting is the automated process of reviewing each file line-by-line, ensuring your code adheres to a specified style and raising warnings when it doesn't.
00:19:04.590
I understand that some find linting tedious, as it often involves making small adjustments that can feel overwhelming at times. However, I see it as an opportunity for quick wins. If you address one file at a time, it can be incredibly rewarding.
00:19:48.620
For example, I have a colleague who, when starting a new task, checks out every file she will touch beforehand and lints them all first to start with a fresh workspace. In this way, she simultaneously improves the codebase while preparing for her task. Like when updating gems, breaking down tasks into manageable parts ends up being quite manageable.
00:20:47.100
Linting is a great learning opportunity, especially for those who are new to programming. Linters are built on community standards, making writing code with their help a chance to learn best practices. This ensures that your work aligns with commonly agreed-upon standards, resulting in a more cohesive codebase. It’s easier for other developers on your team to navigate a consistent codebase.
00:21:39.380
Establishing a style guide greatly helps in the linting process. If you and your team set clear guidelines for how you'd like your codebase to look, new code will naturally raise fewer linter errors because you’ve decided on a standard.
00:22:16.750
For fun, I like to liken this process to playing a game. You can envision yourself as a spaceship pilot in a classic arcade game, battling aliens as you resolve linter warnings. Every time you address an issue, you’re making your codebase better, and once you've triumphed, it feels like you’ve crushed all the enemies. It's a fulfilling experience.
00:22:58.290
Finally, let’s touch on refactoring, a topic that many developers dread. Refactoring has the goal of making your code more understandable, whether that means significant changes in structure or smaller syntax tweaks in one file.
00:23:33.220
The reality is that refactoring can feel impossible at times, especially when it involves complex legacy code distributed over numerous classes. But it's often a necessary effort, particularly when it makes our lives easier by clarifying how code operates.
00:24:17.660
Being able to make code more accessible helps everyone involved. Refactoring respects your teammates and the language. As Rubyists, we have a language optimized for human readability. By utilizing Ruby’s strengths, we can enhance the clarity of our code, creating elegant solutions that benefit everyone.
00:25:47.569
To summarize, the question we set out to answer was: how can we love our jobs more? We could steadily update gems, treat upgrades like video game boss battles, write documentation to enhance understanding, comment on our code during development, implement robust tests, and take time to refactor our solutions.
00:26:35.490
This change takes time; it isn’t just a quick fix. It’s about building better habits and fostering a culture of empathy that will lead to better development practices. When we recognize the needs of our teammates and users, we build better software—and become happier teams in the process.
00:27:14.860
I'm Megan Tu, and I work with CallRail. If you're in Atlanta or interested in joining us, please reach out! You can find me on Twitter, where I’ll be posting slides from today’s chat. Thank you for being part of this experience, and I'm happy to take questions off stage and in the hall. Please feel free to come say hi!
