I Wrote Down Everything I Learned While Programming for a Month

Here's a poor man's version of dnote in my .bashrc. It's the only thing I've used consistently:

  notes() {
  	local fpath=$HOME/notes.md
  	if [ "$1" == "gvim" ]; then
  		gvim + $fpath
  	elif [ "$1" == "vim" ]; then
  		gvim + $fpath
  	elif [ "$1" == "date" ]; then
  		echo '' >> $fpath
  		echo '# '`date +"%m-%d-%Y-%T"` >> $fpath
  		echo '---------------------' >> $fpath
  	elif [ "$1" == "" ]; then
  		less +G $fpath
  	else
  		echo '' >> $fpath
  	    echo $@ >> $fpath
  	fi
  }

Insert the current date with `notes date`. Store a note with `notes the earth is about 25k miles around` or `notes dentist appointment Thursday` or `notes purfunctory - carried out with a minimum of effort or reflection #vocab`. Look up recent notes with `notes` or read/search the entire notes database with `notes vim`.

Interesting study - I think it's a great idea! Though I disagree with the statement 'we do not actually learn much'.

Most learning is very hard to condense into a short note. For example, "Booleans have a toString method in JS" is a tiny factoid that, yes, is something that can be learned. But I think it is only a minor fraction of what is actually learned.

An tennis player may write down what they learn in a month, trying to get better at the game. But ultimately, much of the learning comes from understanding abstract patterns and building up a portfolio of experiences to draw reference to in real-time.

It's the same way with programming - if I work on a game, and use some engine - yes, I'll learn the API to that engine, and maybe some extra factoids about C# I didn't know. But the learning that does me the most good is the more abstract stuff - intuition about how to structure larger projects - how and when to start focusing on performance, rather than features. Stuff that doesn't really boil down to a one liner, and you may not even realized you learned until after the fact.

I kept a list of bugs one month in the 1980's. I figured this way I'd never make the same mistake twice. I found the sheet of paper years later. Last entry:

Forgot to eat. Got sick.

I wrote down everything I learnt from 13 years of solving tricky bugs (194 entries in the file). A very useful and interesting habit that I'm still following.

I distilled the most important lessons here:

https://henrikwarne.com/2016/06/16/18-lessons-from-13-years-...

The approach the author used here is similar to using flashcard apps like anki, except not as well fleshed out.

Normally, in a flashcard app, you would write down a question and an answer. So you can review the question, and see if you can answer it or not. He wrote this down all as a oneliner for each of his "learnings". Its nice to see a frequency graph to see how often you are learning, but it doesn't really serve a purpose besides showing how inconsistent you are learning new things.

I would highly suggest anyone interested in the authors approach to learning to read these 2 articles about spaced-repetition-learning and flashcards, which goes into much more detail.

https://www.jackkinsella.ie/articles/janki-method.

https://www.supermemo.com/en/articles/20rules

Not all things benefit equally from writing things down learned / flashcards. Some things can only be learned through practice, such as learning a sport you aren't familiar with such as football. But flashcards can be beneficial here to learn about the rules of football, the mechanics, terminology, etc.

The hardest part is differentiating what pieces of information benefit from using flashcards and which don't, and consistently recognizing when new information is learned / making a flashcard for it

I wanted to measure how much I was really learning while programming. So I wrote down notes every time I learned something for an entire month in January.

The result revealed that we do not actually learn much and that we have misconception about 'learning.'

I've recently switched from a giant append-only text file which I've been using for 18 years, to using TiddlyWiki -- a personal wiki. Each journal entry (or any wiki page within it) can be tagged and you can view pages across tags, so the ideas is to tag the journal with topics and then later transfer it to some learning article about that specific topic (or any part of my past life in general).

I've found that I constantly scan HN etc. for new articles, may read them through and it gets weakly stored in some kind of background memory, but it doesn't really make me form a sufficient opinion on the subject. 15 years ago information was scarce (C/C++ user's journal only came out once a month!) or expensive (E.g. O'Reilly books), or questionable (Usenet groups). Nowadays there's just a constant stream of interesting things happening.

I did something similar over last year at work. I put a section called "Insight from today" in the default template I use(d) for everyday work notes, in which I wanted - hoped - to put something new I've learned.

