Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Keeping a plaintext “did” file

theptrk.com

Post reply on HN
Print view View original

81–90 of 202 posts

Re: Keeping a plaintext “did” file

#81

Post by kchr »

TheSpiceIsLife wrote: post #48
ajuc wrote: post #26

Similar but not the same: most days day at work I create one or more txt files in notepad (kate to be exact) where I paste every temporary info while I work on some task. Basically everything that doesn't go to git, and you have to keep somewhere while you're working on it: - nonobvious terminal commands or small scripts I had to write - fixes for enviromental/configuration problems - fragments of stacktraces - fragm…

If it's appropriate, would it be easier to use a clipboard enhancer that writes everything you copy to a file? I use ClipX at work (Windows), fairly sure it has a logging feature, and I think it can be told not to record from password fields; and Flycut at home (Mac) but Flycut doesn't seem to have logging.

Hmmm, everything? Unless you write perfectly all the time, that clipboard/file would be full of near-duplicates, corrections, copy/pastes, etc....

It would be a mess for me at least ;-)

Re: Keeping a plaintext “did” file

#82

Post by kchr »

idiomatic1 wrote: post #49
ajuc wrote: post #26

Similar but not the same: most days day at work I create one or more txt files in notepad (kate to be exact) where I paste every temporary info while I work on some task. Basically everything that doesn't go to git, and you have to keep somewhere while you're working on it: - nonobvious terminal commands or small scripts I had to write - fixes for enviromental/configuration problems - fragments of stacktraces - fragm…

Vimwiki diary, `\\w` to go to today's file, and even get syntax highlighting blocks for anything vim knows about.

Vimwiki user but unaware of this feature. TIL!

Re: Keeping a plaintext “did” file

#83

Post by criddell »

thinkingemote wrote: post #60
ajuc wrote: post #26

Similar but not the same: most days day at work I create one or more txt files in notepad (kate to be exact) where I paste every temporary info while I work on some task. Basically everything that doesn't go to git, and you have to keep somewhere while you're working on it: - nonobvious terminal commands or small scripts I had to write - fixes for enviromental/configuration problems - fragments of stacktraces - fragm…

I have used a Google Doc for this, as it has ability to copy in screenshots. However a large project with lots of stuff makes it lag

That's a better idea than in local text editor if you are working in Windows. My machine has a way of deciding to reboot on precisely those days that walk away with something open that I don't want to lose.

Re: Keeping a plaintext “did” file

#84

Post by dotancohen »

tga wrote: post #79
tempay wrote: post #67

Earlier quoted context omitted.

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.

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

#85

Post by dotancohen »

henrik_w wrote: post #36

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 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.

Re: Keeping a plaintext “did” file

#87

Post by s-shellfish »

Tade0 wrote: post #69

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…

> Of course the main purpose it served was to relieve stress, nevertheless it helped me with my work a few times.

That seems more preferable to becoming what essentially amounts to becoming a mouth piece for potential areas of preference (error?) in software design.

Re: Keeping a plaintext “did” file

#88

Post by dev_north_east »

thinkingemote wrote: post #60
ajuc wrote: post #26

Similar but not the same: most days day at work I create one or more txt files in notepad (kate to be exact) where I paste every temporary info while I work on some task. Basically everything that doesn't go to git, and you have to keep somewhere while you're working on it: - nonobvious terminal commands or small scripts I had to write - fixes for enviromental/configuration problems - fragments of stacktraces - fragm…

I have used a Google Doc for this, as it has ability to copy in screenshots. However a large project with lots of stuff makes it lag

Microsoft OneNote is good for this.

Re: Keeping a plaintext “did” file

#90

Post by roryisok »

mholmes680 wrote: post #74
Tade0 wrote: post #69

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 used to do this in visual studio, it had a task list view that would aggregate all the comments that start with 'TODO'. Since I made the move to VSCode I haven't found anything similar.
Post reply on HN