Engineering requests are often abstract, with many details of the request not visible to engineers. The role of engineers is not only to write code but also to ask the right questions to stakeholders before solving technical challenges.
Let me share a story with you, but I will omit many details because it is related to a work event. I was tasked with developing a way to determine if we were losing data. At first, I recognized that this seemed like an engineering problem, but I also realized that I needed to ask various questions to find the solution. This led me to ask different questions in various channels and forums to identify the root cause of the data loss issue. My findings are interesting because they deviate from what an average engineer would have done.
The specific use case or question we had in mind for this task was not clear.
For a portion of the task that seemed achievable, another larger group was already working on it. This saved us from debugging and engineering efforts to figure out why this issue existed.
Our data loss could only be due to crashes and internet outages, which we were already logging.
You may think these were trivial, but consider a situation where you, as an engineer, string together 100 lines of code only to realize that those lines were not needed because you failed to gather as much information as possible during the task initiation stage.
In conclusion, I encourage engineers to improve their communication skills and stakeholders' conversational skills. Additionally, we should develop the soft skill version of our debugging skills, which involves extracting information from vague tasks. You never know, you may solve many of your bugs simply by asking clarifying and follow-up questions. Many of our engineering tasks may not require code. Until I have another letter for you, goodbye!