Pair programming has two common shapes.
Sometimes you need true collaborative editing: two people typing in the same project, moving around the codebase, and making changes together. Tools like VS Code Live Share and JetBrains Code With Me are made for that.
More often, the request is smaller: “Can you look at this error with me?” or “Can I show you what I just got working?” That job usually needs a clear live view, not another editor session.
Linkside is built for the second shape: create a room, send a link, show the screen, close the room. No account gate. No IDE extension. No recording to clean up later.
What this is
A Linkside session is one-way screen sharing. The host chooses what to share from the browser’s screen picker. Guests can watch, but they cannot type in the host’s editor, move the host’s mouse, or take remote control of the machine.
That limit is the point. A lot of quick pairing is not “please co-author this change with me.” It is “please be here while I walk through the thing that is confusing me.”
The flow
- The driver opens linkside.io/app/create and creates a room.
- They paste the invite link into Slack, Discord, iMessage, email, or wherever the team is already talking.
- The guest opens the link in a browser. No account, email, download, or IDE setup.
- The host clicks Share and chooses the IDE window, terminal, browser tab, or screen they want to show.
- Both people talk using whatever voice path makes sense for the team.
For code, share a specific window when you can. If you share your whole screen, the guest may see notifications, other apps, or a different workspace when you switch context. The browser asks the host what to share each time, so make that choice deliberately.
Why it feels live
Linkside is peer-to-peer-first. The browser tries to send the media directly from the host’s browser to the guest’s browser using WebRTC. Linkside’s signaling service helps the browsers find each other; it is not meant to sit in the middle of the video path when a direct connection works.
When that direct path is blocked by a restrictive network, corporate VPN, or difficult NAT setup, the session can fall back to an encrypted TURN relay. That relay adds a network hop, and free rooms get a 5-minute relay trial before a license is needed for unlimited relay use. The important privacy point is that the media stays encrypted in transit on both paths. The relay routes encrypted packets; it does not see the screen contents.
For a quick coding session, this shape works because the driver is still using their local IDE at local speed. The guest does not need input synchronization. They need the stream to be current enough to follow the command, the stack trace, the debugger step, or the UI state.
What it’s good for
Use a browser screen share when the work is mostly “watch and reason together”:
- Reading an error in context. The driver shares the terminal, browser, and nearby code instead of pasting a cropped stack trace into chat.
- Walking through a debugger. One person steps through the program while the other watches variables, call paths, and state changes.
- Showing a feature in progress. A 90-second demo should not need a calendar invite or a plugin install.
- Reviewing a branch before checkout. The author can walk through the diff, the behavior, and the failing case before you decide whether to pull it locally.
- Coaching without taking over. The less experienced engineer drives. The reviewer asks questions and points out patterns, but cannot grab the keyboard.
That last case matters. The lack of remote control can be useful for mentoring because it keeps the person with the problem in the driver’s seat.
What it’s not good for
Be precise about the limits:
- You cannot edit the host’s file. If the session needs both people to type, use a collaborative editing tool.
- You can’t run the code on your machine. It’s their machine, their environment, their working set.
- There is no replay. Linkside does not record sessions. When the room ends, there is no transcript or video to re-watch.
- There is no persistent room. Rooms are temporary. The signaling worker keeps room state only while the session is live, then the room is cleaned up.
- The guest sees what the host shows. Share the IDE window when possible. Share the whole screen only when you are comfortable with everything that might appear there.
- Desktop hosting is the best fit. Chrome and Edge on desktop are the recommended host experience. Mobile is better treated as guest-only.
When to switch tools
Use the heavier tool when the work really needs it:
- If the session needs both people to type into the same buffer, use VS Code Live Share or JetBrains Code With Me. Editor collaboration is worth the setup cost when both people need to edit.
- If the session is long and both people are actively changing code, set up the right editor collaboration workflow. The setup cost makes sense when you will use it for the whole session, not just a five-minute question.
- If you need a recording or transcript, Linkside is the wrong product. It deliberately does not provide that.
For everything in between, open a Linkside room and send the link.
What this changes about how you pair
The shape of a tool changes the shape of the habit. When the cost of starting a quick pair session drops to “send a link,” you stop over-explaining weird bugs in chat. You show the actual state: the failing test, the tab with the console error, the debugger paused on the bad branch, the half-finished UI.
That is the right trade for ad-hoc pairing. You give up remote editing and persistence. You get a private, temporary, browser-only room that is quick enough to use before the moment passes.
Open a room and send the URL to whoever you’d otherwise have asked to schedule a Zoom.