I Wrote Down Everything I Learned While Programming for a Month

I Wrote Down Everything I Learned While Programming for a Month
dnote.io

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.

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.

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

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

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.