Live data from Hacker News

Use a work journal

fev.al

281–290 of 305 posts

Re: Use a work journal

#281
I also keep an error journal, which I call "The Library of Horrors", so when an error reocurs I can refer to.

I found this necessary because I tend to remember the "oh, this happened earlier..." but not the "... and this is the approach we followed succesfully" that should follow. The information is slotted in my brain, but not accessible unless I have some key reminder.

Also serves as a communication device between my past and future self, and between coworkers. The error-solving information tends to live transiently in your and your coworkers minds, and it is very valuable.

I haven't solved the method to properly identify-and-recalling. I simply save new information per project, per language, etc, with not much thinking. This would clearly be the next point of improvement.

Re: Use a work journal

#282
Very nice! I immediately created a fish shell function for this. Feel free to copy/modify/ignore.

Running `journal` quickly allows you to add a line to your journal. This will fallback to ~/.journal.log unless you have a .journal.log file in the current directory or any of its parents. Running `journal show` outputs the tail -5 of that journal. Running `journal init` creates a log in the current folder.

Adding .journal.log to your global gitignore is recommended.

$ cat ~/.config/fish/functions/journal.fish

function journal set -f journal ~/.journal.log

        if test "$argv[1]" = "init"
                set -f journal .journal.log
        else
                set -f journal ~/.journal.log
        end
        touch $journal

        set -l dirparts (string split "/" (pwd))
        set -l dircount (count $dirparts)
        for x in (seq $dircount -1 2)
                set -l dir (string join "/" $dirparts[1..$x])
                if test -f $dir/.journal.log
                        set -f journal $dir/.journal.log
                        break
                end
        end

        if test "$argv[1]" = "show"
                printf "Last journal entries from: %s\n" "$journal"
                tail -5 $journal
        else
                printf "Add to journal: %s\n" "$journal"
                read -P "Addition: " -l line
                if test -z $line
                        printf "Nothing added.\n"
                        return
                end
                printf "%s\n" "$line" >> $journal
        end
end

Re: Use a work journal

#283

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.

My forcing function was external. I was getting randomized by a lot of tasks and I felt I wasn't getting anything done. So I started to break down my day into 30 minute chunks. This got the feedback loop of seeing things get done going.

I also started to take notes about projects, other teams' working, notes from internal documentation etc. This has allowed me to retrieve some things super quickly to the point my teammates have been amazed. Another way to get the dopamine hit going.

Long story short: my brain is a primate, it needs dopamine hits, find a way to make your intended behavior give you dopamine hits.

Re: Use a work journal

#284

Earlier quoted context omitted.

If I'm working on something particularly complex I basically just do the journaling in a code comment adjacent to what I'm working on. So the first commit may be three lines of code and a huge long winded rambling comment of what I've already tried or thought about. By the time the task is done I've pared away the more speculative/rambling elements of what I wrote, and what's left is typically some extremely well com…

I like that. There are other ways of capturing work in progress adjacent to the code, instead of writing a journal. One of my favourites is to write a failing test - pretty much impossible to overlook or misunderstand on "re-entry" to the task. Another is to write a temporary commit log, with "WIP" in the first line and a TODO list in the rest of the log. This is good for ephemeral information that would just clutter…

These are really good!

Re: Use a work journal

#285

Earlier quoted context omitted.

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 in…

What editor did you modify?

https://github.com/brunophilipe/Noto

Looks like you can download from the App Store now, too.

It’s dead simple and I’ve never found a bug in 6 years of daily use. It’s pretty awesome and shows a lot of restraint and skill on the author’s part.

Re: Use a work journal

#286

Earlier quoted context omitted.

I do kind of the same but I’d be concerned to have it readable and n not private. But maybe I shouldn’t be. What’s your thoughts on having it open? I think it would be the first in the company if it’d do that.

Eh, I just try to not slack off too much. I've been doing this for nearly 2 years and so far only benefits as far as I can tell. I think very few people look at it besides myself and occasionally my boss.

Yeah I definitely don’t slack off (at this job, I’m precious it was terrible), so that wouldn’t be the concern. It’s more like I think I’m quite a private person. What would be the benefits that you’ve seen out of it?

Re: Use a work journal

#288

Earlier quoted context omitted.

> 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. I wrote a program (used from a CLI, but I mostly use the GUI I developed for it) to do something similar for my own use: https://github.com/lelanthran/frame/blob/master/docs/FrameIn... I use it daily.

It's low-tech, but I've been using notebooks (not too thick, stapled usually). I write a header for each day when I start and then a line or two as I work on tasks and I try to note each time I switch tasks. I keep the notebooks but rarely look at them once they are filled. Maybe once or twice as I switch to a new notebook and then once again when it comes to yearly review time. A couple of times I have rifled throug…

I have a nice setup with notebooks, on one page I put down the date and my meetings for the day, then i list the tasks i want to get done for the day. I start crossing things off once they are done per project. Went to standup? ok cool cross it off, new task comes in, add it to the list to priortize for the next day. I can go back and see what i've done on every single day and which days i've been in meetings most days. Having a nice pen/pencil really helps.

Re: Use a work journal

#290

I also keep an error journal, which I call "The Library of Horrors", so when an error reocurs I can refer to. I found this necessary because I tend to remember the "oh, this happened earlier..." but not the "... and this is the approach we followed succesfully" that should follow. The information is slotted in my brain, but not accessible unless I have some key reminder. Also serves as a communication device between…

> "The Library of Horrors"

Oh god that brings back memories from when I dared to propose sharing "failure stories" instead of success stories when I was in consulting. The look on people's faces was that rare blend of disdain and horror. We can't fail, how can we share failures? I mean you only learn from each other's successes right?

Post reply on HN