When building an understanding of a singular piece of code within a large application, we can use tooling to debug and study how it functions. In JavaScript, we can simply place a debugger; statement, and then execute the part of the application that we know activates that particular code. We can then step through the code, line by line, to answer the following questions:

• Where is this code called? A clear expectation of how an abstraction is activated can help us to build up a model of the flow or order of the application in our head, enabling us to make more accurate judgements about how to fix or change certain things.
• What is passed to this code? An example of what input an abstraction receives can help us to build up a clear concept about what it does, and how it expects to be interfaced with. This can directly guide our usage of the abstraction.
• What is outputted by this code? Seeing the output of an abstraction, partnered with its input, can give us a really solid idea of what it does, computationally, and can help us to discern how we may wish to go about using it.
• What levels of misdirection or complexity exist here? Observing complex and tall stack traces (meaning that, functions that are called by functions that are called by functions, ad infinitum...) can indicate that we may have difficulty in navigating and understanding the flow of control and information within a certain area. This would tell us that we may need to augment our understanding with additional documentation or communication with informed colleagues.

Here is an example of doing so in a browser environment (using Chrome Inspector):

Using a debugger like this can present us with a call stack or stack trace, informing us of what path was taken through the code base to get to our debugger; statement. If we are trying to understand how an unfamiliar class or module fits into the larger picture of a code base, this can be very helpful.