EE > Write a Lot!
The single most valuable tool I've found for maintaining my orientation and sense of progress as I work through something complex is to have a written log of everything I'm trying, what's worked, what's not, links and screenshots. Which is why writing gets a full section just for itself.
There's a certain structure to take notes that works fairly well for me; I recommend adapting it to one that works well for you:
What's the goal?
Start by writing out the problem you're solving at the top: why are you dealing with this? What do you hope to achieve? Scrolling past the note every morning is extremely useful for avoiding rabbit holes and focusing on the most valuable ways to spend your time.
Open Questions
Second, I try to have a list of major open questions I want answers to that I haven't found yet: either why a certain subsystem works a certain way, or where I should make certain changes as examples. This reminds me to look out for signals I would otherwise ignore.
Daily Log
A daily log to take notes on progress: I tend to write out how much time I expect to have today to work on this, then the actual work I hope to accomplish as headings. I fill this in as I go through the day, including stack traces, observations, other TODOs that pop up (particularly second-order tools I could build to make all of this painless, and why-oh-why has no one else implemented it yet).
The daily log tends to be incredibly valuable as an excellent replacement for my memory: I can easily return to the project and start right where I left off. It also helps maintain momentum and understand my own progress – without concrete results or code it can be hard to remember the sheer amount of work that goes into ramping up on something complex or brand new.
If you're unfortunate enough to have a manager's schedule instead of a maker's schedule, your daily log acts as an excellent way to regain context and continue from where you left off.
References
Then I keep quick links to references I need to access frequently that are related to that project. This list can become extremely large so I'd recommend keeping it to only the most important references. The rest can live in the daily log.
Diagrams!
A complementary skill to build out is to build mind maps of the code base: I strongly recommend using something electronic like Kinopio or Scapple. That allows you to paste in links and code instead of writing them down and can help navigate the most confusingly named of code bases (Android, I'm looking at you!).
Be selective about how you structure your diagram: resist the urge to include every single class (which is something that can be automated) – prioritize what's important and build a map into the code base that highlights the parts that you actually care about.
I used to lean on Scapple a lot while I was working on Android. As an experiment I'd written a web-based Scapple renderer to be able to share these: you can also pan around a full Scapple I'd made while exploring how ANRs work in AOSP.
