“A teammate asked how they managed stay in flow state — the editor should get out of the way and let them write. They started explaining and realized every step ran through vscode. Specifically, extension marketplace with 40,000+ extensions had become load-bearing.”
When I'm they've just cloned a new repo for a project they're inheriting, I want to stay in flow state — the editor should get out of the way and let them write, so I can understand their codebase quickly when working in an unfamiliar part of it.
A full-stack developer with 2–10 years of experience for whom VS Code is the primary tool of their craft — the place they spend most of their working day. They have a VS Code configuration that took months to arrive at and that they bring to every new machine. They know their extensions. They know their keybindings. They have an opinion about whether Prettier should run on save. Their editor is not the default installation — it's a reflection of how they think about working.
To make vscode the system of record for stay in flow state — the editor should get out of the way and let them write. Not aspirationally — operationally. The kind of intention that shows up as a daily habit, not a quarterly goal.
The tangible result: stay in flow state — the editor should get out of the way and let them write happens on schedule, without manual intervention, and without the anxiety of extension conflicts that cause subtle, hard-to-diagnose issues. vscode has earned a place in the daily workflow rather than being tolerated in it.
They've just cloned a new repo for a project they're inheriting. The existing team used different extensions, different formatting settings, and committed their `.vscode` folder with settings that conflict with their own. IntelliSense isn't working because the TypeScript version in the project doesn't match their global config. They're going to fix this. It will take longer than it should. They will not remember how they fixed it.
Has 20–40 extensions installed. Uses GitHub Copilot. Has a settings sync connected to their GitHub account. Works across 3–5 repositories simultaneously. Uses the integrated terminal as their primary terminal. Has configured split panes and workspace layouts for different project types. Uses git integration inside VS Code for staging, committing, and viewing diffs. Has tried other editors — JetBrains for Java work, Cursor for AI-first workflows — and returns to VS Code as the base.
They've stopped comparing alternatives. vscode is open before their first meeting. Tasks and launch configurations automate build, test, and debug workflows. The strongest signal: they've started onboarding teammates into their setup unprompted.
It's not one thing — it's the accumulation. Remote development sessions can be unstable with SSH connections dropping that they've reported, worked around, and accepted. Then a competitor demo shows the same workflow without the friction, and the sunk cost argument collapses. Their worldview — the best development environment is the one you stop thinking about — makes them unwilling to compromise once a better option is visible.
Pairs with `github-primary-user` for the full development workflow from code to review. Contrast with `cursor-user` for the AI-native IDE vs. AI-extended traditional IDE tradeoff. Use with `linear-primary-user` for the integrated engineering workflow: issue → code → PR → close.