You Need to Ditch VS Code

49 points by kugurerdem 139 days ago | 110 comments

https://web.archive.org/web/20251230103907/https://jrswab.co...

iepathos 139 days ago |

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.

graemep 139 days ago | |

That you for mentioning that. I have often argued with people in favour of my approach (home ed so I got to choose how to teach my kids from about 9 to 16) of not doing things like memorising times tables and learning arithmetic techniques like long division.

jftuga 139 days ago | |

This is a well-thought-out critique. Thanks for sharing your insights.

diarrhea 139 days ago |

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?

monooso 139 days ago | |

I agree that certain commands require some effort to learn, but I would not include `cp` or `mv` in that list.

diarrhea 139 days ago | | |

I have trouble gauging the effects of `*`, aka "will I cp/mv the dir or all contents of the dir"? Then shell expansion getting in the way, like expanding it all ("argument list too long"). I try to use rsync when possible, where intermittent `.` in paths are relevant, as well as trailing slashes... and don't forget `-a`! Then I forget if those same things apply to cp/mv. Then I cp one directory too deep and need to undo the mess -- no CTRL+Z!

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.

donkeybeer 139 days ago | |

What is there to get wrong in your flattening dir example? I'd mv the internal dir as some other name to outside say dir2, them rm rf outer and mv the dir2. Unless there is something wrong in this approach.

I would agree with the rest, I always have to look up find and xargs syntax.

20k 139 days ago | | |

If you make a typo, it'll go wrong. This is something that file managers fundamentally do not suffer from when trying to do that operation

greatgib 139 days ago | |

   can never get `cp`, `rsync`, `mv`, `find` right without looking them up

Wow! You have the brain really fried by not using it if you have issue using these simple command without help.

I would double down on advising you to go back learning to use the roots before getting IDE or llm assistant...

diarrhea 136 days ago | | |

Interesting attack on my person!

The things I want to get done on my computer are so much richer than moving files back and forth in a terminal all day. Simple things should be simple. Tools should enable us. Moving files is a means to an end and these commands having so many sharp edges makes me unhappy indeed.

But yes, of course I am an IDE toddler and cannot even tie my shoes without help from an LLM, thanks for reminding me.

abhinai 139 days ago | |

Most of the commands you've mentioned have worked fairly well for me. Are you sure you're looking up cp, mv and find every time before using them? Sounds pretty weird.

xigoi 139 days ago | |

With fish, `for f in *.pdf` Just Works™.

FeloniousHam 139 days ago | | |

This is also a crutch. Take the time to learn the kludgier tool. It will make you a better developer.

