00:00:00.160
Hello, I'm Avdi. I wanted to talk a little about my experiences with pair programming.
00:00:07.040
This talk is going to have a lot of hand-raising in it, kind of like a charismatic church service. So let's start off with a simple question: Have any of you ever done any pair programming?
00:00:21.199
All right, how many people have done pair programming? Great, that's a good number. And who hasn't done any pair programming? Not too many. So it's pretty good that quite a few of you have been exposed to it. That means you might not need to hear this talk.
00:00:39.120
But I'm going to keep talking anyway; maybe I'll find something valuable to share. So let me ask you this: Have you ever been new to Ruby or Rails and felt a little lost? You know, maybe you've read some books or watched some screencasts, and you have a lot of facts, but what you really lack is context. Have you ever felt this way?
00:00:56.399
Have you ever been a sole developer, perhaps the only person working on a project, or a remote developer? Maybe the rest of your team is in one place while you're off somewhere else, feeling a bit isolated? Here's another question: Have you ever used a new library or technique and realized partway through that you did it all wrong?
00:02:03.280
All right, here’s a tough one: Have you ever felt like other developers are just a little bit crazy? Have you ever found yourself staring at your screen, wondering what they were thinking? And have you ever gotten a bit cynical about the industry you’re in as a result of these moments?
00:02:21.200
I mean, we’ve all been there. I’ve been there. Have you ever wanted to do more for the community but didn’t feel inspired to blog? Or maybe you feel like you don’t have a lot of time to contribute hours to open source software—have you ever felt like this?
00:03:00.000
If you raised your hand to any of those questions, I have a suggestion for you: Pair programming. How many of you pair program regularly, like once a week or more? Quite a fair number of you; that’s pretty cool.
00:03:09.280
Now, when I say pair programming, I specifically mean to pair with people outside of your usual circles. I want to encourage you to pair more widely and more often, typically by pairing remotely. Today, I want to explain how to do that and, more importantly, why you should.
00:03:36.799
I’m not here to convince you why pair programming is a good idea—you’ve already experienced its value. But just to quickly highlight some reasons why pair programming is awesome: First of all, it's instant code review. There’s a great blog post by Steve Jackson about how he learned to love pair programming.
00:04:31.680
He recounts a time when he lost two and a half hours to a typo. We've all had that happen way too many times. Pair programming acts as a sanity check. Sandy Metz talks about rules and guidelines for coding, saying that you can break a rule if you can convince your pairing partner that it would produce better code.
00:05:05.680
Of course, if you don’t have a pairing partner, you don’t have anyone to convince. Having a pairing partner offers moral support; sometimes you’re just tired, or the code you’re working on is frustrating. Days like that are when having someone to work with can really lift your spirits.
00:05:33.360
You’ve probably heard the term rubber duck programming, where you explain your problem to a rubber duck on your desk until you find the solution. While that works, explaining it to an actual human being often gets results much quicker.
00:06:03.840
Pair programming is great for staying focused. Nobody wants to pair while also scrolling through Twitter. It provides a little less temptation to switch over to that Twitter window.
00:06:30.400
Around the middle of last year, I made a switch in my career. I stopped doing traditional software consulting and transitioned entirely to what I call being a consulting pair programmer. This means that developers would make appointments with me for pairing sessions, and I would work with them on their projects.
00:09:04.840
Up until this point, I’ve had over 60 pairing partners and spent more than 250 hours pairing with different individuals. Many of these sessions were paid, but I also tried to set aside time each week to do one free open-source pairing session. Those sessions were great fun, and I got to meet interesting folks along the way.
00:09:52.480
People came to me for various reasons. Some were newbies to Ruby or Rails looking for tutoring, while others were working on projects but faced specific challenges they wanted to work through or wanted me to review their solutions. Interestingly, the most common request was help with Test-Driven Development (TDD). Many developers expressed they didn't know how to implement TDD in a project from scratch.
00:10:40.240
Having observed many developers, I've realized there's still a significant testing gap in the Ruby community. Many developers aren't testing or doing TDD appropriately, often because they work for companies where it's not part of the culture or they've never had exposure to it. This gap can lead to embarrassment and a missed opportunity for learning.
00:11:52.560
In my sessions, I noticed that many developers are uncertain about writing tests to verify that their code solves expectations. I found it incredibly valuable for those in that position to pair with someone experienced in TDD. This can guide them through the red-green-refactor cycle.
00:12:04.080
Some mechanics shaped my pairing sessions. I want to clarify that I’m not an expert on remote pair programming; it’s still early in development. The practices I found effective may not work for everyone.
00:12:06.800
I ran all of my sessions for two hours, as this length allowed time for setup while ensuring we completed solid work without burning out. Pair programming is high-energy, and sessions too long can lead to fatigue.
00:12:23.280
I scheduled all sessions in advance. Having an assistant to help manage scheduling proved essential, as trying to coordinate meetings can be overwhelming. I preferred participants to bring their own projects—anything they were excited about. This method allows us to focus on something meaningful.
00:12:59.760
When I learned to play the guitar, I found it much easier to practice songs that I cared about rather than homework exercises. Ensuring participants brought projects they were invested in fostered engagement. Engaging with projects you find compelling makes learning enjoyable, making the process smoother.
00:13:38.240
Allow me to show you a dated picture of my workspace. I’ve now upgraded to an actual monitor, which is a significant step up. However, I want to emphasize some critical features from my setup that facilitated our sessions.
00:14:08.880
For example, having a good headset while pair programming is crucial, as it reduces echo and feedback. I recommend using a wireless headset to allow movement around while you work. Currently, I use a Corsair Vengeance 2000 headset, which is designed for extended wear.
00:14:32.639
I mounted my tablet beside my monitor, using it to run video calls with my pairing partner. This setup allows me to see each partner while coding. When I’m coding, I can simply glance at them, maintaining a natural interaction instead of the awkwardness of shared screens.
00:15:04.639
I also use Yugo for screen sharing, optimizing for remote sessions. I often pair with various developers each week, so I need compatibility across different setups. This is just one of many interesting tools for remote pair programming that have emerged recently.
00:15:31.559
When orienting to a new project, I recommend starting by showing the application live rather than just reading documentation or tests. Observing the application in action helps frame how components fit together and makes it easier to understand the code structure.
00:16:06.640
During these sessions, I take comprehensive notes to develop clear documentation for each pairing session. This practice benefited both my partners and me, allowing us to reference critical resources shared during our time together.
00:16:28.960
Typically, I used the navigator-driver pairing technique in my sessions, with partners at the keyboard sharing their screens. This method keeps participants engaged while not overwhelming them with new tools, allowing them to work in familiar environments.
00:17:43.520
I emphasize that the individual learning should be at the keyboard. Doing the typing allows them to internalize the details better and feel more engaged in the process.
00:18:07.360
However, let’s talk about why all of this matters. Pair programming isn't just beneficial for personal skills; it's essential for the health of the developer community as a whole. As we build networks of collaboration and mentoring, we enhance our skills and knowledge collectively.
00:18:53.440
For instance, if you're a newbie in Ruby or Rails, working with someone experienced can help you feel more connected in understanding frameworks. This experience enhances your learning and builds a network of support.
00:19:41.280
If you’re feeling isolated, pair programming offers validation for your design decisions and can help spot issues you’ve overlooked. That collaboration reignites your enthusiasm and can create lasting motivation, benefiting your long-term productivity.
00:20:31.160
Moreover, when dealing with new technologies, seeking out those with experience is incredibly beneficial. It offers a faster learning curve as they can guide you on how best to fit new tools into your existing projects.
00:21:16.480
Lastly, if you find yourself feeling cynical about programming, pairing can provide a fresh perspective. Helping someone else can restore your sense of purpose and remind you that all developers face challenges—striving for improvement together makes the journey worthwhile.
00:21:55.680
Thus, the next time you encounter someone online with different opinions, consider inviting them to pair with you. Through this talk, I want to inspire you to build upon the culture of pairing in our community.
00:22:28.640
Communities thrive with diversity, and we must foster an ecosystem of shared ideas. Through sharing our experiences, we prevent getting stuck in mental ruts. Enhancing our skill set and boosting our creativity relies heavily on collaboration.
00:23:16.640
I encourage you to reach beyond your immediate circle and embrace pairing on a wider scale. The tools exist, and they're improving; we just need to seek others wanting to pair. Ultimately, how can you find like-minded individuals who also want to collaborate?
00:23:59.840
Reflect on this for a moment; consider someone in the community who you would love to pair with. Think about how you could reach out to them.
00:24:08.640
If someone reached out to you with enthusiasm about your work, chances are you would consider agreeing to a pairing session. I challenge you to invite at least one person to join you in these collaborative sessions each month.
00:24:39.440
By offering a welcoming message through your social platforms or websites, you communicate an openness to connect. Doing this alleviates the hesitance many feel about asking someone to pair.
00:25:00.960
On my website, I’ve created a simple way for people to indicate they’re available to pair. I urge you to consider tagging your messages, perhaps with #PairWithMe on Twitter to draw more visibility to the idea of remote pairing.
00:25:57.440
The ultimate goal is to spread awareness that collaborating and sharing your experiences collectively contributes to a healthier community. Working together allows us to inspire and uplift each other.
00:26:07.920
Ultimately, we have the power collectively to enhance our craft and our community through collaborative efforts. If we embrace pairing widely and often, we can all become more engaged programmers, contributing meaningfully to an ever-evolving craft.
00:27:12.960
Thank you all for your time and for listening to my experiences. I hope you leave here inspired and motivated to start pairing widely with others!
