I only joined Zed, the company, a week ago, so take this with a grain of salt, but:

I've never really used real-time sharing (tried VS Code's Live mode and other apps) for longer than just 1-2 attempts, but at Zed things are different somehow. Everybody is constantly available in a channel and people just hop in or out. In the last 7 days I spent 3-5hrs every day pairing with others, using Zed's live mode. No video, only audio and sharing code in Zed (no video was weird at first, but now I think I'm starting to get used to it?)

IMHO it's a combination of culture and technology, but when the mix of that is right it really feels game-changing.

> In the last 7 days I spent 3-5hrs every day pairing with others

This sounds remarkably inefficient?

That may depend on what you're trying to do. If you are figuring out something tricky, then lots of quiet head down time is what you need. Every interruption hurts when you are concentrating.

However, a lot of the time is just figuring out how to glue together multiple systems. Being able to pull in various people to interface little bits is priceless. There is no flow here, only collaboration.

Are you kidding? Sounds remarkably efficient specifically because OP just joined a week ago.

I think what’s nice is that it’s frictionless. If I can just click a button to see someone’s editor, then there’s no dance with sharing screen, I can open files I need to see, etc.

With standard sharing you always end up trying to direct people to do things instead of just showing them.

Zed developer here, You can come try it out with us right now if you like: https://zed.dev/channel/zed-283

Though you'll have to sign the CLA first :)

Thanks for the offer. I unfortunately don't have a mac but I appreciate it :)

This looks really cool, but I have a suspicion my employer would be against external connections. Any distant plans in the future for an enterprise/onprem license?

Yes! In fact, that's one of our planned revenue sources, once we've fleshed things out :D :D

When a person tells another person "you need to do X" or "I did Y and it didn't work on my machine", they sometimes ignore important details due to their own curse of knowledge. That's when I need a shared terminal/editor so that both parties know exactly what is happening.

I don't frequently share terminal/editor but occasionally need to do so, maybe a handful times a year. Most of times when I tell a new colleague "hey, connect to my tmux socket by running this command / opening this link", they were amazed and thought it was magical. I am not a Zed user but it's always welcome to see people making effort to make pair programming easier for everyone.

Now, I don't know how I would feel if one day my colleague send me a sharing session link that can only be opened by a particular editor.

The benefit as a viewer is you can drive navigation on your own without asking the presenter to go to a certain spot. So the presenter can be discussing a problem or a function, and you can investigate/gather context without interrupting them, among other things.

I personally can't live without it, and am almost annoyed when folks aren't using VSCode/have no way of doing a live share. Screen share sucks.

In our 100% remote startup, VSCode live share and Slack Huddles is how we work through the really tough stuff together.

We should probably do it more often than we do, but there is a real fatigue after an hour or two.

what do you think causes the fatigue?

I think it's mainly the intensity of the sessions. You've got someone on the other end of a call so you don't really chill and take it easy. Creates some urgency to get the thing done and you're just a bit fried by the end.

It is such a game changer for me. Pair programming or multi pair programming if you will, suddenly has 0 barriers. Including others in your session with no overhead changes things completely. Before I would rarely include others in my processes because it cost too much. Now I'll do it whenever... Switched from sublime and got my coworkers macs just to be able to use zed and work in this way.

It is extremely important it works fast and fluid, and zed is the only one I've tried that nails it. There are still a few things that needs tweaking wrt. undo history, but I'm sure they'll get that to feel intuitive in the end.

I've greatly enjoyed pair (and trio) programming with friends using it (vscode's version of this) on side projects. For the most part I'm not sold that pair programming is an efficient way to program, but it's a nice social way to program.

If you're going to do it, especially remotely, it's really nice to have your editor support it instead of just using screen sharing.

I've never really pair programmed - I've worked on joint projects, of course, but collaboration occurs over discord/github. I'm intrigued - what does this actually consist of? Does one person write one function and another write the next while you chat about what needs to be done?