Turned out, I'm not learning new things too much at my $dayjob (or my attitude is wrong). Ultimately, I was disappointed, but it made me reconsider just how much I'm really implicitly learning - turns out that more often than not, those are irrelevant minutiae instead of more fundamental facts. I favor more explicit, focused learning now.

Most notes were obviously about code (Java, JavaFX), some about my mental state while coding. Some more interesting ones:

-

There are some serious reasons[0] for Java not to have Pair<K,V> or Tuple classes in its standard libraries. They mostly boil down to avoiding people using Pairs as cons cells to avoid creating classes that would properly name and give meaning to what is being composed and why.

-

TabPane in JavaFX has a division-by-zero exception in the arrow keys handler when you have 0 tabs in the pane. Note, modulo op (%) can cause division by zero too. Obviously.

-

Storing trees (hierarchical data) in a database -- closure tables. Explanation: [1], HN thread: [2].

-

Thread.setDefaultUncaughtExceptionHandler FTW.

-

Switch-case has lexical scoping on the entire switch block. Example:

  switch(something) {
  case foo:
      String abc = "xyz";
      break;
  case bar:
      //String abc = "uvw"; //wrong - abc already exists; it's scoped for the entire switch
      //System.out.println(abc); //wrong - though abc exists, it won't be initialized in this case block
  }

For per-case scoping, we need explicit blocks.

Nice trick question for an interview, lol.

-

Stress is bad.

--

[0] - http://stackoverflow.com/questions/24328679/does-java-se-8-h...

[1] - http://www.slideshare.net/billkarwin/models-for-hierarchical....

[2] - https://news.ycombinator.com/item?id=13127938

When I started my current position (my first as a developer), I was given a company notebook that I use as a learning log. For each PR I write a bullet point or two of things I learned/mistakes I made in creating the PR.

I go through it every so often to look for patterns, and use them to focus my learning. It helps avoid repeating mistakes, and makes my professional development much more directed/intentional.

I prefer keeping the learning log in a notebook than on the computer, as looking for patterns requires me to review everything I've written. I've found that unexpected connections pop out at me when I do that.

I've been doing something similar using jrnl. I use hashtags so I could theoretically look up stuff in the past.

I.e.

> jrnl "@vim type _:noh_ to remove the last search's highlighting"

And then a week later when I can't remember, I could use

> jrnl -n 10 -and @vim

Looks great. I would try it if I didn't already use Org Mode capture templates. In Emacs you can hit `C-c c` and then choose a template (`n` for "note template" in my system). Then write your note in the box that appears (with Vim keybindings available if Evil is installed). `C-c C-q` to add tags, then `C-c C-c` to save and close the note. Each capture template files the notes away in locations and formats that you designate with short lisp snippets. I have 12 different capture templates for various kinds of information that I want to save.

Personally I've found in multiple fields its often harder to quantify, categorize, and explicitly memorize things than it is to just learn them. Usually the most important items are semi abstract (how to organize, when to optimize) or just keep coming up so frequently, you don't really need to plan around it. The repetition that comes from regular work cements a _ton_ of knowledge you don't even realize you are picking up -- its just part of the job. I do take regular notes (on a notes app I'll finish one day, https://www.striatum.io/) but I use them more for reference, reflection, and to just off-load my mind when I have too many thoughts floating about.

I am a fan of being able to take notes, log your own behaviour (and track time) and do other things off the command line. I like the approach.

Pedagogically speaking, I'm curious if this will actually help. It seems to me that note taking and review is definitely an important part of learning, but I've found that writing out in long-hand and being able to draw diagrams helps considerably. None of it useful without regular review, and application too. I'd be curious to hear other people's thoughts on this approach from a retention/review perspective.

I wrote something[1] for taking notes while programming in particular, and it's been incredibly helpful. I use a script to roll up a week's worth of notes and review them, and filter "the good parts" into my personal wiki and Anki to review.

[1]: https://github.com/Az4reus/logrs

Starting doing same. Learned a lot, as when you write -> you read to plug the gaps. Plus these notes help me to revise my work. Also share toy codes on Github to experiment.

I usually use mediaWiki for doing things like this. Thanks for remind me to start the notes again.