Pairing

Last night I had a great pairing with @Shicholas working on the String Calculator kata. Setup We again used TMUX + VIM, even though Nick wasn’t very familiar with VIM. Based on his experience, I think this might be the best way to learn VIM since you have someone guiding you through. You won’t pick up on everything, but you’ll learn a handful of new things each time. Exercise We went through each of the different rules and ping ponged back and forth. It was a struggle to do the simplest possible thing every time, and really let the tests DRIVE your development. Your developer brain wants to generalize the solution to a problem, but the strength of TDD is keeping your actual solution as simple as possible. Developers are notorious for over complicating things and over desigining. ...

The easiest things to pair on are little tasks that you both understand and can be easily “completed” within a 1-2 hour pairing session. Unfortunately, Tic Tac Toe, Conway’s Game of Life and Bowling become stale quickly. It’s not that they don’t have valuable things to teach you, but you can’t pair with the same people over and over again just doing those problems. Eventually you need to dive into a real project. ...

I had my first pairing session with @willpragnell today. He’s a smart guy and my first European pair partner. It was a pleasure to talk to him about his iOS and Ruby experience and I picked up on a lot of little things from our pairing session together. Setup TMUX and VIM - (I got to use my newly revised pairing script to set up everything in seconds) TicTacToe - RSpec The Session We set a couple of goals out for the beginning. We both wanted to learn more of RSpec’s new syntax and we wanted to really adhear to the TDD principle of doing the most simple thing next. ...

I’ve now been pairing with several people a week for the last few weeks. Even over that short period of time, I’ve seen a pattern emerge: If you watch someone else (of any skill level) and pay attention, you will learn. When I’m watching others, I tend to be thinking of what I’d do in their situation, but sometimes just observing very simple things a user does – a VIM action, a command line script, an obscure API call, a rare tool – these are the details that change you in the small over time. This same principle is why counselors tell you to actively listen to your spouse – hear what they’re saying instead of just thinking of what you’re about to say. Sometimes you pick up on things they might not be able to vocalize themselves. Sometimes you pick up on emotions you would be too busy to notice otherwise. Actively listening in any relationship involves shutting up and noticing the details–it just happens to be true when you’re pair programming as well. ...

Today I paired with @mattr_ and got quite a bit of good input regarding how to attack a problem and write tests. Matt is a super smart guy who has really absorbed some of the fundamentals of TDD and it shows through his ability to break down a problem. Setup TMUX & VIM on my box Conway’s Game of Life as an exercise Process When implementing the game of life, we started off looking at the problem on Wikipedia and found the 4 rules. I immediately started writing the first test when Matt noted that he liked to write all the specs he knows of as pending specs right at the beginning. Then he can really plow forward and know what’s next. He also noted that he likes to be able to write the assertion first, based on the test, and then build the test up from there. I felt the lightbulb go off when he pointed these two things out. When I’ve struggled to find the test or figure out how to test something, usually it’s because I can’t figure out how to get to the assertion, and that really comes down to not testing the right thing. ...

{% blockquote Chris Knight and Lazlo Holyfeld http://www.imdb.com/title/tt0089886/trivia?item=qt0435761 Real Genius %} “How’d I do? I passed! But I failed! Yeah!” “Well, then I’m happy and sad for you.” Last night I made a mistake. In an effort to continue pairing with people I really enjoyed pairing with, I scheduled 2 pairing sessions for the same evening. I left 30 minutes between them, I prepared as I should… but I was stressed and it made both sessions worse. ...

Update 2013-06-14: Improved the script, removing the github-auth dependency, some of the OS X dependencies, and added firewall punch-through (user specific) and ssh-command with external IP auto-copy to clipboard I wanted a quick and easy way to set up a new TMUX session with a brand new pair, so I came up with this: #!/bin/sh gh-auth add $1 sudo cp ~/.ssh/authorized_keys /Users/pair/.ssh/authorized_keys sudo chown pair:staff /Users/pair/.ssh/authorized_keys gh-auth remove $1 tmux -S /tmp/pairing new -ds pairing && chgrp staff /tmp/pairing && tmux -S /tmp/pairing attach -t pairing sudo rm -f /Users/pair/.ssh/authorized_keys That will download ssh keys, create a tmux session, and attach to it. When you’re done it will cleanup so the other person has no access to your box. ...

Last night I had a great #pairwithme session with @_zph. He’s been doing Ruby on nights and weekends for the last few years and he’s been using VIM much longer than I have. I learned a lot of little tricks about VIM that I just hadn’t quite worked out before. We also refactored some of his Buff Gem. Setup: Zander had a VPS already provisioned with my ssh keys installed. Super Easy setup. TMUX + VIM for our editors RSpec for testing the Gem We started off trying to think of what to pair on within Zander’s gem. He was concerned about the tests, so we actually spent a fair amount of time just looking at the WebMocked tests and discussing the pros and cons. Eventually we decided that WebMock might be a good way to start off your TDD of an API wrapper since you have complete control of the response, but VCR gives you the best long term support since you can both get fast tests and confirm that you’re still working with the API correctly and that you didn’t just magically stub out the wrong thing–just delete your cassette and you’ve got “free” real API tests, followed by nice fast tests. ...

Last night I had my first pairing session with @shicholas. Nick recently graduated from law school and is looking to pass the bar, but somehow programming calls to him. It’s a good thing too, since he’s clearly gifted and a fast learner. Setup: ScreenHero Sublime Text 2 shuhari by @jarhart While we were kicking things off with the “get to know you” talk, I found that Nick had a Rails + Angular.js app he was working on. I’ve not done any work with Angular and asked him to show me what was going on. He pointed out the general structure as well as the custom directives that Angular.js allows you to create. I’ve watched the Ember.js Peepcode Intro, and found it difficult to get excited about it. Being introduced to Angular.js in this particular manner gave me real world applications and it seemed much more intriguing. No verdict yet on either, just initial impressions on both frameworks. ...

Had a great 4th pairing with @kmeister2000. Always a pleasure to work with him. Interesting Parts of our session setup: Worked on a real world app Karl was developing Used MiniTest instead of RSpec Refactored existing code MiniTest Takeaways: MiniTest expectations about method calls are not as clear as in Rspec and the documentation/examples aren’t as readily available. MiniTest is a lot like RSpec in nearly every other way. I’m not a fan of Mocha. I think it promotes antipatterns for how to really test. I actually like the explicit mock.verify in MiniTest::Spec General Takeaways: ...