Taking a break from pair programming

About seven months ago I officially put out my shingle as a consulting pair-programmer. Since then I’ve logged around 250 hours of pair programming with at least 60 different programming partners. Most of that was paid sessions, but I also did one free Open-Source session per week. Until RubyTapas subscriptions started shooting up at the end of last year, pair programming was my primary source of income.

“Consulting pair programmer” isn’t exactly a crowded niche. I know of some other freelance programmers who do a lot of remote pairing, but I’ve yet to hear of anyone else making a living on short (2-hour) sessions with many different clients. I wasn’t at all sure what the response would be like when I started the experiment. I half expected that I’d get an initial burst of interest which would then tail off after a month or two.

In actuality, the response has yet to abate. I’ve had little trouble filling my available time with pairing appointments, and I’m still receiving a steady stream of new inquiries every week. All this from no PR other than some links on my blog and an occasional mention on Twitter or Ruby Rogues.

It’s been a remarkable experience. Getting to see the Ruby world from the perspective of many different programmers with a broad range of experience has been incredibly valuable. Especially as someone who tries to put a lot of educational material out, I can’t think of a better way to get an idea of where people are coming from, and what concepts they have the most trouble with.

It has also been exhausting. As anyone who with pair-programming experience knows, a productive pairing session can leave you much more drained than the equivalent amount of time spent solo coding. Pairing keeps the focus and energy high. Not to mention that when people are paying for my time, I have a strong imperative to be 100% “on” from beginning to end. Some days I did four sessions—that’s four different people, working on four different projects—in a row. Those were exhilarating days, but also some of the most tiring I’ve known in my career.

In late September I launched RubyTapas, my subscription screencast service. Since then it has grown by leaps and bounds. As of today it has well over 1000 subscribers. This has caused a shift in my priorities. I’m no longer a consultant with some products on the side. RubyTapas is my primary source of income, and hence it is now my focus.

The months of transition, during which RubyTapas wasn’t yet big enough to support us, but still required a great deal of time in order to turn out three videos a week, were difficult. Keeping up with enough pairing sessions to pay the bills;  spending many hours writing, recording, and editing videos; and oh yeah, also dealing with a new baby with only a tenuous grasp on the concept of “sleep”… let’s just say I didn’t get a lot of rest. We talk about technical debt; I feel like I’ve run up some stress debt which it’s now time to pay down.

Which is why I’ve decided to put my pairing services on hiatus for a while. I’m going to focus on making videos, finishing Confident Ruby, and on my rather full 2013 conference schedule. I’ll obviously be keeping my scheduled appointments, and those of you on my OSS pairing queue: don’t worry, I’ll keep going down the list. But I’m taking down my pairing contact form for now.

There’s a lot I could write about my experiences pairing with so many different developers. I’m not really sure where to start though, so I’d like to open the floor instead. What would you like to know? As they say on Reddit: AMA!

