61–70 of 202 posts
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).
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…
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.
Similar but not the same: most days day at work I create one or more txt files in notepad (kate to be exact) where I paste every temporary info while I work on some task. Basically everything that doesn't go to git, and you have to keep somewhere while you're working on it: - nonobvious terminal commands or small scripts I had to write - fixes for enviromental/configuration problems - fragments of stacktraces - fragm…
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'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.
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 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…
> 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.
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 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…
> 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.
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 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.
Short and sweet. Nice.