Title is nonsense, content is weak. Many people who use VS Code (me included) probably ignore the features that are supposedly a problem, such as built-in SSH. The idea that basic autocomplete is bad for you is for the birds.
TL/DR: I strongly encourage you to understand the fundamentals and not view all of our tools as black boxes, but once you have an understanding of the tools and the various layers of abstraction, feel free to use them to boost your productivity and output.
---
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.
Very weak article. I do all of these things in the terminal not because they’re better, but because of muscle memory. I’m under no illusions that me typing my git commands by hand makes me a better programmer. I didn’t become one with the machine.
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.
"You should not let your IDE do the thinking for you"
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.
Some of the older heads here are 100% with you, the notes and comments in this thread should be clear enough indication of that.
But you're right, tools that make short work of ridiculous incantations, 100% good.
We don't sit around trying to re-write arithmetic, but apparently not knowing how to do git pull --rebase is a crime to these smart folks, who don't seem to realize they know very little about getting sh!t done.
I'm quite surprised to see the need to debug a live server here. I'm of the belief that the need to repro a problem locally and using a debugger lead to better understanding. SSHing into boxen feels like a cowboy behaviour on a modern stack - it shouldn't be necessary with competent observability and unit tests.
For me, the friction of VS Code is more cognitive than computational. I call it the "searching with your eyes" [0] problem. To make it clear, I've no problems with VSCode but haven't used it in a long time -- maybe it has added some keyboard-only features that makes workflow smoother.
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 don't trust devs who can't operate outside their IDE. Maybe I'm just old fashioned, but it reminds me of useless Enterprise Java drones who are helpless without Eclipse and can't debug anything.
> 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?
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
It's all-round horrible advice. Once you have developed an understanding of 'fundamental operations', such as code formatting and file operations — and, realistically, you will already have done so if you are doing any programming — the next step is to automate them so that they take no time or mental energy, leaving you to work on things that matter. IDEs help with that.
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.
I've moved to VS Code after almost 20 years of Emacs. Couldn't been happier.
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
Research on calculator use in early math education (notably the Hembree & Dessart meta-analysis of 79 studies) found that students given calculators performed better at math - including on paper-and-pencil tests without calculators. The hypothesis is that calculators handle computation, freeing cognitive bandwidth and time for problem-solving and conceptual understanding. Problem solving and higher level concepts matter far more than memorizing multiplication and division tables.
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.
While this issue is up, I've recently been looking for an alternative to vscode for personal use because it runs so slow now with a few other programs running in the background. My main requirement is copy paste needs to be ctrl+c, ctrl+v and text selection needs to be ctrl shift + arrow keys or some combination of those. Using geany for a week or so hasn't been terrible but its not great either.
33 comments
[ 3.1 ms ] story [ 35.9 ms ] thread---
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.
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.
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.
But you're right, tools that make short work of ridiculous incantations, 100% good.
We don't sit around trying to re-write arithmetic, but apparently not knowing how to do git pull --rebase is a crime to these smart folks, who don't seem to realize they know very little about getting sh!t done.
Interesting survival skill, in case of armageddon or when camping in the wild, yet most folks will do just fine with matches and lighters.
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.
[0] https://barish.me/blog/stop-searching-with-your-eyes/
Why would you need to give this up? I use breakpoints with terminal debuggers all the time.
No.
> 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?
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.