33 comments

  1. I wasn’t too sure about pair programming but some of the other folks in our local ruby group kept raving about it. I was a fan of Ruby Rouges and started following you(Avdi) on twitter and reading your books/tutorials. I took the plunge and purchased a small block of time to try out pair programming. Now I am complete fan of it, you helped accelerate and solidify my coding and project. It has helped me get over my previous tendency to use procedural programming and answered some of the questions that I never could seem to find in a book.

    I am bummed I didn’t get a bigger block of time now! When I work on a project alone and spend an hour hunting down a typo that would have been caught by a co-pilot/pair programmer.

  2. You have earned a well deserved break.
    Congratulations on the 1K subscribers. It demonstrates the value of what you are providing; bite-sized, easily digestible bits of Ruby goodness.

    Those videos in which you demonstrate your ‘thought process’ are very interesting. May I recommend the following topics to consider:
    More focus on testing (how do I approach a new project wrt writing tests?) and, perhaps, a bit more detail on the process of Refactoring.

    1. I’d definitely like to cover more on testing and refactoring. These are topics which require a little more thought in how I approach them, so having more time will definitely help.

  3. I concur with @4849bd13c34b59d4d58ceb8325ad9871:disqus about your thought processes, especially on testing. I’ve only recently gotten a good handle on TDD and my biggest hurdle was getting past the ‘how do i start’ phase of development. Your FFI stuff has been wonderful for that so far. Also, I’ve really enjoyed digging into the less obvious uses of the Ruby API’s. You’ve given me some invaluable ideas for accomplishing tasks in new ways, such as the recent Enumerable episodes. More of that please 🙂

  4. Seems a sensible move since pairing can be exhausting and leave you with little energy for anything else at the end of the day. Remember to update your About page which still has your pair programming services on offer.

    1. By a long shot, the single most common request was “help me with TDD”. I heard many variations on this:

      • “I’m teaching myself, and the tutorials didn’t really show me how to TDD a project from scratch”
      • “I’m on a team that doesn’t do TDD, so I’ve never really experienced it”
      • “Everyone says TDD is great but I just don’t see how to write the tests before my code”

      I’ve spent many hours walking people through the rhythm of TDD, helping them to write the next tiny test, watch it fail, then make it pass, then refactor. In most cases they’ve ended the session with a new appreciation of how at every point in the process there’s always a clear next step.

      Part of my approach to this has also been to show people how to TDD outside-in, which I find extremely helpful in choosing a place to start, as well as in understanding how the whole system fits together. With Rails projects, we start with a dead-simple integration test that begins to describe some system functionality. That forces us to define a route, then a controller, then an action, then a view, then some model logic…and eventually model logic forces us to write some Unit Tests to drive out the behavior we want. Once people see the thread leading from idea to test to implementation without any breaks, they are a lot closer to “getting it”.

    2. By a long shot, the single most common request was “help me with TDD”. I heard many variations on this:

      • “I’m teaching myself, and the tutorials didn’t really show me how to TDD a project from scratch”
      • “I’m on a team that doesn’t do TDD, so I’ve never really experienced it” * “Everyone says TDD is great but I just don’t see how to write the tests before my code”

      I’ve spent many hours walking people through the rhythm of TDD, helping them to write the next tiny test, watch it fail, then make it pass, then refactor. In most cases they’ve ended the session with a new appreciation of how at every point in the process there’s always a clear next step.
      Part of my approach to this has also been to show people how to TDD outside-in, which I find extremely helpful in choosing a place to start, as well as in understanding how the whole system fits together. With Rails projects, we start with a dead-simple integration test that begins to describe some system functionality. That forces us to define a route, then a controller, then an action, then a view, then some model logic…and eventually model logic forces us to write some Unit Tests to drive out the behavior we want. Once people see the thread leading from idea to test to implementation without any breaks, they are a lot closer to “getting it”.

  5. Avdi,
    what would be the top 5 common ruby idioms/patterns you see less experienced developers use or get stuck on?

    1. I think the most common problem I help people with is naming things. So often they’ll present me with some code they don’t feel good about, and I’ll ask them questions about it until some domain concept emerges that had been lying implicit in the logic but they hadn’t yet addressed by name. We’ll name it, make it into a method or a class, and they’ll say something like “wow, that helps me understand my own code better”.

      The thing that people ask for help with the most up-front is TDD. I’ve heard many, many versions of “I’d like to be doing TDD but I just don’t get it yet”.

      Another thing I often show developers how to do is to use blocks to their advantage. Many developers use language/framework-provided methods with blocks, but haven’t yet grokked how to simplify their own code by writing methods that yield.

      Sorry, only three…

    2. I think the most common problem I help people with is naming things. So often they’ll present me with some code they don’t feel good about, and I’ll ask them questions about it until some domain concept emerges that had been lying implicit in the logic but they hadn’t yet addressed by name. We’ll name it, make it into a method or a class, and they’ll say something like “wow, that helps me understand my own code better”.

      The thing that people ask for help with the most up-front is TDD. I’ve heard many, many versions of “I’d like to be doing TDD but I just don’t get it yet”.

      Another thing I often show developers how to do is to use blocks to their advantage. Many developers use language/framework-provided methods with blocks, but haven’t yet grokked how to simplify their own code by writing methods that yield.

      Sorry, only three…

  6. What issues have you seen most when pairing? Lack of knowledge? Lack of discipline? Do you mostly contribute expertise or encouragement?

    Also, what have you learned from the way different people approach problems? Do you think differently based on what you’ve learned?

    1. The biggest lack is usually context: there’s a lot of info out there, but it’s not always clear to people which bits are relevant to them, and how they all fit together.

      I don’t think I’ve changed how I think. But pairing with newer devs is always a good way to be reminded that certain things are non-obvious.

    2. The biggest lack is usually context: there’s a lot of info out there, but it’s not always clear to people which bits are relevant to them, and how they all fit together.

      I don’t think I’ve changed how I think. But pairing with newer devs is always a good way to be reminded that certain things are non-obvious.

  7. Avdi,

    What % of your partners generally picked the topic and codebase for the session vs you picking a concept and illustrating it with examples? Which did you find was more effective from an educational standpoint?

    1. I made a point of having people bring either a project or an idea to the table. For me there’s no contest: having something that YOU are interested and/or invested in is both more effective and more useful than working on some toy problem.

    2. I made a point of having people bring either a project or an idea to the table. For me there’s no contest: having something that YOU are interested and/or invested in is both more effective and more useful than working on some toy problem.

  8. I’m quite bummed I’d been working remotely from Mexico for so long I didn’t have a chance to pair with you. I’m really enjoying exploring the boundaries of Ruby and Rails and some insight into how tests will change as I transition objects out of PORO “Domain-logic” into persisted ActiveRecord objects is something that I’d love more discussion of.

    But if this gets more progress on Confident Ruby, I guess it’s worth the sacrifice. =)

    1. It’s not forever, just for a while. I had a fantastic pairing session today and I’m sure I’ll start missing that feeling eventually.

      But yes… I really need to get back to Confident Ruby 🙂

  9. Without having context starting on projects, were there any that were particularly intriguing to you when you got into them? Also, in the same vein, any tips for us “multi-project” contractors out there for being able to switch context rapidly?

    1. I think the projects that have been the most fun have actually been non-Rails ones. A recent example would be one that dealt with concurrently downloading large numbers of files full of METAR weather data.

      For context switching, in the (typical) case of a Rails app, I generally ask the client to show me the running app first, especially the parts we’ll be working on. I have them explain a little about what it does. Then we dive down outside-in, looking at the views, then the controllers, and finally the models. I’ve found this the fastest way of getting oriented; much faster than, for instance, reading the tests first.

      1. I am ready to be vetted 🙂 I have been doing ruby since 2008 professionally.

        You can find me @ http://rubylove.io. If you don’t have time to ‘pair to vet’ then you can certainly give me a task to do. You can also check out my code (at least for this profile) on github and gists. Lots of stuff there!

        I have been doing 3-4 sessions a week for a month now. I love it. Nothing better than helping the light go on, or getting someone through a hard task so they can be a hero at work the next day.

        Also, thanks for tapas and confident ruby. You have truly changed how I code.

  10. I would like to know what you did to manage your mental energy.. what you ate, how you took breaks, etc.

    You talk about being exhausted and 100% on, and I’m curious what you noticed about your mental state and your energy levels while doing the work.

Leave a Reply to Nathan Cancel reply

Your email address will not be published. Required fields are marked *