I have been working in teams where pairing was greatly encouraged as well. It might not have been as spontaneous as it is at Zed but still.
For me I found it to be extremely energy draining. Not because there were the wrong people or the tools we used were not good enough but just in general it is just energy draining to me...
Also from what I have heard it is usually claimed that the produced code has a greater quality due to the knowledge sharing while creating the code.
However I found the opposite to be true quite often: Nobody "owns" the produced code, not everyone involved understood all of it 100% especially when they were typing while someone else was giving the direction.
Moreover I found myself making shortcuts during the sessions (e.g. adding TODOs) in case something became "off topic" or some people were not too familiar with some part of it.
So I came to the conclusion that:
I want to pair if something needs to be explained or walked through by someone else and it would take way longer asynchronously.
But as soon as it becomes clear what a solution would look like then I would end the session and either me or one of the others would wrap it all up alone in a normal PR.
I fully get that. I think it depends on a lot on who you're working with, what you're working on, what the setup is, how much you both know about the code/the problem, etc.
It sounds exciting as you describe it, but it didn't stop me from being worried that this sort of work setup comes with many interruptions, preventing people from really focusing on their work for extended periods of time. I wonder if people who worked on Zed with this approach for several months feel any irritation because of that. And if do feel some, how do they balance it out, like, how often do they mark themselves unavailable for pairing, and the such?
Also, the approach has the obvious but strong limitation that it only works when people are there at the same time. But of course, if the editor is on par with the alternative one would use, then one is not any _worse_ off with it for async collab, either.
There's barely any interruptions. Slack is quiet, Zed is quiet. People just don't join a channel when they don't want to pair. I've also had full days without pairing and nobody even reached out to me. Join a channel if you're up for pairing, don't if you're not.
> only works when people are there at the same time
Yep. I think that's what I tried to say: it's about people willing to be there, working synchronously.
I have been working in teams where pairing was greatly encouraged as well. It might not have been as spontaneous as it is at Zed but still.
For me I found it to be extremely energy draining. Not because there were the wrong people or the tools we used were not good enough but just in general it is just energy draining to me...
Also from what I have heard it is usually claimed that the produced code has a greater quality due to the knowledge sharing while creating the code.
However I found the opposite to be true quite often: Nobody "owns" the produced code, not everyone involved understood all of it 100% especially when they were typing while someone else was giving the direction.
Moreover I found myself making shortcuts during the sessions (e.g. adding TODOs) in case something became "off topic" or some people were not too familiar with some part of it.
So I came to the conclusion that:
I want to pair if something needs to be explained or walked through by someone else and it would take way longer asynchronously.
But as soon as it becomes clear what a solution would look like then I would end the session and either me or one of the others would wrap it all up alone in a normal PR.
I fully get that. I think it depends on a lot on who you're working with, what you're working on, what the setup is, how much you both know about the code/the problem, etc.
It sounds exciting as you describe it, but it didn't stop me from being worried that this sort of work setup comes with many interruptions, preventing people from really focusing on their work for extended periods of time. I wonder if people who worked on Zed with this approach for several months feel any irritation because of that. And if do feel some, how do they balance it out, like, how often do they mark themselves unavailable for pairing, and the such?
Also, the approach has the obvious but strong limitation that it only works when people are there at the same time. But of course, if the editor is on par with the alternative one would use, then one is not any _worse_ off with it for async collab, either.
There's barely any interruptions. Slack is quiet, Zed is quiet. People just don't join a channel when they don't want to pair. I've also had full days without pairing and nobody even reached out to me. Join a channel if you're up for pairing, don't if you're not.
> only works when people are there at the same time
Yep. I think that's what I tried to say: it's about people willing to be there, working synchronously.
I really like this approach, never used it professionally, but with my friends while working on personal projects, it's really fun
I think it's time search for a nvim plugin for crdt