[barrkel]

Well, I use this logbook approach, in a text editor with persistent undo (which allows a few tricks, like emulating folding by deletion and relying on undo history to unfold). I approximately follow this algorithm:

- Consider the high-level goal; can it be completed immediately? if yes, do it, otherwise break it into smaller parts.

- First part is usually some kind of research. If it's a bug, it'll be a reproduction. If it's a well-specified feature or a refactoring, it'll be locating all areas of code that need to be updated. If it's design, it'll be an initial sketch.

- Subsequent parts depend on the task at hand. For a bug, I generally try and work through to a minimal set of reproduction steps. For a feature, it'll be a generated list of tasks that came out of the research step.

- When working on any given task, I add sub-entries in the form of a dialectic. For a bug reduction, I come up with a hypothesis, then try and prove or disprove it by testing. For design, I propose one approach, then consider the implications; then another approach, and so on. For a feature, tasks generally get added for any "todos" that crop up as I implement things, to ensure I complete everything.

I essentially record salient details of my internal monologue to ensure that I can pick up context again easily, and generally fit more into my working memory by offloading it into text.

I reckon it made me perhaps twice as effective an engineer, particularly in distraction-prone environments. It's also made me a lot more confident that I'm not relying too much on memory as I get older - not that I think I forget much now, but I believe I won't be very dependent on a large working set.

[nine_k]

Emacs Org mode works wonderfully in a scenario like this. Consider trying it.

[Derbasti]

Better yet, try org-journal, which automates the one-file-per-day part, integrates with the calendar, and adds searching.

[fao_]

Do you have any ideas on how to adapt this to someone who doesn't have a "present" internal monologue?

If I concentrate, I can sense something akin to the typical "internal monologue", but it isn't present enough to be copied down, and even when it is it tends to move so fast that I only really get the conclusion.

[barrkel]

Imagine you're explaining what you were doing to a programmer pairing with you, or to a junior dev, or just someone who is smart but lacks context.

When I started coding, as a teenager, I'd pace around the room explaining things to myself almost as if I was giving a lecture, so it's fairly baked into my thinking process. If you assert something, laying a statement out there, the process of hearing it can cause you to start to think other things: is it actually well-justified, are the assumptions behind it solid; what are the consequences and implications of the statement; all the things you might think if you heard someone else say something, and you're listening critically and intently.

[bramen]

Interesting, when you think about something you don't ever hear yourself talking it out inside your head?

[fao_]

I can hear small parts of it now and then, and I can definitely 'hear' myself read and write text, but most thought doesn't pass through my internal monologue. I can't tell if it's because it's going too fast (Which is certainly possible), or because of some other reason.

[bramen]

Could be you're a more visual thinker?

[geezerjay]

> Do you have any ideas on how to adapt this to someone who doesn't have a "present" internal monologue?

If you use a text editor you don't need to write everything down right away. You can just dump a keyword or a snippet that describes or is associated with what you're doing, note your intent and/or your goal, and as you work on your task keep updating your notes whenever you get the time.