Mob Programming with Geekettes
All the brilliant people working on the same thing, at the same time, in the same space, and on the same computer - Woody Zuill
Last night was our first crack at a mob programming event with the Twin Cities Geekettes. As usual, we walked away with reminders of why we do this, why we push to get and keep women in the tech industry, why we want to build a welcoming and inclusive community, and why we keep plugging away when we find that software kicks us in the ass. Because it never fails to do that.
We started out with a simple problem - implement the game of battleship. Throughout the evening, we asked questions, we wrote code, we learned, and we met new friends.
Just like any project, we learned that not everyone knew what the game of battleship is so we spent a couple minutes laying out the mission of the game and some terminology. We learned that it’s important to use the same language, and the people driving the process (our audience) had to learn how to communicate what they wanted, both from a business standpoint (SINK ALL THE SHIPS!) to a code and syntax perspective (Don’t forget that semi-colon!).
We didn’t know how much code we were starting with or what the intention was of the original programmer, which is exactly what happens in any project. The first few mobbers spent time sifting through the code to grasp it and to explain to the rest of us what was going on. Sometimes an audience member would contribute as well. As we got into it, mobbers spent a little more time writing code instead of analyzing the code and our velocity went up.
During the mob process, we had thought provoking questions that sparked a level of conversation that is frequently not happening in our day jobs:
- how do you know where to start?
- how do you break down a problem?
- what if we had tasked this problem out differently from the start?
- what if we started from scratch (a greenfield project) instead of existing code (a legacy codebase)?
- should we increase the scope of our work?
- should we refactor now or later?
- when do we write our tests?
- will that have good performance?
And this all happened in the span of TWO hours.
What could you learn in two hours of mob programming?
Just imagine if you slowed down for two hours to experiment with mob programming on your next hard problem at work.