Employees change their work habits based on the company's requirements or on personal situations, so that, for example
- the home office is used (from completely to partially to not at all)
- the working time is reduced (from 0% short-time work to part-time models in short-time work to normal working time as before)
- the technical setup is not ideal (no laptop available at home, no external monitor, no workroom, no headset)
Pair programming is a method in which two software developers work together on a piece of code at the same workstation.
„Write all production programs with two people sitting at one machine.“
But Pair Programming is more than that. Adoption of Pair Programming is still poor. This is partly because the classic driver and navigator style prescribes the following distribution of roles:
The Driver operates the keyboard and mouse to write the code. The driver's focus is to pursue and complete a small goal. Distraction by other problems should be avoided. In doing so, the Driver comments on his actions.
The Navigator is the observer of the situation. He reviews the Driver's results as they are created and provides tips and suggestions for improvement. The Navigator looks at the bigger problems in the code and has a view on the further roadmap.
The advantages are:
- fewer bugs happen to you
- your motivation increases due to the close collaboration
- you write less code, which leads to less complexity
- your communication in the team improves
- your integration into the team improves
- you profit from the knowledge of the others through intensive exchange
Pair programming has a bad reputation despite the clear benefits. Adoption often falters, teams try it out, it doesn't work right away, and then it's abandoned. Our observations align with this. Pair Programming unfolds its potential over a longer period of time and is not a short-term solution to problems.
The use of pair programming can be difficult or even fail due to a lack of conviction. All it takes is a few critical voices in the team. But what if we use the Corona time and see it as an opportunity to implement things that did not seem possible before?
One of the biggest challenges for Pair Programming is the greater asynchrony of many workflows. Pair Programming requires synchronous time because problem solving, idea collection, development, and testing happen simultaneously.
In other words: I can devote 3 weeks to a 3h problem (piece by piece) or be in flow for 3 hours solving the problem. Often the 2nd option is the more efficient, but also one that requires predominantly synchronous team-based work.
And this is exactly one of the bigger challenges. Greater individuality has made it harder to find synchronous time slots. But you absolutely need them to get started in the first place.
Tools that help here are, for example, the calendar or tools like Doodle, if you are working with companies that do not have access to their own calendar.
Technology: Simple software tools
Due to the great diversity, the tool selection often has to find the lowest common denominator.
In general, any screen sharing tool can be used that has a way to share the screen with the other person and, if necessary, turn it around. Tools we have already used are:
- Microsoft Teams
- Google Meet
We are currently increasingly using Microsoft Teams in our projects. Just like Google Meet, it offers a very low barrier (all devices, collaboration inside and outside the company possible, simple operation). On the other hand, it offers the possibility of automatic recording, which makes it very easy to record longer sessions and make them available to the participants. These videos are automatically transcribed, so you can also search for interesting parts in the text that need to be watched again afterwards.
Tools such as Microsoft Visual Studio Live Share also offer integrated solutions that allow code, video and audio to be integrated in one interface. This allows pair programming to be implemented without compromise. The following advantages result from this:
- Cooperative working on code in real time
- Direct editing of code possible
- Uncomplicated swapping of the driver and navigator roles
- Individually designed set-up remains intact, even during the sharing process
By not having to agree on an environment and allowing everyone to keep their own settings and shortcuts, it can be easier to get started working on the content of the code.
Besides the software, there are some basics without which remote pair programming is hardly possible. First of all, there must be a stable Internet connection on both sides so that fluid communication and screen transmission are basically possible.
Since communication is a crucial factor in Pair Programming, wearing a headset is an advantage. It should be worn close to the mouth to avoid disturbing background noise and to ensure good audio quality.
It is also advisable to use a second screen so that both can always keep an eye on the split screen, but at the same time have the second screen available for chatting or further research.
Translated with www.DeepL.com/Translator (free version)
With a good setup, pair programming sessions can work well as remote sessions. However, there are limitations, since the personal level and direct face-to-face communication are largely eliminated. Non-verbal communication is also not possible or only possible to a limited extent via video transmissions. This requires a special level of empathy.
In the case of a simple set-up, other problems can also arise. If it is not possible to swap the driver-navigator roles, it quickly happens that one of the participants is forced into the passive spectator role and the driver goes ahead too quickly. This contradicts the actual meaning of Pair Programming and should be avoided.
The exchange of code snippets can also be problematic with simple tools. The navigator then has to make his code ideas linguistically comprehensible so that the driver can implement them. This is cumbersome and can cost nerves for both sides.
In the case of simple screen-sharing tools, there is also the potential for conflict, since you have to agree on a setup.