How can I contextually learn about my team's upstream and downstream dependencies quickly?
One thing I have noticed about competent engineers is that they have a very strong understanding of upstream and downstream dependencies in terms of what are the typical parameters being passed into our API's and what we return and what are the things we pass into our dependencies API's and what they return,
How can I learn the context behind what data is typically being passed quickly? I understand that one of the best ways to learn is to start tinkering, and call the API's myself and see what they return. I was wondering if there is any faster way because surely a staff/principal/TL doesn't have the time to tinker with all of the different dependency services and understand what they take in and return. Is it just a matter of reading documentation and asking around?
Discussion
(2 comments)- 3a year ago
It may not always be feasible to tinker a complex nested collection of microservices. What you could do is review some of the documentation and make educated guesses. For documentation, APIs generally have documentation in wiki or the model themselves. You could also figure out what an API is for by looking at the API code themselves, but that's generally for deeper dives. You could also search for reference of the API and how its being used in the internal code search.
Ask your teammate or the dependencies owner question about their services.
One thing to note staff+ engineers generally pick up context faster but its not necessary deep diving into the code and models. For my ramp up, i generally find talking to a lot of tenured people and asking a lot of question help build a lot of context much faster. - 2a year agoMeta, Pinterest, Kosei
There's another element as well, which is to be ok with not knowing. Very senior engineers make a judgment call on whether it's worth going down a rabbit hole to understand exactly the format and types of data being passed into and out.
Imagine the depth of understanding for a module being from 1 - 10, with 1 meaning you have no idea what's happening, and 10 meaning that you are intimately familiar with every line of code. You don't need to get to 10 (in fact, if you get to 10 before getting started, you probably wasted a bunch of time). Be ok with getting to a level 6 or 7, and then you can make educated guesses to fill in the details.
Some level of hand-waving is fine here, because you'll find that Staff+ engineers can usually predict what's behind the hand-waving, based on their past experience and judgment.
