Collaborative programming in remote-first environment(vtorosyan.github.io)
vtorosyan.github.io
Collaborative programming in remote-first environment
https://vtorosyan.github.io/collaborative-programming/
14 comments
Making sure the readers of that writing understand and (when consensus is required) agree with that writing.
Not that you need pair programming to get that kind of closed loop. But the closed feedback loop is essential in the long run.
Not that you need pair programming to get that kind of closed loop. But the closed feedback loop is essential in the long run.
collaborative programming gets you the benefits by weeding out all developers who can't "knowledge sharing, less WiP, real-time reviews and focus time"
If that's true, then collaborative programming will leave the teams empty: it is such a gigantic waste of time that those who can will vote with their feet too.
Pair programming almost destroyed a small team at my remote-first company. It's a powerful tool but some developers don't know when to stop.
> Recently we started experimenting with synchronous collaborative programming
I wonder how those experiments are going? The expected benefits do make sense, I wonder if there are any downsides (expected or experienced) at all? It's never all free lunch, and wondering about the two sides.
The calendar-based call-out to the team when one's ready for some collaboration is an interesting tool, and something I'm gonna try. I'd guess a cousin of the "focus time" calendar events when the activity is very similar (still coding), except preferring solo rather than collaborative.
I wonder how those experiments are going? The expected benefits do make sense, I wonder if there are any downsides (expected or experienced) at all? It's never all free lunch, and wondering about the two sides.
The calendar-based call-out to the team when one's ready for some collaboration is an interesting tool, and something I'm gonna try. I'd guess a cousin of the "focus time" calendar events when the activity is very similar (still coding), except preferring solo rather than collaborative.
Hi, I’m the author of the post.
While it’s a bit early to make right conclusions, we already have some learnings and outcomes. We do see increase in overall happiness and mood in the team, knowledge is shared more effectively and we started slowly to break silos. Another interesting side-effect seems to be that regardless people collaborate on particular problem or not, disagreements somehow got easier to resolve, as we understand each other better. Another interesting change is that we need less synch meetings.
So far the biggest challenge is respecting individuals preferences, as the more people collaborate together, the more it becomes implicit expectation, whereas not everyone wants to do it, or some days you want some others not. So making sure that we don’t get pulled to any extreme is very important. Time zone differences is another challenge, sometimes because energy level really differs and its hard to find the harmony working together.
While it’s a bit early to make right conclusions, we already have some learnings and outcomes. We do see increase in overall happiness and mood in the team, knowledge is shared more effectively and we started slowly to break silos. Another interesting side-effect seems to be that regardless people collaborate on particular problem or not, disagreements somehow got easier to resolve, as we understand each other better. Another interesting change is that we need less synch meetings.
So far the biggest challenge is respecting individuals preferences, as the more people collaborate together, the more it becomes implicit expectation, whereas not everyone wants to do it, or some days you want some others not. So making sure that we don’t get pulled to any extreme is very important. Time zone differences is another challenge, sometimes because energy level really differs and its hard to find the harmony working together.
I do almost all my work completely collaboratively in a "pair" and have run into literally zero of the problems outlined here, is this a unique case?
We don't have problems with roles or scheduling or anything of the sort and we're 5 hours apart timezones as well
I wonder if I'm the outlier or if this article is bikeshedding about nonexistent problems
We don't have problems with roles or scheduling or anything of the sort and we're 5 hours apart timezones as well
I wonder if I'm the outlier or if this article is bikeshedding about nonexistent problems
Hey, I am the author of the article. Happy to hear that it works well for you. I have been personally where you are only in office environment, and fair point, it does and can happen that things work smoothly.
That said, I have seen it more not working than working. I think it depends a lot on the environment and conditions that people are working/operating, for example we are a relatively newly formed team (90% of the team joined within last 10-12 months), and we definitely see the outlined problems more, while we learn how it is to work together.
That said, I have seen it more not working than working. I think it depends a lot on the environment and conditions that people are working/operating, for example we are a relatively newly formed team (90% of the team joined within last 10-12 months), and we definitely see the outlined problems more, while we learn how it is to work together.
My partner works for a company that actually does pair programming in the interview process, to ensure all new hires perform satisfactorily using that method of development. All development there is done using pair programming and the general overall sentiment is that it improves productivity over solo development. So it works if everyone you hire works well with it.
How many developers even pair program regularly? 0.1%? Maybe?
That sounds truly awful
So, what's the point of collaborative programming for someone who already knows how to manage their time (including focus time), keeps track of WiP and insists on writing down all the knowledge gleaned from the code during reviews?