
I Wrote Down Everything I Learned While Programming for a Month - stockkid
https://dnote.io/blog/writing-everything-i-learn-coding-for-a-month/
======
lwerdna
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`.

~~~
askafriend
Why not just use Notes.app?

~~~
guessmyname
> Why not just use Notes.app?

Because not everyone uses macOS.

This shell script works on most Unix-like systems unlike Notes.app

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

~~~
stockkid
Author here. I agree. Some things we learn cannot be easily quantified. For
example, the way I write code has changed compared to years ago. But I cannot
put in words what it is that made me so.

It makes me think maybe my tool is better suited for more obvious learnings.
One applicable demographic would be beginner programmers because I remember
that when I started coding I had to learn many obvious things such as API,
language features, etc. And even seasoned programmers are always beginners at
some things.

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

------
henrik_w
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-...](https://henrikwarne.com/2016/06/16/18-lessons-
from-13-years-of-tricky-bugs/)

~~~
swat535
This was really valuable to read! Thank you so much

------
Kagerjay
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.jackkinsella.ie/articles/janki-method).

[https://www.supermemo.com/en/articles/20rules](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

~~~
enugu
This thread[1] by Michael Nielsen is a good description of the use of spaced
repetition to memorize things.

[1]
[https://twitter.com/michael_nielsen/status/95776322945477427...](https://twitter.com/michael_nielsen/status/957763229454774272)

~~~
jacquesm
Here is a pretty exhaustive (Gwern style) overview of SRS:

[https://www.gwern.net/Spaced-repetition](https://www.gwern.net/Spaced-
repetition)

------
stockkid
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.'

~~~
codingdave
I don't know that it is fair to extrapolate conclusions about "we" from the
single data point of just yourself.

Learning is also about the big picture. Counting the number of factoids that
you pick up about specific languages isn't the same thing as gaining a broader
understanding of software development, or of a particular framework or even a
specific codebase.

~~~
artmageddon
I can't read the article(blocked at work here), so at face value I agree with
you. But then the question is, how do you go about measuring the latter?

~~~
codingdave
I'd ask a different question, of why do you need to measure it in the first
place? I learn more about our codebase, my productivity goes up -- I deliver
more updates, with less bugs, faster as I learn. Do I need to measure the
details of how much I learned? Or is it sufficient to just know that I'm
grokking more each day, and that is reflected in my work?

Isn't that the mantra of BI? Be careful what you measure, because that is what
you will improve.

~~~
TeMPOraL
> _Isn 't that the mantra of BI? Be careful what you measure, because that is
> what you will improve._

The corollary is that you don't improve what you don't measure.

> _Or is it sufficient to just know that I 'm grokking more each day, and that
> is reflected in my work?_

OP's point is, I believe, that you _don 't know_ that you're really grokking
much of anything and how much it's actually reflected in your work, because
you're not measuring it. This can work if you have good feedback mechanism at
work, though.

~~~
cortesoft
> The corollary is that you don't improve what you don't measure.

I mean, this is a nice saying, but it is pretty clearly not true. Lots of
things that aren't measured are improved; we have not measured my two year
olds vocabulary at all, but it is certainly improving.

~~~
swsieber
Indeed. The correct corralary is "Things that don't improve aren't being
measured"

E.g. negating A => B yields !B => !A

~~~
jayliew
So measuring learning is a good thing, because it means you will likely be
more deliberate in actually getting better at it, as opposed to just leaving
it up to chance

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

------
TeMPOraL
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...](http://stackoverflow.com/questions/24328679/does-java-se-8-have-
pairs-or-tuples)

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

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

~~~
hguant
Unrelated to the substance of your comment, thank you for putting up those
citation links.

~~~
TeMPOraL
They were part of their respective notes, I just reformatted them to be in one
place in this comment :).

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

------
infomofo
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

~~~
jihadjihad
Hadn't heard of jrnl before. Love how clean it is and the tagging is awesome.
Will definitely be using this, thanks!

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

------
cloverich
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/](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.

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

~~~
thenobsta
I'm starting to begin the same set of things(logging, trackign...). Just
curious, do you have any tools you like?

------
Azareus
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](https://github.com/Az4reus/logrs)

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

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

