Coding Tour – Stop Three – Ruby, Rails and HAML with Rachel at Makers Academy

 

Thursday 30^th November. Spitalfields, London, England.

I’m off to pair program for two days with my old friend Rachel Davies at Maker’s Academy. For those of you who don’t know Rachel, she is one of the most experienced agilists in the country (if not the world), and has recently returned to a full-time coding career herself.

After a quick tour of the building and an overview of what Maker’s do, we install ourselves at the pairing station we will be using and Rachel sketches out the high level architecture for me. She also has a nifty tool that can be used to generate an Entity Relationship Diagram, that we use to get my head a little bit around the data model, which is pretty cool.

The pairing screen is giant, which we both really like once we realize that we work best with the IDE window slightly minimized to fit in the middle of the screen so we aren’t leaning over each other all the time. The large screen size helps us to not get distracted by all the other sensory input of the office, which at times is fairly “buzzy”. I immediately enjoy the fact that we are pairing on one single, set up machine and using the same editor and other tools.

We pick a ticket off the board and we’re off.

Mindful pairing

I’m struck by the mindful pace at which Rachel works. There’s no false sense of urgency that could lead us down a hole, rather Rachel explores the code and thinks aloud as she considers different approaches to solving a problem. We swap drivers at each commit and I’m pleased to say I even teach Rachel a new shortcut or two that I have picked up from the Cucumber team. I feel like a bumblebee, taking ideas from one team and pollenating them elsewhere.

For our first problem, we realize that there is a whole load of code that we can delete – I love deleting code, and I’m feeling much more at home with Ruby – and with the automated tests there as a safety net and even the ability to rollback database changes to previous versions, it feels much safer than it did back in the day.

Mobbing and pairing dynamics

One interesting insight for me was the difference between the mobbing I have done so far and the pairing I am doing today. On the mob, the navigator has usually been the person with the clearest idea of what to do, and has steered the driver much more, making quite granular suggestions and having often quite detailed conversations about the tactics as well as the strategy at hand as they went.

In contrast, Rachel has found that in the most effective pairs, the navigator’s role is more the quiet act of contemplating where the pair or mob will be driving to next (e.g. spotting refactoring opportunities and what the next test to write is).

This catches me out at first and I inadvertently “over-navigate” somewhat and break Rachel’s train of thought.  Perhaps partly through my autistic “mirroring” and the fact that Rachel has needed to help me at a much more granular level than is needed when we are in the opposite roles. It’s really helpful that we have these conversations and correct and tweak our pairing approach as we go.

There is still plenty of time for contemplation and conversation. We sit back from the keyboard and discuss strategy, sketch out mind-maps and update them frequently (which again I have learned to do more regularly from the Cucumber mob). We take frequent breaks from the enormous screen to give our eyes a rest. Plus of course, we take lunch breaks and catch up more generally with each other.

The first afternoon we quickly put together an events web page using HAML and YAML and it’s lovely to have such a solid quick win at the end of the day.

When solving another issue, we decide to flesh out the somewhat flaky tests a little. We have noticed that sometimes the tests fail once, and then pass the following times. This makes us less confident when making changes so it feels good to start to build in some more robustness.

“stopping to think and decide is fine”

All too soon, the two days are over. The big take-aways from this session for me were:

• How to be careful deciding on outside-in or inside-out testing depending on where in the stack we decided to begin.
• Pace is important, stopping to think and decide is fine.
• Returning back to a strategy of baby-steps is a great idea. Every time.
• There may be some significant differences between mobbing and pairing, or possibly just that different groups of people have different styles.

I leave, as always it seems, wishing I could come back next week and code some more with Rachel. In fact, we decide to do just that some time in the New Year.

Advertisement