Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Using a logbook to improve your programming

routley.io

Post reply on HN
Print view View original

21–30 of 75 posts

Re: Using a logbook to improve your programming

#21

Post by torbjorn »

What the author says about aliases in the bashrc being evaluated only once when the bashrc is run when the shell session is opened is wrong.

Go ahead and try this:

Put,

    alias lb='vim ~/logbook/$(date "+%s")'
in your bashrc.

Source the bashrc.

Run the lb command. It creates a new file with a different epoch timestamp each time. This `lb` command doesn't need to be a bash function. It can be an alias and work just fine.

Maybe how this works in zsh is different...

Re: Using a logbook to improve your programming

#22

Post by barrkel »

leviathan wrote: post #2

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…

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.

Re: Using a logbook to improve your programming

#23

Post by nerdponx »

torbjorn wrote: post #21

What the author says about aliases in the bashrc being evaluated only once when the bashrc is run when the shell session is opened is wrong. Go ahead and try this: Put, alias lb='vim ~/logbook/$(date "+%s")' in your bashrc. Source the bashrc. Run the lb command. It creates a new file with a different epoch timestamp each time. This `lb` command doesn't need to be a bash function. It can be an alias and work just fine…

Zsh is different, although I'd be surprised if this wasn't the Bash behavior.

It doesn't make sense. If you do

    alias e=vim
it's not like Vim opens when your shell starts.

The only way to have a "precomputed" alias is to get the quoting wrong, and leave $() in double quotes instead of single quotes, meaning it will be evaluated before the alias is even assigned.

Re: Using a logbook to improve your programming

#25

Post by nine_k »

barrkel wrote: post #22
leviathan wrote: post #2

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…

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

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

Re: Using a logbook to improve your programming

#26

Post by deerpig »

gavinpc wrote: post #17
krupan wrote: post #6

Emacs org-mode is great for this.

I've been using org-mode for about ten years to document moment-to moment progress on tasks. I'll give a basic summary of the problem, copy in significant commands and results as I run them, and ask the next questions to drive the next steps. Some features that make Org useful for this: - I'm clocked into the task so I can always jump to it easily, even as I hop around other emacs buffers - supports code snippets wit…

Org is already 10 years old? It seems like yesterday that I was using Muse Mode. Then, seemingly overnight the muse discussion lists went very quiet because everyone switched to Org. I still have a bunch of notes in files that was created in Muse.

Re: Using a logbook to improve your programming

#27

Post by fao_ »

barrkel wrote: post #22
leviathan wrote: post #2

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…

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.

Re: Using a logbook to improve your programming

#28

Post by dominotw »

lucisferre wrote: post #18

Based on a some of the comments so far I think people are glossing over the key elements of the logbook. This isn't simply an activity log. The first step is to describe the nature of the problem as well your planned solution before beginning. I think this can be a pretty powerful practice in being mindful. All to often I find myself jumping into a half-baked solution while at the same time having only half-understoo…

>All to often I find myself jumping into a half-baked solution while at the same time having only half-understood the problem.

This is what kills me in tech interviews. Unfortunately its hard to calm down and think quietly when you are being hounded by the interviewer to "think out loud".

Re: Using a logbook to improve your programming

#29

Post by bramen »

fao_ wrote: post #27
barrkel wrote: post #22

Earlier quoted context omitted.

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.

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

Re: Using a logbook to improve your programming

#30

Post by perseiden »

Heh funny, I started writing a "labbook" like this ~6 months ago with markdown writer in atom for every day. I have a background as a Lab technician where I was used to keep a daily detailled labbook so I didn't have to develop that habit..

I like to structure my programming lab book in a similar way, for every task/ bug/ project I try to jot down a description, hypothesis, expected outcome and document my progress with code snippets / outputs / plots. I also keep a Todo list at the top to visualize my current workload. It really helps if you have to come back to a problem later on or just to get a good overview of your current task. I feel lik this also works nicely in conjuncture with GTD to increase my productivity.

Post reply on HN