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.
The author touches on performance & understanding tools, which are valid points. But for me, the friction of VS Code is more cognitive than computational. I call it the "searching with your eyes" [0] problem.
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.
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.
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.
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.
VSCode over SSH is one of the best ways to develop on various SBCs. You can run the code locally while having a high powered editor experience on your machine machine.
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.
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.
The author touches on performance & understanding tools, which are valid points. But for me, the friction of VS Code is more cognitive than computational. I call it the "searching with your eyes" [0] problem.
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/
> Try debugging without breakpoints
Why would you need to give this up? I use breakpoints with terminal debuggers all the time.
Yea this take makes no sense. What in the world is wrong with debugging with breakpoints?
in an age where junior engineers are no longer _reading code_ due to LLMs, VSCode isn't exactly the worst offender
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.
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.
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.
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.
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.
Not to mention its extremely insecure plugin architecture.
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.
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.
VSCode over SSH is one of the best ways to develop on various SBCs. You can run the code locally while having a high powered editor experience on your machine machine.
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.