Home office is a challenge where people work and communicate closely together. Pair programming, i.e. working together on a source code, also lives from working together. The following tips can help ensure that this also works remotely.
Developers in particular can work well in the home office – because they are undisturbed – 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.
How pair programming works?
In pair programming, two developers work actively 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 directly on the test bench, 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 exclusively in a technical and as unemotional way as possible.
In order to work in a structured way, it can help to split 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 is created.
Pair programming with suitable tools
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 audio channels switched on at all times so that the partner knows what is happening even in more tacit working and thinking phases.
It is also important that the technology works well and that those involved can use the tools. That 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 each developer to have two monitors available – one for sharing screens and one for video transmission.
In addition, there is 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 exchange ideas in advance about how they want to organize the joint work.
Continuous software design as a paradigm
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.
Actively pass on experiences and learn from others
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, that is still the case in principle, but it is very much limited to the project team itself. There is little information about other projects and the informal, unspecific technical skirmishes in between now hardly take 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 does not seem to have anything 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 with colleagues.
Work structure in everyday home office life
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, plan more time for breaks. That also 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 under the condition thatto remain flexible even within these guidelines.
Home office is here 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.