I am using a very simple system for remembering commands and procedures, and for tracking what I work on. I have two plain text files called notes.txt and worktime.txt. In the notes file, I write down things that are important to remember. For example: various shell commands, steps when creating a new release, how to install and configure tools, company procedures for time reporting etc.
In the worktime file, I write down the hours I worked that day, and what I worked on. I also have a python script that calculates the number of hours worked for the day and the week.
In the past few years, I have started at four different companies. At each company, there are many things to remember. Which repositories do I clone? How do I build, test and deploy the system? How do I report time? The first time I do these things, I typically write down some notes about it. The next time, I can do it without asking anybody. If I do the task often enough, I will usually remember how to do it without having to refer to my notes. But the first few times, it is good to have the steps written down.
Notes
I usually add new stuff at the top of the file. The only exception is if there is already a few related items further down in the file. Then I will make an addition there. However, it doesn’t matter if there are duplicate entries. When I look for something, I usually just search from the top of the file. The most recent entry is usually the one I am looking for.
Occasionally, I have grep:ed through the whole file, so I can see all occurrences of some term at once, for example all git commands I have written down.
Commands
Some examples of commands I have saved in the file:
# To see versions (images) of what's running:
kubectl -n trade-sched get deployments -o custom-columns="NAME:.metadata.name, IMAGE:.spec.template.spec.containers[0].image"
gcloud artifacts docker images list --include-tags docker.pkg.dev/edab-platform-cicd/kbt/tee --format=json | jq | grep -C2 'v5.11.20' # Find images with a given tag
grep -i 'error\|panic\|fail\|fatal\|SIGSEGV\|back-pressured' *
git rebase -i HEAD~3 # Interactively rebase the last 3 commits
Some of these commands are not hard to recreate. But it is nice not having to think about what the path is, or what the arguments are, and instead just copy the command. Of course, if I used it recently, I will just find it in my shell history, so no need to look it up in the file then.
Recently, I have been using curl to test various APIs. Then I will save the commands, including headers, body, URL and query parameters. It is much quicker to look up a working example than to recreate it.
With LLMs, it is quite easy to just ask for custom shell commands when you need them. I still think it is worthwhile to write important ones down. My goal is to learn them by heart, so I don’t have to look them up in my notes. Writing them down helps with that. Case in point: I know git rebase -i by heart now, so don’t need it in the file anymore.
Setting Things Up
Setting up a new MacBook takes some time. Because it is something I don’t do very often, I have written down what to install, and where to take it from. This is an (incomplete) example:
Install XCode from Appstore (needed for homebrew)
Install homebrew (from homepage, with curl)
Install MacVim: brew install macvim
Install GoLand
Other things include shortcuts in the IDE, other apps to install, how to set access tokens, settings in applications like Chrome, Slack etc.
Procedures
For example, how to make a release, how to deploy to the test and production environments, how do start and stop systems, and where to find the logs.
Typically, these kinds of activities are documented somewhere else too, such as on a Wiki-page. However, I can write down a version that is tailored to my needs (more or less information). If the official documentation is just what I need, I will just save the link to it. Even this is worthwhile to have, since sometimes it is not easy to find. Ideally, all official documentation should be comprehensive and easy to find, but that is rarely the case.
Company Procedures
This includes how to report time, vacation days and sick days, how to create an internal IT support ticket, how to book a meeting room, and where contact lists are located. I include both the URL, and the steps I need to take in the system (unless it is obvious).
Time tracking
Time
This is what it looks like:
240322 7:30-11:25 13:15-17:50 SNE-1635 Unzipping files from google cloud bucket ...
240321 8:10-12:25 13:30-18:00 Made tag v5.11.13 for tee, and deployed ...
240320 8:25-11:55 12:25-17:45 Refactored Kraken futures websocket code ...
The file is in reverse chronological order, so I always add the new day at the top of the file. I use an empty line to separate the weeks. I have a python script that calculates the hours and minutes worked each day, and the total and average for the week. The script makes it easy to see if I work my 40 hours per week, or if it is less or more.
What I Worked On
I shortened the descriptions in the example lines above. Typically, I write a few sentences on what I worked on that day. If there is a Jira ticket number, I try to include that. Sometimes I just take the commit messages for the day.
If I don’t write down what I worked on at the end of the day, I will not remember what it was. Fortunately, it only takes a few minutes to write down when it is fresh in my memory. Having it written down can sometimes be useful. For example, to answer “How much time did you spend on task X?”, or “Why did that take so long?”. When it is time for the yearly performance review, I usually look through the notes to see what main projects I worked on.
Conclusion
I have been using this system for over fifteen years now, and it works very well for me. It is only two plain text files, nothing more. There is no configuration. There is no vendor lock-in. The data format will not be obsolete. I don’t have to spend time organizing or labeling the information I put in.
I know many people, especially programmers, like to use more elaborate systems. No doubt such systems can do more than mine can. But I think it is useful to consider if maybe a simpler system will give you almost the same benefits, at a lower cost.
Top comments (0)