The team space contains two tables facing a large (10’ x 5’) projection area. It feels like the split-screen arrangement I’ve seen many developers using, only much, much larger. It’s easy for all six of us to sit on the long side of the tables opposite the projection to take our turn at the controls for the single development machine. The cubicle walls enclosing the rectangular team open space are coated with several layers of giant post-its, index cards, and whiteboards.
The day begins with a one hour learning (“katas”) exercise. We open the code files for a tic tac toe game. Someone hands me the keyboard and I add my name to the queue in their homebrewed timer window. The team consults and decides to spend their learning hour refactoring the code in their tic tac toe game. One of the files has a bunch of redundant code, so (following the principle of “Don’t Repeat Yourself”) the team will delete that and replace the redundant code with a single method.
We set to work, with one person at the keyboard “driving”, and a second person “navigating” with occasional use of a laser pointer to draw attention to something in particular on the projected image. When the timer goes off, the “driver” passes the direct control over to the “navigator”, and a new person becomes the next navigator.
“One of the best things about the timer is that we’d become so connected to thinking in code that it would hamper our ability to program. This method has really helped us break that habit.” Code-language, Woody explains, is not a good headspace for solving problems. Human-language is.
I had warned Woody before I came down that I wasn’t much of a coder. To be on the safe side, told him I could not code “at all”. “Don’t worry”, he assured me “The mob works at the speed that the driver is comfortable with.” The tic-tac-toe game is in C# (which I’ve never used) and the dev environment is Visual Studio (which I haven’t touched since 2008). As promised, this proves to be surprisingly little impediment. The team slows down when I’m “driving” (typing) or “navigating” (verbally directing the next solution), but there’s so much collaboration going on, that it’s surprisingly easy to contribute to the solution even while laboring under these restrictions, at least during katas. Before experiencing this for myself, I had doubted Woody’s assertion that I could become a fairly decent programmer after spending a couple of months working like this with the team. Now that doesn’t seem unlikely at all.
I get extremely excited envisioning a Railsbridge mob programming class. One of the challenges I’ve observed is that while Railsbridge has been hugely successful at increasing the percentage of women in the Ruby community, very few aspirants have managed to make the transition to a career in software engineering. Perhaps it would be easier and faster for students to do this using an apprenticeship model based on this team method.
I mention this to him later after the team’s somewhat harrowing lunchtime hiking experience. “Modern practice is to teach people to learn things individually, this is maybe not the best approach.”
