Writing every single line of code grounds up in every project you work on is reductio ad absurdum. Often times we need to look at and understand code written by our team members or some employees who no longer work on that project.
So if you are new to a project, here is what you could do before you ask one of your colleagues for assistance and try to increase your skills to debug existing code.

Read Product documentation

This is mostly the best place to start because this is where your customers start. For you to know a feature from end to end, this should give references or content that your customers actually go through to set up or use the feature. If you don't find this, just imagine how a customer who doesn't even have access to the code would be using the feature!‍
Try the feature in a lower environment

After you read up the documentation and you have some context, always try the feature yourself in a test account in one of the lower environments (something that's your Continuous Integration environment). This will always give you the ability to be comfortable with some network calls and also with some interactions happening from the client which can help you kick start looking at code.

Go through the Technical Documentation

Every project ought to have some technical design document or some form of documentation for the feature that you are about to venture into. Going through the technical documentation will give you an idea of why a particular feature is developed in a particular way. It might answer some questions like What were the design drivers, considerations, challenges?, `What's still to be done for the project?

Endpoint Identification

This section is only applicable if your application has HTTP (RESTful, GraphQL, SOAP, or such) Endpoints, Asynchronous Messaging Endpoint, Scheduler-based Endpoint, etc exposed that the client invokes to achieve a business functionality. Once you have the endpoint, you have to look for the endpoint pattern in the codebase of your application gateway (if you have a multi-tiered application) or the codebase of the microservices.

Unit test cases

This may seem weird to a few people, but unit test cases, if well written, can easily act as a guide to understand the business functionality and the output of a specific core business functionality for a given set of inputs
Specifically, as you write code and if you are debugging your application, always try to ensure that you have the call stack and its arguments written at each level. This gives an idea of which stack was invoked with what values to arguments. And NEVER PRESUME ANYTHING. One should make no presumptions around the code and start debugging every stack and every code within a method.

For example, let's take a sample code where you are trying to start a group call with a participant where you first validate if a group call already exists with the participant, if not fetch the participant detail and then start group call.
‍

‍
The code is a core logic and you would've gone through a lot of cases to understand each step. But what truly helps is something like

          Dividing the code into logical chunks

So always try to break the methods into smaller logical chunks based on the business workflow. Always understanding code based on business use-case mapping is easier.

Do check out some of these articles

twitter bot
Boltzmann Machine
Average handling time
ensemble averaging
hold time
semantic reasoner
temporal difference learning
scripting language
support operations
rule-based system