I just finished my first #pairwithme session with @hinbody. It was my first remote session to use TMUX+VIM instead of ScreenHero – I have to say, it was quite easy to use and given the fact that it’s free, fast, and cross-platform, I’ll be using it with any vim users I pair with who are willing. I’d love to get CoVim working since it allows you to use your own vim setup. I drool a little bit at all that. But I digress. ...
I paired with @thecommongeek last night again. This time we were more prepared and I think the session went much better. In our first session I misjudged where Dennis was as a coder and struggled a bit with how to pair with him effectively. This time we had him drive through ScreenHero and decided to start from the “basics” by doing the RubyKoans. The RubyKoans are meant for Ruby 1.8.7, but 1.9.3 is commonplace now, so we struggled a bit at the beginning. For anyone going through the RubyKoans on 1.9.3 getting a value19 in nearly all your errors, I’d suggest making the following changes on neo.rb (starting on line 34): ...
I had my first international pairing session with @javichitone tonight. He’s from Peru and will soon be graduating. He should have no trouble finding a job based on the code I got to read of his :) We talked for a bit and settled into looking at a gem he recently published. Since it was his gem, I elected to drive. I’m familiar enough with gems that I’m comfortable in general, but he knew the specifics of his gem, so to get the most out of it, he needed to be commenting on the specifics he knew and I needed to be diving into figuring out those specifics. ...
Another great pairing session tonight with @jdar! I continue to be amazed at how pleasant and personable the developers I meet are. The internet is a wonderful place. First up, I’d never coded a Chrome Extension, so Darius took the reigns and started walking through what we were using. The biggest takeaway I got was to put your pride away when you’re pairing. Everyone’s exploring, we’re all trying to get to the next answer, so it doesn’t matter if we’re really well prepared or never coded before… just take the next step. ...
Last night I did a #pairwithme session with Karl Meisterheim. He’s an experienced developer who currently work part time and was looking to improve his skills. Besides having a good deal in common and really enjoying our conversation, I also learned a bit more about remote pairing and came away with a couple of observations. First off, we paired 2 nights in a row for about an hour each night. Both sessions we tried to solve the same problem: TicTacToe. We started off on the second night with the code from the first night, but quickly threw it away and decided to “start over” as an excercise. Doing this taught me the most significant lessons from our session. ...
When I heard about the #pairwithme idea, I thought it was something I really wanted to do. I set aside 3 nights a week from 9-10pm and started pinging people on Twitter during that time, asking if they wanted to pair. I tried for no less than 3 weeks before actually getting a real pairing session going. I had several cancellations and a bunch of fits and starts trying to figure out how to really communicate with people. Here’s my takeaways from the experience of coordinating sessions remotely. ...
I had a great pairing session with @thecommongeek tonight. It was my first live-remote pair programming and I wanted to to a little “post mortem” on it to record my thoughts. We spent some time on introductions and then jumped into a problem. Since my box was all set up, I typed. I’m more experienced than Dennis as a coder, so I viewed it as the potential to mentor him a bit. I also learned from him both in the “how to be a better mentor” department and the “how to pair better” department. ...
I often have a bit of time that I could spend on other tasks, but couldn’t set up a true share-and-pair session due to logistics and communication issues. A friend of mine suggested that we “pair” over github. I took the idea to the next level by creating a true ping-pong pairing project where each commit is a ping or a pong. Here’s the basic setup: Create a README with the full description of the “task” at hand Create a github repo and add your ‘pair’ as a collaborator. Write a failing spec git commit and git push Then, each individual takes turns doing the following: ...
I’m interested in creating a culture of pairing… not just in my workplace, but in my life. I want to be able to pair with people in order to improve on the skills I alread have. This is seen clearly in the relatively new #pairwithme ‘micro-movement’ that is happening on twitter. It shows that people want to learn from each other and improve their craft. But it doesn’t have to apply solely to programming. Last weekend I “paired” with a neighbor to fix my lawnmower. He is a bit more mechanically inclined than I was, but it took both of our efforts and problem solving to diagnose and fix the problem. All in all, a worthwhile time where I improved both my relationship with Ben and my ability to cut my grass. He got something out of it too, he felt great and is excited to tackle more mechanical projects. This is exactly the same reasons we talk about the benefits pairing in the first place. ...
When pairing, especially remotely with someone you don’t work professionally with, it is sometimes helpful to have some ideas about how to go about getting the session going or what to do. This is just a set of ideas that might get the ball rolling. Problems to work on PuzzleNode - 15 shortish (30 minutes to 4 hour) problems. Great for pairing. Conway’s Game of Life - Can implement a basic version quickly. Lots of ideas for restrictions on this site. TDD Katas - Can be done in 30 minutes alone. Dominion - A larger problem, but it will tease out larger design issues that you don’t get with smaller systems. Build a Twitter - Simple system that can be extended. Adding a UI and continuing strict TDD is very interesting since you might be able to TDD the core system, but have more difficulty with the surrounding. Are there ways to mitigate the risks of using a framework as a shell? Are there ways to make the shell “swappable” – not so you’d actually swap, but so you have loose coupling? Ideas to practice Ping Pong - Pair back and forth, one writes a failing test, one makes it pass, then writes the next failing test, and so on. Various Limitations - No loops, no conditionals, limit lines per method, no voice communication (or typing out in chat… only communication is through code) TDD As If You Mean It - Strict TDD that involves real tests before code and strict refactoring rules. This can be combined with any other limitation or idea, but it’s so difficult (And rewarding) that it’s okay to Just Do This. Tools Vim + tmux - how to tmux · tmux basics screencast · Syme · easy ssh/public key auth Screen Sharing - ScreenHero · Google+ (read only) Audio - Skype · Google+ Find Pairs - RubyPairs · IRC #pairwithme · Twitter #pairwithme