/s (I'm a big fan of fish)

eddyg 139 days ago | | |

Same with zsh

000ooo000 139 days ago | |

mv --interactive

cp --interactive

rm --interactive

alecco 139 days ago | |

LLMs make all those commands trivial to learn. Back in the day we had to study whole man pages meant as reference. Like keeping attention for minutes at a time. The horror!

morkalork 139 days ago | | |

You read the manpages once and then if you're some super elite user you create some aliases for yourself.

Or if you are me, you do `history | grep name-of-command` to find the last time you used it and edit that haha

DecoySalamander 139 days ago |

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.

barishnamazov 139 days ago |

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.

[0] https://barish.me/blog/stop-searching-with-your-eyes/

diarrhea 139 days ago | |

All IDEs including VSCode have fuzzy-finding for files, and fuzzy-finding for symbols as well. Between these, I never find myself using the file tree, except when it's the best tool for the job ("what other files are in this directory?", file tree manipulation (which IDEs recognize you doing, adjusting imports for you!) etc.).

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.

barishnamazov 139 days ago | | |

I have worked in monorepos for large codebases. In those, file trees are completely useless because you can't fit the repo layout to your mind. Also, the file trees are so large that when I'd ask a coworker using VSCode to open a file, they'd usually take a few seconds trying to locate it (on remote ssh, it even takes a bit to load files to expand directory as well).

For smaller code bases, I usually read the repo first and I'm able to learn what exists while working through it.

jemmyw 139 days ago | |

VSCode doesn't heavily rely on the file explorer, that is personal preference. I use its jump to file far more than the explorer, both by filename, by reference jump and by "dumb" jump, a plugin that does simple reference jump with rg. That jump by reference just works now in VSCode for all the languages I use puts it ahead of neovim which requires a bit of fiddling to get going.

tubs 139 days ago | |

Don’t you just press ctrl p and type in vscode?

rainforest 139 days ago |

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.

j_w 139 days ago | |

Not all environments are equal. Some vendor systems have basically non-existent debugging capabilities that end up dumping you into the wild west when things go wrong.

I have worked with more than one Fintech that provides no test systems/debugging capabilities and have spent time on calls with their developers as we walk through production logs. Not fun.

PaulRobinson 139 days ago | |

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.

antonvs 139 days ago | |

I see that regularly at startups or other environments where the developers aren't necessarily professional software people (especially ML people!) The update-run-debug cycle is how they think and operate, at every level including on prod servers. Moving beyond that tends to require quite a bit of knowledge and infrastructure, and which infrastructure you need also requires knowledge.

imron 139 days ago |

> Try debugging without breakpoints

Why would you need to give this up? I use breakpoints with terminal debuggers all the time.

robertjpayne 139 days ago | |

Yea this take makes no sense. What in the world is wrong with debugging with breakpoints?

jeltz 139 days ago | | |

It is for many problems, especially concurrency related ones, much less powerful than trace points. But the issue I have seen is that some tools like gdb have unergonomic support for tracing so there I tend to use break points or printf debugging just because the tracing support is so bad in gdb.

nikanj 139 days ago | | |

It’s a particular subcategory of cork sniffing where you pick the hardest, dumbest way to do things because you’re a Real Developer

wrenky 139 days ago | |

There is a good argument for never using debuggers except for core development- Once finished your logs/metrics/events should be good enough to understand what is happening in an application. If debugging your application requires breakpoints you wont really be able to debug a live instance, and wont be able to easily signal off what is happening in the future.

imron 138 days ago | | |

That is a reasonable argument - but it was not made in the article and also does not preclude the use of breakpoints (see your except clause which covers a lot of ground).

rounce 139 days ago | |

It actually said

> Debug your code without visual breakpoints

With ‘visual’ being the important aspect.

jasode 139 days ago | | |

There's another section below your quote where the author also wrote:

  The Challenge
  [...]
  3. Try debugging without breakpoints

The alternative to breakpoints is to study the output logs. He wrote:

  Real Growth Requires Discomfort
  [...]
  Debug using logs and terminal output

ctxc 139 days ago | |

Tbh it's the default way I start my app in, debug mode xD

spiderfarmer 139 days ago |

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

spoiler 139 days ago | |

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.

jasonm23 136 days ago | |

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.

wiseowise 139 days ago | |

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

abc123abc123 139 days ago | |

Strange. Articles like this remind me never to hire vibe coding brogrammers who have no idea about basics such as cp, mv, find etc. Usually they leave behind a mess which soon breaks.

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.

spiderfarmer 139 days ago | | |

Using VS Code !== Vibe coding

And using an IDE that enables you to work faster, doesn't mean you can't learn basic shell commands. Or learn the fundamentals behind the technology you use. Just like pedantic engineers are no guarantee for code that doesn't break.

herval 139 days ago |

in an age where junior engineers are no longer _reading code_ due to LLMs, VSCode isn't exactly the worst offender

testdelacc1 139 days ago |

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.

wiseowise 139 days ago |

> This deeper understanding makes you a more capable programmer because you know exactly what's happening under the hood.

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.

jemmyw 139 days ago | |

I don't necessarily agree with your thrift store take, I understand making a great personalised ide with vim or emacs. But I do agree with you that all the other points make no sense. VSCode doesn't solve your merges for you any more than vim does, the resolve tooling is very similar. VSCode doesn't do the build for you either.

tempodox 139 days ago |

Not that the arguments are completely invalid, but they’re not particularly convincing either.

> You're letting the IDE think for you instead of building a deep understanding…

That’s not specific to VS Code, you can say that about any IDE. The headline made me expect arguments specifically against VS Code. I want my 10 minutes back.

PaulRobinson 139 days ago |

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.

heratsi 139 days ago |

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.

azaras 139 days ago | |

I follow using Emacs, but for debug and AI.

Using both is not so bad.

bhouston 139 days ago |

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.

ForHackernews 139 days ago |

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.

bobmcnamara 139 days ago | |

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!

pjmlp 138 days ago | | |

One of the main architects is the same.

wiseowise 139 days ago | |

It's Intellij nowadays, gramps.

jaredcwhite 139 days ago |

I don't see this as an either/or. It's great to be able to remote SSH into a personal server and do whatever you need to do to tweak and deploy software via the CLI alone. And I do believe those are skills every developer should cultivate.

But for day-to-day dev tasks, having VSCode/code-server/Zed/Neovim/whatever floats your boat, with all the lovely extensions and fonts and syntax highlighting and type hints and whatever you like to use, that's awesome and nothing to shrink back from.

Vanit 139 days ago |

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.

qn9n 139 days ago | |

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

maccard 139 days ago | | |

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

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

hbogert 139 days ago | |

I use magit with emacs, Id say terminal purists and vscoders are missing out. But now I probably sound like that insufferable emacs guy from work.

globalnode 139 days ago |

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.

kevinfiol 139 days ago |

The focus on VS Code is a bit confusing. The author seems to have an issue with juniors relying IDEs as a crutch in general.

gmac 139 days ago |

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.

queenkjuul 139 days ago | |

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

barishnamazov 139 days ago | | |

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.

bhouston 139 days ago | | |

VSCode over SSH is one of the best ways to develop on various SBCs. You can run the code on the SBC while having a high powered editor experience on your main machine.

nchmy 139 days ago | | |

It's the primary way I work on remote servers. Takes a few seconds to start up, but then it's just as if I'm working locally.

antonvs 139 days ago | |

The title should be more like "Juniors shouldn't rely entirely on VS Code." The author wrote:

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

general1465 139 days ago |

> Try debugging without breakpoints

Break your ankles with a hammer and start running, pain will build your character. That's about the level of advice I am getting from this article...

pjmlp 139 days ago |

Another blog advocate for learning how to make fire with sticks and stones.

Interesting survival skill, in case of armageddon or when camping in the wild, yet most folks will do just fine with matches and lighters.

xigoi 139 days ago | |

Notepad = making fire with sticks and stones

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

jemmyw 139 days ago | | |

It's a code editor. It's not that much more complex than vim. It doesn't do magic to your codebase that makes development different. I've written plugins for vim, neovim and VSCode... VSCode at least has well documented interfaces for everything (edit: well ok not everything, there are some difficult gaps in the docs), and it's pretty clear how things work under the hood. Neovim is fine too, lua is nice. Vim plugins I didn't enjoy much.

pjmlp 139 days ago | | |

Vim/Neovim = cutting down wood and chemistry for the matches, molding plastic and metal for the lighters.

QuiEgo 139 days ago |

In a big company, this seems like a great way to get PiPed as all of your coworkers outpace you because they go faster with easier to use tools.

thefz 139 days ago |

Nope, I can CTRL-Shift-P faster than anything else, Sublime Text and NP++ included.

OutOfHere 139 days ago |

Craziness. You can use the command line just fine from within VS Code, and I do.

NooneAtAll3 139 days ago |

no, we need to ditch *Javascript* in VS Code

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

jemmyw 139 days ago | |

It's not actually that bad though. I do remember the days when VSCode would often be the problem app, but not for a couple of years now. Sometimes a plugin runs a process that causes an issue... but the same happens with neovim, its the curse of any editor with plugins.

throw-12-16 139 days ago |

Not to mention its extremely insecure plugin architecture.

diarrhea 139 days ago | |

I've had a color scheme plugin yanked from my IDE a while back, as it went malicious (Material Theme). It's just a bunch of hex codes, how is that even possible? Baffling and disappointing indeed.

throw-12-16 139 days ago | | |

It gets even worse when you realize most extensions ship bundled node_modules and are a very juicy target for supply chain attacks.

tubs 139 days ago |

Is the author aware of the vim plugin?

rounce 139 days ago | |

Every VSCode (Neo)Vim plugin I’ve tried (most, if not all of them) is a janky mess of random missing features and/or broken state handling. They’ve all felt like a worse experience than just doing things the ‘normal’ VSCode way.

my_brain_saying 139 days ago | | |

You are trying very niche plugins then... my experience has been superb for almost 10 years now. Recently I started using LazyVim by folke which I think is a really polished experience as well. Worth trying out if you don't like the regular plugin workflow.

kermatt 138 days ago |

Weird take. As someone who spends more time in Vim than vscode, I don't see any reason to force learning into a tool that makes getting work done easier.

I don't suggest to new developers on my team to use Vim, unless they _want_ to learn it. I also don't suggest they learn assembler to write web apps unless they have time to spare.

I also don't suggest they vibe code blindly, and instead spend time understanding the code emitted by any tool. The middle ground of what works best for any task at hand is the right choice.

20k 139 days ago |

>Every time you:

>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

bentt 139 days ago |

This argument that “convenience makes you weak” can be taken all the way to “real programmers write assembly” or “binary is the one true path”.

On the other end it’s also “I’ll vibe code it bruh”.

So we land at the eternally wise YMMV.

nacozarina 139 days ago |

I tried vscode and it just seemed like a crippled version of jetbrains, I don’t get it.

OutOfHere 139 days ago | |

If you compare with the free versions of Jetbrains software, to the extent they even exist at all, there is a lot more than one can do in VSCode that one cannot do in free Jetbrains. Granted, the paid annual licensed version of Jetbrains may have more features. Extensions in VSCode make up for the rest. VSCode costs nothing and I can have ten instances of it without even having to think about licensing.