Does anyone remember what your Maths teacher used to say?
Show your working out!
I mean, I bet they said more than that, but this is what I remembered. I think we used to get marked down if you just provided the answer. You got more marks when you showed how you derived your answer.
This post is a plea for software engineers to do the same when answering technical questions, or debugging an issue in group communication channels.
Let's take a standard question we are probably asked from time to time: "Can we see if there is a performance issue on our application right now, please?"
It's a typical question, so let's show differing levels of answering this question.
1 - Just the answer π
You're asked, and you answer.
No, I cannot see any performance issues at the moment.
Helpful to the originator of the question, they have their answer. Perhaps less useful to the next engineer to come along?
2 - The answer and visuals ππ
You're asked, you answer, and you provide some evidence to back up your opinion.
No, I cannot see any performance issues at the moment. See the attached graphs for the relevant systems.
Graphs attached πππΉπ
With any luck, the graph will provide some hints to the next engineer where you got the data from. The next engineer may be able to come to the same conclusion. Maybe next time, they can help answer the question (Multiplier effect).
3 - The answer, the visuals, and links to the original data source πππ§
You're asked, you answer. This time, you provide clickable links to the original data source that backs up your opinion β€οΈ.
Looking at this graph for system A, and this graph for system B, I cannot see any performance issues in the last hour. Interestingly, if you scale out here for 1 week, we are running a little quicker than the norm.
See the attached graphs for the relevant systems.
Graphs attached πππΉπ
With this level of context, many engineers can now walk in your shoes as to how you answered the question (Multiplier effect unlocked). Ideally, for those without direct access to monitoring systems, you provide visuals that are useful within in your communication format (be it Slack, email etc).
For me, this is the best type of answer to the situation. Sure, it takes longer, but perhaps this unlocks others to start answering the same questions in the future. The more you share knowledge around engineers, the quicker we can collectively respond to questions.
Summary
I'd recommend we strive for example 3 above. If you provide enough context, others can learn from your experience. This unlocks their potential, and allows everyone to deliver at pace.
Photo by Susan Q Yin on Unsplash
Top comments (0)