Team programming

A few weeks ago I started to experiment with Open coding sessions in which I'd work on some open source code while I share my screen for everyone to see. Later that became a pair programming session in which someone more knowledgeable than me in the specific subject would help me to write some automation, to develop a web application or to understand BDD and Cucumber

I like these and I've scheduled a few more. These are pair programming sessions with guests, but I wonder if they should be-could be expanded to involve more people working together.

In my recent self report I mentioned doing more pair programming and more team programming, but I have not explained what I mean by the latter.

I saw people using the term mob programming and recently I also saw Ensemble programming which would be the same with a better name. (The latter still does not have a Wikipedia page, neither does it redirect to Mob programming.).

Although I used it myself, I did not really like the name "mob-programming" myself because of the negative connotations. However "ensemble" is too hard for me to pronounce. It sounds a bit like a word only aristocrats could pronounce correctly.

So I used the term "team programming" even though the wikipedia page uses that for something slightly different. Slightly broader.

There is a big difference between what one can do in a company with a fixed team and what can be done when working with volunteers on open source projects. Volunteers who will not always have free time to join a session.

Open source programming

What we had so far in the live sessions was a kind of pair programming with a few people joining us in the chat of Zoom. They can hear us. They can watch our screen and they can write to us in the chat.

So far I did not want to allow others, "the general public" to talk in order to avoid "zoom-bombing", that is when a malicious actor joins the session and starts sharing inappropriate content. (It can still happen via the chat, but it less appealing and less appalling than sharing screen, video, or sound could be.

I could enable more access to selective people whom I already know, but I am not sure it would not lead to unpleasant feelings of why this person is enabled and that person isn't. So for now I stick with the pair+audience setup.

So far it was always me having the keyboard and the other person telling me what to write. I am not sure if this was good for my co-programmers as well, but at the time it felt right for me as we were more-or-less in a teaching mode where they were telling me what to do. However I am not sure this is really good. Maybe we should start swapping the roles. I should probably have a retrospective with each person asking them what do they think.

Corporate setting

At various clients I have been working in a similar manner. However at a corporation the participants are much more fixed (with the occasional sick-leave). These sessions varied.

In one place it is primarily in "teaching mode" or Strong style pair programming in which I told the "designated driver" what to write. There were several observers who occasionally helped with the configurations and with the corporate knowledge. In each session we had a different driver.

At another client it is more of the one-on-one development process. We schedule a time-slot with each individual separately and then work on whatever task they need to work on. This can be programing in various languages (e.g. Perl, Python, JavaScript). It involved working on Jenkins jobs, GitLab pipelines etc. It involved working on Docker, Pulsar, ELK, Linux sysadmin stuff, you name it.

In these case there is a huge advantage of having one (or more) company employees work with me. I know some of these technologies better. They know the local environment better. They know their application. They know their politics. In general, they have the local knowledge.

So working together and combining these things is way better than either of us working alone.

When we worked with the team I think some of the people might have been a bit bored or out of the development loop, but there definitely were cases when we needed the help of a 3rd or a 4th person. This especially happened because the local corporate environment is very complex (or over-complicated). There is no DevOps culture. The cooperation between the developers, the people who run the CI system, the people who are responsible for corporate security is limited. So we had to overcome a number of issues that stemmed from this lack of cooperation.

Anyway, the point is that it was useful to have someone more experienced (in some aspect of the work) be present (virtually) in our sessions.

Conclusion (so far)

I can definitely see the value I get from pair programming on Open Source projects and the value I can provide to a company using this technique. I can also see the value when there are a few other people in such event, but probably 5 is already too many. However we were doing development on a relatively restricted area of the application so we did not need a lot of diverse knowledge. When we get to that point we'll probably be better off having a domain expert from each domain be part of our team.