How to share code with someone: six options compared

Getting a piece of code in front of another person should take ten seconds. It regularly takes twenty minutes, and the reason is almost always that someone picked a method optimised for a different situation — pasting eighty lines into a chat window, or opening a pull request for a question that needed one sentence.

Six methods, what each is genuinely for, and the specific case where each is the wrong choice.

1. Paste it into chat

Good for: under about fifteen lines, where the reply is a sentence.

Chat wins on friction — zero — and on context, since the code sits inside the conversation that motivated it. For a short function or a stack trace, nothing else is worth the extra step.

Wrong when: the snippet is long enough to scroll. A hundred lines in a channel destroys the readability of the channel for everyone else, cannot be edited after posting, loses indentation in some clients, and becomes unfindable within a day. The failure is social as much as technical: people stop reading a channel that is full of code dumps.

The threshold is roughly “does it fit on one screen without scrolling”. If not, link to it instead.

2. A gist

Good for: a self-contained snippet you want to keep and refer back to.

Gists are versioned, syntax-highlighted, commentable, and permanent. They are the right answer for a reference implementation, a configuration example, or anything you expect to link to more than once.

Wrong when: the exchange is a conversation. A gist is read-only to the recipient — they can comment, but they cannot change the code and hand it back, so every iteration is a new revision and a notification round trip. It also requires an account, which rules it out for anyone outside your usual circle.

3. A pastebin

Good for: one-directional sharing with someone you have no shared platform with. Logs, error output, a config file for a stranger on a forum.

No account, no setup, works for anyone. Expiry is a genuine feature when the content is a log with a hostname in it.

Wrong when: you need a reply in kind. Same problem as a gist, plus no history, so a corrected version is a second unconnected link. Also worth remembering that many pastebins are publicly listed and actively scraped for credentials — never paste anything with a token in it, expiry or not.

4. A screen share

Good for: showing something happening. A UI bug, a confusing tool, a build that fails in an interesting way.

Screen sharing is unmatched for demonstrating behaviour, because behaviour is exactly what a static snippet cannot convey.

Wrong when: the other person needs to work with the code rather than watch it. A screen share is a video feed: the viewer cannot select text, cannot copy anything, cannot search, and cannot fix the typo they can plainly see. They are reduced to reading line numbers aloud. Everything they contribute has to be dictated, which is slow enough to suppress most of what they would otherwise say.

This is the most commonly misapplied method on the list, because it is the default in every video call and requires no decision. For anything collaborative it is the wrong tool.

5. A branch or pull request

Good for: changes to a real codebase that are going to ship.

This is the heavyweight option and it earns its weight: CI runs, review is threaded and attributable, and the discussion is preserved next to the change forever. For anything entering the main line of a project, nothing else is acceptable.

Wrong when: the code is exploratory. Opening a PR to ask “does this approach seem sane?” imposes review ceremony on a question, and the answer comes back as a formal review of code that was never meant to be merged. It also excludes anyone without repository access, which is everyone outside the team.

6. A collaborative editor

Good for: anything where the other person should be able to change what they are looking at.

The distinguishing property is bidirectionality. Both people edit the same text at the same time, so a suggestion is a change rather than a description of a change. That collapses the loop that makes every read-only method slow: instead of “on line 12, try wrapping that in a try/catch”, you wrap it in a try/catch and they see it happen.

Wrong when: the content is a permanent artefact. A shared workspace is a whiteboard, not a filing cabinet — no review trail, no CI, no attribution per line. Work that matters should end up in version control; the editor is where it gets figured out first.

Side by side

A decision procedure

Three questions, in order.

1. Does this need to end up in the repository? If yes, use a branch. Everything else is a detour.
2. Does the other person need to change it? If yes, use a collaborative editor. If no, a gist or a paste is simpler and you should take the simpler thing.
3. Is the thing you are showing behaviour rather than text? If yes, share your screen — and if they then need to work with the code too, do both, since they are not exclusive.

Two things worth checking regardless

What is in the snippet. Credentials, internal hostnames, customer data and API keys leak through this route constantly, usually via a stack trace that somebody pasted without reading. Scan before you send, particularly for anything going to a public paste site.

Who can reach the link. Most sharing methods produce an unlisted URL, which means anyone holding it can read the content — a reasonable default that is not the same as private. If the content genuinely needs to be unreadable to the service hosting it, that requires end-to-end encryption, which is a specific technical property rather than a synonym for “secret link”.