I don't claim it's better, but a couple of the points here echo those I made myself four years ago so people might find that post interesting as well.

https://obdurodon.silvrback.com/navigating-a-large-codebase

> But don't just try to get by with basic vim and grep. Learn something better.

I laugh because... I get by with vim and grep (although arguably my vim usage doesn't qualify as 'basic'). I seem to compensate mostly by splaying my stuff over large amounts of terminal windows--apparently needing a dozen different terminals to work on something isn't common? ;-)

I got by using vim (or sometimes emacs) and grep for twenty years, but it stopped working when I encountered large codebases written by people who have abandoned (or never learned/embraced) modularity. The current fashion seems to be splattering related definitions and (tiny bits of) code across hundreds of files all over a huge monorepo, with no rhyme or reason or comments. If you can hold such a huge pile of loosely-connected garbage in your head right from the start then great, but I think the common advice should still be to let your tools do the cross-referencing and indexing.

So, what should I use instead? I want to start working with huge C codebases. I want a tool that is open source.

I don't disagree that having a good cross-reference/indexing setup is wonderful. I'm fortunate in that most of the projects I've worked on are sensible enough that I can at least narrow down the couple of locations it might be in, and where it's not so easy, it's at least something where "oh yeah, all the interesting code in LLDB is actually in Plugins/" can easily be slotted in the brain. (glibc is another horrible one)

One of the things I've considered doing is putting together a recording of fixing a bug in a project whose source I've never seen before, as the only way I can think of to explain how to navigate a large code base without accidentally skipping several steps of "I apparently memorized the layout of the monorepo without realizing it". This plan is defeated by... not having a code base I can use for this where I haven't actually poked around its source before at least once.

but then, succumbing and using "tools" because the code is bad, is a sure recipe for rewarding / encouraging people to write bad code, right?

Perhaps, but doesn't choosing not to do so also increase the likelihood that you will be less effective about figuring out what a better solution looks like that is minimally disruptive to production?

I mean if you're skilled enough to do without those tools great =)...

my point is, if you dont flag bad code and fix it during code review because "it's workable when you have the right tools", then that code isn't going to improve, and it will slowly accrue technical debt for which the IDE will no longer be an adequate solution.

but, yes, this is me being idealistic. i get that this probably wont happen much in practice.

> Step 2: Build the Project > Just cargo cult guides, websites, whatever you need

No. Look in the readme for the section on building the project.

If it doesn't have simple, usable instructions outlining all steps and pre-requisites - immediately stop wasting your time.

first there is usually a INSTALL, and second the best instructions are nowadays in the various CI actions.

what the author here calls trace down and learn up effectively sounds like the effect and feature sketches from the M Feathers book on working with legacy code.

Agree with all the above and something that I personally haven't always done was "Becoming a user". Unfortunately, not all products/services/code bases make it easy to dog food, especially if you are building primitive infrastructure that's difficult to test out on your own environment.

Nice article. I'll add "write unit tests" to this. Especially if the system isn't already under test, getting it there will really force you to understand the expected inputs and outputs. As a bonus it becomes trivial to extend these tests for your new behavior as part of TDD

Good article. It may also applies to someone joining new company and need to understand the product.