> I work with someone that navigates the tree structure of all our directories every time they need to look for something
Counter example: I’m working with LSP dragging codebase where basic code lint takes 45s. My colleague takes a break after each change so that their code navigation starts working again.
Inefficient people are inefficient.
Not using LSPs isn’t guarantee of efficiency just as using LSP isn’t one. Different strokes for different folks - one has to accept consequences though (more automation means less presence, but it’s everyone’s own choice to make).
It is not about speed, is about quality.
When I met the other 2 blind people, one of them joked that yes, they were very organized, but because they had to be, unlike us, being not organized wasn't an option for them.
I don't question the ability you may have to deliver quicker results, but I bet that your incentive to organize stuff is smaller than what your friend has.
Maybe he will be more inclined to refactor that than you and take even more time, and that maybe it pays off. Of course, I have no idea of your deadlines or if you are in a rush for MVP in search of market fit.
But this also follows those lines of: "wanna go fast go alone, wanna go further go together".
I value more quality than speed, but also understand that sometimes speed is what is needed.
Needs more RAM?
I've been doing work on a Raspberry Pi project, which got large enough that it took forever to get code nav back after an edit.
I switched to using VSCODE remote from a beefier machine with 32GB of memory (and an admittedly better processor). Editing response is now under 10 seconds. Sweetness and light! And even the compiles (which still take place on the Pi) run about 6x faster.
Nope, we are working on beefy machines. Problem are circular dependencies that trigger recompilation multiple times and macros sprinkle on top.
We’re refactoring it and get there eventually but without LSP and types (stack is dynamic) there is only so much that can be done.