During the month of December, Advent of Code passes out a new puzzle every day. The daily challenges are a fun way to learn new algorithms and getting to know new ways of programming. In our software engineering team we followed along at least the first half of the programming challenges and enjoyed discussing the solutions together.
For one of our Monday meetings, however, I proposed to try out something new to solve the puzzles: Mob Programming. Mob programming is similar to pair programming, where two programmers share a single keyboard and a screen. But in the case of mob programming, it is usually 3 or more programmers who are collaborating in front the computer. The programmer at the keyboard is the driver, as they are the only one having access to the keyboard. The other programmers, the navigators, read the code, make sure there are no errors, and give inputs.
Remote and local mixed
We immediately faced a first challenge: We are a team of three software engineers, and one of us was working remotely. At first I didn’t want to do mob programming, fearing that the remote person would be excluded in this set up. But luckily he was active enough to participate even working from home, so we went ahead with the plan.
Driving the implementation
Starting out, I read the daily challenge prompt in the morning before starting work, and looking back, I think this was a mistake: I didn’t give the other two engineers in my team enough time to read and understand the challenge when they were ready to start. At that point, I had roughly a 3-hour head start during which my brain was already searching for solutions; which when we started the mob programming, I of course had already figured out, but they didn’t yet. So it took me some time to convince my teammates that my solution was quite good. In hindsight, I probably should have used an example to more convincingly demonstrate, why I think my solution was the best.
For most of the programming part, I had the task already in my head. I think I should’ve taken some time to summarize how I wanted it to look like first, however. But then again, it was supposed to be a 30-minute project, which ended up taking 1.5-hours instead, and with that far longer than intended. This was interesting, given that mob programming is often argued to help accomplishing tasks in a more efficient and faster manner.
Suggestions
Right away we started with the first steps of implementations. Reading the files was quickly set up, and off we went with some first code. For me as the driver, it was quite a nice experience. In part also because one of my teammates is fare more proficient in Rust than I am, so I ended up learning a thing or two in Rust as well! Listening to immediate suggestions by the team was a great experience and helped a lot in the flow of work. Some of the suggestions I didn’t think were all too useful, however, and because this was a low-stakes project, nobody took offense whenever I didn’t accept their suggestions. I suspect, however, that with a high-stakes project, my teammates would’ve pushed back harder if I had ignored them.
Debug statements vs. debugging
One interesting part of the experience was how we went about searching for bugs. Yes, we had bugs…! One of our team members wanted to println! everything, while I tried to use the debugger. In the end we managed to find a good balance between stepping through some code, and getting some outputs directly. As the problems in this daily challenge prompt were based on a map, it was nice to see the map and what we were doing with it. However, for some problems where you think you know where the error is, it was easier done with a debugger.
Navigator experiences
The other team members, the navigators, who read the code, checked for errors, and gave inputs, also were positive about our first mob programming adventure.
Navigator 1: “It was an overall good experience for me. Not being familiar with Rust, it allowed me to peer into the language syntax without having to code directly. Not being fond of “competitive programming” in general, I could also engage in the most interesting part of the thought process of solving the problem, without being bored of giving up too fast.”
Navigator 2: “It was entertaining; I really felt a team spirit when doing it! Everyone was thinking and discussing how to best approach the solution. For me it was hard not to nitpick on Rust and algorithmic details, however. But the experience of mob programming also showed me, that one does not have to have the fastest way to approach a problem, to actually solve it. In addition, we had the time limit which gave us a good rush and motivated us to finish fast.”
Conclusion
Trying out mob programming was a nice change of pace. I also thought that the experience of programming alongside two very good programmers was excellent: you get a lot of comments, small errors are immediately detected, and the discussions about how to solve the problem helped me better understand what to do. Moreover, because we know each other well, we could tell when to push for changes and when to accept that the other might be right, and not despair if in the end he was wrong anyway.
Now I wonder whether collaborative mob programming is the next step for the ChatGPT, Github Copilot, and all the other AIs that help coders to code. From what I saw, they are not capable (yet) of creating complex code on their own. But could they help code in a seamless manner like in this small example? Of course, using AIs to program would remove one of the main benefits of engaging in mob programming: my coworkers would not gain any insights into the part of the program I am working on.
Overall, mob programming is a great method to bring the team together, to facilitate learning from each other, and to share ideas. But it is probably not faster than conventional methods and certainly not my preferred method of working for the majority of the time.