5 ms·

This article seems lacking some examples. I have found that such ideas are nice in theory, but when it comes to practice, they tend to fall short. So the autho

This article seems lacking some examples. I have found that such ideas are nice in theory, but when it comes to practice, they tend to fall short. So the author says that it's a good idea to write logbooks, and that it will help. But no mention on how it would help, and what would you actually do with them after you write them up. A few concrete examples would have been nice. If the idea is to help you solve the problem more efficiently, why should it be formalized? as opposed to scribbling notes on a notepad that you throw away at the end of the day.

taeric 9y ago
Advice of this sort is tough. I really really want something prescriptive. I suspect it is ninety percent confirmation bias. Looking back at successes and assuming something in common of all of them had to be contributive. Not claiming it is all luck. Just saying that outside signals usually bear more meaning than given credit.
barrkel 9y ago
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 9y ago
  Emacs Org mode works wonderfully in a scenario like this. Consider trying it.
  - Derbasti 9y ago
    Better yet, try org-journal, which automates the one-file-per-day part, integrates with the calendar, and adds searching.
- fao_ 9y ago
  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.
  - bramen 9y ago
    Interesting, when you think about something you don't ever hear yourself talking it out inside your head?
    - fao_ 9y ago
      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 9y ago
        Could be you're a more visual thinker?
  - barrkel 9y ago
    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.
firmgently 9y ago
"It provides a framework for solving hard problems by encouraging you to break them down into a series of smaller ones. "It helps you focus on the task at hand by providing immediate context on what you’re doing. If you forget or become distracted, you can quickly get back to your train of thought. "It helps you learn quickly. You can observe your method for problem solving, see what works and what doesn’t and make improvements." Saying "no mention on how it would help, and what you would do with them after you write them up" feels inaccurate to me (although the observation about the lack of specific examples is correct).
- geezerjay 9y ago
  > Saying "no mention on how it would help, and what you would do with them after you write them up" feels inaccurate to me (although the observation about the lack of specific examples is correct). To me it is an accurate description, as the author focuses on what he believes are the results while not presenting any tangible example or framework on how to get them. In short, without any information on the "how" this blog entry boils down to a page and a half where the author states that he believes that writing down things he is doing in no specific way and following no specific method may help him in some way. Well, good for him.
Mikhail_Edoshin 9y ago
It works. There's even a psychotherapy method called "problem-solving therapy"; all it does is that it formalizes the process of finding a solution to a problem: define the problem (what you have and what you want to have), outline possible approaches, evaluate, choose. I myself use something like that in my work (software development) with a text file and I can attest that following the steps often helps me to find or choose a different solution than what initially popped up in my head. It doesn't solve all problems, e.g. a complex problem that is hard to understand are not a good fit; if I notice that what I write is lengthy or that I keep returning and restating it, then this is that kind of problem; here I normally leave the desk and try to sketch it on paper. Very seldom I look through the file to find why I've made a particular choice; I don't think logbooks are of any use here, it's better to document the design elsewhere, closer to the product. I'd say logbooks are write-only (although they may be a source for the docs).

taeric 9y ago

Advice of this sort is tough. I really really want something prescriptive. I suspect it is ninety percent confirmation bias. Looking back at successes and assuming something in common of all of them had to be contributive. Not claiming it is all luck. Just saying that outside signals usually bear more meaning than given credit.

barrkel 9y ago

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 9y ago
Emacs Org mode works wonderfully in a scenario like this. Consider trying it.
- Derbasti 9y ago
  Better yet, try org-journal, which automates the one-file-per-day part, integrates with the calendar, and adds searching.
fao_ 9y ago
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.
- bramen 9y ago
  Interesting, when you think about something you don't ever hear yourself talking it out inside your head?
  - fao_ 9y ago
    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 9y ago
      Could be you're a more visual thinker?
- barrkel 9y ago
  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.

firmgently 9y ago

"It provides a framework for solving hard problems by encouraging you to break them down into a series of smaller ones. "It helps you focus on the task at hand by providing immediate context on what you’re doing. If you forget or become distracted, you can quickly get back to your train of thought. "It helps you learn quickly. You can observe your method for problem solving, see what works and what doesn’t and make improvements." Saying "no mention on how it would help, and what you would do with them after you write them up" feels inaccurate to me (although the observation about the lack of specific examples is correct).

geezerjay 9y ago
> Saying "no mention on how it would help, and what you would do with them after you write them up" feels inaccurate to me (although the observation about the lack of specific examples is correct). To me it is an accurate description, as the author focuses on what he believes are the results while not presenting any tangible example or framework on how to get them. In short, without any information on the "how" this blog entry boils down to a page and a half where the author states that he believes that writing down things he is doing in no specific way and following no specific method may help him in some way. Well, good for him.

Mikhail_Edoshin 9y ago

It works. There's even a psychotherapy method called "problem-solving therapy"; all it does is that it formalizes the process of finding a solution to a problem: define the problem (what you have and what you want to have), outline possible approaches, evaluate, choose. I myself use something like that in my work (software development) with a text file and I can attest that following the steps often helps me to find or choose a different solution than what initially popped up in my head. It doesn't solve all problems, e.g. a complex problem that is hard to understand are not a good fit; if I notice that what I write is lengthy or that I keep returning and restating it, then this is that kind of problem; here I normally leave the desk and try to sketch it on paper. Very seldom I look through the file to find why I've made a particular choice; I don't think logbooks are of any use here, it's better to document the design elsewhere, closer to the product. I'd say logbooks are write-only (although they may be a source for the docs).