Closet Coder

I work in my closet. I code. Yep.

Pairing Post Mortem - @Shicholas - Real World Lessons and Bowling

| Comments

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.


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.

After a few minutes looking at Angular, we decided to implementing the Bowling Scoring as a quick TDD exercise in Ruby. We used shuhari to set up the app and have everything in place for quick exercise. It’s a nifty little gem for speeding up the setup process if you’re wanting to focus on learning something specific.

We got through the whole exercise in about 45 minutes. I’m discovering that Test Driven Development is affected a great deal by the intuitions you have about where something is heading. Implementing the “minimum solution” to pass the test is often subjective. Gary Bernhardt said in one of his Destroy All Software screencasts that there was a point where he could code the constant as a return value to make the test pass, but it was actually much less mental effort to solve it outright, so he did. There was no test that forced him there, he just did it. It made the test pass, and certain other tests didn’t have to be written. We saw this happen in our last 2 tests because of the way we chose to iterate over “frames” in the bowling score implementation.


  • Be open to learning about what other people are doing. Their real world applications show you much more than any exercise will ever show you.
  • Angular.js looks more exciting than I’d initially thought.
  • shuhari is a cool tool for pairing on basic exercises.
  • Be aware of how much you blur the line between letting tests drive your design and using your intuition to discover the next step.

It was a great session and I am hoping that I get to pair with Nick again on his Angular.js project.

On to the next pairing session…