For me, it's tracing code/pipelines to figure out how a result was produced, typically in the context of that result being wrong somehow. Go To Definition is the most useful function in any editor.
I'm always surprised by how frequently colleagues don't think to do this and are left helpless.
This reminds me of my further theory that everyone needs one 'heavy' and one 'light' technique. The 'light' technique is something that often works well as a heuristic and can be an effective unit of iteration. The 'heavy' technique is something that you can fall back on in difficult cases, something that can reliably solve hard problems, even if it's slow.
Sometimes the heavy technique is: just ask someone else. ;)
You jest, but that's how my sister gets through life, and it's always fascinated me.
She's incredibly intelligent, but more importantly she's a phenomenal social networker. She always has someone to call to ask about any question or solve any problem that comes up in life, and she's great at connecting these people with each other when they have problems of their own - so they all want to help her with whatever she needs, just to gain access to a pool of people they themselves can talk to.
What do you do with a skillset like that? I honestly don't know - something in leadership, probably, something where finding the right people and setting them to work is the most important skill of the job.
That wasn't in jest. I worked in a place where this was a norm. Nothing was properly documented, instead everyone would just ask and answer questions on chats; somehow, this actually kept velocity high.
Found it really hard to adjust to that. I'm the kind of person that prefers to research things on my own, find hard references and understand context. But there, this was the wrong approach.
I have both felt and seen this at work and I would add to this the meta-technique of binary search. Once it is added to your light and heavy technique you can solve what seems intractable at first glance faster than many people can even orient to the problem.
Likewise. I don't always do this, but for problems that cost me much time or effort, I like to try to make sure that, if I wanted to reproduce a bug or problem, I'd know exactly how to write it.
Writing and understanding working correct software is, it turns out, a rather different skill from that of writing and understanding broken (or confusing) software. I'd also wager good money that the latter skill directly builds the former.
It's amazing that a lot of new developers don't know how to use them at all! I'm not even talking about using the command line gdb, but just the basic "Set Breakpoint" feature and attaching to processes.
I'm always surprised by how frequently colleagues don't think to do this and are left helpless.