"By writing down an entry in the bugs file for each interesting bug, I find that I learn much more easily. There is something with the act of writing that makes me think more deeply about what happened." - linked post
I like this a lot, I've been using my blog as an extension of my brain and the act of formulating a single post about a text file forced me to clarify my thoughts. Ill try this the next time I find bugs. Also +1 for split keyboards!
From your 18 lessons learned post:
> 6. Changing assumptions
My solution for this is to litter my code with "assert" which acts to both document the assumptions and prevent them sneaking past the point where the assumption was made.
Depending on the language, they might not prevent anything because asserts can/will be ignored in production. See for example Java, python -O.
Re:Keeping a plaintext “did” file
by dotancohen on Monday July 16, 2018 @08:35AM
(#17540784)
That's exactly why assert() is used and not if(). It is meant to be ignored in production in places where one would traditionally do `if (foo) { // This should never happen }`. Production code throws no Exception, in 20 ms the trajectory is recalculated anyway, and everybody is happy. Happens in testing or staging? The exception is logged and fixed.
Re:Keeping a plaintext “did” file
by dotancohen on Monday July 16, 2018 @08:38AM
(#17540797)
I do something similar, but take note of language-specific features which cause or could prevent the bug. I find lots of the tricky bugs are due to language peculiarities.
Oh, and the file is called entomology.txt because it's more about studying them then logging them.
You have only 210 bugs in 15 years?
Date:
Symptom:
Cause:
How found:
Fix:
Fixed in file(s):
Caused by me:
Time taken to resolve bug:
Lessons:
I've used this system for 15 years now (210 entries), and it's been very helpful, especially for lessons learned.
More here: https://henrikwarne.com/2016/04/28/learning-from-your-bugs/
https://henrikwarne.com/2016/06/16/18-lessons-from-13-years-...