5 ms·

It's not a problem if you're using a proper IDE. Rider and IDEA will take you right to the implementation (or will display a list if there are multiple implemen

It's not a problem if you're using a proper IDE. Rider and IDEA will take you right to the implementation (or will display a list if there are multiple implementations) on Ctrl+Alt+B. This works on any of the parent classes/interfaces, or any inherited field or method.

humbleMouse 6y ago
Yeah this is what I was thinking. I pity the people who navigate java projects without ctrl+alt+b. What an existence that must be.
- tasuki 6y ago
  I pity the people who navigate java projects.
acdha 6y ago
It’s less of a problem but it’s still a problem because it forces people to have to keep more context in addition to what they’re really working on. Even experienced developers with the latest IDEs are slowed down when the culture encourages layers of gratuitous complexity, and the gains offered by advanced tooling are often cancelled out by people seeing that tooling as reducing the counter pressure against adding more.
- iainmerrick 6y ago
  Agreed, it’s not an insurmountable problem, but it’s still a hassle that gets in the way. Something that should be one click becomes 2 or 3 clicks and only works 85% of the time. For example, there might be one real implementation and one (or more) test stubs and that slows you down.
carapace 6y ago
> It's not a problem if you're using a proper IDE. From another POV it's IDE vendor lock-in: make the basic programming exercise so challenging that the users have to buy your special tool to even attempt it.
- bluGill 6y ago
  We just did a major reorg, and everyone who promoted that locked in tool got let go. There were other reasons for the reorg, but take this as a warning, if the tool you promote isn't productive you lose your job.
  - sidlls 6y ago
    Without additional context, that seems a bit extreme. People often promote tools because they have some experience and have not (yet) had a poor experience with them.
    - bluGill 6y ago
      These were senior technical architects that I doupt wrote more than a dozen lines of code in the tool, nothing real. They had great pie in the sky ideas, and the tools did useful things, but they forced everyone to use it for many years and kept defending it for years while evidence kept building up that using the tools made projects take 5 times longer than just writing in C. If they had accepted the evidence and backed off the tool until it could deliver the better than C quality (which it did do) at the same speed of development they might still be around. However in the end we need to ship code to make money and our competitors were catching up on us which isn't acceptable to the business. Let this be a lesson when you want to adopt new tools. They might be better but they might have some unexpected downside that means they are not useful.

humbleMouse 6y ago

Yeah this is what I was thinking. I pity the people who navigate java projects without ctrl+alt+b. What an existence that must be.

tasuki 6y ago
I pity the people who navigate java projects.

acdha 6y ago

It’s less of a problem but it’s still a problem because it forces people to have to keep more context in addition to what they’re really working on. Even experienced developers with the latest IDEs are slowed down when the culture encourages layers of gratuitous complexity, and the gains offered by advanced tooling are often cancelled out by people seeing that tooling as reducing the counter pressure against adding more.

iainmerrick 6y ago
Agreed, it’s not an insurmountable problem, but it’s still a hassle that gets in the way. Something that should be one click becomes 2 or 3 clicks and only works 85% of the time. For example, there might be one real implementation and one (or more) test stubs and that slows you down.

carapace 6y ago

> It's not a problem if you're using a proper IDE. From another POV it's IDE vendor lock-in: make the basic programming exercise so challenging that the users have to buy your special tool to even attempt it.

bluGill 6y ago
We just did a major reorg, and everyone who promoted that locked in tool got let go. There were other reasons for the reorg, but take this as a warning, if the tool you promote isn't productive you lose your job.
- sidlls 6y ago
  Without additional context, that seems a bit extreme. People often promote tools because they have some experience and have not (yet) had a poor experience with them.
  - bluGill 6y ago
    These were senior technical architects that I doupt wrote more than a dozen lines of code in the tool, nothing real. They had great pie in the sky ideas, and the tools did useful things, but they forced everyone to use it for many years and kept defending it for years while evidence kept building up that using the tools made projects take 5 times longer than just writing in C. If they had accepted the evidence and backed off the tool until it could deliver the better than C quality (which it did do) at the same speed of development they might still be around. However in the end we need to ship code to make money and our competitors were catching up on us which isn't acceptable to the business. Let this be a lesson when you want to adopt new tools. They might be better but they might have some unexpected downside that means they are not useful.