How do your systems truly work in production?
I get questions about the product from different areas of the company like business development, marketing or data science. Even the product managers who wrote the requirements are asking what exactly is going on.
So I read the source code to understand.
Edge cases, legacy conditions, or plain bugs can surface when I’m excavating code. I document the true behavior of the system, not what the customer wants or what the product team intended. The code is the source of truth I can use to explain why users are observing a certain behavior.
To hone this skill, what helped me was not be judgmental about code. I ignore the formatting, who wrote the methods, or if tests are present. I turn a blind eye if they used a O(N^2) algorithm instead of a O(log n) one. Does not matter when I need to explain the behavior. I don’t have time to refactor code as I’m tracing through each line.
I need to understand how the system works quickly and summarize for non-technical people.
When I worked on compliance, I would then work with the lawyers to compare their interpretation of the law with what I observed. If there was a mismatch, only then would I call in engineering support to modify or write code.
My team is usually too busy working on issues or extending the product. I would have a hard time asking an engineer off a project to have them read code in an area they’re not even familiar with.
You might not need to code daily while managing. I stress the importance of explaining what the product is doing and why data is in a certain state. Many business functions like strategy, legal, product, or analytics need this information to make accurate decisions for the company.
Maintaining the ability to read code quickly is a valuable skill which will help everyone around you.
Leave a Reply