A common trap is trying to learn all the parts and reading the docs. Docs for most codebases are out of date. We stopped doing docs - most engineers are better

A common trap is trying to learn all the parts and reading the docs. Docs for most codebases are out of date. We stopped doing docs - most engineers are better at reading code than the docs, and we design things in a way that when someone leaves or joins, things can be picked up without docs. First, learn how the parts connect to one another. You want to add a button. What is that button connected to? What runs underneath? Where does that change? Does it go through an API? Is the value tracked in a global variable? What else is a value connected to? How is change displayed? Often changes in value are observed in modern code, but it can also be manually changed when a value is changed. You don't want to learn parts because parts are easily replaced. Learn connections between those parts. Some things appear invisible to those who have worked in similar systems. These don't show up in docs sometimes, which makes the learning curve steeper. Next: learn purpose. Why not purpose then connections? A system can be corrupted from its purpose. Things will eventually rewire to suit the purpose, but they don't function that way now. Purposes can change too. When a code is written by a large contractor, the purpose is to make money. When that code is passed to the client, the purpose is to keep doing what it does and also to save money and time. When you see major refactors, it can be because of a change in purpose, but it's useful to understand how and why it's changing. Sometimes there's no purpose - someone copied something they didn't understand. Docs are good at denoting purposes too, so this is a good place to read them.