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.
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.
I agree being able to see the pointer is important, since not everyone is good about moving the cursor around.
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.
Feature Toggles: https://martinfowler.com/articles/feature-toggles.html
BEAM (Erlang, Elixir) provides hot-swappable code and lots more
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.
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.
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.
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.