Has anyone here actually used realtime collaboration in an IDE productively, like Live Share, Code With Me or something similar? I really like the idea: less "can you quickly share your screen?" and more sitting together at the problem right away.
I’m curious where you see the added value – pair programming, support, onboarding, code reviews? And when does it get chaotic, if suddenly two people edit the same file at the same time?
This post has been automatically translated.
I've used Live Share a few times for debugging and onboarding; it's really invaluable for that. Especially when the other person can immediately set breakpoints, look at logs, or quickly test a small change, it saves the whole "scroll over there" spiel. For real pair programming, though, I would definitely assign driver/navigator roles — otherwise both people type half‑simultaneously and in the end nobody remembers why the code looks the way it does.
What has worked for us: one person types while the other comments or highlights spots. Switch after 20–30 minutes or when you get stuck. Do you also use it across remote containers/WSL? Depending on the project I've run into annoying differences with paths and local tools there.
This post has been automatically translated.
I agree: for debugging that “just scroll over there” chatter is really the biggest win. Driver/Navigator sounds formal at first, but it prevents exactly the kind of chaos I asked about above. Switching every 20–30 minutes is also a good trick against tunnel vision — and for onboarding the new person learns not only the code but also the mindset behind it.
I’ve only used Remote Container/WSL with this experimentally so far. In principle it works, but I’d clarify beforehand who gets access to which secrets, databases, and local services. Especially during support sessions, a stripped-down dev setup is probably more relaxed than accidentally exposing half of your local environment to the guest.
This post has been automatically translated.
For me, the sticking point isn’t the IDE but the environment. Live Share seems harmless at first, but as soon as someone can use the terminal, running processes, or port forwarding, it’s effectively temporary access to your development machine. That’s why I would never share secrets through the real local `.env`; instead, I’d work with demo accounts, mock services, or a separate dev container.
I used Code With Me once for a production bug: it was great from a technical perspective because my colleague could follow the request flow directly. It became annoying when his local configuration had different feature flags than mine—we spent ten minutes looking for a “bug” that was actually just an environment difference. So before the session, briefly compare versions, branch, configuration, and data state; that saves more time than any collaboration feature.
This post has been automatically translated.
For production bugs, that distinction would therefore be important to me: look at the code and the requests together, but not necessarily share the entire local environment. Ideally, the session runs in a dev container with a fixed Compose setup and a clear `dev.env.example`. Feature flags, locale, time zone, and database state should be documented or reproducible as much as possible—otherwise you end up debugging two different applications.
What I also find helpful in sessions like these is recording the current Git state and the active flags once before starting, then going through the diff together afterward and not simply leaving the changes in the workspace. Especially with Live Share, it’s easy to forget that the guest may have changed files or started processes. For sensitive projects, I would also leave guest access read-only by default and grant write and terminal permissions only briefly for the specific step.
For reviews, on the other hand, I find real-time collaboration somewhat ambivalent. It’s great when you’re working through a complex section together, but in my opinion it isn’t a substitute for a regular PR process: otherwise, comments, traceable commits, and a later review pass are missing. For us, the process would be more like “analyze together and build a small fix,” followed by a clean PR with tests and a second review.
How have you handled permissions—do you use fixed roles/session profiles for this, or is everything configured manually each time?
This post has been automatically translated.
The point about keeping the Git state fixed is really important. I’d add a small checklist before a session: branch/commit, feature flags, time zone/locale, the container version used, and who is allowed to operate the terminal or debugger. Otherwise, you quickly end up with “works on my machine” — just with two different states. For sensitive projects, I’d also consider it important that access is actually terminated after the session and, ideally, logged.
For code reviews, we’ve found that a shared session with only one person having “write access” works better, while the other comments. For onboarding, the newcomer can then take the wheel themselves, even if it’s slower. Do you actually use the IDE’s integrated chat/commenting features for sessions like these, or does communication still happen through Teams/Discord?
This post has been automatically translated.
The checklist sounds sensible, but I can already see the moment coming when a little change-management meeting takes place before every 15-minute help session 😄 For me, the pragmatic middle ground would be: a standard dev container plus a short session header in the chat with the commit, flags, and purpose of the session. At least then it would still be possible to understand later what state things were in.
What I sometimes miss in the tools is truly granular permission management. “Allowed to change code” is still reasonably clear, but the terminal, debugger, files outside the project, and port forwarding all represent very different levels of risk. Especially during onboarding, I’d like to allow debugging while completely blocking shell access and access to `.env` files. Otherwise, the friendly colleague is theoretically only one command away from “Why does your computer know about the production VPN, anyway?”
By the way, I don’t always think a live session is better than a regular PR for reviews. The session is useful for discussing architecture or tricky parts together; comments and decisions should still go into the PR afterward, though, otherwise they disappear into the spoken fog. A short note with the open points and the final diff is often enough.
How do you actually handle cleanup afterward? Is the session merely ended, or does someone also check active permissions, port forwardings, and temporary user rights? I don’t completely trust the tools blindly there—“window closed” unfortunately doesn’t automatically mean the same thing as “access revoked.”
This post has been automatically translated.
Fine-grained permissions are also the point where I feel the tools still need to mature a bit. “Can modify code” and “can execute arbitrary shell commands” are simply two completely different risk categories. I’d like to see a simple profile for each session: read-only for reviews, write access but no terminal for pairing, and breakpoints/logs in addition for debugging—and all with an expiration time instead of permanent access.
For short help sessions, we’ve found it useful for the guest not to work on the live environment at all, but to get an isolated container instead. It was a bit slower at first, but it saved us several discussions about local configurations. Interactive debuggers are trickier: someone really has to control the process, otherwise one person is setting a breakpoint while the other keeps clicking through. How do you handle this—fixed roles during debugging as well, or do you simply coordinate in the call?
This post has been automatically translated.
In my experience, the “slightly slower” at the beginning quickly turns out to be cheaper than troubleshooting in a half-shared local environment. Especially for support sessions, a standardized session profile would be practical: purpose, permitted actions, expiration time, and then an automatic brief export of the commit, container image, and any commands that may have been executed. Not as surveillance, but rather so that you still know afterward what actually happened.
Something else I’d find interesting: How do you handle changes during the session? With pairing, collaborative writing is clear, but for a spontaneous bug-fixing session, I’d probably create a temporary branch or patch first and only then merge it deliberately. Otherwise, the line between “we’re investigating this” and “someone changed the code on the side” becomes blurred pretty quickly. Do you have fixed rules for this, or is coordinating in chat enough for you?
This post has been automatically translated.
Don’t have an account yet? Register yourself now and be a part of our community!
