This is a very nice illustration of a hack versus expert: Expert had years of battle-scar, and internalized everything. Hacks/shortcuts are going to take you only to where the expert's domain starts.

Also another take away is, we humans are dumb. We don't have anything to be proud of about our mental prowess. I make so many stupid mistakes every week, it is frustrating. It is a shame we can't get much smarter on the spot. But in the offline mode (doing research/thinking by writing), I think we can do better. We can only make up for the shortcoming of our brains by using discipline (writing or math-symbolic computing).

There are many levels of learning/mastering

There are many levels of knowing. The first level is "knowing by word". With passive learning (like I did for studying for the diff final), you get the most limited form of understanding/knowing. It is ephemeral, and you are not able to reconstruct that on your own. The second level is "knowing by first hand experience". At this level, you are able to understand/witness and if necessary rediscover the knowledge on your own. Finally, the third level is "knowing by heart" or grokking it. At this level, you internalized the knowledge so that it becomes part of your nature.

The best way of learning is by doing. You need to work hands-on, make a lot of mistakes so you can start to internalize that knowledge. That means you should make, and produce things continuously. For this to work in a sustainable manner, you need to change your default mode from the consumer mode to the producer mode.

Learning/mastering is a gradient descent process

In that down hour after teaching, what do I do? I have regret-flashbacks about some parts of the lecture I delivered. I have remorse about how I botched some parts of the lecture and how I couldn't answer a student's question better. The reason I botch up a part of the lecture is often because I haven't internalized that part yet. The reason I wasn't able to make a smooth transition from one part to another part is often because I didn't have a better understanding/insight about how those parts fit. It is likely I was missing some context about it. Or maybe more likely that I knew the context, but I didn't internalize it well enough. There are many different levels of knowing, and the more reliable/resilient/dependable level of knowing is knowing by experience. Teaching is a way to have hands-on training in your research area. You learn through your regrets about how you couldn't explain it better.

Tools grow your brain

I think one of the things that really separates us from the high primates is that we’re tool builders. I read a study that measured the efficiency of locomotion for various species on the planet. The condor used the least energy to move a kilometer. And, humans came in with a rather unimpressive showing, about a third of the way down the list. It was not too proud a showing for the crown of creation. So, that didn’t look so good. But, then somebody at Scientific American had the insight to test the efficiency of locomotion for a man on a bicycle. And, a man on a bicycle, a human on a bicycle, blew the condor away, completely off the top of the charts.

And that’s what a computer is to me. What a computer is to me is it’s the most remarkable tool that we’ve ever come up with, and it’s the equivalent of a bicycle for our minds.

Adopt/Invent better tools "Give me six hours to chop down a tree and I will spend the first four sharpening the axe." -- Abraham Lincoln

I mean, not just better but transformative tools of course. Most often, you may need to invent that transformative tool yourself. When you are faced with an inherent worthy problem, don't just go for a point solution, generalize your solution, and ultimately make it in to a tool to benefit for the future. Generalizing and constructing the tool/system pays that technical debt and gets you to have truly 10X benefit. MapReduce as a tool comes to my mind as a good example for this. By generalizing on the kind of big data processing tasks/programs written at Google, Jeff Dean was able to see an underlying pattern, write a good tool to solve the problem once and for all.

Scientists spend decades to invent transformative tools (Hadron Collider, Hubble telescope) and then they get breakthrough results. As researchers in computer science, we should try to adopt/cultivate this mentality more.

After you master a tool

As to methods, there may be a million and then some, but principles are few. The man who grasps principles can successfully select his own methods. The man who tries methods, ignoring principles, is sure to have trouble.

-- Ralph Waldo Emerson

MAD questions

Related links

Couple months ago, a friend sent me this article about "Speed learner Max Deutsch challenging chess grandmaster Magnus Carlsen". My friend called the story a life-hack story, and remarked that this is the "Silicon Valley bro" frame of mind in action: "Nobody deserves any respect because I am so confident and valley savvy I could naturally write an app and do it better".This was my reply on the article.This story is a perfect illustration of the need for tooling and the need for mastering your tools. This is what I wrote in 2012 about the many levels of learning. It has a nice backstory as well, about how I almost flunked differential mathematics as a freshman.As it comes to learning/mastering a tool, hacks/shortcut does not cut it. Just having a passing familiarity with the tool doesn't empower you. You need to master and internalize your tools.No pain, no gain. If you don't bend yourself, you did not master the tool. You are short-cutting and won't get the full benefits of the tool and level up.You truly master a tool only when you master yourself and bend yourself with that tool's thinking mode. Mastering the tool and yourself through the tool, takes many weeks, and sometimes years. When you pay your dues and go deep, only then, you transcend and level up.You (well, at least I) progress through the levels of learning gradually almost via a gradient descent like process. Let me give an example from Paxos.The first time I taught Paxos in my distributed systems class around 10 years ago, I don't think I understood it well. I was a hack. I felt very unsatisfied about how I couldn't explain it better. Through these regrets, I started getting better at it. This echoes what I wrote earlier about "what I learn from teaching" So the way I got better at internalizing and explaining Paxos was by making mistakes and feeling like an idiot. Once in a while I would be saying "Oh, wait, this doesn't make sense in Paxos", or "Wait, how does Paxos deal with this?", and then work my way out of these problems. I would feel bad and say to myself "How come I didn't notice this after this many years?", but I now got used to this feeling. I know this is a natural part of the learning/mastering the tool. This is a good kind of screw up, because it makes me learn. When I screw up and learn from it, I am leveling up. A good tool is a force multiplier. So it is definitely worth the time to master a good tool, because you will get a lot of mileage out of that tool as multiplicative factor.Young Steve Jobs was pitching computers as bicycles for the mind.To make a transformative contribution, sometimes you will need to invent your own tools as I wrote earlier in " How to go 10X ":The good news is mastering a tool makes it easier for you to pick up another one. As you become expert in one tool/domain, you can map other tools/domain to that and contextualize and master them much faster.After you master a tool, you internalize it and go minimalist, and reduce it to first principles. You not only internalize how to use it, you also internalize its limitations and learn when not to use it. You learn from your tools and start converging to more minimalistic tools and first principles.Does critical reading qualify? How about writing well? Here is John Regehr's answer, but this is just one answer and it is given with a pretty literal interpretation of "tool".I really liked "You are your tools" post by Daniel Lemire.