Sincere thanks for your response. This is probably one of my biggest weaknesses as an engineer so I really appreciate your help.
Right off the bat, I think you hit the nail on the head whereas I have only slowly started to think about how API's are used, rather than just how they're written.
1 is a great point. I'll take some time to get more info on the end to end flows, and I think that will provide some great foundational understanding before even going in.
2. Is a whole knowledge bomb in itself. I hadn't even thought of many of these points. Talking to the consumers is another great idea and I'll make sure to do that.
3. I appreciate the reassurance. Part of why I never built up the skill so far is because it's, frankly, intimidating to start poking at some big system from scratch. Thinking about downstream APIs is a smart angle.
4. I like this point a lot. Seems like a way to level up and start thinking about the bigger picture.
I can already see the benefit of these strategies and how they'll help me develop my understanding. Now I feel equipped to tackle our team API's, not as daunted as I was feeling before. Thanks!
You are most welcome! I'm glad you found it useful.
As you go through this exercise I'm sure you will gain new insights into the process and the API itself. Please document them for the benefit of others around you. The way I see it, you are anyway putting all the effort to learn the system, you might as well put in a little bit more effort to document and get your peer's appreciation in return. Also, you will have something concrete to show for all the time and effort you put in over 2-3 weeks, as opposed to just saying "Right I'm now ready to maintain/change this API".
Written communication and specifically documentation is a very under-appreciated skill among software engineers. But it's a great way to make yourself visible among your peers and spread the knowledge of the system.
The software you write will have impact on customers, but they are far removed from you. The documentation you write on the other hand is beneficial to your peers with whom you work and interact every day so this is a good way to be in their good books. They will appreciate and respect you for going the extra distance to spread the knowledge.
Absolutely. I've always been a huge fan of documentation and push for it when I'm at an org that doesn't care much for it. Thankfully my current org, at least my current team for sure, is very pro-documentation, so I'm more than happy to create documentation for everything I learn and give back to our internal community since I've also benefited a lot from others' documentation.
I also like your point on visibility a lot. That's something I've only really starting learning about recently at my current org, and you make great points there.
Right off the bat, I think you hit the nail on the head whereas I have only slowly started to think about how API's are used, rather than just how they're written.
1 is a great point. I'll take some time to get more info on the end to end flows, and I think that will provide some great foundational understanding before even going in.
2. Is a whole knowledge bomb in itself. I hadn't even thought of many of these points. Talking to the consumers is another great idea and I'll make sure to do that.
3. I appreciate the reassurance. Part of why I never built up the skill so far is because it's, frankly, intimidating to start poking at some big system from scratch. Thinking about downstream APIs is a smart angle.
4. I like this point a lot. Seems like a way to level up and start thinking about the bigger picture.
I can already see the benefit of these strategies and how they'll help me develop my understanding. Now I feel equipped to tackle our team API's, not as daunted as I was feeling before. Thanks!