We tend to work on one 'thing' at a time. Sometimes that means we're both/all on the same few lines of code writing a new function - at which point one person is usually doing all or nearly all the typing. If you then need to go define a constant somewhere else in the code or something the other person does that so you don't have to pause. Other times one thing involves code in various places because you're doing something like changing what arguments a function takes, or fixing compiler warnings, and we do spread out and handle instances of the thing we're fixing as we come across them.

Lines of code per second it's closer to one person than the 2 or 3 people involved, but the quality of those lines definitely improves a bit as people spot each-others mistakes/less than optimal choices. (Edit: But I'd emphasize we're doing this for fun, not to maximize productivity)

Thanks for elaborating, that sounds pretty fun.

Often one person is the driver, the other is a director.

Like being in a rally car :)

As a senior engineer, it really helps when helping junior engineers. When I'm on a call and we're sharing screens it gets really annoying having to tell them "no, go up. Go up, all the way up, the button at the top. THE TOP"

This. The worst thing is that I get mad at them for not doing what I want them to, faster, when the tooling and my crooked explanations are at fault, not them. Not that I mention that out loud, but sometimes I feel ashamed for those feelings.

Having real time collaboration that works so seamlessly as Zed apparently does would really get me to consider switching IDEs!

Seems like VNC or similar would be a better solution. Might need to use a terminal or other program. Instead of confining it to one application.

I'm using VNC for coworking/mentoring sessions and it works very well for us (it's lower latency, higher frame rate, sharper picture than typical screen sharing, and allows both/all sides to interact with the session and use the mouse pointer to point to things). We're using Linux on both the server and client side. There's a full desktop on the remote side, to fully interact with that (to have key bindings go to the server instead of the local desktop) the client needs to be made full screen. Latency isn't really an issue even between central US and Europe.

I've automated the set up of a Debian server for the purpose using[1]. There are some details on how to run it and how to set up the client side here[2] (probably slightly outdated). Feel free to mail me about it.

[1] https://github.com/pflanze/chjize [2] https://github.com/pflanze/chjize/blob/master/client-side-to...

You can share terminals in live share and even share servers etc. I’ve had no issues and I’ve built multiple teams that are very collaborative at this point. Dozens of engineers

I feel no shame for getting mad at my coworkers

Maybe not your peers, but I hope you feel at least alittle guilty for being mad at junior developers under your guidance:)

It sounds nice in theory but I've noticed I cannot focus when somebody else is looking over my shoulder. It could be useful as a way to occasionally show somebody around the code base though.

The anxiety of someone constantly peering over my shoulder in a virtual sense greatly amplifies any imposter syndrome already present.

Every typo, every goofy idea (which clearly would not work), etc. all laid bare to see in realtime.

Pair programming was the main reason I left a company after management rolled it out to every team.

Same here, for me it is a gimmick without much value over a screen sharing session.

I disagree.

For example, in vscode if the sharer start a http-service the port can be port forwarded through the session so anyone in the session can interact with the service.

Pretty neat and useful!

I find it as interesting as mob programming.

Anyone can interact with common team servers.

It is one of those things that developer advocates love to show at conferences.

Maybe I'm opening the lid to the industry's best-kept secret, but every team I've worked on used SSH with a shared tmux session for pairing. There are probably more complex tools that cover every use case, but I never encountered much demand for one.

That is pretty cool, I didn't know about that. I could see it being useful in some niche circumstances.

Honestly, it's pretty cool in my experience; in VSCode everyone gets their own "client-side navigation" so while you are typing something, your coworker can go look up a function for you in another file, etc. Even though they exist in "your" instance, they still get Go To Definition, Find References, type-on-hover, etc.

Realistically though it doesn't replace every instance of screen sharing, for me. It's also cultural to some extent I guess. For things like debugging or being intro'd to a new codebase, I think it's great, though.

ime, real time sharing works best when there’s shared context. otherwise it’s essentially an artist rendering a public performance in the presence of an audience. unless you derive some joy from watching people code it could get frustrating real fast.