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.<p><a href="https://obdurodon.silvrback.com/navigating-a-large-codebase" rel="nofollow">https://obdurodon.silvrback.com/navigating-a-large-codebase</a>
> Step 2: Build the Project
> Just cargo cult guides, websites, whatever you need<p>No. Look in the readme for the section on building the project.<p>If it doesn't have simple, usable instructions outlining all steps and pre-requisites - immediately stop wasting your time.
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