It’s hard to avoid doing a few such stints in a programming career. Being able to navigate and wring value out of an existing code base can be a superpower at t

It’s hard to avoid doing a few such stints in a programming career. Being able to navigate and wring value out of an existing code base can be a superpower at times. But don’t let this be the predominant part of your programming career. Some tips for your current situation: 1. Accept the slowness and irreducible complexity that comes with large codebases. There is no quick fix. Don’t beat yourself up. Even people who wrote a codebase find it frustrating to come back later and make changes to it. 2. Understand the data model and the core data flows of the codebase from a business point of view. Make diagrams and notes to capture this, but do it for your own reference and not to share it with others. 3. Understand the technical architecture of the project to a sufficient extent that you’re not getting bogged down in technical questions when trying to follow the logic. This is one of the reasons that simple languages like Java or Go are preferred over more complex languages. Understand what flavor of OO or any other paradigm applies in the codebase. 4. Create a fork or branch of the codebase where you can annotate the code and add any documentation. This doesn’t need to be kept in sync with the main code as long as it’s substantially the same. 5. When you’re working on a piece, look up git blame and commit messages to see how that piece came about. All these steps will yield results, but slowly. My feeling is that there tends be an inflection point when all the various bits of knowledge start to add up. Until then it will be slow going.