Hacker News new | past | comments | ask | show | jobs | submit login
I Wrote Down Everything I Learned While Programming for a Month (dnote.io)
169 points by stockkid on Feb 12, 2018 | hide | past | web | favorite | 46 comments

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
  		echo '' >> $fpath
  	    echo $@ >> $fpath
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`.

I really appreciate the minimalism of this approach. Going to give this a try, thanks for sharing!

Yeah, this is really useful. I think it'll break on single quotes: `notes we'll need oranges tomorrow`, but otherwise, it's a very low-friction method, to me.

Yeah, had a similar issue with parentheses while using it today (but escaping them with '\' worked just fine).

Can this be used with nano as well?

Yes, if you change all references of "gvim" to "nano".

Why not just use Notes.app?

> Why not just use Notes.app?

Because not everyone uses macOS.

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

Notes will try to insert smart quotes in your code and other silent changes (made to improve text notes but catastrophic for code.)

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.

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.

Peter Naur's "Programming as theory building" comes to mind: https://software-carpentry.org/blog/2016/10/programming-as-t...

Agree. Learning is more about building a web of interconnected idea, generating new insight, refining existing idea.

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:


This was really valuable to read! Thank you so much

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.



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

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

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


This is insightful, some of his tweets I found written there I didn't find elsewhere.

- For 9000 cards+, reviews 100 cards a day in 20 minutes

- Delete 1 or 2 % of cards that are poorly made

- Reading a science paper is 0 to 5 questions unless to understand it well its 20 to 40.

- Enter cards through desktop app, review on mobile (this i do already)

- If memorizing saves 5 minutes in future, put it down

I only have a few hundred cards or so, I only add a handful of cards a week at best.

I came here to say exactly this. I can see his software as being useful if you an export it into csv -> anki. But in the end, the data needs to wind up in flash cards for schedule reviews

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

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?

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.

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

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

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

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

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

FWIW, I have found that I am learning more that I realize. This has been brought to my attention when I go over what I have been working on with someone who is in a comparable state as I was when I started (a new team member, for example), and I find myself having to explain more than I would have guessed was needing to be explained.

I spend a lot of time thinking on this - how to become a better programmer, and how to learn more effectively. I find myself vacillating between googling "how do I get the drop-down to stop showing up behind the button" and reading "Javascript: The Definitive Guide" cover to cover. In the long run, I believe that I get more out of real deep-dives into the core of the subject matter, but I worry that I don't have much specific to show for it.

I suppose that makes a case for having a portfolio of projects and "how I made this" type blog posts, because it can serve as a proxy for the kind of things you have learned and done, as well as the kind of challenges you had to overcome to accomplish

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";
  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

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

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

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.


> 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

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

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'm starting to begin the same set of things(logging, trackign...). Just curious, do you have any tools you like?

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.

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact