Is unknowingly transmitting a disease that could kill someone you love (or even that you don't) without your knowledge not scary to you? Great, you have a healthy family and friends. What happens when one of those friends or family members isn't as healthy as they were the last time they caught covid? Still seems pretty scary to me.
Well, I do work for one, and yes, last time I participated in an all company call the majority of the time the management spent talking about racial equality, completely unrelated to our business?
The numbers are close enough to be meaningless, as is the benchmark. Your users won't be able to read 10 rows in the difference in time it is from react to vue's rendered rows, much less 10,000...
I'm sorry to hear that this is the way things are for you. I've never worked at a company with this kind of culture, and would leave one in an instant. This is disgusting, and shouldn't be the way things are.
I'm not sure what code completion you're using, but if it's contextual, I'm very lost as to how typing a ridiculously long name would be faster than auto completing it. Especially since once you're used to the auto complete, you can basically use shortcuts for specific things you're using in that context a lot. "BindingOperations.EnableCollectionSynchronization()?" oh, that's "bop.ecs". There should be very few options to pick from unless everything is very similarly named...
I also find autocompletion invaluable when I'm working with an API I don't interact with regularly enough to have everything memorized, mere mortal that I am. I might not remember exactly what naming convention the methods conform to, or what order the arguments need to be in, and autocompletion gets me both of those essentially for free, without having to pull up the docs for every method call.
I can agree with this — if you’re really working on a codebase that you rarely interact with, then sure, “jump to” and autocomplete features are helpful.
Over my career, the relative amount of time spent doing that is really tiny though. It doesn’t invalidate the value of autocomplete or “jump to” features for this use case, but for me it’s not common enough to matter a whole lot. Other forms of searching work just fine too.
My other comments are written regarding the case when you’re hopping around an in-house codebase, and beyond some initial burn-in, you should have a lot of working knowledge of the details.
It wouldn’t matter if the auto-completion only had one option to pick from. The visual disruption of needing to see that and hit enter or arrow down is already a time loss compared with just typing the thing.
Go to definition is insanely useful. Just because you "write good software," and are able to put everything in exactly the correct place, and find everything without it, doesn't mean that everyone else does, or the guy next to you does, or that you aren't wasting your time by not using it. Go to definition isn't just for multiple inheritance hierarchies. It can be as simple as getting to another method in the same file 50 lines away, or to a child class's method which is in exactly the right spot, and you'd be easily able to find. It's not about where it takes you, it's about the speed at which it takes you there. You press one button and you're back to getting through the control flow of the code without interrupting your thought process by having to search for a method. Press another button and you're back to where that method ends. Yes, you don't need it, but the speed that it offers you is invaluable a lot of times.
> "It's not about where it takes you, it's about the speed at which it takes you there."
But that's exactly my point. Jump-to-definition features slow you down. The only real exception is if the code's overall organization is extremely pathological and you wouldn't have a chance of mentally caching the local layout relevant for some work you're doing.
Flipping around to different files is super easy to do in any number of ways, with various shortcuts and macros. "Go to definition" features do not differentiate themselves based on that.
The difference is if you navigate to a section of code intentionally because you know it contains what you're looking for, or if you let yourself be taken to that place and then have to orient yourself around what you find.
For me anyway, the mental difference is huge. "Go to definition" means that after the quick keystrokes for invoking that feature, there will follow a noticeable slowdown while I figure out where I am.
Imagine two different ways of teleporting somewhere, like say a restaurant. In one way, you can say, "teleport me to wherever this pizza was made" but when you appear there, you won't know the prices, the etiquette, the lay of the land.
In the other way you say, "Ah, I know where this pizza was made, take me to X" and your mind is already set to the expectations and you're ready immediately.
The mere typing difference of saying "take me to X" with a few extra keystrokes instead of a shortcut keystroke for "take me to where this was made" is not relevant, plays no part in what matters for quickly moving around in the code.
I think this mental distinction, especially added up over thousands and thousands of "go to definition" invocations, is a huge thing. Your productivity takes a tiny hit each time you do the unplanned context switch.
I work with other people's code. I just don't get what are you trying to say here.
Go to definition goes to place where the the thing I am looking at and see first time in my life is defined. Had there be no go to definition, I would use something else. Go to definition still causes zero effort. Less then guessing layout, really.
I don't magically know everything about code Base I am looking at, even if written by super organized geniuses. Go to definition helps you to learn.
Discovering where function or class definitions are found for the first time ever is a necessarily rare part of software engineering. It happens when debugging some third-party tool, when joining a new team or project, etc., but the vast majority of the time you aren't doing that stuff and you are working on a codebase whose internals you're expected to have a mental model about.
When just exploring a codebase for the first time, frankly just grep would be more useful than jumping, because if you're looking for the firs time, there is no purpose to following a thread. You'd need a task or some other understanding of what you need to do. However, I do concede that "jump to definition" is a perfectly fine tool for this sort of search if it's what somebody wants.
But the situation is totally different in the vast majority of the time, when you're working in a codebase you're expected to understand already, but which you need to navigate around the architecture.
That case, which is most of the time (by definition), is not benefited by "jump to definition" except in the pathological cases when the organization of the software is exceptionally bad. Basically, if you find yourself in a situation where a "jump to definition" feature is constantly helping you, even after you have worked in that codebase a while, then it is a clear symptom of really big, pervasive problems about that codebase. It's not an endorsement of "jump to definition" features as being generically helpful.
