> I can't seem to hold more than about 2 levels of call stack in my head...several layers deep...call stack in my head. This describes me (early 40s but I was

> I can't seem to hold more than about 2 levels of call stack in my head...several layers deep...call stack in my head. This describes me (early 40s but I was always like this) so I just write it down in a notebook. There's no advantage in trying to keep everything in head when we can use well tested tools. As such, do know that porting API is tough in best of times. It's not easy to just walk into it and understand, let alone replicating the functionalities in other language. You are trying to pull off several things at once. I'll also repo my earlier comment verbatim[1] where I offered my suggestion to someone in similar situation. It's beneficial to approach learning about an API top-down and bottoms-up. The context in which the API operates and then the working of the API in itself. Imagine if you were in charge of maintaining a hardware tool. I first want to know how this tool is used by various customers before learning how the tool works. 1. Begin by learning all the end-to-end product flows this API is going to be invoked within. This is the context in which your API is operating in. It also sets the stage for non-functional requirements such as latency, and availability requirements. How will end customer and business be impacted if this API were to misbehave? 2. Next speak to all the customers of this API. How do they produce the data for your API's inputs and how do they consume your API's output. You will be surprised by all sorts of creative ways in which an API gets used, not necessarily what the API was intended to begin with. But you need to support all those clients so better get to know their use cases. Also, understand how they handle your API failures. The consumers tend to make unstated assumptions about input/output validations and invariants. It's not documented anywhere but floats around as tribal knowledge. Extract that knowledge and document it somewhere. Make sure you are very clear about every single input parameter, how it's produced and its expected values as well as every single output parameter and how it's consumed. Don't forget about exceptions. Often times customers treat exceptions as just one of the expected output parameters and so actually depend on the API throwing that exception. 3. Finally, take a look at the API's implementation. Don't get frustrated if you don't understand more than 50% of the code. It's perfectly fine. Make notes of the parts that make sense and also note down those questions. Ask around. Often some parts makes absolutely no sense to you. But it is there for a reason, someone as competent as you put it in the first place. Again, ask around both within your team and the API's clients. Pay attention to the API's downstream dependencies and how their failures are handled and bubbled up to your clients. Your API's SLA depends on your downstream APIs, learn about them and ensure that it matches the expectations. 4. You also have indirect consumers of your API who depend on the side effects produced by it. Make sure you learn about them. If this API causes a side effect (such as DB update, publish a message to Kafka) then learn how those side effects are consumed. Does someone depend on it? If yes, how? Though I've described these steps in sequence I find it useful to approach all of them in parallel and over multiple iterations. At first everything is blurry and after first pass you penetrate through about 10% of cloud cover. After 4th or 5th pass you will have a reasonable understanding (~85%) to make small bug fixes. [1] https://news.ycombinator.com/item?id=25944265 https://news.ycombinator.com/item?id=25944265