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
Because not everyone uses macOS.
This shell script works on most Unix-like systems unlike Notes.app
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.
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.
Forgot to eat. Got sick.
I distilled the most important lessons here:
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
- 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.
The result revealed that we do not actually learn much and that we have misconception about 'learning.'
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.
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.
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.
E.g. negating A => B yields !B => !A
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 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.
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 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: , HN thread: .
Switch-case has lexical scoping on the entire switch block. Example:
String abc = "xyz";
//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.
 - http://stackoverflow.com/questions/24328679/does-java-se-8-h...
 - http://www.slideshare.net/billkarwin/models-for-hierarchical....
 - https://news.ycombinator.com/item?id=13127938
> 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
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.