Using a logbook to improve your programming

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.<p>So the author says that it&#x27;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.<p>A few concrete examples would have been nice.<p>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.

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&#x27;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.

Based on a some of the comments so far I think people are glossing over the key elements of the logbook. This isn&#x27;t simply an activity log.<p>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.<p>All to often I find myself jumping into a half-baked solution while at the same time having only half-understood the problem.

I did not go to college&#x2F;university for engineering, but just hearing the tools of &#x27;real&#x27; engineers is great.<p>I&#x27;ve been opening up Jekyll in the morning as the start of my day. I write the blog post for the work I&#x27;m about to do. I&#x27;ve noticed that I&#x27;m getting better at explaining the problem clearly and the solution. When there is a paragraph that feels out of place I yank it into a different file immediately to get it out of the current flow of the post. The paragraph felt out of place because it was probably a distraction from the problem Im trying to solve today. Also, the great thing about this technique is that I have a blog post at the end of the work day that I can look back on and say, &quot;Damn, I shipped something&quot; if I didn&#x27;t feel like I shipped anything else (common problem in our field of software developers)

Keeping a journal is particularly useful to resume your work.<p>Before lunch, or a meeting, or end of day, or when someone interrupts me and needs something, or any form of break, I &quot;serialize&quot; what I am working on in the journal, and then I read it when I am coming back.<p>In this way I can keep my mind clear and focus in the next activity.<p>It is also useful for standup meetings, retrospective meetings, etc... when you often need to describe what you did yesterday or this week.

Heh funny, I started writing a &quot;labbook&quot; 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&#x27;t have to develop that habit..<p>I like to structure my programming lab book in a similar way, for every task&#x2F; bug&#x2F; project I try to jot down a description, hypothesis, expected outcome and document my progress with code snippets &#x2F; outputs &#x2F; 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.

I believe many of us already do what the author suggests, maybe in a slightly different way.<p>Here&#x27;s how I use my own flavor:<p>1) I create a GOAL. The GOAL is my ultimate big picture, which will give me immense happiness. So, the most recent example is, I wanted to build an E-Commerce application.<p>2) I map out the PATHS to achieving my GOAL. So, what I consider PATHS is:<p>a) What programming language should I use? b) Which APIs should I use, Paypal or Stripe to accept payments[1]? and so on...<p>3) I follow a flavor of DDD[2] to come up with the important modules I need to have for a functioning E-Commerce project.<p>Examples: I will need a Order Management module, I will need a Marketing module (for sending emails, running campaigns). I will need a CMS module to host product pages.<p>4) For each of the modules, I will create an issue on Github and add a checklist[3] of the stuff I need to get done.<p>5) Everytime I make a commit, I will reference this issue and the tasks along with it. Eg. &quot;Removed Paypal #12&quot;<p>6) At the end of the week, I will review the commits and evaluate whether this particular method I used was worth it. A good use case would be experimenting with a library and comparing it with another - Eg. Bootstrap vs Semantic UI. I will use the learnings from this workflow in my future projects.<p>7) I will also see if something can be automated. For example, for my current E-Commerce project, I use Phoenix&#x2F;Elixir. It has it&#x27;s own set of scaffold generators, but they&#x27;re opinionated (they use Bootstrap). So, for every project I got tired of replacing bootstrap and customizing the generated scaffolds. So, I wrote a custom generator that drastically saves me a lot of time for large projects.<p>Hope this helps :)<p>[1] Not sure why anyone would use PayPal in this day and age tho.<p>[2] <a href="https:&#x2F;&#x2F;stackoverflow.com&#x2F;questions&#x2F;1222392&#x2F;can-someone-explain-domain-driven-design-ddd-in-plain-english-please&#x2F;1222488#1222488" rel="nofollow">https:&#x2F;&#x2F;stackoverflow.com&#x2F;questions&#x2F;1222392&#x2F;can-someone-expl...</a><p>[3] <a href="https:&#x2F;&#x2F;github.com&#x2F;blog&#x2F;1375-task-lists-in-gfm-issues-pulls-comments" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;blog&#x2F;1375-task-lists-in-gfm-issues-pulls-...</a>

Maybe I go against the common thought here, but for me I think it is completely useless. Whenever I start working on a problem I obviously have an approach in my mind, but very often I find out that is the wrong one. And I can realise it only after I start working on the actual problem and solving it. At a certain point I will find some obstacle that will make me rethink the whole approach. For this reason I can&#x27;t really see the added value in spending more time before actually tackling a problem once you have a plan in your head. The most important thing to do when solving problems is to be prepared to change your point of view multiple times and to attack the problems from several different directions. I&#x27;m sorry but I really can&#x27;t see how writing in stone your approach before you fully understand the problem can help you in any way...

I&#x27;ve found keeping a software-engineering logbook very useful at work.<p>Recommend the vim-wiki plugin for this <a href="https:&#x2F;&#x2F;github.com&#x2F;vimwiki&#x2F;vimwiki;" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;vimwiki&#x2F;vimwiki;</a> in any vim-window the logbook for today is accessible via [leader-W-leader-W].

I find this interesting. Mainly because, I&#x27;ve been trying to implement similiar strategy on my daily works to fight off low productivity hours and really figure out where all my time is going. One of the things I&#x27;ve been doing is noting down the time and date when I set to do things. Seeing something similar presented in the post with more formal and clean approach made me happy - as in being on the right track.<p>But than again, there was TED talk of all this organization is ultimately shifting the energy from actual. Which led me reducing number of &#x27;productivity&#x27; application and sticking with a few.<p>Wunderlist Onenote Evernote - mainly for the phone.

