Wherever people work and communicate closely, working from home is a challenge. Pair programming, i.e. working together on a source code, lives from cooperation. The following tips can help ensure that this also works remotely.

Developers in particular can work well in the home office – because they are less disturbed, one would think. Unfortunately, the opposite is often the case, as there is a particularly lack of professional exchange with colleagues. Agile software development in particular suffers from the distance, as it lives as an iterative process from the development team organizing itself and constantly developing. Regular short meetings or development techniques such as pair programming require close cooperation.

In pair programming, two developers are actively working together on the same task at the same time – usually on the same VM, sitting next to each other in front of two monitors. It is discussed, constructively criticized, directly corrected and tried out. Developing in this way is extremely communication-intensive and also exhausting, the team has to get along well. Practice shows that pair programming works very well in an agile environment. Code reviews and refactorings are already part of the development itself – this not only saves rework, but also prevents dead ends and misunderstandings at an early stage. Pair programming is by no means alone, but should be implemented in the software factory as part of a comprehensive methodology that includes processes, procedures and platform-as-a-product. This way, high-quality code can be developed more effectively. But how can that work when everyone works alone in the home office?

Pair- Programming lives from communication. The process of problem solving is very different from the traditional way of reviewing a finished piece of code. Every action by the programmer is put to the test, is questioned and must be justified. Code arises from the discussion. A pairing team needs to talk about what they’re doing while they’re doing this. The partners should be on the same, solution-oriented working level, discuss only professionally and as unemotionally as possible.

In order to work in a structured manner, it can help To divide up the work: While one developer mainly programs and thinks about the next logical instructions, the other takes on the strategic considerations. It checks what effects the code that has just been created has on other parts of the program, what functional requirements it meets or has not yet met and how it must proceed. The considerations of both together then result in a well thought out next step. If the roles are constantly swapped, a very productive dynamic arises.

Speaking of communication: talking in detail about expectations, ideas and problems is extremely helpful. However, an almost as large part of communication is non-verbal. Video chats are therefore well suited for pair programming: While video platforms quickly reach their limits in meetings of larger groups due to latencies and prioritization in data transmission, it is easy to work with two people. It makes sense to have both the video and the audio channel switched on at all times so that the partner knows what is happening even in more silent work and thinking phases.

It is also important that the technology works well and that those involved can use the tools. At first this sounds like a self-evident requirement, but it is not always so easy to implement. In addition to high-performance Internet access, you also need good audio equipment, such as a headset with a microphone. Background noises can thus be faded out better. It can also make sense for every developer to have two monitors available – one for sharing the screen and one for video transmission.

There is also the choice of the right tools. The market offers a wide range of options, and many companies also have certain licenses or specifications. Most video platforms are basically good and have the option of mutual screen sharing included. Here, too, it can happen that data transmission latencies make programming difficult. Break-out rooms can be helpful here. Instant messaging services can be used to chat at the same time; some allow the integration of other tools and apps. In any case, the pair programmers should discuss in advance how they want to organize the work together.

When software is developed in an agile way, little is known at the beginning – apart from the requirements that the software should meet. Developers should consciously take the time to design the software architecture and be ready to realign and adapt it again and again in the course of the process. Often there are different design patterns, libraries, or frameworks that approach the problem from different angles. It can be more effective to use an existing, well-documented framework than to develop from scratch. In addition, in agile software development, the experience of several experts flows directly into the process, so that a number of approaches can be discussed. So you can flexibly put together the right architecture and get closer and closer to the ideal solution.

One of the main concerns of agile software development and pair programming in particular is that team members learn from each other. The exchange is lively, various experiences and skills are incorporated. If everyone is in the home office, this is still the case in principle, but it is very much limited to the project team itself. Little is learned about other projects and the informal, unspecific technical banter in between now hardly takes place. Two approaches can help here: On the one hand, team members should actively ask whether the programming partner would like to learn more about one or the other skill, for example. Even if it doesn’t necessarily have to do with the actual project. On the other hand, the team leaders and those responsible are in demand here. You should give your developers the time and the opportunity to develop further in the home office. This can be done through online training opportunities or through topic groups among colleagues.

Software development is a demanding job, both in the office and in the home office. If the development is agile – and especially if pair programming techniques are used – there is also a lot of communication. This is sometimes even more exhausting via video call and chat than informal exchanges in a real meeting. Specifically, that means: Developers should structure their everyday home office well and, above all, more r Schedule time for breaks. That too sounds banal at first – in practice, however, it has been shown that many home workers tend to sit longer at their desks, only take breaks when they feel like they need to, and therefore run the risk of being less concentrated and therefore inefficient. Agreements with the team and appropriate planning can counteract this – of course, always subject to the stipulation that you remain flexible within these guidelines.

Home office has arrived to stay. Even if, sooner or later, many developers will return to their real open-plan offices and meeting rooms, home office will probably become a permanent and widely accepted part of the work culture. With active, constructive and considerate communication as well as suitable technology and suitable tools, agile software development in the home office also works well.

For further reading:

• Efficiency and productivity: 5 tips for working in the home office
• Storage fever in the home office? This app shows you coworking spaces in your area
• Onboarding in the home office: That is the biggest challenge – according to the HR manager

Frederik Bijlsma

Frederik Bijlsma heads the Sales for the VMware Tanzu portfolio for the CEMEA area. Before that he was Director Sales CEMEA Benelux, Switzerland, Nordics and Government at Pivotal and VP Sales at TeleStax.

You might also be interested in