Master your tools
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.
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.
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.
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":
Acquiring new tools is the surest way to get smarter.
Does critical reading qualify? How about writing well?
2. I want to learn from you, what are the tools that benefited you the most?
3. What does your mastering process look like?
4. What are some good tools for computer science students?
Here is John Regehr's answer, but this is just one answer and it is given with a pretty literal interpretation of "tool".
5. Refining from the tools/methods to principles, what are some good principles for "computer science" thinking?
Thought-processes.
Intuition pumps.
How to go 10X.
Good engineers use good tools.
Teach Yourself Programming in Ten Years.
This was my reply on the article.
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).
This story is a perfect illustration of the need for tooling and the need for mastering your tools.
There are many levels of learning/mastering
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.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.
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.
Learning/mastering is a gradient descent process
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".
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.
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.
Tools grow your brain
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.
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.
To make a transformative contribution, sometimes you will need to invent your own tools as I wrote earlier in "How to go 10X":
Adopt/Invent better tools "Give me six hours to chop down a tree and I will spend the first four sharpening the axe." -- Abraham LincolnThe 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.
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.
Acquiring new tools is the surest way to get smarter.
After you master a tool
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.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
1. What qualifies as a tool?Does critical reading qualify? How about writing well?
2. I want to learn from you, what are the tools that benefited you the most?
3. What does your mastering process look like?
4. What are some good tools for computer science students?
Here is John Regehr's answer, but this is just one answer and it is given with a pretty literal interpretation of "tool".
5. Refining from the tools/methods to principles, what are some good principles for "computer science" thinking?
Related links
I really liked "You are your tools" post by Daniel Lemire.Thought-processes.
Intuition pumps.
How to go 10X.
Good engineers use good tools.
Teach Yourself Programming in Ten Years.
Comments
Just thought you might be interested to know (in case you didn't already). The 'three levels of learning' you write about map quite well onto the three levels of understanding that amateur Buddhist mediators are taught. For them it goes:
1. Belief. Having been told something and believing it to be true. Essentially dogmatic.
2. Intellectual understanding. Knowing why your belief is true. Being able to express the reasons for it's correctness.
3. Experiential understanding. Having experienced the truth of your belief first hand. Better than 2) because no doubt can possibly exist.
In case you didn't know, I thought you might like to see that your idea is backed up by ancient teaching. :)
Substitution is the basic technique in proof construction and algebra. Years of programming and proof writing has made substituting variables a second nature for me, but witnessing the difficulty which my classmates have with the problems always intrigues me into attempts to better explain this principle. I believe I have been inspired by lambda algebra to develop such an intuition about substitution after all the experience, but lambda algebra is not taught to them so I cannot really use it to explain. Too many mistakes made in algebra comes from hacks taught to shortcut substitution. On the other hand, basic algebra laws are underutilized because substituting the name of a variable can totally throw off one's understanding of the properties of the variable. It also has implication in proofs. For example, when a universal instantiation is performed to instantiate a variable from the same set as the universal quantifier, failure to relate the instantiated variable and the universal quantifier is very common, and I've given up explaining the full formality of it.
In computer science, parameter substitution is the necessary skill for writing abstractions such as functions. I was first led to lambda algebra by Haskell. But in the process of tutoring, I've found classmates struggling to keep track of variables and parameters as data flows from the scope of one function to another. A common mistake is to refer to a value passed into a function not by the parameter name declared in the function signature, but by the name of the variable passed in as the parameter. This is quite similar to the above failure of distinguishing an instance and the universal quantifier in proof writing.