Comment by Hasu
1 year ago
> This doesn't really make sense, either. How do you not consider the right tool for the job?
The thing people keep trying to explain is that when it comes to this stuff, there isn't a "right tool" for every job and every programmer. You like LSPs? Great, use 'em. You don't like them, and you can be just as productive without them? Great, turn 'em off.
So many people yelling at each other over personal preferences. It's not enough to have the tool and use it, you need everyone else to use it too? Why? To validate your own use of the tool? If you really truly believe it gives you an edge, great. I don't think it gives me one, and anyway, not everyone fights with the blade.
One group sees the other as a person backpacking with a bespoke gadget for every little thing, wearing a 60lb rucksack while they are wearing a 20lb ultralight pack and have a multi-tool that serves 90% of their needs.
One group sees the other as a person with a reel-mower proclaiming they don’t need a tractor mower, while they can mow much less grass a day.
Both groups are right, and both are wrong. Depending on what you’re doing, it can make sense to use heavyweight tools, lightweight tools, little tooling, or lots of tooling. If you’re hired into a big codebase written over the course of ten years, skipping tools that will help you make sense off it is probably not the right choice. If you’re building a system from scratch, then those same tools might inoculate you to the dangers of having a poorly organized codebase. If you need to debug a server remotely, bring productive in vim and basic command line tools could be invaluable. But if your debugging stuff, you could have saved yourself hours by turning on a debug port and stepping through the code in a debugger.
The arguments everyone is having look to be about whether it’s worth it to learn how to use tools. The answer is yes, but everyone has their identity caught up in their pet workflows.