Live data from Hacker News

Keeping a plaintext “did” file

theptrk.com

91–100 of 202 posts

Re: Keeping a plaintext “did” file

#91

Isn't this effectively what code commits are for? If you've done something worth noting, it should probably be in a commit anyway.

As a contractor it’s useful record things like attending meetings, presentations, research etc that aren’t code.

In fact for any employee it’s useful to keep track of stuff like this, come PR time.

Re: Keeping a plaintext “did” file

#94
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

Same here. But haven’t found an effortless way to append from the shell file like author. As a result, I have more days without entry than days with.

I looked at Google’s scripting and didn’t see an easy way to open and append text like timestamp.

I used something similar and just appended a file in Dropbox, but I have a few locations that don’t allow Dropbox mounted.

Re: Keeping a plaintext “did” file

#95

Earlier quoted context omitted.

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.

I think https://marketplace.visualstudio.com/items?itemName=Gruntfug... is what you're looking for.

Re: Keeping a plaintext “did” file

#97
post #78

Earlier quoted context omitted.

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 would do the same if I weren't afraid of coming off as passive-aggressive given that I voiced my opinions in the past but received a reply in the vein of: "We're aware that this old code is really bad, but with our constrained resources we need to prioritize keeping this boat afloat.".

I keep mine locally. I have the PlainTasks[0] package installed for Sublime Text. It's a plaintext file with a bit of TODO functionality baked in. When I find something, I note the commit, the line (or block), and why I want to fix it. I try to slightly estimate high enough that I could throw some fixes in for the sprint.

[0]: https://github.com/aziz/PlainTasks

Re: Keeping a plaintext “did” file

#98
post #5

This reminds me of the `plan` files used by John Carmack and and ID software. It's a good way to look back at things and remember how far you've gone and give some perspective on how some big problems at the time were not so big today...

I've gotten into the habit of defensively tracking every interruption - if somebody stops by my desk or slacks me or asks me to come by and look at something, I keep a text file of exactly when and how long. Then, if anybody ever asks why such-and-such is taking so long, I have a detailed record of _exactly_ why.

Re: Keeping a plaintext “did” file

#99
post #78

Earlier quoted context omitted.

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 would do the same if I weren't afraid of coming off as passive-aggressive given that I voiced my opinions in the past but received a reply in the vein of: "We're aware that this old code is really bad, but with our constrained resources we need to prioritize keeping this boat afloat.".

At some point you do need to stop baling water and actually plug the hole though.
Post reply on HN