Good idea, but as others noted it was a bit light on details.<p>Some more concrete suggestions from what appears to be the university of Idaho&#x27;s Electrical Engineering department can be found here:<p><a href="http:&#x2F;&#x2F;www.ee.uidaho.edu&#x2F;ee&#x2F;power&#x2F;jlaw&#x2F;COURSES&#x2F;CAPSTONE&#x2F;F05&#x2F;handouts&#x2F;EngineeringLogbooks082205.pdf" rel="nofollow">http:&#x2F;&#x2F;www.ee.uidaho.edu&#x2F;ee&#x2F;power&#x2F;jlaw&#x2F;COURSES&#x2F;CAPSTONE&#x2F;F05&#x2F;...</a>

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.<p>Go ahead and try this:<p>Put,<p><pre><code> alias lb=&#x27;vim ~&#x2F;logbook&#x2F;$(date &quot;+%s&quot;)&#x27; </code></pre> in your bashrc.<p>Source the bashrc.<p>Run the lb command. It creates a new file with a different epoch timestamp each time. This `lb` command doesn&#x27;t need to be a bash function. It can be an alias and work just fine.<p>Maybe how this works in zsh is different...

Emacs org-mode is great for this.

This is similar to what I&#x27;ve been doing on and off for nearly 5 years now: <a href="https:&#x2F;&#x2F;gist.github.com&#x2F;sent-hil&#x2F;3444793" rel="nofollow">https:&#x2F;&#x2F;gist.github.com&#x2F;sent-hil&#x2F;3444793</a>, except on paper.<p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=4448361" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=4448361</a> has some good tips and tricks.

I have similar ideas. At the beginning (20 years ago) I use windows notepad.exe. It has a trick that if you put “.LOG” on the top of a txt file, every time you open it with notepad, it appends current date to it. Later on I switched to Evernote, then Apple Notes.app and settled. Recently I added a service with Automator to allow me insert current date to a note. Quite convenient.

I don’t keep a log but I use pen a paper to create diagrams which visualize my problem and potential solutions. It has been very helpful and good excuse to rest my eyes from the monitor. I don’t care about dates cause I like to work in a chaotic kind of way and I don’t like planning ahead I prefer exploration and critical thinking during execution.

Might as well auto generate a header for the file...<p><pre><code> function lb() { today=$(date &#x27;+%Y-%m-%d&#x27;) fp=&quot;&#x2F;home&#x2F;you&#x2F;logbook&#x2F;${today}.md&quot; if [ ! -f $fp ]; then echo &quot;# ${today}&quot; &gt; $fp fi vim $fp }</code></pre>

I&#x27;ve been using Typora to make my todo lists recently. It&#x27;s a markdown editor. Super simple to type, and you can really got some professional looking layout, with headings and titles quickly too. Recently they built in a file browser. Open one file in a directory, and it will show you all the files in side panel. Which in my case are just todo lists for day of the week. But it could be any type of notes. Highly recommend it. For Example typing ###Title would give a large title typing - [ ] will give you a checkbox, and so on.

My &quot;bash function&quot; adds just a few more lines, so as to git add&#x2F;commit&#x2F;push after closing the editor, and adding a good title by default:<p>----<p>journalfile=$(date --utc +%Y%m%d-%u.md);<p>if [[ ! -f $journalfile ]]; then<p>echo &quot;# &quot;$(date &quot;+%A, %e %B, %Y&quot;) &gt;&gt; $journalfile;<p>git add $journalfile;<p>else<p>echo &quot;File already exists: $journalfile&quot;;<p>fi;<p>vim $journalfile;<p>git commit -m &quot;Changes in journal file $journalfile&quot; $journalfile;<p>git push origin master;<p>----<p>Source: <a href="https:&#x2F;&#x2F;github.com&#x2F;samuell&#x2F;mdnote&#x2F;blob&#x2F;master&#x2F;editnewjournalfile.sh#L3-L18" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;samuell&#x2F;mdnote&#x2F;blob&#x2F;master&#x2F;editnewjournal...</a>

I like the idea, i just think MD files might be too limited. I really came to enjoy Onenote because it is so easy to put unstructured data, images, links, videos and even draw on top of it all with a stylus but i didn&#x27;t use it for every task i do. Will try that in the future as i often have issues resuming old tasks or remembering some details to a problem in the past.

This is a nice and simple! Usually I keep a logbook separated for each project but it looks more like a diary where I record failed approaches and new tries to solve a problem.<p>For more structured documentation, I keep separated text files for each solution that I can easily find if I need it later.<p>EDIT: Also, scratching your plan with pencil and paper before implementing it helps a lot.

I keep a log of things I don&#x27;t really know but should invest some time in to learn it properly as I make use of it. That&#x27;s quite useful, not so much the log, but the forced awareness of making a mental note. I&#x27;ve also been thinking of keeping a log (repo with notes) of the incremental experiments I do when learning things.

In between commit messages, bugs and design docs, I&#x27;m not sure what I&#x27;d put in a log book.

I find writing documentation as I go to be a particularly good form of this. I start before I fully understand how I&#x27;m going to solve something, and only check the documentation in once it&#x27;s correct.

I’ve been exploring keeping a logbook for awhile. Some apps I recommend: Quiver, Boostnote, and jrnl.sh<p>All of them have open data formats so you’re not locked in and can save everything in git which are requirements for me.

Typora is a great markdown editor for something like this.

What could help is if you take pictures of the relevant logbook pages with your smartphone, and then commit them into your git repo, along with your code.

Free tip: commit often and write proper commit messages.

I keep a simple text file to log features and bugs. This approach of creating date-based files seems cool. May try it out as well.

I started doing this &quot;naturally&quot; :)