I like to think of blank pages as mini whiteboards. With a multifunction copier i can print out lined, grid paper or specialty layouts and whip it through the scanner once im done with it keeping a digital copy. 3USD buys me 500 pages, and with a laser printer [250USD], toner refill kit, etc. that comes out to less than a cent a page, or 3 cents if I amortize the printer over 10k pages (assuming it breaks once it hit…
“I like to think of blank pages as mini whiteboards.” This. I never enjoyed drawing diagrams in Inkscape, though my boss swears by it. I’d much rather draw with pens on paper and then digitise by scanning.
I could see your bosses workflow working as long as he has a library of common elements. For graphs I tend to use yED, which is nice. You know how LaTeX has the mantra that you input the data, and it worries about the layout for you? yED is similar, you add nodes, connect them, and then you chose from one of two dozen layouting algorithms, like "hierarchical", "swimlane", or even "family tree".
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 prob…
"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 i…
> 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.
Surprised no one has mentioned doing this in a physical notebook with a pen. I started doing what the author describes a long time ago to document bugs to come back to later. I soon realized it's just a good way to keep my thoughts organized and be more productive. I tried doing something similar with a text editor but grew tired switching screens or tabs. A notebook is also a bit more accessible than a laptop when y…
> I tried doing something similar with a text editor but grew tired switching screens or tabs.
I've found that using a text editor that supports code folding, and following a markup language that enables the text editor to automatically set fold points, helps navigate log entries more efficiently.
I also use a notebook to jot down tasks, but when a job requires a high number of different unrelated small tasks that are completed rather quickly I've found that a physical notebook actually makes the process very inefficient.
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.…
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.
> 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.