(Sorry, just now reading this because I'm bored haha)

I guess my first thought here is that Vim has stuff like "go to definition", and depending on your language has had it for quite some time. I do agree there's a kind of toxic "in my day we wrote programs directly on spinning hard disk platters by being very careful with a magnet and tweezers" attitude in places, but I'll bet that for every one of those there's an equal, "I use actual good IDEs and anyone who doesn't leverage them can't possibly be as productive as me", so I think it probably washes out.

I don't think you should know everything about your code, the opposite actually. I think you should be able to entirely forget everything about your code when the day ends. I think you should be able to walk onto any codebase and quickly understand how things work having no foreknowledge, as though you'd forgotten everything over night. I don't think this has anything to do with IDEs or editors, but has everything to do with coherent mental models and documentation. Without that stuff, you're just Ctrl-P'ing around, just like w/ IDEs. My manager uses VS Code and whizzes around pretty well. I use Vim and whizz around just as well (arguably better as I don't use go to definition so I'm grepping and guessing where stuff is with... idk very good accuracy). I don't really see a point in arguing about it.

> Refactoring entails moving, renaming, consolidating, etc. Personally, I've found most of these activities are usually much simpler to run using tools crafted for that purpose vs crafting my own from a variety of tools.

I hear so much about refactoring and this kind of thing, and it conjures up this image of some sorcerer extracting a pervasive, cancerous hydra from a code's corpus and transmogrifying it into a new, tamed organ. I think a few things about this, but mostly "I frequently have to rename and restructure countless structures/classes and functions/methods across a multi-million line codebase and I need a tool to facilitate that" sounds bonkers to me. It's also hard for me to square that with any kind of testing infrastructure, code review process, or design process. Having to do that kind of thing even once is pretty wild; I can't imagine having to do it so often that I require tooling for it. I can't imagine an engineer dropping a multi-thousand line PR on me with "I refactored billing, but I used IntelliJ so don't worry" in the description. I wouldn't even look at it, honestly.

Which is to say, I actually think it is rare and generally unsuccessful. I've used refactoring tools and wizards in IDEs. They'll rename fields, change types, update type signatures, generate new getters/setters, etc. That's cool (I don't need it though, because I have Vim and macros)! But that's not really refactoring, that's changing names and types. Refactoring is changing the fundamental representation of the problem space, which means you're changing what different classes/modules are responsible for and how they meet those responsibilities. IDEs won't help you with that, but testing can and it's independent of IDEs or editors. I can imagine an engineer dropping a multi-thousand line PR on me with "I refactored billing, took forever to get tests to pass, but now they do" in the description. Not only would I look at it, I would dig in and help refine the approach (or whatever).

So again, I think IDEs are fine. I'm sure there are benefits to either side and I'm not super interested in them. I think it's largely an issue of aesthetics. But, again I think you're right that smart people try to make their aesthetic choices "correct" as though they're above irrational personal preferences, but the best thing I can say about that is it's just no fun haha.