Ever since I experienced mob programming, it became my primary teaching tool. But due to COVID-19, it’s suddenly time for me to support remote workshops. Can mob programming work remotely?
To date, I’ve taught over 230 students about unit testing and Test-Driven Development. Almost all has been in person, with everyone in one room.
My last TDD for iOS workshop was going to be in Amsterdam. But with the unfolding health crisis, my host Jeroen Leenarts and I decided to make the workshop fully remote. I’d been intending to start remote workshops some day, but this forced my hand.
In this post, I want to share how my remote mob programming is evolving. And you can add your own ideas.
When I first started teaching, students worked solo on their own computers, Then I had them work in pairs. But after a workshop taught by Llewellyn Falco, I got hooked on mob programming.
Here’s how I do mob programming when on-site.
There is one computer, hooked up to a projector. The IDE is set to light appearance (not dark), with a large font. In Xcode, this means I go to Preferences > Fonts & Colors, and select “Presentation (Light)”. I usually also go to System Preferences > Displays and use a Scaled display to make things larger. Otherwise, the text might be legible, but the controls will be too small.
Then I establish 3 roles:
I use 3-minute rotations. It may sound fast, but it works well with 10 people. When we start, I use the Timer app on my phone. This gives me the ability to pause the timer, so that I can use the latest changes to teach something.
When I’m no longer pausing the timer to point things out, I shift to using MobTime on the computer. MobTime pops up a window to interrupt the current rotation. Counter-intuitively, a strong interruption keeps things moving. And if I want to pause the timer to discuss something, I can ask the Driver to do so.
This configuration works great for a group learning together in one room. Everyone is looking at the same code. Discussions happen in the context of the shared code. Everyone observes, gives instructions, and feels the code come out of their fingers.
(Mac keyboards vary greatly from country to country. When teaching in another country, set System Preferences > Keyboard > Input Sources to “Show Input menu in menu bar”. Add different keyboards for whatever languages the students use. It’s also helpful to connect an external keyboard for the local language.)
At one point, I did a remote workshop as a pilot experiment. I applied the same ideas, but used Zoom to give remote control of my computer to the next Driver.
The experience for the Drivers was often less than ideal. Operating a remote computer has some lag. The feedback loop from fingers to eyes becomes delayed. As this lag increases, the experience gets worse.
I’ve seen folks trying to delete a few characters. Due to the delay, they’d often hit the delete key too many times. The unwanted results would break the flow of collaboration.
This was quite bad in one workshop where one group was in the room with me, and another group was elsewhere. It led to an inequality between the local group and the remote group. (After this, I decided my workshops should be local or remote, not mixed.)
With the Amsterdam workshop suddenly going remote, I wanted to avoid the problems I saw with remote-driving. Instead, my goal was to have each Driver work on their own computer, sharing their own screen. To pass code from one Driver to the next, I set up GitHub repositories. (This meant upgrading my account, so that everyone could have write access.)
This eliminated lag, and worked pretty well. But it did introduce other problems:
In spite of the problems, the basic idea of avoiding lag worked well.
Most of the problems we had were around one-time configuration. So the next time I teach a remote workshop, I’ll turn this list of problems into a checklist. I’ll ask participants to go through the checklist before we meet.
One thing I did right was to have a practice round. No timer, no mobbing. Everyone takes turns sharing their screens, and adding their names to a file. This helped iron out the initial kinks.
But this practice round didn’t necessarily help when we switched to a new repo. So instead of separate repos for each project, next time I’ll make a single parent repo containing all projects.
Every time there was a handover, the current Driver had to commit and push, and the next Driver had to pull. From the Remote Mob Programming website, I learned that we can use a tool made to simplify this workflow.
I was already planning to start remote workshops at some point. But COVID-19 accelerated my plans. Thanks to everyone’s patience in the last workshop, we can all be more effective going forward. Remote mobbing, yay!
Do you have any suggestions on how I can make things even smoother? I’d love to hear your ideas for remote workshops!
Programming was fun when I was a kid. But working in Silicon Valley, I saw poor code lead to fear, with real human costs. Looking for ways to make my life better, I learned about Design Patterns, Refactoring, and Test-Driven Development (TDD). Programming became fun again! I've now been doing TDD in Apple environments for 18 years. I'm committed to software crafting as a discipline, hoping we can all reach greater effectiveness and joy.
Please log in again. The login page will open in a new tab. After logging in you can close it and return to this page.