Last updated: August 8, 2025
Let's collect the real "must have" features we genuinely enjoy using and that make our work more distraction free…. but – have some self control ok — ? We don't need your "OK – here's how I setup my VSCode with tons of bullshit." We're talking — core needs here. (you can load up and get nerdy somewhere else)
We don't want a virtual server or a terminal or git or anything else but the core text editor. (we have dedicated things for that already!)
This guide is split into two parts:
- Part 1: Why these features actually matter — Deep dives into each feature with the real reasoning and frustrations behind why modern editors are failing us
- Part 2: The practical progression checklist — Your actual setup path, organized by experience level
(Derek only cares about a very small set of things, but he cares about them a lot)
It's crazy that I have to ask for command + N to make a new text file — in a text editor… but here I am. I like this. Can we have this? And if you want a more special "new" – how about command + shift + N for I don't know… a Vue file or a special window to deal with where you want it.
I prefer to not use the side bar most of the time — but – I still want it to be there as an option — and i don't want to have it dissapear / and then spend a long time trying to find it … and not be able to find it – because it has some confusing name…
When VSCode first came out – it was like Nascar for texteditors. We don't need a bunch of icons — (it just makes everything worse).
You should be able to think of what you want and get to it immediately without looking through a file directory/sidebar. Ideally very loose just mashing of letters: lec = listing editor controller etc.)
command + P is how they do it in Sublime (for example) and it's very good. You can mash out crazy letters and it somehow still finds what you want. Some look for the first letters of words only.
In PHPStorm there's shift + shift – and it has a really in-depth search area / but it's way too complex when you're just looking for files. So, you can map a form of that that defaults to by file. Furthermore, you can create a sub-scope of files for it to search and leave out vendor etc. (but after setting this up and losing it / and resetting and so many different attempts to make the most of it — instead / we just basically memorized ways to get around it)
You should be able to zoom in and out (change font sizes) / so that when sharing your screen people can read what you're showing them. But you should be able to only zoom in the pane you are in. If all the UI also gets bigger and not just the actual code – it's not nearly as useful. Using the classic command w/ + and - (like every program does) is ideal. If you need a unique shortcut – and all the UI zooms — fuck off. srsly bro…
command + F and command shift F for across all files (and we don't need a whole specialized app that pops up and blocks everything / and ensures you can't click and copy from your text anymore)
command + D is how Sublime does it (duplicating selection) — and command + U will back up – if you went one too far. Command + shift + G will get all of them.
In Sublime there's the "command palette" (like Alfred or terminal) where (with very little keyword memorization) – you can pretty much just do anything. Need to install something? command + shift + P – then think of what you want. Want to "install" something. Create. You don't need some super ugly app store built-in to the editor.
section.name + tab ===
This is really helpful. But for the record, life still went on when it was just 2 colors ; )
This either has to be 100% right / or having none would be better. But as long as the editor makes these things possible, the community will create them.
Sublime uses command + click but VSCode and PHPStorm use that for drilling down to a class or function (which is very helpful) — but maybe that's command/shift/click?
This isn't a HUGE issue… but Sublime Text does it well with command + option + 1, 2, 3 4, 5 etc – with no strange side effects.
On a team, it's important that we're not looking at syntax changes in PRs. So, I'd like to have a set of formatting rules that are ideally shared with the team – and work in all the different editors the same. I'd like to choose whether I want to explicitly format – or auto format.
- Auto imports — as in / if you're not using Nuxt… – automatically figuring them out and pasting them in there
- Error highlighting — highlighting things that are incorrect / or unused. (very helpful!! But not worth a ton of other bullshit that counters that) — but not incorrectly — like seems to be the case — so often…
- Browser refreshing — browser refresh package for basic PHP stuff / but usually – we're using Vite anyway
- Extensibility — a way to create extensions/plugins/packages to extend the editor
- Vertical cursor placement — Also useful, but needed much less would be to click and drag down a vertical line of cursors. That's holding option and dragging. But maybe we just skip that and use
option + clickfor drilling — orcommand + shift + clickfor drilling.
OK, so – before we get into the super boring and annoying configurations and things… you know what's really great for working out ideas? Yes you do: CodePen.
CodePen is an online sandbox, and it has a lot of powerful features, but the core ones are: three little code panes for HTML, CSS, and JavaScript, and an output window. There's a lot of stuff going on behind the scenes, but for the user, they just type in their code and it updates live like magic.
Since you can create a Pen with no extra apps, even on a computer at the library or something, maybe that's the lowest barrier to entry. And to be fair, there are many many different sandbox-based online editors like this, so – whichever ones work for you.
The problem with VSCode‑centric tutorials is that you load up all this "stuff" you don't really understand. You follow what the tutorial guy says during that long "just type what I type" section at the start of the course. The problem is that most people have no idea how any of it works, and then they move on taking it all for granted. CodePen is allowed to be a little magic. But once you get serious and start working locally on your computer, we don't want any mysteries. And as of 2025, there's all sorts of "AI" and autocomplete and coding assistants built in — which we highly recommend you stay away from until much later in your learning journey.
The most basic text editors are the best place to start. You can put your editor on the left and your browser on the right. Your editor might be split into a pane for HTML and a pane for CSS. You'll be able to use as much of your screen as possible and see the whole story. But your browser isn't going to refresh automatically — because why would it? How would your text editor know to send a message to the browser telling it to reload after every change?
If you're used to that kind of thing, it might feel annoying at first. But we've found that, in the beginning, it's important to take it slow. You make a change. Maybe a few more. Then you go over, click refresh, and re-request the page (right? because… HTTP). And then you see the update, for better or worse. This is good.
When you're starting out, it can be too distracting to see the changes happen instantly. You don't want that. Trust us – we've tested this with hundreds of students. The people who get anxious and are really tied to VSCode do the worst 😬.
Follow this path based on where you are in your journey. Each stage builds on the previous one.
- Stable, minimal UI — No clutter. Calm space to write. (if you can only have one thing — well, this would be it)
- Turn off distractions — The ability to turn off anything that's on by default (like autocomplete etc / which is often wrong and surely visually distracting)
- Tabs, spaces, indentation — Change tab width easily. Simple settings file. We use actual tabs (not spaces) so everyone can set their own display width - 2, 3, 4, whatever works for their screen. Some editors have crazy huge/deep panels for turning everything on and off. Sublime Text has a simple JSON-like file where you just write the key and value.
- Create new documents fast — Cmd+N should just work.
- Pane splitting — See HTML and CSS side by side. (as soon as you have an HTML page – and it's CSS – it's really helpful to see both at the same time / especially while learning)
- Set file type manually — when needed
- Syntax highlighting — Optional at first, enable once comfy. You really can live without it… and in the early stages of learning — it's nice to do that — and really learn to see the characters. But if we could only have plain text and pane splitting – that would be more important
- Find in file search — Cmd+F
- Project-wide search — that ignores vendor folders. (maybe this is more important than file search? But in some of these cases – you'll have both or none anyway)
- Fast file search (fuzzy find) — for larger projects. At the beginning – there are very few files — so, you can use the sidebar to see the directory structure — but the sooner you can start just thinking "I want this file" and having it appear the better — and also because it will help you ensure you're naming things in an intuitive way — which is a career-long challenge
- Multi-cursor / batch edits — change multiple occurrences in seconds
- Structured shorthand (Emmet) — once markup is second nature. In the beginning — it's nice to write out all the characters
<header class='site-header'>… – but once you've 100% got all that down, to get your thoughts out on the screen faster, typeheader.site-headerand hit tab. It's not guessing and suggesting, it's from a preset rule system. It's not all about being 'faster' (speed is never really the bottleneck) — but what it really does is keep your mind in gear / and it leads to less typing errors too.
- Editor on left, browser on right. Manual refresh on purpose.
- Use plain files first. Learn cause and effect of saves and reloads.
- Practice with and without syntax highlighting.
- Start naming files clearly, then use fuzzy find to reinforce naming.
- Skip AI, autocomplete helpers, and integrated terminals for now.
Goal: same look on every machine, zero style debates.
.editorconfigfor indent, newline, charset.- One formatter. Prefer Prettier for web files. One script:
npm run format. (that introduces node so early though… so — I'm not sure I'm excited about that… ) (if they aren't all using different formatters – this isn't going to matter quite yet, right?) - Keep rules minimal. Document the one fix command in README.
- Basic Git awareness in editor. Commit however you like (CLI or Tower). (I think the git awareness is confusing and the colors just distract people / so, I'd want to turn that off)
- No linters yet unless they solve a real problem.
Why PHP here: teaches what a server does without a framework.
- First server step without a framework
- Use PHP includes for reusable HTML chunks
- Explain MAMP/LAMP and why they exist
- Use MAMP or Herd. Project lives under the web root. Hit http://localhost.
- Browser request now goes through the server
- Keep Sublime setup minimal, just use .php files
- Sublime auto-refresh plugin only now, after manual refresh is understood:
- Add only after manual refresh habits are solid
- Map to Command+Shift+R
- Speeds CSS and markup loops
- Does not replace understanding caching and requests
- Keep it toggleable for debugging
- Create .env for secrets. Commit .env.example, never commit .env.
Editor needs for this stage:
- PHP syntax highlighting and basic IntelliSense.
- Project-wide search that ignores vendor/.
- Multi-cursor for routes, includes, repeated markup.
- Keep editor minimal. Terminal, server controls, and Git in dedicated apps (iTerm, MAMP/Herd, Tower).
- We could talk about CodeKit and how it's used to abstract away the need to understand package managers and build tools
- (anything unique here?)
- We have students build out things with ESM and build their own apps without any build tools or frameworks first
- Pure JavaScript modules, no bundling
- Understanding the browser's native module system
Why now: modules, imports, HMR. Still small, still fast. At this point — we can't avoid build tools.
- First Node based tooling
- Dev server with hot reload
- Use ES module imports and simple assets
- Keep config tiny, run with defaults
- Optional: add Prettier once you are here
- Avoid piling on plugins just because you can
Editor needs do not change. Same core features as above.
Add shared config only if it removes friction:
.prettierrcand.prettierignore. One format script.- Optional ESLint with the smallest sane ruleset. Only if it prevents real bugs.
- Optional
jsconfig.json/tsconfig.jsonfor path aliases so editor "go to file" works with@/.... - Keep Vite config tiny. Defaults first. No plugin pile-on "just because."
- Document the one or two commands teammates run in the README.
When a second person touches the code:
- Add
.editorconfigfor indent and newlines - Add Prettier for formatting, one script to run it
- Document the one fix command in README
- Keep rules minimal and agreed upon
- Frontend heavy path: components, design system, Storybook
- Backend heavy path: database, APIs, auth
- Deployment path: build, envs, simple CI
- Laravel: comes after these, ties it all together