Posts

I gave a quick lightning talk on how to have a good #pairiwthme session at LSRC this year. I still had a question on how to get started in pairing afterward. I came up with a basic set of steps, which can be combined as needed. Get a pairing session scheduled and established. Share a screen. Type together. Sometimes this takes longer… sometimes it’s just a few minutes. Work on the simplest possible setup you’re comfortable with. Usually this is Google+ and ScreenHero, but YMMV. Work toward an optimal setup you’re comfortable with that maximizes responsiveness and communication. Typically this is low bandwidth (i.e. Audio Only (Skype?) and terminal sharing (tmux)) You may be able to get all the way to step 3 in your first session, or you may take 3 separate sessions to get all the way there. Either way, you’ll get there, and then you’ll be comfortable enough to take someone else through it. ...

I finally got a chance to pair with @jnanney tonight. He had a project dealing with the OnStar API that needed OAuth Authentication, so we took a stab at implementing it. Setup Skype - TIL Skype 6.x turns off your video if you connect to a Skype 2.0 client–but the audio still works! TMUX+VIM on a slice (not local) Experience We started by making some large, rough ideas about what we wanted to accomplish and then began looking up some things on OAuth2 to help us accomplish them. Pretty quickly we stopped driving everything via tests and started exploring via IRB. ...

Last week I had the opportunity to pair again with @willpragnell. He had just moved and didn’t have internet access, so I suggested that we try a “mute” pairing session from a coffee shop, where all our communication happened through VIM. He was game, so we started off with a quick chat session on Google+ to get set up, and then switched to a VIM+TMUX setup for the rest of the time. ...

12 Lessons I learned from Unit Tests/TDD is a great article for practically adding TDD to your teams rhythm. I can’t stress enough how much point 8 makes a difference: Pair programming helps the team to adopt TDD. When we are trying TDD for the first time or when our deadline is tight, we will have the will to forget the tests and write only production code. Pair programming will prevent the team to cut corners and will keep it writing tests. ...

Today I got to pair with Peter Vanderabeele, who is a programmer from Belgium with a highly methodical bent. He has clearly had a lot of experience and it was neat to get to work on his project since it isn’t every day you get to work on a high performance fact storage system. Peter is creating a data store meant to store semantic facts that have relationships to each other. It’s a very different project with a goal, he stated, to have data in this format and extractable for the next 50 years. To try to view code with that lens is very different from how most other Rubyists think. We tend to see our code dying in the next 5 years… max. So we make decisions with that timeline in mind. Thinking of a timeline longer than my own life has very different implications. ...

Last night’s pair session was with @stuartrexking - a very experienced developer and technologist currently working at a really neat company called Antipodean Labs. It seems like he’s got a great handle on solving problems and staying maintainable. We started off by trying to decide what to do. I’m increasingly convinced this is the possibly the hardest part of remote pairing with people who aren’t part of your company. You don’t have a predefined complex project you both find interest in, so the most likely shared interests are either meta problems or highly common ones. Highly common ones are very visible and difficult to find low hanging fruit for. The meta problems are good to solve, but somehow feel like they are less valuable than the “real” problems. Maybe this is just a feeling I have. ...

Ruby is not Rails. Learn Ruby first. Get rbenv (preferred) or rvm installed with Ruby 1.8.7, 1.9.3 and 2.0 Write Hello World and run it puts "Hello World" Go through the Ruby Koans (simplest with 1.8.7) Go through some TDD exercises Code a simple ruby script that solves a problem you have, like… Add a TODO to a file Print out the date in another time zone Tell you how many days until… Perform some repetative task related to your environment Display something silly for your kids Ruby is not Rails. You do not need to learn all the “magic” of Rails to learn the awesome of Ruby. Spend some time and get where you can really drive a script and solve a simple problem. Doing this will get you far beyond a beginning Rails developer. You simply have to learn the magic incantations of Rails to be able to develop web apps after that. And those incantations won’t be nearly as scary.

I had a great #pairwithme session with @_zph. Always a pleasure to talk to him and solve a problem together. Setup TMUX + VIM on a slice github-auth gem Experience We wanted to add the feature to gh-auth so you could pass a –path or –user argument to it. Because we’re good developers, we started off by coding the acceptance test. We discussed the merits of how to write good tests and whether to follow convetions within a gem authored by someone else or do things ’the right way’ – according to whatever coding religion you follow. Eventually we decided on sticking to the conventions of the gem while trying to improve–but not radically change–the tests/testing that we touched. From there, we dove down into the implementation and unit tests and drove through until we had the –path argument working. Along the way we did a little refactoring to use the OptionParser instead of requiring a specific ordering of options. ...

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. ...