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.
Usually `finger` was not used alone. Associated tools included grep, fsck, mount and if all went well `yes`. I usually prefer to finish the task with `sleep` as well.
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.)
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.
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.
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.
Great 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
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.
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.
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.
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.
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.
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.
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.
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...
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.
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.)
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.
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.
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.
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 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...
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.
> 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.
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.
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.
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.
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.
"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!
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.
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.
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.
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.
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 number of hours I have spent trying to find an alternative note taking system to paper is rather more than I like. Unfortunately search sucks, they tend to get lost and I have horrible handwriting.
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.
201 comments
[ 0.55 ms ] story [ 331 ms ] threadvim is perfectly fine if you invoke it with the name of a non-existent file; it will just create it.
Usually `finger` was not used alone. Associated tools included grep, fsck, mount and if all went well `yes`. I usually prefer to finish the task with `sleep` as well.
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.)
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.
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.
In fact for any employee it’s useful to keep track of stuff like this, come PR time.
It will create a time-stamp (similar to F5) each time you open the document.
So nothing for us that never closes applications ;)
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
[0] https://github.com/vimwiki/vimwiki [1] https://github.com/vimwiki/vimwiki/blob/master/doc/vimwiki.t...
It has a few subcommands, which are date-aware.
https://github.com/alexthehurst/Diary.py
- 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.
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.
That way I end up with 100+ unnamed files in notepad++. At least it is searchable.
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.
It would be a mess for me at least ;-)
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 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.
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://orgmode.org/manual/Clocking-commands.html
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.
(Religious org-mode user for approximately four years.)
Every few months I toy with the idea of implementing a poor man's org-mode in VBA.
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.
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...
I use the same approach for a super simple "pomodoro" timer:
> 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/
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.
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-...
> 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.
Oh, and the file is called entomology.txt because it's more about studying them then logging them.
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!
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.
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.
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.
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.
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.
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.
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.