It's 100x harder to read and work with existing code than it is to write from scratch. The engineers that came before and had no existing structures had it easy.
I am also an L6, and have felt similar. When shipping my latest feature, the work was 9 parts reverse engineering the existing code and its insane abstractions and only 1 part shipping CRs. If you actually look at the aggregate of all my CRs, not all that much code was written and a bad SDM might ask "why did this take you so long, it was only 500 lines of changes for this feature". Right, but getting to the understanding that those 500 lines were the ones to change took me an enormous amount of context chasing, reading, and stepping through code.
One thing I would suggest especially since you are not super familiar with C++ and multi-threaded, multi-process, microservice protobuf serializing insanity code, is to look at what other tooling exists to help you trace this code more effectively. A profiler is a great place to start. Most people think of profiler for performance tuning, which is true, but it also tells you which call sites are actually the ones called most frequently, and you can spend more time understanding those ones, vs all the frivolous code that is written all over the place and rarely called.
Usually when I start working on a monster new code base with its own "abstractions" I start tracing everything from input to output and create my own design inspector with my own abstractions to help as a guide to remember the data flow between different components and their RPC calls, get as detailed as you need to help you remember and understand. I was also an L64 at Microsoft prior. Good luck, but don't give up and don't take it as a reflection of your competency. This company is terrible about supporting engineers.
