Does that sound interesting for you and your company?
Then get in touch with us.
We show what options are available, how we can use them, what works and what doesn't work.
Employees change their working habits on the basis of the company's requirements or due to personal situations, so that, for example
the home office is used (from completely to partially to not at all)
working hours are reduced (from short-time work 0% to part-time models in short-time work to normal working hours as before)
the technical setup is not ideal (there is no laptop at home, no external monitor, no study, no headset)
These changes result in a number of technical and organizational challenges that teams working together have to face today.
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. The adoption of pair programming is still poor. One of the reasons for this is that the classic driver and navigator style dictates the following distribution of roles:
The driver uses the keyboard and mouse to write the code. The focus of the driver is to pursue and complete a small goal. Distractions caused by other problems should be avoided. The driver comments on his actions.
The navigator is the observer of the situation. He checks the results of the driver during creation and gives tips and suggestions for improvement. The navigator looks at the major problems in the code and has an eye on the roadmap ahead.
fewer bugs happen to you
your motivation increases through close cooperation
you write less code, which leads to less complexity
Your communication within the team improves
Your integration into the team improves
you benefit from the knowledge of others through intensive exchange
Despite its clear advantages, pair programming has a bad reputation. Adoption often falters, teams try it out, it doesn't work immediately and then it is abandoned. Our observations are consistent 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 coronavirus period and see it as an opportunity to implement things that didn't seem possible before?
One of the biggest challenges for pair programming is the greater asynchrony of many workflows. Pair programming requires synchronous time, as problem solving, brainstorming, development and testing happen simultaneously.
In other words: I can devote myself to a 3h problem for 3 weeks (piece by piece) or be in the flow for 3 hours and solve the problem. The second option is often more efficient, but it also requires predominantly synchronous team-based work.
And that is precisely one of the biggest challenges. Greater individuality has made it more difficult to find synchronous time slots. But you absolutely need them to get started at all.
Tools that help here are, for example, the calendar or tools such as Doodle if you work with companies that do not have access to your own calendar.
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 the option of sharing the screen for the other person and, if necessary, flipping it. Tools that we have already used are
TeamViewer
Skype
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 within and outside the company possible, easy to use). On the other hand, it offers the option 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 that you can also search for interesting passages in the text that need to be looked at 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. This results in the following advantages:
Collaborative work on code in real time
Direct editing of the code possible
Uncomplicated swapping of the driver and navigator rollers
Customized set-up is retained, even during the sharing process
Because you don't have to agree on an environment and everyone can keep their own settings and shortcuts, it can be easier to get started working on the content of the code.
In addition to the software, there are a few basics without which remote pair programming is hardly possible. First of all, this includes a stable internet connection on both sides so that smooth communication and screen transmission are generally possible.
As communication is a decisive factor in pair programming, wearing a headset is an advantage. It should be worn close to the mouth to avoid disturbing background noise and ensure good audio quality.
It is also a good idea to use a second screen so that both users can always look at the split screen, but at the same time have the second screen available for chatting or further research.
With a good setup, pair programming sessions can work well as remote sessions. However, there are limitations, as 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 degree of empathy.
Other problems can also occur with a simple set-up. If it is not possible to swap the driver - navigator roles, it can quickly happen that one of the participants is forced into the passive spectator role and the driver goes ahead too quickly. This contradicts the actual purpose 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 their code ideas linguistically comprehensible so that the driver can implement them. This is cumbersome and can cost nerves for both sides.
With simple screen sharing tools, there is also potential for conflict, as you have to agree on a setup.
Pair programming can offer many advantages if you take enough time to implement it properly. It is important to choose the right tools, but individual needs must be taken into account and no one-size-fits-all solution can be expected (depending on the context and company). Pair programming is also possible with simple software tools, but compromises cannot be ruled out here.
There are also many factors that influence collaboration: Hardware, software, personal relationships, etc. It is necessary to adapt well to each other and allow feedback-oriented, constructive communication.
Then get in touch with us.
You are currently viewing a placeholder content from Vimeo. To access the actual content, click the button below. Please note that doing so will share data with third-party providers.
More InformationYou are currently viewing a placeholder content from YouTube. To access the actual content, click the button below. Please note that doing so will share data with third-party providers.
More InformationYou need to load content from reCAPTCHA to submit the form. Please note that doing so will share data with third-party providers.
More InformationYou need to load content from hCaptcha to submit the form. Please note that doing so will share data with third-party providers.
More InformationYou need to load content from reCAPTCHA to submit the form. Please note that doing so will share data with third-party providers.
More InformationYou are currently viewing a placeholder content from Turnstile. To access the actual content, click the button below. Please note that doing so will share data with third-party providers.
More Information