Isn't this effectively what code commits are for? If you've done something worth noting, it should probably be in a commit anyway.
In fact for any employee it’s useful to keep track of stuff like this, come PR time.
91–100 of 202 posts
Isn't this effectively what code commits are for? If you've done something worth noting, it should probably be in a commit anyway.
In fact for any employee it’s useful to keep track of stuff like this, come PR time.
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
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.
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.
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.".
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...
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 use gtd with org mode and I can move my finished tasks to a done file when they're complete (if I care to.) Helps with standup etc.