Posts

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

As coders, we’re often given tasks to do. These tasks can sometimes overwhelm even the best of us. How many times have you stared at a problem and when you finally sat down to attack it, you spent a quarter of the time you expected to on it. If only you hadn’t spent 3 hours playing Angry Birds. There are lots of things you can do to “hack” your productivity, but most of them are focused on helping you keep track of tasks instead of motivating you to get going. ...

I love GTD. I love making lists and having things to do. I love having a system. That also makes me love bug trackers when I’m on a team. I love having everything listed in one place. I love letting it be the communication point for a team to get things done. Bug Trackers and To Do lists are great. They just don’t seem to work very well together most of the time. ...

I always find it interesting to place artificial constraints on myself. I don’t think it’s the constraint itself that is good as much as what it shows me about myself or what I do. I read an article on Rands in Repose a few years ago that talked about giving up your mouse for Photoshop. The idea isn’t to rid yourself of the mouse entirely. The idea is to make you aware of when you depend on the mouse. ...

I spent a little (longer than I thought… maybe 2 hours?) implementing Tic-Tac-Toe in the TDD As If You Mean It style. Ended up with a VERY different implementation than I ever would have done if I just “started coding” – everything was only in one class, including the AI to “play” against itself. Observations: It was quite different to implement things inside the test method. I ended up coding like it "does something..." do player = Player.new def player.something # do work end player.something.should be_true end It was difficult to not refactor as I went. Many times I would see the duplication and want to refactor immediately. I resisted this urge until I felt the implementation was done, then refactored out duplication, ensuring that the tests continued to pass after each change. I’m still not quite sure how you’re supposed to improve design without breaking the rules. Doing pure method move seems limiting and doesn’t allow for you to see duplication. The only thing I could think of is that there can be additional refactoring after you’re “done” All in all, a very interesting exercise. I want to do it now on something broader, and eventually on something that has a core with a wrapper so that the core is purely TDD’d and the wrapper is thin, but swappable. I think Dominion is my next big attempt.

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