[mlthoughts2018]

> "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.

[watwut]

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.

[mlthoughts2018]

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.