Keeping a plaintext “did” file(theptrk.com)
theptrk.com
Keeping a plaintext “did” file
http://theptrk.com/2018/07/11/did-txt-file/
201 comments
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.
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
[0]: https://github.com/aziz/PlainTasks
At some point you do need to stop baling water and actually plug the hole though.
Nah. The bridge crew all have executive lifeboats. No biggie if the ship goes down.
To completely and hyperbolically torture this metaphor, as long as you whip the galley slaves to row fast enough so that you can jump to safety on "Short Term Stock Gain" Island, you'll be fine.
They should teach this at MBA school. But they don't.
[deleted]
As well as the many IDEs and editors that support these comment tags, Ruby on Rails (and I'm sure other frameworks also) provides direct support for these.
rails notes
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.
Thank you!
> 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.
That seems more preferable to becoming what essentially amounts to becoming a mouth piece for potential areas of preference (error?) in software design.
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 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-...
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-...
"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!
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.
> 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.
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.
Oh, and the file is called entomology.txt because it's more about studying them then logging them.
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
- fragments of log files
- packages that needed to be installed
- short todo lists I created while doing sth
- links to webpages I found that had a solution to my problem
- profiling results for solutions I compared
- parts of emails I copied to focus on the important fragments with stuff to check/fix
- names of temporary branches created when working on the problem
- xml fragments from some requests I copypasted to kate to prettify it
There's no structure and no plain English descriptions in these files, just bunch of copypasted stuff separated by a few empty lines in a text file.
I have to keep these things somewhere anyway while I work on them, and pasting them in one file that I later save in one directory preserves them for future. I call the file yyyymmdd_some_keywords.txt.
I don't bother to describe the task in plain English, the stuff that's copypasted there is enough for context, I can also check git from same date if something's not clear. The most important thing is - there's no overhead, just open the file when starting a new task, keep it opened while you work on sth and save it when you finish. So I have hundreds of these files after a while, and when I encounter some problem I can quickly grep to check if I seen similar stacktrace before and what it was about.
Before I started doing this I had several instances of déjà vu - I could swear I've seen this problem before but can't remember what it was about and how it was solved.
- nonobvious terminal commands or small scripts I had to write
- fixes for enviromental/configuration problems
- fragments of stacktraces
- fragments of log files
- packages that needed to be installed
- short todo lists I created while doing sth
- links to webpages I found that had a solution to my problem
- profiling results for solutions I compared
- parts of emails I copied to focus on the important fragments with stuff to check/fix
- names of temporary branches created when working on the problem
- xml fragments from some requests I copypasted to kate to prettify it
There's no structure and no plain English descriptions in these files, just bunch of copypasted stuff separated by a few empty lines in a text file.
I have to keep these things somewhere anyway while I work on them, and pasting them in one file that I later save in one directory preserves them for future. I call the file yyyymmdd_some_keywords.txt.
I don't bother to describe the task in plain English, the stuff that's copypasted there is enough for context, I can also check git from same date if something's not clear. The most important thing is - there's no overhead, just open the file when starting a new task, keep it opened while you work on sth and save it when you finish. So I have hundreds of these files after a while, and when I encounter some problem I can quickly grep to check if I seen similar stacktrace before and what it was about.
Before I started doing this I had several instances of déjà vu - I could swear I've seen this problem before but can't remember what it was about and how it was solved.
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!
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.
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.
This is very similar to what I do as a sys eng. I call them weekly's, store them as [date].txt and use notepad++ to compose. I separate stuff with #########[brief desc/todo] and save the all the random tidbits, logs, dumps, presentation outlines, requests, urls, etc.
I have a script that copies them up to my backup drive and Windows full-text indexing is enabled on the folder, so it is easy to search all the content from the start menu. It helps me because my memory is not the best...your point on the deja vu is right on.
The stuff that ends up being really helpful, such as some long bash command, PS for querying AD, complex DB queries, etc. get promoted to helpful_notes.txt.
I have a script that copies them up to my backup drive and Windows full-text indexing is enabled on the folder, so it is easy to search all the content from the start menu. It helps me because my memory is not the best...your point on the deja vu is right on.
The stuff that ends up being really helpful, such as some long bash command, PS for querying AD, complex DB queries, etc. get promoted to helpful_notes.txt.
> Basically everything that doesn't go to git, and you have to keep somewhere while you're working on it
That way I end up with 100+ unnamed files in notepad++. At least it is searchable.
That way I end up with 100+ unnamed files in notepad++. At least it is searchable.
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.
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.
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.
Notepad++ might be your friend in this situation. It auto saves the doc (even if you haven’t ‘saved’ it yourself)
Microsoft OneNote is good for this.
[deleted]
Thank you for sharing. It is simple and efficient. I did something like this on a "per-ticket"-basis but did not really thoughtful use it. I will definitely try this again with more focus on putting all necessary/related information in it - I included only a fraction of the relevant information.
I am constantly approached with adhoc requests, often unrelated to the application I work on, probably more of these than actual ticket items.
I've started to number these myself in my own ticket system where I keep scripts, screenshots and logs etc. but I'm using OneNote, because it's so unrestrictive.
I've started to number these myself in my own ticket system where I keep scripts, screenshots and logs etc. but I'm using OneNote, because it's so unrestrictive.
I do the same thing, directly in the ticket comments. It turns into a nice journal, interconnected with other issues, and laid our in time.
Back in the late 1990s and early 2000s I experimented with a number of complex rich text, database, and proprietary formats for my notes files. It was a disaster in terms of long term accessibility. Since ~2004 or so I've used exclusively a single plain text file with embedded filepaths if media references were required.
This has worked far better and now offers a remarkable resource for both nostalgia and getting stuff done. It's huge and search is pretty much the only way through it but I still add every day.
Plain text is best. I feel that even using vim to automate time stamps is too complex. I just write it once by hand. It's easy and literally takes half a second.
This has worked far better and now offers a remarkable resource for both nostalgia and getting stuff done. It's huge and search is pretty much the only way through it but I still add every day.
Plain text is best. I feel that even using vim to automate time stamps is too complex. I just write it once by hand. It's easy and literally takes half a second.
You might be interested in the vimwiki plugin. The diary feature automatically creates pages per day named with a datestamp. Grep to search.
+1 for vimwiki; all plain text, with some light organization sprinkled on top. I've gone the OneNote/Evernote/GoodNotes route and keep coming back to vimwiki. If I could find a non-kludgy way to get it on iOS, my grail will have been found.
You don't even need grep, as vimwiki has built-in search:
":VWS /pattern/
You don't even need grep, as vimwiki has built-in search:
":VWS /pattern/
Search for /pattern/ in all files of current wiki.
To display all matches use |:lopen| command.
To display next match use |:lnext| command.
To display previous match use |:lprevious| command."i have a folder of plain text files that i use as my notes (my understanding is that vimwiki stores them the same way); i store them in a folder in my dropbox and use 1Writer as the iOS interface to them; it works very well!
I'm also searching for a good solution on iOS.
My current kludgy method is to upload the files to S3 and hit my tiny flask server via WorkflowApp to read the contents. It's not great, but achieves what I need it to do.
My current kludgy method is to upload the files to S3 and hit my tiny flask server via WorkflowApp to read the contents. It's not great, but achieves what I need it to do.
I've settled on a couple of helper functions in bash to accomplish a similar thing (daily journaling):
#######################################
# Normalizes date arguments
# Globals:
# None
# Arguments:
# date (defaults to today)
# Returns:
# string of format 'YYYY-MM-DD'
#######################################
function getDate {
local DATE=${1:-$(date -I)};
if [[ "${DATE}" =~ [+]+ ]]; then
DATE=$(date -I -d" ${DATE} days");
elif [[ "${DATE}" =~ ^- ]]; then
DATE=$(date -I -d" ${DATE} days");
elif [[ "${DATE}" == "tomorrow" ]]; then
DATE=$(date -I -d" +1 days");
elif [[ "${DATE}" == "yesterday" ]]; then
DATE=$(date -I -d" -1 days");
fi
echo "${DATE}";
}
#######################################
# Load a journal file
# Globals:
# None
# Arguments:
# date (defaults to today)
# Returns:
# None
#######################################
function journal {
local DATE=$(getDate "$1");
emacs ~/notes/journal/${DATE}.md;
}Nitpick: here you can use a `case` instead of `if [[ ... ]] elif [[ ... ]] elif ...`:
case "$DATE" in
+*|-*)
DATE=$(date -I -d" $DATE days") ;;
tomorrow)
DATE=$(date -I -d" +1 days") ;;
yesterday)
DATE=$(date -I -d" -1 days") ;;
esacGreat idea. Welcome to the .txt family. A while ago I published Journal.TXT - a single-text file format for journals and the human multi-document format for writers. See https://journaltxt.github.io
PS: I also started Awesome .TXT - A collection of awesome .TXT tools, formats, services, tips & tricks and more. See https://github.com/officetxt/awesome-txt
PS: I also started Awesome .TXT - A collection of awesome .TXT tools, formats, services, tips & tricks and more. See https://github.com/officetxt/awesome-txt
Just checked it out a bit today. Looks like a lot of good stuff there. Thanks for sharing.
For a decade or so, I've been using `vim -o ~/{todo,progress,done}`
That gives me vim with three splits. Every day I add a new heading with the current date in the bottom split, then in the top one I list the things I plan to do that day. As new urgent work comes in throughout the day, I add it to the top split too. When I start working on something, I move it to the middle split. If I have to shift between tasks, I'll keep their entries in the middle split up to data with what i've done, next steps, etc. When I finish something, I move it from the middle split to the bottom split.
You can see a sample at https://imgur.com/a/jNa5Qp3
This helps me
* plan how much I can accomplish in a day
* limit the number of things I'm doing at once
* remember context when i do have to multitask
* explain to others (e.g. my manager) what i've been working on
That gives me vim with three splits. Every day I add a new heading with the current date in the bottom split, then in the top one I list the things I plan to do that day. As new urgent work comes in throughout the day, I add it to the top split too. When I start working on something, I move it to the middle split. If I have to shift between tasks, I'll keep their entries in the middle split up to data with what i've done, next steps, etc. When I finish something, I move it from the middle split to the bottom split.
You can see a sample at https://imgur.com/a/jNa5Qp3
This helps me
* plan how much I can accomplish in a day
* limit the number of things I'm doing at once
* remember context when i do have to multitask
* explain to others (e.g. my manager) what i've been working on
This is great! I might end up doing something like `alias todo=vim -o ~/{todo,progress,done}`
edit: I was curious so pulled up the man page: changing -o to -O opens the windows horizontally stacked.
edit: I was curious so pulled up the man page: changing -o to -O opens the windows horizontally stacked.
Yep, -o will have your work flow top to bottom, -O will have it flow left to right. I prefer the former because it gives me more horizontal space on each line.
For those who use Emacs, org-capture is probably the way to go: https://orgmode.org/manual/Capture.html#Capture
Plus org-clocking, easy time keeping and also offers easy aggregation for reviews. It is really interesting to see after a while how much time was spend at various activities...
https://orgmode.org/manual/Clocking-commands.html
https://orgmode.org/manual/Clocking-commands.html
here's an example of the kind of summary information you can generate over time:
https://snap.philsnow.io/2018-07-16T11-15-11.9p5nrv1j2ohavi6...
I once was really good about keeping notes like this, but I stopped when I couldn't integrate it very well with the flavor-of-the-day bug tracker my team used.
https://snap.philsnow.io/2018-07-16T11-15-11.9p5nrv1j2ohavi6...
I once was really good about keeping notes like this, but I stopped when I couldn't integrate it very well with the flavor-of-the-day bug tracker my team used.
Org caputre is great. Also, helm-org-rifle is an excellent way to quickly find something in your notes:
https://github.com/alphapapa/helm-org-rifle
You can give mulitple search terms to search for them in any order with instant results when typing.
https://github.com/alphapapa/helm-org-rifle
You can give mulitple search terms to search for them in any order with instant results when typing.
Honestly even without using org-capture, org mode is perfect for a "did.org" file.
Yep. I'm amazed by how many different hacks, tools, and one-offs get proposed in threads like this when an amazing plain-text note/organization/GTD/life management ecosystem already exists and is supported by endless configurability. Of course, we're talking about org-mode.
(Religious org-mode user for approximately four years.)
(Religious org-mode user for approximately four years.)
I'm perpetually saddened because I work in aerospace where the IT policies are quite restrictive due to security clearances and whatnot, so I'm stuck on windows and can't install emacs :(
Every few months I toy with the idea of implementing a poor man's org-mode in VBA.
Every few months I toy with the idea of implementing a poor man's org-mode in VBA.
Emacs doesn't have to be installed on Windows, strictly speaking... you can run it out of a subdirectory without using an installer. IIRC the Windows installer just sets up some registry keys that make life a bit more convenient, but they aren't blockers to actually running the application.
That's tough, especially because emacs + org-mode is most usable when combined with a few melpa packages. Even if you could get emacs installed, you'd (probably) want melpa packages to make it more usable.
Is there a great intro to org mode that isn’t the docs? (Never used emacs but tempted because all I’ve heard of org mode)
And for those who don't use emacs, starting to use emacs & then adopting org-capture is probably the best way to go!
I mean, you can tortuously gin up some plaintext format by hand, or you can use Org mode; you can tortuously gin up a skin over git by hand, or you can use Magit; you can tortuously gin up a skin over wget/curl by hand, or you can just use eww.
I mean, you can tortuously gin up some plaintext format by hand, or you can use Org mode; you can tortuously gin up a skin over git by hand, or you can use Magit; you can tortuously gin up a skin over wget/curl by hand, or you can just use eww.
hadn’t heard of these emacs addons. Commenting to save this.
You can combine org-mode with deft for quick note organization and lookup. https://jblevins.org/projects/deft/
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...
The history of the .plan file goes back to way before ID or Carmack. It's been part of unix for a long time. Back when things were simpler, you could finger a user and read their .plan to see what they were up to.
... and other useful info such as office location, phone number, etc. Those were the days before corporate directories.
For a brief bit I had a simple python script dump tweets into a .plan file mostly just to amuse myself by connecting new social media to old.
Hmm, I wonder if I ask my Mastodon host nicely if they'd open up finger protocol support, lol. (ETA: Reminds one of the old adage about blind men touching the elephant.)
Hmm, I wonder if I ask my Mastodon host nicely if they'd open up finger protocol support, lol. (ETA: Reminds one of the old adage about blind men touching the elephant.)
I was shocked to discover that finger is no longer installed by default on most linux distros.
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.
What do you do when somebody interupts you on the way back from your interruption? Do you just log it as "interruption"?
I'm non-reentrant. In that case, I kernel panic.
I've got a small A6 notebook for this, computers are great, but there's still work to be done in translating the abstract diagram/flowchart/sketch amalgamation that's in my brain to a digital representation.
A picture tells a a thousand words, there's pages where I tried redesigning a scene graph implementation, it'd take hours to transcribe the knowledge that I gleaned from those (roughly drawn) images into words.
A picture tells a a thousand words, there's pages where I tried redesigning a scene graph implementation, it'd take hours to transcribe the knowledge that I gleaned from those (roughly drawn) images into words.
Paper rocks. I really like its battery life, negligible boot-up time, customisability, interoperability and extensive unicode support.
Paper beats silicon.
The computer is a gateway to a billion distractions, my most productive days are the ones where I manage to write down the most on paper. The physical act of writing helps memory, and it works everywhere.
Physically checking checkboxes is also fun, as is crossing out plans that become irrelevant during the day.
The computer is a gateway to a billion distractions, my most productive days are the ones where I manage to write down the most on paper. The physical act of writing helps memory, and it works everywhere.
Physically checking checkboxes is also fun, as is crossing out plans that become irrelevant during the day.
> Its super important to take a second every once in a while to simple write down what you did during the past mental sprint. Writing down what you learned solidifies the knowledge.
Sorry, I didn't get why it's super important. Isn't it a context switch? How does it really help to solidify the knowledge? How often do you review those did files? How exactly reviewing what you did helps? (I'm thinking of myself reading some "did" from the past and fail to see any benefit). How this solution is better than using Notes or Google Keep or whatever online tool? How to manage it across multiple machines and backup it?
If the goal is to solidify knowledge, I can't help but suggest using Anki: there was an article about in HN not so long ago: http://augmentingcognition.com/ltm.html
Sorry, I didn't get why it's super important. Isn't it a context switch? How does it really help to solidify the knowledge? How often do you review those did files? How exactly reviewing what you did helps? (I'm thinking of myself reading some "did" from the past and fail to see any benefit). How this solution is better than using Notes or Google Keep or whatever online tool? How to manage it across multiple machines and backup it?
If the goal is to solidify knowledge, I can't help but suggest using Anki: there was an article about in HN not so long ago: http://augmentingcognition.com/ltm.html
I have a windows notepad file for the same reason. F5 prints the date/time stamp.
or you can just start the file with:
.LOG
one of the few extra features notepad have =)
Just to clarify because I had to google to have any clue what writing .LOG at the top was supposed to do.
It will create a time-stamp (similar to F5) each time you open the document.
So nothing for us that never closes applications ;)
It will create a time-stamp (similar to F5) each time you open the document.
So nothing for us that never closes applications ;)
Wow! I truly wonder whether that's in there to scratch one Windows engineer's personal itch some day back in 1998 or something ;-)
Didn't know this! I'd upvote if I could.
Thank you for this shortcut!
Sharing my utility Jot: https://github.com/mkaz/jot
Jot stores notes in text files organized by date, includes simple searching, templates, and a few other niceties; plus you can add notes via command-line, pipe, or open in your EDITOR (vim)
Jot stores notes in text files organized by date, includes simple searching, templates, and a few other niceties; plus you can add notes via command-line, pipe, or open in your EDITOR (vim)
Whoa never heard of Syncthing (open source syncing to replace dropbox). What led you to choose that?
I was using Bittorrent Sync for awhile but the product got buggy, renamed, and seems like going through weird times. So looked for an open source alternative and found Syncthing. It works well to keep files in sync between laptop and desktop, its all local - but you give up any cloud storage if all your computers go fubar.
It definitely takes extra work to protect yourseld against data loss using syncthing over something like Dropbox. I have a mirrored ZFS (FreeNAS vm) which I back up to a usb HD and Backblaze (600GB is running me about 3USD/month)
How do you set up the mirrored ZFS? Is this running some type of job that runs something like rsync on a schedule?
In my case it all depends on having the FreeNAS up and running. Once that's working, it's pretty easy to configure it with a couple drives to have them mirror each other. I'm actually running FreeNAS in a VM, but I'm passing through the PCIE SATA controller so FreeNAS has complete control over the hardware, which is important for ZFS. My machine also has ECC memory, which the FreeNAS folks claim is pretty much a must. Hard to determine how true that is. I've seen some conflicting opinions.
It always brings me sincere joy to see another person discover syncthing. One of my all-time favorite pieces of software.
I like it. Of course I created my own note/task-taking app years ago, which I can't even find anymore. It was in Perl. The purpose was to have a user-friendly command-line interface. If I was going to grep for something, I wanted to display the results in a nice way. To list notes or tasks done, priorities, etc I wanted to sort and display in a nice way. And eventually I added a merge function if I forgot I had more than one editor open at a time. I think I abandoned it for the same reason I abandon every note-taking app I try: it's just not easy enough to use everywhere.
The note-taking app I use most often now is e-mail drafts. I write an e-mail to no one and save it as a draft. It's synced everywhere, sorted by date, has a subject (which can be edited to include tags such as "(!) ", "(plan)", "(done)"), can contain any text format (even attachments), and it works on every e-mail client and server. Maybe I should write an interface to it...
The note-taking app I use most often now is e-mail drafts. I write an e-mail to no one and save it as a draft. It's synced everywhere, sorted by date, has a subject (which can be edited to include tags such as "(!) ", "(plan)", "(done)"), can contain any text format (even attachments), and it works on every e-mail client and server. Maybe I should write an interface to it...
For quick notes the most important for me is as little friction as possible.
Having to switch to a terminal and using an alias is too much friction.
So I have a global hotkey which I can press anywhere on my desktop, regardless of the current application and if I press it it opens an editor window with the current timestamp already added, so all I have to do is type and press a key to finish the entry.
This way I don't have to switch apps to make a note, I stay in the current context and it's so quick and convenient to make notes that I don't even have to think about doing it.
Having to switch to a terminal and using an alias is too much friction.
So I have a global hotkey which I can press anywhere on my desktop, regardless of the current application and if I press it it opens an editor window with the current timestamp already added, so all I have to do is type and press a key to finish the entry.
This way I don't have to switch apps to make a note, I stay in the current context and it's so quick and convenient to make notes that I don't even have to think about doing it.
> Having to switch to a terminal and using an alias is too much friction.
Given that the examples are all for 'vim', this appears to have been written from the viewpoint that one is already in a terminal, so there is no switching friction when one's focus is a terminal at the start.
Given that the examples are all for 'vim', this appears to have been written from the viewpoint that one is already in a terminal, so there is no switching friction when one's focus is a terminal at the start.
The implementation in the article is less important than the concept of making notes as people in the comments here mentioned Emacs, Google Docs and other tools as well.
Also, you can have ideas or want to make notes when reading a PDF or browsing some documentation, so your editor or terminal are not the only apps from where you want to initiate creating a new note.
Also, you can have ideas or want to make notes when reading a PDF or browsing some documentation, so your editor or terminal are not the only apps from where you want to initiate creating a new note.
Hm, that’s cool. Is your note taking an app part of the menu bar (if you’re using Mac) If so which is it?
Agreed on the global hot key. I use iTerm and it has a global hot key so you can bring it up with a shortcut and then hide it with the same shortcut.
Agreed on the global hot key. I use iTerm and it has a global hot key so you can bring it up with a shortcut and then hide it with the same shortcut.
I don't use Mac, but the actual note taking app is not important. The important thing is the global hotkey, so you can make a new note trivially when this global hotkey activates your favorite note taking app.
My hotkey software can also send keypresses to running apps, so beside bringing the note app to the foreground it also starts creating a new note automatically.
My hotkey software can also send keypresses to running apps, so beside bringing the note app to the foreground it also starts creating a new note automatically.
In case it's useful to anyone (or they want to pick at my code), here's a quick and dirty python thing I use to automate timestamps on journal entries. It just accepts strings of text and saves them in a file named with today's date and a time above each entry.
import time
user_input = ""
date_string = '-'.join([str(n).zfill(2) for n in time.localtime(time.time())[0:3]])
while user_input != "q":
user_input = raw_input("Log entry (q to quit): ")
with open("time_log_"+date_string+".txt","a") as timelog:
#timelog.write(time.asctime(time.localtime(time.time()))+'\n')
timelog.write(
'-'.join([str(n).zfill(2) for n in time.localtime(time.time())[0:3]])
+ ' '
+ ':'.join([str(n).zfill(2) for n in time.localtime(time.time())[3:5]])
+ ' | '
+ user_input
+ '\n')Thanks - this is cleaner than what I was using for something similar. Here's my version:
import datetime
user_input = raw_input("Log entry: ")
with open("did.log", "a") as timelog:
timelog.write('\n')
timelog.write(datetime.datetime.now().strftime("%Y-%m-%d %H:%M (%a)"))
timelog.write(': ')
timelog.write(user_input)http://todotxt.org has a format for a done.txt list, too. Useful before project meetings to get an overview over what you did in the last days.
TodoTxtMac creates this for me: https://mjdescy.github.io/TodoTxtMac/
I've been using it together with Dropbox (for access from my phone) for 3 years now.
TodoTxtMac creates this for me: https://mjdescy.github.io/TodoTxtMac/
I've been using it together with Dropbox (for access from my phone) for 3 years now.
Interesting, I've been seeing a lot of interest in syncing the file and this seems like a good next project. I never thought to use dropbox to sync, I wonder what the dropbox api does with merge conflicts
It will create a second file in the directory, renamed with information where it comes from. No problems here as it is merely a text file.
There used to be an Android app for todotxt, but it does not seem to exist / work anymore after the Dropbox API changed.
There used to be an Android app for todotxt, but it does not seem to exist / work anymore after the Dropbox API changed.
No need for "normal Go". ex commands like r take addresses.
vim +'$r!date' did.txtAt first when I read this I thought why not use Vimwiki or org-mode or taskwarrior, etc... but actually I really like these simple aliases.
I use the same approach for a super simple "pomodoro" timer:
I use the same approach for a super simple "pomodoro" timer:
alias pomo='echo "Starting timer for 25 minutes"; sleep 1500 && zenity --info --text "Pomodoro break; 5 minutes"; sleep 300 && zenity --info --text "Pomodoro: back to work"'Notably, this doesn't add the date at a reliable place in the file. Instead, it adds the date at the last place your cursor was when you had the file open last.
I think adding a command to go to the next line would be the sweet spot
this doesnt seem to work in the same way for me, it doesnt print a timestamp to the file
oh thats smooth
Tool as a tool (I work daily with a "nth-priority-ideas.md", and appreciate that plaintext files clutter-free, portable, customizable, etc).
But what I found inspiring is to maintain a list of accomplished tasks, not only a daunting one of todos. My PhD co-advisor run one, maybe I should have copied this approach.
But what I found inspiring is to maintain a list of accomplished tasks, not only a daunting one of todos. My PhD co-advisor run one, maybe I should have copied this approach.
For the same reason, I use vimwiki[0] with its diary features, which is much better regards syntax highlighting linking.
[0] https://github.com/vimwiki/vimwiki [1] https://github.com/vimwiki/vimwiki/blob/master/doc/vimwiki.t...
[0] https://github.com/vimwiki/vimwiki [1] https://github.com/vimwiki/vimwiki/blob/master/doc/vimwiki.t...
EDIT: I made a [Github project](https://github.com/stevenschmatz/did) which adds a few niceties to this blog post, like better dates, no date duplication, and syntax highlighting in Markdown.
---
If you want syntax highlighting and better dates, you can use a Markdown file with the following command:
``` vim +'normal Go' +'r!date +"\# \%B \%d, \%Y (\%A)"' ~/did.md ```
Make sure to turn `syntax: on` in your `.vimrc`.
---
If you want syntax highlighting and better dates, you can use a Markdown file with the following command:
``` vim +'normal Go' +'r!date +"\# \%B \%d, \%Y (\%A)"' ~/did.md ```
Make sure to turn `syntax: on` in your `.vimrc`.
What I do for all of my side projects now is keep a TODOs.md file in the project root. I no longer keep track of to-dos for programming projects external to the project. I find it makes it much easier to pick up a project I've left for a while.
What I do is every time I think of a new work item or discover a bug, I add an item to the list. Once I finish an item, I check it off. Since it's checked in with everything else, it's a good history of what work was "discovered" along the way and what work has been done.
For the last few years, I've worked on a bunch of little side projects projects here and there and this system has kept me sane.
For an example, see https://raw.githubusercontent.com/allenu/YokosukaJS/master/T...
What I do is every time I think of a new work item or discover a bug, I add an item to the list. Once I finish an item, I check it off. Since it's checked in with everything else, it's a good history of what work was "discovered" along the way and what work has been done.
For the last few years, I've worked on a bunch of little side projects projects here and there and this system has kept me sane.
For an example, see https://raw.githubusercontent.com/allenu/YokosukaJS/master/T...
Keeping a "did" file is also immensely valuable to demonstrating your performance and achievements to your employer. Think about all the positive things you've done for work over the past year. It's hard to account for them all mentally, and even harder for your boss to remember.
I think this is important. One of the most career oriented people I know, call him a mentor of mine, kept entire binders full of everything he did. Every accomplishment. He prepared for performance reviews like he was going to war.
As a manager I suggested to my reports that this in addition to proving your work, it also helps as a way to understand whether you are stagnating at work, or continuing to learn and evolve.
As a manager I suggested to my reports that this in addition to proving your work, it also helps as a way to understand whether you are stagnating at work, or continuing to learn and evolve.
Dang. I love this. I only remember preparing this intensely for grad school apppications but come to think of it the stakes are just as high if not higher at work + life.
I keep an info.txt file about useful commands and information. Years ago I remember an HN comment on someone that stored everything as Prolog facts that could be consulted.
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.
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.
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:
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=============================\<Esc>\"' ~/Dropbox/did.txt"
alias did="nvim +'normal G' +startinsert ~/Dropbox/did.txt"
Did you use vimwiki's diary functionality?
`\w\w` to go to today's page.
You have a better memory than me. I would instantly forget whether or not I’ve added an entry for the day
In my .zshrc I have
Separately I have current and last 2 month files open in the leftmost column of acme (about half as wide as other columns). This is for moving entries between months etc. I have to remember to do a Get before editing and Put when done editing to sync with any updates done from command line.
In the same column I have a per year "projects" file (multiple indented lines per project) and a per year "future" file (things I may want to do someday).
This is far from perfect but has endured. A simple grep can tell me what was done or what needs to be done in a given month or year.
For taking notes in a meeting I have now switched over to using an ipad + apple pencil as I can scribble notes, draw pictures, doodle etc. without having a laptop screen between me and others or clicking keys annoying people.
todo() {vi '+$' ~/todo/$(date +Y/%m)}
+() {echo + $* >> ~/todo/$(date +Y/%m)}
-() {echo - - $* >> ~/todo/$(date +Y/%m)}
Separately I have current and last 2 month files open in the leftmost column of acme (about half as wide as other columns). This is for moving entries between months etc. I have to remember to do a Get before editing and Put when done editing to sync with any updates done from command line.
In the same column I have a per year "projects" file (multiple indented lines per project) and a per year "future" file (things I may want to do someday).
This is far from perfect but has endured. A simple grep can tell me what was done or what needs to be done in a given month or year.
For taking notes in a meeting I have now switched over to using an ipad + apple pencil as I can scribble notes, draw pictures, doodle etc. without having a laptop screen between me and others or clicking keys annoying people.
I have a thing for “want to do someday” called Asana but it’s never ending. My killer feature for a todo list would be either Auto Delete or auto “tell me a reason why I shouldn’t delete this”
In a way the whole point of making todo lists is mindfulness -- to pay attention to a task when needed. The point of automation is exactly opposite -- you don't want to pay attention to something!
A todo list is more effective if you do regular reviews (daily/weekly/month/yearly). Similarly mindfulness at the time of deleting a someday task may provide useful feedback.
A todo list is more effective if you do regular reviews (daily/weekly/month/yearly). Similarly mindfulness at the time of deleting a someday task may provide useful feedback.
I wonder if you could script that with the API? Post a comment after a certain period of time and if you do not interact with it, delete the task.
For Notepad++, I'm using a custom "TODO" syntax highlighting [0]. I like this for "temporary" TODOs (mostly work-related stuff to be done today) and as an overview for my scrum dailies.
[0] https://github.com/darekkay/config-files/tree/master/notepad...
[0] https://github.com/darekkay/config-files/tree/master/notepad...
Not sure I understand the reason for needing to keep track of things like the examples shown...
On the other hand, if I am in the middle of some large changes I will make notes at the end of the day before I leave the office. I usually write down what I accomplished and what remains to be done as well as anything I need to come back to. I don't get too fancy with it, usually just use Sticky Notes on my Windows PC at work.
On the other hand, if I am in the middle of some large changes I will make notes at the end of the day before I leave the office. I usually write down what I accomplished and what remains to be done as well as anything I need to come back to. I don't get too fancy with it, usually just use Sticky Notes on my Windows PC at work.
I'm much like you. I used text files and utilities, developing some of my own, but in the end I've fallen back to a simple pen & paper technique.
1) I find it easier to browse written pages. It also seems to tweak some sort of memorization when I need to recall things from long long ago. I doodle a lot, especially during meetings so I can recall when I needed to remember a note that it was written somewhere around the page with a dinosaur wearing a baseball cap in the margin
2) Taking my eyes away from the screen to jot my tasks, is almost like a mental reset. It causes me to slow down and think more about what I've done or will be doing tomorrow
3) It almost becomes an "additional monitor" to have up. No tabbing to a file, no spacing things on desktops to keep the work list above other forms; its just there, off to my left to view.
4) (EDIT) Can't believe I almost forgot what I consider the strongest point... is connecting thoughts. Trying to draw a line between comments I made earlier and something I've done just now is nearly impossible to do cleanly in text IMO. Notes like "See July 4th, 10:35PM" is worthless and requires a new level of focus that a squiggly arrow just accomplishes so much easier. Colouring in a black box above an important note I want to immediately catch my attention when i'm flipping backwards is so much more important to me than any text file organization.
1) I find it easier to browse written pages. It also seems to tweak some sort of memorization when I need to recall things from long long ago. I doodle a lot, especially during meetings so I can recall when I needed to remember a note that it was written somewhere around the page with a dinosaur wearing a baseball cap in the margin
2) Taking my eyes away from the screen to jot my tasks, is almost like a mental reset. It causes me to slow down and think more about what I've done or will be doing tomorrow
3) It almost becomes an "additional monitor" to have up. No tabbing to a file, no spacing things on desktops to keep the work list above other forms; its just there, off to my left to view.
4) (EDIT) Can't believe I almost forgot what I consider the strongest point... is connecting thoughts. Trying to draw a line between comments I made earlier and something I've done just now is nearly impossible to do cleanly in text IMO. Notes like "See July 4th, 10:35PM" is worthless and requires a new level of focus that a squiggly arrow just accomplishes so much easier. Colouring in a black box above an important note I want to immediately catch my attention when i'm flipping backwards is so much more important to me than any text file organization.
Here's what I use for this same purpose: my fork of someone else's old and unmaintained pet project. I think it's pretty good. It creates a new entry each day, or appends to this day's diary entry.
It has a few subcommands, which are date-aware.
https://github.com/alexthehurst/Diary.py
It has a few subcommands, which are date-aware.
https://github.com/alexthehurst/Diary.py
I sort of had a did.txt for 3 years, updated quite often during my working hours (at least once a day, if I were super busy, to dump all my daily activities and notes). It was quite useful for standup meetings and such. It is a pretty gigantic did.txt now, and in 3 years can you guess how many times I needed the info sitting there? Zero... go figure :-(
Totally, i've never actually fully read my did file (just started), but I find the act of writing a concise summary of what I've done to be the major benefit.
I love how many ways there are to do this. My version uses empty Git commits: https://github.com/ellotheth/dotfiles/blob/master/bash_funcs...
projects/done is a directory?
I log everything worth remembering and some. Whether it is something I did, a link I want to read, or something I bought. I use a file called log.txt. It is synced across all my devices. I have a very minimal format that goes like this:
I tried Evernote, onenote, physical notebooks and a hundred other tools. This is one that I settled on. All I need is a text editor on any platform.
Back to the log, there are several times I have visited it to find out what happened during the day. I use it at times as a review of how well the week went and what I could improve on.
# 16/07/2018
- read about did.txt on HN
- [ ] write about log.txt on HN
- cost: 2.9€ coffee at 93
I tried Evernote, onenote, physical notebooks and a hundred other tools. This is one that I settled on. All I need is a text editor on any platform.
Back to the log, there are several times I have visited it to find out what happened during the day. I use it at times as a review of how well the week went and what I could improve on.
Back (some time ago) when work, etc., had me spending a lot of time on Windows, I found and used this generous free and open-source project.
https://www.codeproject.com/articles/5371/todolist
Looking now at the revision history, it looks as if something may have happened to Dan after last summer.
It wasn't plaintext, but it and its format are open. And I found it a pretty good combination of features in a compact presentation.
There've been a couple of recent "to do" threads, that made me think of this. This thread finally got me to look it up.
I never tried this:
http://abstractspoon.com/wiki/doku.php?id=linux
https://www.codeproject.com/articles/5371/todolist
Looking now at the revision history, it looks as if something may have happened to Dan after last summer.
It wasn't plaintext, but it and its format are open. And I found it a pretty good combination of features in a compact presentation.
There've been a couple of recent "to do" threads, that made me think of this. This thread finally got me to look it up.
I never tried this:
http://abstractspoon.com/wiki/doku.php?id=linux
Self plug: I wrote https://github.com/dbalan/idid to do more or less the same thing when my did file needed a bit more structure (also an excuse to write some haskell).
Yeah, it's easy to forget. CHANGELOG is the historical equivalent, but that seems to be dead.
I made one of these, too. Here's a gist: https://gist.github.com/chadlavi/15fd674162ccbd2f4765bd76f33...
I wrote about something similar in a comment https://news.ycombinator.com/item?id=16322942
It's served me well. I have records from as far back as 2009.
It's served me well. I have records from as far back as 2009.
I have done something similar some years ago. Reminds me it's probably time to update. https://fimdomeio.com/thingsIhaveDone.txt
I like the idea of publishing interesting text files like this automatically to a personal site.
I would recommend, http://jrnl.sh it's made for the purpose described but in a much better and simpler way (also allows tagging and searching in a simple way).
It's interesting that they boast "256-bit AES" on the Github README, but when I look at the source code, they're not doing authenticated encryption:
https://github.com/maebert/jrnl/issues/549
https://github.com/maebert/jrnl/issues/549
Which part is the offender?
These small log files really help to keep things in perspective. However for longer plans I use Trello. It works as an issue tracker / planner for me so I can put the bits I find on the issue to the cards, or to my dropbox and link them.
When I finish a task, I put all relevant information to a folder in my "Old documents" folder, and put the card to the "Done" column. If the task is a project, everything is already become documented and archived on git at the end.
When I finish a task, I put all relevant information to a folder in my "Old documents" folder, and put the card to the "Done" column. If the task is a project, everything is already become documented and archived on git at the end.
Does anyone know of a good open source text-based journaling system that lets you easily inline images/audio/video/etc, with render-to-html functionality? My goal is to document what's going on in my life, and that's not really possible with only text. This is where Evernote really shines in my opinion. I've been missing that functionality ever since I got off Evernote. Been wanting to create a basic system for myself for a while now.
Emacs Org mode fits that requirement nicely.
Org mode (a plain text format ljke Markdown, but much more than that) files export easily to Markdown, HTML, tex/PDF, and multitude of other formats using Emacs itself or even Pandoc.
My site (in my HN profile), for example contains text, images, etc. The content source is in Org mode.
Org mode (a plain text format ljke Markdown, but much more than that) files export easily to Markdown, HTML, tex/PDF, and multitude of other formats using Emacs itself or even Pandoc.
My site (in my HN profile), for example contains text, images, etc. The content source is in Org mode.
Since the start of this year I've been keeping a similar journal. Instead of opening an editor to write a single line to a text file, I just print the arguments of a command to the end of a file and prefixed with a timestamp. Since there's no need to review or save the file, there's no interruption in what I'm doing. Logging things to the file feels like shooting things into the ether and I end up doing it constantly throughout the day.
[deleted]
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.
the moving from a todo file to done file is something i still havent figured out in plaintext
You can move between headings and files with a few keystrokes in emacs/org-mode.
This doc shows a fairly advanced way of doing gtd w/ org-mode. I use a stripped down workflow based on this.
https://emacs.cafe/emacs/orgmode/gtd/2017/06/30/orgmode-gtd....
This is the one that I use
> doing is a basic CLI for adding and listing “what was I doing” reminders in a TaskPaper-formatted text file. It allows for multiple sections/categories and flexible output formatting.
http://brettterpstra.com/projects/doing/
> doing is a basic CLI for adding and listing “what was I doing” reminders in a TaskPaper-formatted text file. It allows for multiple sections/categories and flexible output formatting.
http://brettterpstra.com/projects/doing/
I just store all of my shell command-lines in a big file, including the date and current working directory. That way, I can always grep and see what I did. For stuff that doesn't happen on the commandline, I just type "echo" followed by a description of what I did, and it ends up in the history file just the same.
Lol at secret uses of echo. How are you logging your command line entries?
If you're using vim already for journaling, you should try Vimwiki. Out of the box, it has a diary, and typing Leader-W-Leader-W opens a buffer with today's diary file, ready to record things you've done or serve as a scratchpad for the day that you can search and refer to later.
I found that using this snippet leaves the cursor at the start of the date string, so I have to shift+A then enter to get to the next line to start typing. Adding +'put _' to the command inserts a newline so that you can immediately switch to insert mode and start typing.
Cool! I would store this file on keybase’s KBFS so it’s available on all of your machines.
I do that with my org files. It's great. Keybase is great.
IIUC, Keybase does not cache files locally (in contrast to Dropbox), so doesn't that mean that you can't access your Org files offline? Also, how does it handle latency, broken connections, etc? If the Keybase fs returns from a write call, is the file actually saved to anything? What if I save a 5 MB file over a slow connection--does e.g. Emacs block waiting for fsync?
The apparent lack of info about this (short of reading the source myself), and it still being in "beta" makes me very reluctant to trust it with my important data.
The apparent lack of info about this (short of reading the source myself), and it still being in "beta" makes me very reluctant to trust it with my important data.
Thanks!
I wish all linux servers had something like this, out of the box, for all users.
the first thing I do after sshing into a box is spend an hour trying to figure out the basics. Where are the web folders? what daemons is running? what hacks does have in place?
the first thing I do after sshing into a box is spend an hour trying to figure out the basics. Where are the web folders? what daemons is running? what hacks does have in place?
Do you mean a did file for yourself or a collective file for the machine?
I'll throw mine into the pile of other solutions posted here. I hope someone finds it useful:
https://github.com/chrisallenlane/node-did
https://github.com/chrisallenlane/node-did
So do you have to keep this server running or do you have a separate nodemon script that auto starts on start up?
There's no server here. This is just an executable written in node, which writes to a SQLite3 (flat-file) database.
I hope one day I can run linux on my phone so that I can use these tools everywhere.
If you're on Android, you can do this today with Termux. I believe you can also set up shortcuts (so you could have a home screen widget to open your TXT file).
That would hand over full control to the author of Termux. According to the play store it is a guy called Fredrik Fornwall. I never heard of him. So I would not trust him with my digital life.
Seems to be open source -- https://github.com/termux/termux-app.
That does not help much. What am I supposed to do? Do my own security review of it and compile from source?
I put the author's terminal command into an Alfred Workflow: https://github.com/geberl/alfred-did-txt
join the (very recent) crowd: https://news.ycombinator.com/item?id=17532094
If the file does not exist, then
vim +'normal Go' +'r!date' ~/did.txt
Isn't this effectively what code commits are for? If you've done something worth noting, it should probably be in a commit anyway.
Do you mean that all is worth is code ? I code as a living but wouldn't say that all I do is coding or in a text file. By example talking with X is worth noting or setting up a complex embedded device with all its tooling is definitely worth noting.
Well, most version control systems can be used outside of coding too. I know a few authors who use Git to track and handle multiple revisions of their technical or fiction book writing.
No reason you couldn't have a text file with setup notes on a system and have commit any updates so you have a trackable log.
No reason you couldn't have a text file with setup notes on a system and have commit any updates so you have a trackable log.
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.
In fact for any employee it’s useful to keep track of stuff like this, come PR time.
Yeah commits are great for logging code changes.
I started using the did file while learning a new language, don’t remember which. I’d have 15 tabs open with different docs and tutorials but very very little actual code written or way to mark where I was. I settled on a single text file and It was super helpful to just look back a week and notice there was some measurable progress.
I started using the did file while learning a new language, don’t remember which. I’d have 15 tabs open with different docs and tutorials but very very little actual code written or way to mark where I was. I settled on a single text file and It was super helpful to just look back a week and notice there was some measurable progress.
I have done this since I began learning but I make a folder for every new topic so it’s easy to go back and do a refresher.
What benefit are you getting out of journaling?
isn't this a classic use-case for emacs org-mode?
having said that I do appreciate that plaintext is lower friction/inertia for sure
having said that I do appreciate that plaintext is lower friction/inertia for sure
Title should contain "with Vim".
I was confident that people would post other solutions here.
I'm thinking of a bash script that takes a title starts a text file in the folder ~/.plan with filename generated from the title but prepended by date in yyddmmhhmm format. Might get me recording more things.
Like others, I use paper for the doodles and diagrams.
I'm thinking of a bash script that takes a title starts a text file in the folder ~/.plan with filename generated from the title but prepended by date in yyddmmhhmm format. Might get me recording more things.
Like others, I use paper for the doodles and diagrams.
Emacs provides calendar and diary out of box
M-x calendar then `i d` to create entry for selected date
[deleted]
Hacker News paydirt!
Short and sweet. Nice.
Short and sweet. Nice.
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 me with my work a few times.
One could ask why didn't I just refactor these pieces right away? Two things often stopped me from doing this: first, some of those lines were over eight years old and a huge part of the system depended on their sometimes buggy behaviour. Second, the company review policy was "stability, stability, stability", so any change beyond the scope of the thing I was working on was automatically rejected.