Before I learned the holy ways of g->d, that was essentially what I did (grep -nr).

what is g->d?

Vim keybind for jumping to the definition of the symbol under your cursor, I believe

Exactly! Neovim really changed my workflow.

From NP++, you could just ctrl-shift-f to "find in files" and it'll be quick about it, but I personally would grep from the root of the project. I usually keep a handful of command line tabs open in Console2, one for git, one for grep, one for build commands, others that are running local services etc. Anyways, the reason for this is the mental map / spatial geography of a project .. enough repetition cd'ing through folders and seeing file paths while grepping helps me visualize actual locations of things, which helps me grasp the entire structure of a project.

Meanwhile, in VS Code etc you can just hover over something and click to go directly to it, which is cool, but it's kind of like teleporting instead of actually driving to the destination enough to learn the roads.

I do a similar thing with git PRs -- for example, if you build something that follows a bundled pattern (ex. a component that has frontend, backend and data-related files, plus naming conventions), having a clean + complete reference PR to revisit when you make new components helps ensure I don't miss anything and stay consistent. I usually view these in-browser since Github/Bitbucket/Gitlab all have nice interfaces to see what files you need, where they go, how they're named, etc.

I do the same thing (though with Vim as my editor instead of NP++). Grep is seriously underrated. (well technically I use my own grep replacement[1] instead for a few reasons, but plain old grep can get the job done very well)

[1]: https://github.com/FreedomBen/findref

ctags plugin

ctags + cscope can take you far

I can't live without ripgrep, it's so much faster than grep it's not even funny, especially if working with very large code bases with 100,000+ files

Why is that? Does it build an index so later searches are fast?

No, I just think every last part of ripgrep has had the shit optimised out of it.

Plus it's written in rust and as we know, it's blazingly fast.

No. I've written about why: https://blog.burntsushi.net/ripgrep/

That blog is eight years old now, but still pretty accurate.

For more details at the level of the regex engine, see: https://github.com/BurntSushi/rebar