Live data from Hacker News

Using a logbook to improve your programming

routley.io

41–50 of 75 posts

Re: Using a logbook to improve your programming

#41
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 you leave your desk. During lunch I can read through my notes.

Re: Using a logbook to improve your programming

#42
post #33

Free tip: commit often and write proper commit messages.

If you change organisation and were working on a closed source project, you lose everything. You need to keep your notes on a higher level though (i.e. not describing confidential information). Plus I believe that a commit is generally only covers the third point ("Describe the process of carrying out the method").

Re: Using a logbook to improve your programming

#45

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…

Seeing as the author is using vim he could just have a command within vim.

  :exec ':e ~/logbook/' . strftime("%Y-%m-%d.md")

Re: Using a logbook to improve your programming

#48
post #27
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.

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.

Re: Using a logbook to improve your programming

#49

Earlier quoted context omitted.

Each to their own of course but it seems to me, there's better places for all of that. If there's logic or design that's complicated and not properly commented or documented, then that's worth doing and sharing with the team. Work done for the day for me is typically captured in commits or bug updates - that way my colleagues can easily take over if I win the lottery or are suddenly taken ill. And stuff I learn is le…

> If there's logic or design that's complicated and not properly commented or documented, then that's worth doing and sharing with the team It's the meta also, it is capturing the models mentally and ideas and notes. This reduces cognitive load, and actually by making notes increases the chances of you remember something. > And stuff I learn is learned, so I don't need to write that down :-) Hey if thats the case the…

This does not have to be "either-or". As we see an increased focus on teamwork this could evolve into a shared (electronic) team logbook.
Post reply on HN