Mob programming Adventofcode day 12

See the source image
Mob programming – image from Steve Bishop,

For our weekly “show and tell” at the C4DT Factory in the engineers meeting I proposed to do a mob programming for today’s adventofcode. As I want to continue learning rust, I proposed to do it in this language. I gotta say that while the first days of adventofcode were better for python, the tides are turning. IMHO.

Remote and local mixed

We are a team of three software engineers, and one of us was remote. First I didn’t want to do the mob programming, fearing that the remote person would be excluded. But luckily he was active enough to participate even from remote, so we went ahead.

Driving the implementation

I did read the explanation already in the morning, and I think this was my first mistake: I didn’t give the other two in the team enough time to read and understand. So I had a 3h headstart where my brain was searching for solutions. Which I already had. And they didn’t. So it took me some time to convince them that my solution was better 🙂 I probably should have used an example to better show why I think it works.

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. But then again, it was supposed to be a 30′ project, which took 1h30 in the end…


So off we went 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. Also because one of my teammates is better in Rust than I am, so I did learn a thing or two in Rust! Listening to suggestions was great and helped a lot. Some of them were not useful, I thought, and because this was a low-stake project, nobody took offense if I didn’t accept the suggestion. I suspect that with a high-stake project my teammates would’ve pushed back harder when I ignored them.

Debug statements vs. debugging

One interesting part was how we searched 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 was based on a map, it was nice to see the map and what we were doing with it. On the other hand, for some problems where you think you know where the error is, it’s easier with a debugger.

Github Copilot Voice

I also thought that the experience programming alongside two very good programmers was excellent: you get comments, small errors are detected, and discussion about how to solve a problem help better understand what to do. Also, because we know each other well, we could tell when to push for changes, when to accept that the other might be right. And not despair when in the end he was wrong anyway 🙂

Now I wonder whether this 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 mob programming example? Of course, one of the main benefits would go away: my coworkers would not have insight into the part of the program I’m doing.

Navigator experiences

  • 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.
  • It was intertaining, I really felt a team-spirit when doing it, everyone thinking and discussing how to best approach the soloution. For me, it was hard not to nitpick on Rust and algorithmic details. It turns out that you don’t need to have the fastest way to approach a problem to actually solve it. Also, we had the time limit which gave us a good rush and motivated us to finish fast.