Zed is lovely and I hope it becomes super successful but this kind of mass collaboration might be ok for meeting minutes... maybe. But thinking of it for coding it gives me shingles. Code by mass live committee. Yikes.
I think it's a fun and interesting idea for training junior engineers and possibly for other use cases. Suggesting alternatives to (perceived) bad practices the instant you see them could be helpful for many people, and also save a lot of future time for reviewers.
I could also see it as a potential productivity aid. Person 1 sees Person 2 is writing something and they don't want to be seen as idle, so they start working as well. This might sound oppressive but a lot of people who struggle with ADHD/procrastination/akrasia actually receive great benefit from that structure. Similar to that startup that forces you to code while screensharing with a stranger in order to push you to work, or people who code in cafes/libraries to be more productive.
As long as it's not an organization requiring it for senior engineers, I could see promise to it as an eventual common new paradigm.
You can use remote screen control with Zoom to train up juniors. More often than not, you'll want to share the whole screen so you can show them webpages and other things that do not live in an IDE
Pair programming can be really great. Or horrible. Depends entirely on the people.
This would be good for code-walks too though. Instead of having to share your screen and hope the video comes through well. Everyone can follow along in the comfort of their own editor.
it's probably subjective, but I find these collaboration features can be overused for this kind of thing.
If someone is walking me through something, I just want to see what they see so I can focus entirely on what they're saying and no part of me is distracted by having to follow along or seeing other code.
I know typically these collab modes have an auto follow feature, but it's not as simple as just read only video being streamed to you, there's loads more ways it can go wrong and add noise / distraction that provides no benefit.
re: pair programming, the lion's share is moving to be with agents, not humans.
I think the fundamental flaw that dooms this feature is non-developers. Do teams and orgs want more than one chat system? I suspect not. It will be very hard (impossible) to convince people who can pay back the VCs to switch zed as the basis for their chat for all employees.
> video comes through well
I cannot recall the last time resolution or latency was an issue (zoom/meet)
> Everyone can follow along in the comfort of their own editor.
With different screen resolutions, you cannot be sure everyone sees the same code. Video guarantees this
Let's lean into the chaos and see what it might give us. Imagine a production application deployed directly from a non-version-controlled directory. Anyone on the team can edit the files, at any time. Insane? Probably. The disadvantages are easy to see.
But the positives are really compelling: 1. make small, granular testable changes; 2. use feature toggles; 3. refactor intensely and concurrently; 4. always work on the latest code; 5. use in-code documentation instead of GitHub/etc workflows; 6. explore continuous, incremental, hot-swappable code deployment.
Doesn't thought of ditching all the wasted motion and ceremony around logging async work and just coding sound glorious? I'm actually not a "move fast and break things person" usually. But the idea of moving so fast that broken things will only stay broken for a tiny fraction of the time is pretty compelling. There is also an intensity that comes from real-time interactions where a team needs to reach consensus quickly.
Pair programming usually has a single "driver" on the keyboard to keep things controllable. Here, everybody is driving: "dozens of cursors are concurrently editing the same file in real-time."
a few years ago our company used Screenhero which allowed editing with multiple cursors while screensharing.
The experience was actually quite nice for two-three people but we always had the "ok let me type now" flow. Multiple changes happening at once sounds hyper distracting.
my understanding is that this is the dynamic in modern college classrooms. everyone opens a big shared google doc for notes and they all collaboratively edit a set of notes in real-time.
or at least that's what i've heard, no idea if they actually do it.
it is nice to see a crdt backed editor tool for markdown and code though. gdocs markdown support has been lacking for years.
> or at least that's what i've heard, no idea if they actually do it.
Yeah, we used to do that back when I was in college. It's only for certain classes and most people usually kept their own notes too (or instead, why write twice). Or some classes ban laptops so you'd write on paper anyway.
Yeah, people are different, but a lot of this difference results from various constraints, such as cultural practices around collaboration or technological options. Many of these limitations probably shouldn't be locked in by our tools or norms.
When learning a new way of thinking or moving (i.e. martial arts) people often really benefit from high-bandwidth, low-latency, shared-viewport-onto-reality interactions. Watching someone's cursor move while they talk is one way to get a window into their problem-solving toolkit.
