51–60 of 113 posts
Earlier quoted context omitted.
That exists, though it doesn't have a preview of the file. Also, jump lists to quickly take a look and ctrl+o to go back is a huge game changer for me. Not sure if VSCode supports that now, haven't used it in a long time.
It has jump previews and yea ctrl+o works
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.
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
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…
Wrong way round. 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: somet…
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.
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
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…
Wrong way round. 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: somet…
Same level of experience I have btw.
> Try debugging without breakpoints Why would you need to give this up? I use breakpoints with terminal debuggers all the time.
It actually said > 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 outputAnother 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.
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
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…
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. Cowor…
For smaller code bases, I usually read the repo first and I'm able to learn what exists while working through it.
Not to mention its extremely insecure plugin architecture.
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.