71–80 of 202 posts
I was using Vimwiki for this stuff for long, but this idea seems promising for a daily journal. I mostly divide my tasks by day so I don't want timestamp to be added everytime I add an entry. Here's my aliases if it helps: alias ndid="nvim +'normal Go' +'r!date' +'normal o' +':exe \"normal i=============================\ \"' ~/Dropbox/did.txt" alias did="nvim +'normal G' +startinsert ~/Dropbox/did.txt" So use `n(ew)d…
I used to keep a so-called shitlist for a long term project I was involved in. The idea was to document all the worst places in the codebase(150k LOC) that frequently caused weird behaviours. Each record contained a short description, the reason why this piece is bad, hash of the commit that introduced it and of course the perpetrator. Of course the main purpose it served was to relieve stress, nevertheless it helped…
I keep a bugs.txt text file (complete with alias for opening it), in which I record particularly difficult or tricky bugs. It's a really good way to learn from hard bugs. At the top of the file I have a template that I copy each time I add an entry. It has the following fields: 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…
I used to keep a so-called shitlist for a long term project I was involved in. The idea was to document all the worst places in the codebase(150k LOC) that frequently caused weird behaviours. Each record contained a short description, the reason why this piece is bad, hash of the commit that introduced it and of course the perpetrator. Of course the main purpose it served was to relieve stress, nevertheless it helped…
TODO, REDO, DONE with the corresponding JIRA ticket ID for extended mental notes (Pull Request fits here too). IDEs can grok all that together so you can quantify the bad stuff in the code, which can help management make better decisions.
I used to keep a so-called shitlist for a long term project I was involved in. The idea was to document all the worst places in the codebase(150k LOC) that frequently caused weird behaviours. Each record contained a short description, the reason why this piece is bad, hash of the commit that introduced it and of course the perpetrator. Of course the main purpose it served was to relieve stress, nevertheless it helped…
I would call it notes.txt to make it more positive. Bad code is everywhere, and don't let them make you sad.
Earlier quoted context omitted.
I would call it notes.txt to make it more positive. Bad code is everywhere, and don't let them make you sad.
Actually the fact that I finally had an outlet for my frustrations was very cathartic. It was a lot like writing sad poetry over lost love.
I keep a bugs.txt text file (complete with alias for opening it), in which I record particularly difficult or tricky bugs. It's a really good way to learn from hard bugs. At the top of the file I have a template that I copy each time I add an entry. It has the following fields: 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…
You have only 210 bugs in 15 years?
I used to keep a so-called shitlist for a long term project I was involved in. The idea was to document all the worst places in the codebase(150k LOC) that frequently caused weird behaviours. Each record contained a short description, the reason why this piece is bad, hash of the commit that introduced it and of course the perpetrator. Of course the main purpose it served was to relieve stress, nevertheless it helped…
I've done the same, although, i just put it right in the code: TODO, REDO, DONE with the corresponding JIRA ticket ID for extended mental notes (Pull Request fits here too). IDEs can grok all that together so you can quantify the bad stuff in the code, which can help management make better decisions.
I keep a bugs.txt text file (complete with alias for opening it), in which I record particularly difficult or tricky bugs. It's a really good way to learn from hard bugs. At the top of the file I have a template that I copy each time I add an entry. It has the following fields: 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…
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.
I still like paper and can remember this post on this slick way to index a paper based notepad. I will have to dig it up.