I also log my debugging process, but usually I'm less verbose with the explanations and more verbose about the specific actions I'm taking. For example, instead of a note saying "starting a debugging session to find out the issue with the sign-up during a load test" I'll provide the full command I used. Why? So that the process is reproducible in the event that I need to walk back a few steps or hand off the debugging to another team. I'll also include environment information such as my current machine, PATH, and commit hash.
I do something similar, but only for bugs that were especially tricky. I don't do it as I am debugging, but if the bug qualifies, I'll write down the steps I took debugging it, as well as the reason for it, the fix, and (most importantly) lessons learned. I've done this for close to 20 years now, and I believe it's helped me internalize a lot of lessons on how to code, test and debug.
I make notes like this for all tasks I do at work, not just for debugging, but also find it very useful for implementing new features, preparing presentations, meetings. I don't just log what happened, but also log all thoughts, ideas, TODOs, etc.
I add screenshots of code, screenshots of apps, links, copy code blocks, queries I used, command outputs, various log snippets, file names. I also use highlighters a lot, and draw stuff.
Currently, I use OneNote for all this. I used to use pen and paper in the past, but when it's digital, I can Copy-Paste or screenshot anything. I recommend everyone to try it. :-)
4 comments
[ 2.9 ms ] story [ 17.1 ms ] threadhttps://henrikwarne.com/2016/06/16/18-lessons-from-13-years-...
I add screenshots of code, screenshots of apps, links, copy code blocks, queries I used, command outputs, various log snippets, file names. I also use highlighters a lot, and draw stuff.
Currently, I use OneNote for all this. I used to use pen and paper in the past, but when it's digital, I can Copy-Paste or screenshot anything. I recommend everyone to try it. :-)