Member-only story
For most software engineers, especially individual contributors, your work, the products of your time and effort, will eventually be your codes. But writing codes are not easy. What if you get stuck? What if you are in a marathon of debugging and all you can tell your managers and leads about what you have done is “in progress”/ “I am working on it”. Beyond the final products, there is an important artifact we can create to demonstrate our progress — debugging docs.
Debugging Docs
It is hard to quantify our debugging progress. We have never heard someone saying “I have finished 50% of my debugging and I will figure it out in 30 minutes”. But we can still demonstrate our debugging progress via a debugging doc.
As an intermediate artifact, a debugging doc should simply outline the steps taken to reproduce, diagnose and/or the error.
Since no one knows they are in 10% or 90% of their debugging progress, writing a debugging doc will often be the last thing on their mind: why would I write a debugging doc if I can just finish the debugging and turn in the code? There are some scenarios that a debugging would be helpful.
- After a long hours of debugging, you have exhausted your…