Live data from Hacker News

Use a work journal

fev.al

71–80 of 305 posts

Re: Use a work journal

#71
post #24

What finally got this to stick for me was abandoning all notion of structure and organization (and formal concepts like “logging” and “journaling”) and optimizing fully for capture over retrieval, then relying on search tools and proximity for the latter. I have the OneNote icon in the notification area configured to create a new quick note and use it liberally. Occasionally I look through all the pages, especially t…

It took me a couple years to realize this too. For the past five years I abandoned all structure. I use a literal log file. Chronological from top to bottom, with paragraph breaks for each workday. Higher than necessary verbosity, no points taken away for spelling or grammar mistakes.

I basically do this, too. One big text file. My twist that makes it work for me is a slightly modified text editor that I only use to edit this file.

That way I’ve got a dedicated dock icon and context just for writing notes, but no other overhead. It’s important to me that it not feel like a product, and search works effortlessly (although subject to typo misses).

My only tweak on the text editor is a shortcut to insert a timestamp and a chunk of new lines, which I do periodically so I can separate moments in time and see what I was working on when, how I fixed something, etc.

I used obsidian for a while, but for my purposes it felt like work to organize and get “right”. I ended up writing a script to join all the files into one.

Re: Use a work journal

#73
post #66

Earlier quoted context omitted.

I write a lot of notes in fact I write more than I read. It helps. However I have some issues: 1. How much commentary should I write? I try to write not too many notes because I write code, and some say code should be self-documenting. So it's the same old question of how many comments should there be along the code. 2. How do I retrieve a note I've written earlier? I can use tags and search for them but it is not ea…

> 2. How do I retrieve a note I've written earlier? I can use tags and search for them but it is not easy to come up with a perfect tag which I would remember later. Feed them all to an LLM?

I've thought about that. The AI should figure it out. But if I don't know what I should ask the AI it cannot much help me.

I wrote in some discussion about whether AI could replace us programmers? I think they cannot because:

AI has the answers. WE have the questions!

Re: Use a work journal

#75

To me the hardest part of journaling (or Pomodoro, or whatever work-related methodology/hack) is to stick with it. I have a work journal. I abandoned it and came back, then abandoned it and came back again. It's an endless back-and-forth. To those who keep doing this for a longer period: Any tips would be appreciated.

I have my journal available within my editor, so it's easily accessible. I find that once I've seen how useful past-notes have been its very apparent I need to update.

I keep a standard set of headers for each new entry:

    * DD/MM/YYYY
    ** Admin
    ** Meetings
    ** Tickets/Stories/Work
    ** Problems
I copy/paste that header to the end of the file, and just fill out stuff as I go. I used to have my editor auto-open the diary on startup, but took that away in the end.

Re: Use a work journal

#76
post #22

Earlier quoted context omitted.

Do you all pay for obsidian? Subscriptions rub me the wrong way for whatever reason and it was enough that I didn't want to pay so I use something else.

I'm using the free version synchronized with Syncthing, works great for just myself. Have a couple plugins I built for my own workflow. The good thing is that I can jump to any other markdown app if I want to

There is no free version if you use it for work.

Re: Use a work journal

#77

The benefit of journaling is not just reentry, but that you begin to solidify the mental model into a concrete branching of possibilities that is tightly coupled to the specific problem. Your work becomes traversal and mutation of this tree. Several benefits accrue: you begin to see gaps in the tree, and can fill them in. You begin to have confidence in your mental model, recovering the time you used to spend going o…

I’ve been seriously considering using Logseq for this reason. When I first started with Obsidian I used it that way, but the more I put in it the more I started organizing everything. It became less of a journal and more of a repository for long form stuff. I’m thinking about using both just so I have a dedicated tool just for the journaling side of things.

I use different editors for different purposes, e.g., Obsidian for long form and planning, OneNote for meetings.

I wouldn't overthink it, though, and just use the simplest tools available. I use Sublime Text 3 with a few shortcuts to add the current timestamp, etc. and log everything in a long file. I was too ambitious in the past and wanted to learn how to use Emacs for everything, but it just held me back, and I ended up without any notes.

Also, my unfortunately named thread from 2022: https://news.ycombinator.com/item?id=33359329

Re: Use a work journal

#78
post #13

I keep a stack. Whenever I am interrupted, I push a task onto the stack. When I finish a task, I pop it from the stack. Each task has an associated journal file. Sometimes I reorder the stack.

Similar workflow, except I have 3 lists: TODO, Pending and Done.

"TODO" is actionable items. It's a reorderable stack of work I need to do. Same: interruption pushes a task to the stack, when I finish a task I pop it from the stack, etc. So I always know what to do next.

"Pending" is an unordered list of things I'm awaiting. Say, I asked someone to do something, and they promised they'd get back to me in a few hours (or "by July 20"). I occasionally scan this list to see if some of the items got resolved and I need to continue working in those areas because I'm unblocked.

"Done" is a list of items I completed for the day, all finished items go there. I then copy the entire list to the time tracker (for the PMs) at the end of the day.

However, I organize files by day, not by task. Each day I create a new file for the day by copying the lists of the previous day's file minus the DONE list. I don't modify lists for previous days, so it's kind of an append-only log so I can see what was the state for any particular day. 1 file per day is easy to see as a whole as it mostly fits in one screen (and inside my working memory). I use plain text files because I found it much simpler to use, I don't have to install any software, it just works, and it's easily searchable.

I've been using this system for the last 6 years now and it served me well.

Re: Use a work journal

#79

The benefit of journaling is not just reentry, but that you begin to solidify the mental model into a concrete branching of possibilities that is tightly coupled to the specific problem. Your work becomes traversal and mutation of this tree. Several benefits accrue: you begin to see gaps in the tree, and can fill them in. You begin to have confidence in your mental model, recovering the time you used to spend going o…

I write a lot of notes in fact I write more than I read. It helps. However I have some issues: 1. How much commentary should I write? I try to write not too many notes because I write code, and some say code should be self-documenting. So it's the same old question of how many comments should there be along the code. 2. How do I retrieve a note I've written earlier? I can use tags and search for them but it is not ea…

> 1. How much commentary should I write? I try to write not too many notes because I write code, and some say code should be self-documenting. So it's the same old question of how many comments should there be along the code.

I think the best I've heard this was by a friend who said something akin to this;

Programming is the art of solving problems by codifying complexity. Generally, the self documenting part is the 'defining the problem' portion of the code. But in every problem, there's a certain amount of irreducible complexity, or it wouldn't be a problem.

There's going to be some part of the code where you wish you could make it simpler, or you wish you understood it better, or you wish you could break it down into smaller components but there's no 'good way' to do it in the system you're working in. Or, the way you have working is 'good enough' and it's not worth the investment from some (business needs angle) in making it any better.

This is the portion of the code you should comment, and document, and do so liberally and in detail.

Post reply on HN