Live data from Hacker News

You Need to Ditch VS Code

jrswab.com

21–30 of 113 posts

Re: You Need to Ditch VS Code

#21

"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.

I think they have some good points (having a deep understanding of tools you use), but I think the path they take achieve those results is misguided.

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.

Re: You Need to Ditch VS Code

#23

"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.

This, this and this. Having a person who constantly nags juniors about "true engineering" is such a morale killer.

Re: You Need to Ditch VS Code

#24
I flip flop on this a bit.

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.

Re: You Need to Ditch VS Code

#25
No thank you...

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?

Re: You Need to Ditch VS Code

#26

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.

Sometimes you need to debug the observability stuff a little.

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.

Re: You Need to Ditch VS Code

#27

Earlier quoted context omitted.

VSCode over SSH kinda rocks honestly. I use it with my server all the time.

In my previous work, a few folks in my team used VSCode on a shared dev box. The box has 1TB memory, and we'd frequently OOM due to vscode servers taking up tens of GBs of memory (which adds up quickly when there are multiple vscode windows per person). Sometimes it'd eat as big as 100GB until it had to be restarted. Sure, big codebases, but that's just straight unacceptable.

Which language/plugins?

Re: You Need to Ditch VS Code

#28
post #7

Ugh a terminal purist. Just as insufferable as the ones in person at work. Yeah have fun with your gigantic unorganized git diffs I guess.

You can clean up git diffs a lot, I personally find them easy to ready anyway, with tools like delta[1] which make things super nice to read. Also if you use a text editor such as neovim you can integrate these things into your editor and get beautiful diffs right there.

That said I do not use neovim or delta, I just use git diffs or my language ide's diff features.

[1]: https://github.com/dandavison/delta

Re: You Need to Ditch VS Code

#29

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.

From the embedded systems end, VSCode really feels like the new Eclipse.

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!

Re: You Need to Ditch VS Code

#30

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 switc…

Don’t you just press ctrl p and type in vscode?
Post reply on HN