June 2021 Week Long Code Retreat
Last week I attended a code retreat during my lunch breaks. It was a really good experience, and I think I preferred it to a full day code retreat, which can get pretty exhausting by the end of the day.
I’ve done a few code retreats now using tools like Anydesk, cyber-dojo, and Visual Studio Code Live Share, but in thinking about how I might introduce ensemble programming at work to use on a production code base, I think something that allows each person to use their own familiar tools would be best. The mob.sh tool fills that gap, so I was hoping to try it out during this code retreat. I created a TypeScript template repo as a starting point, and added some stuff to it based on learning’s from this week.
It took a little while to get everyone set up with a local environment, so it was a bit slower to get going than with a tool like cyber-dojo. It wasn’t as bad as I thought it might be though, I think everyone was ready to go within 15 mins, and we had people using Linux, MacOS, and Windows.
I learned a lot about using mob.sh during the two sessions we used it. As a sort of retro, here are problems we ran into:
- Some people in the mob didn’t have write access to the repository, and as a result we got some somewhat opaque error messages that were a bit difficult to solve. I made sure to check the repo permissions for the second day.
- Ubuntu’s snap install doesn’t seem to pass SSH agent information through, so I was prompted for my key passphrase every time. I ended up using the recommended curl install even though I’m not keen to pipe files from the internet through sh, but it worked better that way.
- I found out that my cool trueline terminal prompt looks terrible in both VSCode and Emacs. I normally use a separate terminal, but using one inside the editor means I don’t have to share my whole desktop which is better for everyone.
- mob.sh provides a built in timer, but it just says “mob next” once and we either missed it or something about running mob.sh from a terminal inside an editor meant it didn’t work properly, so one of my turns went way too long. A separate tool like MobTime is probably the better way to go.
- mob.sh doesn’t have a built in way to set the mob order or roles. The first time around we lost track of the order. The second time I put the order in the zoom chat first, which seemed to help.
- I think that letting each person use their own editor and tools is a benefit of using mob.sh, but we did run into differences in editor configuration. For example one person’s editor might be set to 2 space indents, another to 4. Using something like Prettier and/or EditorConfig might be helpful, just as it would on any team where you don’t want to argue style in PRs.
- I learned that some folks don’t compulsively save, which meant that sometimes mob.sh couldn’t find anything to commit. Setting up auto-save helped. If using the `npm run watch` command, it sometimes resulted in ugly errors due to compile failures.
I need to spend some more time with mob.sh to learn the details of using it, but overall is seems like a useful tool.
I also participated in other sessions. In one we collaboratively learned Haskell, which was an interesting experience. No one really knew the language; but we were able to make some progress anyway. Some folks knew some functional programming. I’ve been using Elm quite a bit which is related to Haskell. The best thing was that people could go off and research things and come back with suggestions or they would past links to helpful pages in the chat, and as a result we were able to fairly rapidly learn enough to make progress. Getting a working Haskell environment was a challenge for many though.
I also got my first taste of Approval Testing, which I think is the same thing as Golden Master Tests or Characterization Tests. Although this was the first time I used a library to do this kind of testing, I have used these kinds of tests before. In that case I had a C++ application that took some DICOM data and produced binary and JSON outputs, so I had an hand crafted test harness that verified that these outputs had not changed. Using theses tests and checking code coverage I was had a lot of confidence in the changes I was making. A library like ApprovalTests.cpp probably would have been helpful.
In the case of Game of Life, I feel like it’s easy to conflate the domain representation with the serialized representation of that domain. Adding a printWorld function and maybe a parseWorld can help separate those though. It seems to me that approval tests are a good fit for higher level tests where you want to make sure you don’t change larger scale behaviour of code, ideal for refactoring where narrower unit tests would be too coupled to the code you want to change to be valuable.
Some of the most interesting things that I get out of code retreats are little off hand tidbits that people mention. This time around someone mentioned “Training from the back of the room”, which is a book on helping people learn. Another one to add to my coaching/training reading list.
Code Retreats can be stressful. Working in front of others can be hard when we are used to writing code alone. But it’s so great to be able to discuss design, style, tools, etc in realtime. As long as folks are willing to set egos aside, say “yes, and…”, and be curious and open to new ideas and approaches, it can be really rewarding.