Live data from Hacker News

Use a work journal

fev.al

131–140 of 305 posts

Re: Use a work journal

#131

I was assigned a big project at work 2 years ago. Apart from main code base there were a bunch of other modules and services it talked to at it was all very old code. I couldn't have kept all of that in my head throughout. I kind of rediscovered OneNote which helped me actually do the project. It's like your thought dumping playground. It's the only tool that offers least resistance to jotting down thoughts in whatev…

Same here though my preferred tool is OmniOutliner or any similar tool with hierarchical branching. There are other tools like Roam/Obsidian but Omni has proved to the fastest offline local macOS app with the most rich feature set.

Re: Use a work journal

#132
post #48

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…

> Perhaps the greatest barrier to using it is akin to envy. We see others who apparently do this without written materials, in their head. I think we see this as evidence of intellectual superiority and harbor the doubt that using an aid like a journal means we are somehow lacking in skill or ability. To add to your "this is wrong": These others may have themselves solved the problems we are now trying to solve, like…

I mitigate this "problem" somewhat by taking pride in specialized yet (hopefully) readable notations and sometimes even creative tool usage. Like using a project planning tool with a Gantt chart feature to speed up a boot process with many dependencies.

Of course, sometimes an existing tool or notation used for its original purpose is what you need. Maybe manually remove the stuff that doesn't matter.

Re: Use a work journal

#133
GitLab issues also works nicely for journaling. Each issue is a task, bundled into milestones. Within each issue you can add comments and even have one level of nested comments. Good for a lightweight hierarchical journaling. And comments/threads of an issue can each be “resolved”, all within the same issue. Great for progress tracking.

Ah, and you can paste images and have syntax highlighting. Great for debugging.

Re: Use a work journal

#134

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…

> 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.

Really cool tool. Starred

Re: Use a work journal

#135

It's surprising how many devs are trying to overoptimize for productivity with various fancy tools and techniques, when it actually comes down to simple basics. Here is what I rely on as a founder who does a lot of context switching: - a never-ending text file for todos and work journal [0] - calendar for planning (and blocking focus time) - website blocker - turned off notifications [0] https://news.ycombinator.com/…

For the never-ending text file for todos and work journal, I've found great success with org-mode, especially since deadlines automatically end up in my calendar with org-agenda. The outline format of org-mode is quite nice and it took all of 1 day to learn the key commands for making / manipulating the outline, creating links, and cycling through TODO states (using Doom emacs made the start super easy since I already know vi and didn't have to also learn the text editing commands).

I've also found the concept of an "inbox" from the Zettelkasten method very helpful. Anytime something comes up that's not yet in my system, I add it to the inbox for later processing (org-capture on my computer, and beorg on my phone). This way, note entry doesn't require a full context switch. I then just make sure to regularly drain my inbox.

I don't use emacs currently for anything but org-mode but I'm far happier with this than I was with a never ending `.md` file.

Re: Use a work journal

#137

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…

> 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 great. You should do a separate hn post

Re: Use a work journal

#138

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…

> 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.

Love the sound of this tool! Seems a bit of a shame to permanently delete anything that's been completed, sometimes it's really useful to have a record of what you've been working on.

Re: Use a work journal

#139

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 believe it cuts both ways. Writing things down allows you to dump state so that you can make other complex calculations with your working memory. Then, learning to hold more complexity in your head increases your mental bandwidth using the same amount of external state available. Rinse and repeat.

Re: Use a work journal

#140

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…

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 up the code.

If I do need something like a journal, I have occasionally just written a private gist and put that in a tab on my browser.

Post reply on HN