> "I've seen countless junior developers freeze when their IDE isn't available or when they need to work on a remote server."
This is a valid point: juniors are limiting themselves if they rely on an IDE for everything, to the point of not being able to perform coding-related operations from the terminal effectively, or not even being aware of what the IDE is doing for them.
But once you have that knowledge, using an IDE tends to make a lot of sense. That also allows you to make an informed choice about which operations make sense in an IDE vs. the terminal.
Also VS Code has a good integrated terminal, so it's not an entirely either-or choice. Some of the new AI coding assistants integrate terminal operations with VS Code very well. The real advice should be learn both.
---
This is equivalent to saying "to understand wood working, do not use power tools, use hand tools to understand the wood and the process."
Sure, if you want to artisan woodworking, sure skip power tools or at least try it for a while to get a deeper understanding.
It is no different than saying that programming languages hide the subtleties of the hardware and we should be using assembly.
But once you understand the fundamentals, if you want to get a lot done at low cost (e.g. a professional who delivers at scale), you definitely need to use the power tools (e.g. high level abstractions/automations) that boost productivity.
git on the command line is the power tool. The VS Code plugin is the training wheels version.
These tools the TFA discuss are powerful, but have a learning curve. VS Code has a flatter learning curve, but it's up to you to decide if they are abstracting away things you actually need to understand.
All abstractions serve a purpose, but they're also always leaky. To extend your assembler analogy: sometimes you actually do need to understand what's happening on the stack and the heap, most people never do.
Use what works for you, but don't think that abstractions will be enough for every scenario, sometimes you're going to need to get under the hood and go deep, and if all you ever do is hand-wave it away and hope your IDE/framework/chosen programming language interpreter or compiler is going to just "sort it out" for you... well, good luck with that, and I hope it works out for you. It's just not my lived experience after 30+ years in the industry.
I don't disagree with your underlying point, but git is perhaps the worst example. It is a horrible tool in several ways. Powerful yes, but it pays too large a price in UX.
I've only ever used git through the CLI as well, but having switched to jujutsu (also CLI) I am not going back. It is quite eye-opening how much simpler git should be, for the average user (I realize "average user" is doing some heavy-lifting here -- git covers an enormous number of diverse use cases).
What jujutsu-CLI is for me (version control UX that just works) might be VSCode's GUI git integration for other people, or magit, or GitButler, or whatever other GUI or TUI.
Who cares about training wheels? If the real deal is a unicycle with one pedal and no saddle, I will keep using training wheels, thank you very much.
Same level of experience I have btw.
For junior devs: don’t worry about which tools you use. Ultimately make sure that what you’re shipping is tested and reliable. Make sure of it before sending it for review and you’ll be fine. You don’t need to mess around in neovim to prove anything to anyone.
That said I do not use neovim or delta, I just use git diffs or my language ide's diff features.
All I can see here is “if I use two extra tools, I can almost have as good an experience as vscode (or IntelliJ or whatever) gives me out of the box”.
The article is as misguided as the snarky pushback. Let people work however they’re most comfortable and productive, why does it have to be a purity contest?
As a solo entrepreneur, if something enables me to execute faster, I'll gladly use it. Articles like this only remind me to never (again) hire expensive, pedantic, over-principled and cynical engineers.
A stupid example off the top of my head: I use VSCode and often I'll use the integrated git commit feature. But if need to bisect, rebase, merge, or edit a commit, I will just use the CLI. I don't feel like using the commit GUI makes me worse at using git.
All in all, I think the author thinks that familiarity with one tool makes people worse at another similar tool, but I don't think that's the necessarily the case. At worst, memory might fade if the other tool isn't used, but that's fine, it's clearly not used often. As an analogy: if I don't speak German every day, I don't need to be fluent in German either.
The cynical and pedantic engineers however, do excellent work, and their software never breaks. It takes longer, you pay a bit more, but it is worth every cent.
As a general rule, ssh'ing into prod is a terrible idea. Getting into a pre-prod box to figure out why metrics aren't getting pushed and trying something quickly before you go back to making the changes you need to push into the repo, less so.
Interesting survival skill, in case of armageddon or when camping in the wild, yet most folks will do just fine with matches and lighters.
Vim/Neovim = making fire with matches and lighters
VS Code = making fire with a magic box that weighs 60 kg, you don’t understand how it works and it could randomly stop working at any time
VS Code's heavy reliance on the file explorer tree forces you to constantly visually scan nested directories to navigate. When I switched to Neovim (with Telescope/jump lists), I moved from visual scanning to mental mapping. I don't look for where a file is; I type what the file is. It sounds subtle, but removing that micro-latency of "eye-to-mouse-to-tree" keeps you in the flow state much longer.
I actually notice how this pattern is very fast, but I lose a code base's mental map. Coworkers might take longer to open any individual file but have a much better idea of repo layout as a whole. That makes them effective otherwise.
For smaller code bases, I usually read the repo first and I'm able to learn what exists while working through it.
For decades embedded CPU companies would look at visual studio and say, "Boy howdee if we only had visual studio for our chips!" But they wouldn't be willing to put in the effort to do so, so they'd start with Eclipse, and the C/C++ plugin, and hack in a JTAG interface, and maybe a few code generators to pin out the hardware and say, look at us we made an IDE! And that IDE sucked, not because of eclipse, but because nobody actually put the work in to make it useful. You'd get lime breakpoints but not memory breakpoints or function breakpoints. You'd get a call stack but no way to inspect your RTOS. Every chip vendor did it themselves, so every tool was wildly different even for a big standard ARM core.
VSCode for embedded is the same thing, just in JavaScript. With AI!
Why would you need to give this up? I use breakpoints with terminal debuggers all the time.
> Debug your code without visual breakpoints
With ‘visual’ being the important aspect.
The Challenge
[...]
3. Try debugging without breakpoints
Real Growth Requires Discomfort
[...]
Debug using logs and terminal outputNo.
> In these situations, your VS Code knowledge won't help you.
https://code.visualstudio.com/docs/remote/ssh
> When VS Code formats your code, you don't learn your language's style conventions
Lmao, what is this argument. `go format`, `prettier`, `ktfmt`, `ruff|black` is what you should know, not minutiae of where to put a line break.
> When it handles Git conflicts, you don't learn proper merge strategies
Such as?
> When it manages your build process, you don't learn your build tools
That's what infra team is for. I've seen "build process" written by those who "learned" their build tools – leave it to professionals.
> When it auto-imports modules, you don't learn your project's structure
???
The rest is similar bollocks. If you're at the start of the career – do not listen to advice in the article. You can do it for curiosity, but don't think it'll make you "a better programmer". And I say this as a terminal first dev who uses vi/vi-mode everywhere.
Use that VS Code, depend on that Intellij. Learn them through and through – this will make you a much better developer rather than cobbling together a thrift-store IDE.
Part of me thinks that in 2026 (and onwards), I should make the most of the M4 processor I have in my hands, the GPUs and superb screen I will always have access to, and have a programming environment that is absolutely dripping in luxury baubles compared to what I started out with in the 1990s.
And then I frequently throw open a terminal and start up tmux with neovim in one window and a command line for git and the like in another.
There is something about understanding the tools and the process, the author is kind of right there, but also, there is just something about the ergonomics and speed of it all. There is more flexibility to extend easily, to customise, to make my environment fit using these more "primitive" tools than there is in taking an opinionated stack somebody else has designed.
One of the primary things shells are supposed to excel at is file system navigation and manipulation, but the experience is horrible. I can never get `cp`, `rsync`, `mv`, `find` right without looking them up, despite trying to learn. It's way too easy to mess up irreversibly and destructively.
One example is flattening a directory. You accidentally git-cloned one too deep, into `some/dir/dir/` and want to flatten contents to `some/dir/`, deleting the then-empty `some/dir/dir/`. Trivial and reversible in any file manager, needlessly difficult in a shell. I get it wrong all the time.
Similarly, iterating over a list of files (important yet trivial). `find` is arcane in its invocation, differs between Unix flavors, you will want `xargs` but `{}` substitution is also very error-prone. And don't forget `print0`! And don't you even dare `for f in *.pdf`, it will blow up in more ways than you can count. Also prepare to juggle quotes and escapes and pray you get that right. Further, bash defaults are insane (pray you don't forget `set -euo pipefail`).
How can we be failed by our tools so much, for these use cases? Why aren't these things trivial and safe?
The wide-spread use of `rm -rf some-ostensibly-empty-dir/` is also super dangerous, when `rm -r` or even `rmdir` would suffice, but you need to remember those exist. I find it strange there's no widely (where applicable) available `rm-to-trash`, which would be wildly safer and is table stakes for Desktop work otherwise.
Then there's `dd`...
I use terminals a lot, but a GUI approach (potentially with feedback pre-operation) plus undo/redo functionality for file system work is just so much easier to work with. As dumb as drag-and-drop with a mouse is, a single typo can't wreck your day.
I would agree with the rest, I always have to look up find and xargs syntax.
VS Code will, by default, ask you every time before you do something destructive. I need that kind of safety in my life.
Or if you are me, you do `history | grep name-of-command` to find the last time you used it and edit that haha
cp --interactive
rm --interactive
Edit: just looked up LazyVim and it seems to just be a prebuilt neovim config atop the VSCode-Neovim extension which was one of the aforementioned janky experiences (IIRC undo stack wasn’t shared with VSCode and would get out of sync). I think I tried it as a last ditch effort because someone else said that it’ll fix VSCode-Neovim plugin deficiencies but I ended up just going back to my simple but effective neovim config and using VSCode as a visual debugger. I’ll give it another go if you reckon it’s much better though.
IDE itself is good, "convenience" is benefit and not a sin - but performance and RAM usage needs to be better. And that is only done by throwing webstack into a dump
On the other end it’s also “I’ll vibe code it bruh”.
So we land at the eternally wise YMMV.
Incidentally, the reason the tabs vs. spaces debate has died down is the proliferation of autoformatting. It really doesn't matter once you don't have to spend your precious time manually aligning code.
Spent a little time hacking hotkeys to match my Emacs muscle memory and that's mostly it.
Now I have a debugger that's actually easy to use, ability to run the test case under the cursor in one click and support for Jupyter Notebooks. However, still missing tab completion.
>Look up a Git command instead of clicking a button
>You're building real, transferable skills that make you a better programmer.
I'm convinced that the only reason that people think git is complicated, is because of the incredibly widespread elitist attitudes around using a GUI for git
This is a hot take, but a GUI for git is strictly better (unless you're scripting). You can do incredibly complicated operations at the click of a button, far more safely than you can through the CLI
But even then, the idea that you actually learn anything by using the CLI is just not true. The longest running meme with git is that people just learn a few commands to copypaste in without actually remembering anything. You stick to your tiny niche because you don't know what's actually happening nor is it possible for a human being to truly remember all of the syntax: This meme exists for a reason https://xkcd.com/1597/
Git via a GUI gives you the freedom to actually use all of git. You learn how git actually works, all the power of it - how to merge complex things, and you can create really nice workflows that are powerful and easy to use. You come out of using the GUI for a while with a strong understanding of what git is, not what the git CLI is. The skill I care about is the former
The CLI teaches you nothing by virtue of it being a CLI. All you learn via the CLI specifically is the ability to type accurately without making mistakes, and gain a strong fear of hitting enter. The underlying concepts are the important skill, and you absolutely do learn those via a GUI - much more effectively without the hard wall of an archaic CLI interface in the way
I think about this often when discussing AI adoption with people. It's also relevant to this VS Code discussion which is tangential to the broader AI assisted development discussion. This post conflates tool proficiency with understanding. You can deeply understand Git's DAG model while never typing git reflog. Conversely, you can memorize every terminal command and still design terrible systems.
The scarce resource for most developers isn't "knows terminal commands" - it's "can reason about complex systems under uncertainty." If a tool frees up bandwidth for that, that's a net win. Not to throw shade at hyper efficient terminal users, I live in the terminal and recommend it, but it isn't going to make you a better programmer just by using it instead of an IDE for writing code. It isn't reasoning and understanding about complex systems that you gain from living in a terminal. You gain efficiency, flexibility, and nerd cred - all valuable, but none of them are systems thinking.
The auto-complete point in the post is particularly ironic given how critical it is for terminal users and that most vim users also rely heavily on auto-complete. Auto-complete does not limit your effectiveness, it's provably the opposite.
throw-12-16•2h ago
diarrhea•1h ago
throw-12-16•56m ago