Why Pair
On teams, developers want to get more done. Less experienced developers need to learn from the more experienced developers. The...
For further actions, you may consider blocking this person and/or reporting abuse
I had a USB split keyboard and folks had a regular keyboard at their dock station. I would plugin my keyboard and we could both simultaneously type. Obviously that didn't work unless one person gave way. Yet we didn't need to move chairs to swap roles. We could swap in a keystroke then back. With screen sharing tech you often have to ”pass presenter”. This is really crude as is swapping seats. Just as we can concurrently edit a Google doc we should be able to concurrently type at the same IDE remotely and swap in a split second. When that happens it is like two cyclists working in a team to win a long distance time trial. They keep swapping who is in front to make a push and when they run out of stream the partner steps in and pushes for a while and they get to recharge for a minute and plan the next micro push. Swapping fast and frequently in my experience does get more done that one person working. Pair programming isn't about watching someone else work it is about thinking while they type then typing while the think and doing refactoring based in peer review in ”real-time”.
I’ve seen setups with the “extra keyboard” and I’ve tried the VS Code Live Sharing. They both have a solid places with both positives and negatives. Thanks for the perspective!
Live Sharing looks great thanks for that. I just enabled gitpod on my repos that lets me run a workspace with vscode in a browser but have not had a moment to try it. I also saw a video that eclipse che lets you run a vs code workspace on Kubernetes on a browser. So it seems that remote workspace sharing is now a reality for pair programming remotely.
And what where the positives and negatives?
The extra keyboard: positive, direct interaction with single instance of code. Negative, can’t look at other code while other person is typing. VS Code: positive, multi-individual interaction and allows for any file to be viewed and interacted with. Negative, needs “really” good internet connection; it can lag really badly.
I've never found traditional pair programming to be useful. Introverts find it painful to have someone watch everything they're doing, but might be too scared to speak up. Not worth the stress it puts on them IMO.
The strong technique falls into the same pitfalls that developers encounter when they blindly copy and paste code while watching a YouTube video. They miss the opportunity for their brain to connect the neurons while they work out the problem.
I find the rubber duck technique great for learning a new codebase, since I usually like to explore the code myself and then ask someone from the original team for help if something isn't immediately obvious.
Have to add to the rubber duck technique, even working on my own project rather a new codebase I find it helps just trying to run through what you are doing to someone unrelated.
Even in events where you don't get a response you pick up on something you have missed when describing what you are doing. Something about describing a process to someone forces you not to skip over things in your head.
Thanks for the insights.
Interesting - never knew all the different types of pair programming had names :)
Have you seen pair programming that happens over a long period of time (like, years?) I know there are companies that do ALL of their programming as pairing, but I just don't know how that would feel over a long period of time. Any insight there?
Are they pairing in and out over that time (single set of code) or is it just a matter of always being a part of a pair? Not sure I’ve seen or heard of anything like it ...
I think the most famous example is thoughtbot (could be wrong about that); but I know that some companies just do it a LOT more than others; and I was wondering if you had had any experience with that :)
Unfortunately, no ... I’ll keep an eye out.
I never had an opportunity to do pair programming. It feels like a good way to prevent the bus effect. Especially in small start ups.
I also wonder how pair programming can be feasible in small teams as there are already to many things to do for an extra developer. Any ideas on this?
Pair-programmng lower defects (more eyes on the task) also improve knowledge distribution in the team and remove or at least lower the need for code review. (Someone else already saw the code). With rotation of pairs everyone knows the code.
That is the theory if you do it right and spend some time and effort into it, to make it work for you and your team.
From my experience good pair programming session actually finish complex code/problem tasks faster. Cause you find solutions to problems faster. Also you don't miss less obvious stuff so often.
It is important to factor the time spend understanding other people's code which you had not taken part writing.
At least for myself I found out that is easier to understand code that I had participated in even if only watching other person writing it.
But it depends on the tasks at hand. If there are busy things that just took time like configuring some service, better work separately.
But writing and even debugging complex code/problem most of the time is fast enough and some times even faster then working separately.
In Pair developers are more engaged into the problem, more focused which is more tiring.
Thank you. This provided a good insight.
Excellent! Well said ...
I am happy that there is an actual article on this. I am a junior developer and the lead developer at the company I work for is such a fan of pair programming. I think I have learnt the most from pair programming and honestly i think it also saves the navigator time because he can multi task even if he has only got two hands.
I wrote a similar article recently.
7 Ways to Get the Most Out of Pair Programming
Personally, I love pairing even in a remote setting (we used Tuple for that).