Ask HN: How do you search large codebases before adding a feature or fixing bug?

I use a combination of

(1) breakpoint debugging, finding the connection between program start and various features

(2) Doxygen to generate a dependency graph

(3) create json performance profiles, manually instrumenting functions, and navigate traces using Google Chrome about://tracing or similar tools.

(4) trace and look at the data input and output, using a hex editor or over the network using wireshark

Off the tools topic, but IMO the most important consideration: the mindset should be entirely about understanding the existing approach, conventions and philosophy, vs a critical assessment leading to "this needs to be modernized". Particularly on small-medium codebases with smaller teams, I've seen projects be fundamentally damaged by new, well-meaning devs who bypass most of the hard-slog of really understanding the existing how/why, and instead try to jump to the more comfortable space of using tooling or approaches they're more familiar with. There is certainly a place for that, but depending on the project, that might be 3 to 6 months later. Programmers need to appreciate the power and consequences for management and non-programming team members (product) when a new dev brings a condemning assessment of an existing codebase after one or two weeks.

Whenever I work on huge codebase (think 1M+ lines of code), I always reach for Russ Cox's codesearch https://github.com/google/codesearch. It requires indexing the codebase first, which takes 15 minutes or so, but after that searches are instant.

What really undermines that necessity is this whole thing of having new developers "hit the ground running", meaning they're not just given light tasks for the first few months to help them understand the codebase and philosophy, but full blown important tasks with deadlines. I've had this happen to me more than once and I think it kind of acts to gaslight the new developer into initially thinking that the problem is them and not the codebase. Although I made it through building out a context menu UI from scratch as a first task on a previous project I was hired on to, that probably wasn't the best thing for that reason.

I get that new devs need a mindset to understand the existing approaches, but tossing them right into the middle of the foray actually makes things worse.

And yeah, teams need to be able to respect and respond to the frustrations of new developers. If a new developer, especially a senior developer, needs hours or days and multiple approvals to do something as simple as change a string, for instance, something is seriously wrong and you need to actually re-evaluate what everyone is doing.

Yes, I've experienced that exact phenomenon, and it's amazing how little people are concerned by that kind of thing. I'm not the greatest programmer in the world by any means, but I know how to change a string and when a design is ridiculously inefficient. Yes, there was a project I was on-boarded to where one of the tasks was changing how a string appeared in the UI; it turned out there was a shared library carrying the target string, but it wasn't exactly obvious that was where the string was coming from, and multiple other projects were using that library and so the review process needed to apply to all projects involved. For some reason, although a role was delegated to deploying the app itself, it's up to individual devs to build the library and register it as an NPM package, and there was a tight protocol around. Because of the toolchain, the library was not easy to test with an app locally. So it ended up that changing a string could take several hours or even days, especially if someone wanted to squeeze in another string change into that same task.

As a developer who just joined a team, what are you really supposed to do? Just plow through believing that there's a good reason for the madness?

Maybe the existing approach is actually bad.

It works great for me with much larger projects.