I used to keep a so-called shitlist for a long term project I was involved in.
The idea was to document all the worst places in the codebase(150k LOC) that frequently caused weird behaviours.
Each record contained a short description, the reason why this piece is bad, hash of the commit that introduced it and of course the perpetrator.
Of course the main purpose it served was to relieve stress, nevertheless it helped 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.
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.
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.
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
Will return you a little text report that you can use in your CI or anywhere else that groks text.
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.
> 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.
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.
"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!
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.
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.
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.
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.
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.
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.
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.
+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/
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!
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.
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
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.
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.
Nothing fancy. I keep this vim window permanently open at a fixed position. Roughly once a day I remember to save them. I archive the files and start fresh every time I switch jobs.
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.
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.
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.
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.
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.
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 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.
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
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)
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)
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.
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...
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.
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')
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
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.
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.
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:
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.
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.
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.
Each month's entries are in a separate ~/todo/YYYY/MM file. The + command is to record something done. The - command is to enter a new task. The todo command is for editing this month's file -- add month-days, update entries, cleanup etc.
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.
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.
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.
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.
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.
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 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:
# 16/07/2018
- read about did.txt on HN
- [ ] write about log.txt on HN
- cost: 2.9€ coffee at 93
I grep for - [ ] to see my incomplete tasks, and add an x like - [x] when the task is complete. When the file grows large I move months to separate files.
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.
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).
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).
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.
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.
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.
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....
> 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.
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.
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.
ooh i get it, `alias did="vim +'normal Go' +'r!date' +'put _' ~/did.txt"` and this starts in insert mode. I like this. I think ill change mine to this.
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.
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?
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.
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.
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.
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.