Code editors & workflow

Editor debates online tend to fixate on small things: which colour scheme is easier on the eyes, which one ships with the better Vim emulation, which one has the cleanest tab bar. None of those are wrong to care about, but they are not the decisions that change how productive you are six months from now.

The decisions that matter are larger and rarer. They are the ones you make once, live with for a long time, and only revisit when the work itself changes shape. There are four of them. The order matters — answering the first one constrains the next three. Walk through them in sequence and the editor question almost answers itself.

The rest of this guide is structured around those four decisions. Each section explains what the decision is, what the trade-offs look like, and which of the posts in this topic goes deeper if you want to read past the framing.

This is the first and largest decision. Everything else depends on the answer. A cloud editor — ShareCode, CodeSandbox, StackBlitz, Replit — runs in a browser tab and stores your work on someone else's server. A desktop IDE — VS Code, JetBrains, Vim, Emacs — runs on your machine and stores your work on your local disk. The split is sharper than it sounds, because the things you can comfortably do in one are awkward in the other.

Cloud editors win the moment you need a second human in the document. Sharing a link is free; sharing an IDE workspace is not. They also win when the work is short-lived — a quick experiment, an interview, a debugging session with a teammate, a code snippet you want to embed in documentation. The setup cost is zero and the cleanup cost is zero. You open a tab, do the work, close the tab.

Desktop IDEs win the moment the work is large and stable. A real codebase with a build system, a debugger attached, a language server doing heavy indexing, dozens of files open at once — that work has not yet been matched by anything running entirely in a browser, and probably will not be soon. The IDE knows your file tree, your dependency graph, your git history, and can react to all of them in milliseconds because they live on the same machine.

The honest framing is that most working developers want both, configured to do different jobs. The IDE is the home base. The cloud editor is the place you take work that needs to leave the home base — a teammate, a class, a candidate, a friend. The comparison posts in this topic go through the specifics; if you want the side-by-side feature table, start there.

Within whichever side of the cloud/desktop split you chose, there is a second decision. Do you want a generalist editor that handles every language reasonably well, or a specialist that goes deep on one stack and is mediocre at the rest?

Generalists — VS Code on the desktop, ShareCode in the cloud — are the default answer for most developers because most developers touch more than one language in a given week. You write some TypeScript, some Python, some shell, some Markdown. A generalist that can do all of those without you reconfiguring it is worth more than a specialist that is excellent at one and useless at the next.

Specialists earn their place when one language is the majority of the work. A senior Java developer writing Java forty hours a week will be more productive in IntelliJ than in any general-purpose editor, because IntelliJ understands Java idioms at a depth no extension can match. The same is true for the senior Go developer in GoLand, the senior C++ developer in CLion, and the data scientist living in JupyterLab.

The fragility of the specialist choice is what to do when the work shifts. Promotions, new projects, and new teams change the language mix. If your specialist no longer fits the work, the switching cost is real — months of muscle memory, plugin configuration, and keybindings. A generalist absorbs the same shifts for free. For most developers, most of the time, the generalist is the lower-regret answer.

Most developers underrate this decision because the friction looks small in any single instance. The friction adds up. Over a year, the time spent moving code between humans — into chat, into pull requests, into screenshares, into pastebins — is significant. The right tooling makes that friction nearly invisible. The wrong tooling makes every handoff a small negotiation.

The handoff options worth knowing fall on a spectrum. At one end is the static paste — Gist, Pastebin, a chat message with triple-backticks. Cheap to produce, useless once you need to edit. At the other end is the full collaborative session — both people in the same document, both cursors visible, both able to run the code. Higher setup, far higher utility once you are inside it.

Which end of the spectrum to default to depends on how often you hand code over. If you do it a few times a week, a static paste is fine and the live-collaboration setup is overkill. If you do it a few times a day — interviews, code review, mentoring, debugging across timezones — the static paste is the wrong default and you should be defaulting to a collaborative session. The how-to-share-code tutorial in this topic walks through the specific workflow ShareCode is designed for; the use-cases post catalogues the five most common workflows teams adopt around it.

The fourth decision is the one most developers never make consciously. They picked an editor at some point, it worked, and then the work changed underneath them without the editor changing to match. The result is a slow, ambient productivity tax that no single day exposes but a quarter of work makes obvious.

The signals are reliable. You find yourself fighting the editor more than you fight the code. You use an external tool for something the editor should handle natively. The keyboard shortcuts you learned three years ago no longer match how you actually work. Newer teammates run faster on the same problems because they have a config you do not.

Reading those signals is not a reason to panic-switch. It is a reason to revisit the first three decisions. Maybe the cloud-or-desktop call has shifted because half your work is now interviews and screenshares. Maybe the generalist-or-specialist call has shifted because you have specialised harder into one language. Maybe the handoff call has shifted because you joined a team that pairs daily. The four decisions are not one-time. They are revisited every year or two, quietly, when the work tells you to.

If the four decisions above point to a different editor than the one you are using, the switch is worth making — but only after a small pre-flight check. The switching cost is mostly a one-time hit, but it is a real one, and a checklist saves the worst of it.

First: export everything you can. Snippets, keybindings, code-formatting config. If you can move them across, you keep the muscle memory; if you cannot, plan to rebuild them over the first week. Second: dual-run for a week. Keep the old editor available alongside the new one. The new editor will fail you somewhere unexpected; the old one is the fallback while you patch the gap. Third: write down what you miss. Not what you cannot do — what you can do but slowly. Those are the items you will spend the second week fixing. Fourth: do not switch in the middle of a deadline. The productivity dip is real even when the switch is correct.

Most editor switches that succeed share a profile. The developer knew what they wanted to gain, accepted that they would lose something specific, and did the switch outside the critical path of any deliverable. Most editor switches that fail share an opposite profile — switched on a whim, did not budget the dip, and reverted before the new editor had finished compensating for the loss.

Start with the cloud-vs-desktop comparison if you have not made that call yet. The post is short, the framing is the one the whole topic builds on, and reading it first means the rest of the posts will feel like they answer questions you already have.

Read the cloud-editor landscape post next. It is the closest thing to a reference table on the major online editor options in 2026, written by someone who has spent time in each. Useful even if you have already chosen one, because the comparison reveals what the other options would give up.

Then the sharing tutorial, which is the practical foundation for any workflow that involves handing code over. Even if you do not use ShareCode, the workflow shape generalises.

Close with the use-cases post. It is the lightest of the four, but it is the one that maps the abstract sharing workflow onto specific human situations: interviews, teaching, debugging across timezones. Read it last because the examples make more sense once you have the framing the other posts provide.