Chapter 3. Many problems
You know why I better than you? Because I do MAAAAANY problems.
—Yu-Chong Tai
I managed to spend my first two years at Caltech as an undeclared major. I did this by delaying declaring as long as possible and, when that was no longer permitted, pretending to declare as a major whose department head was notorious for never being on campus, as he spent most of his time at Stanford Linear Accelerator. I would go to the Dean of Students to report his absence, and he would sign off on my course selection.
Because of this, I got to overload on classes far outside my “intended” major: abstract algebra, organic chemistry, molecular biology, philosophy of the mind, assembly language programming, and public finance among others. One of those was EE14a, the first quarter second year class required for electrical engineering majors: linear circuit analysis.
This class was taught by a somewhat eccentric professor by the name of Dr. YC Tai. While linear circuits are rather trivial, Gordon Moore Labs had not been built yet, so the Electrical Engineering department was strapped for resources. Dr. Tai was the department’s ringer, put there to “discourage” some from becoming electrical engineers (or “dah-ble Eeeez” as YC Tai liked to called them in his Chinese accent often parodied by the students).
Dr. Tai would like to quickly solve for the various properties of a linear circuit by using mathematical tricks and other shortcuts honed from years of practice and problem solving. I honestly didn’t think he spent more than a minute per problem, including the time spent to draw the circuit on the chalkboard.
After solving one, he’d point to the chalkboard and say, in thick accented English, “How long that take? 10 second? 20 second? I give you hour exam with five problem. You solve in two minute!”
The class would erupt in laughter. But to this day, I’m not certain he was joking. I’m pretty sure if the department would let him give five minute exams, he would have, even if everyone dropped out of the class.
Anytime a student would seem frustrated with his approach, he’d look at the student and say, “You know why I better than you? I do MAAAAHHH-NNEE problem.” And then he’d let out a quick laugh and continue with the lesson.
It would be “maaaahhh-nnee” years before I’d see the wisdom in his words. I found the secret Dr. Tai repeated to me: the way you really learn something is by doing not just a few difficult problems, but by doing a large volume of them until the difficult became easy and automatic.
Want to learn chess? Do a lot of chess tactics and memorize chess endings until you feel blood coming out of your eyes. Want to learn to draw? Draw a lot. Want to program? Program a lot. And once you think you’ve got it down, program some more.
Malcolm Gladwell popularized the concept of 10,000 hour rule in his book Outliers. He is actually summarizing and restating the research of Florida State professor, Anderson Ericsson. He discovered people achieved mastery after about 10,000 hours of deliberate practice.
Being an author of popular non-fiction, Gladwell deliberately neglects to mention two key things:
First, how much exactly is 10,000 hours? It is 20 hours per week, every week for ten years. Second, before you think you can double up to cut this time in half, the sort of practice Ericcsson refers to, “deliberate practice”, is simply not the sort of thing that can be done for more than 10 or 20 hours per week, because deliberate practice is repetitive, requiring feedback, and decidedly unfun! Not only that, once a practice has been mastered to the point of proficiency, one must challenge oneself with a higher degree of difficulty or it ceases to become deliberate. In fact, those 10,000 hours are just as likely to take twenty years as ten. Even though I have been working on building internet websites for the last sixteen years and coding for almost forty, I probably haven’t yet put in 10,000 hours of deliberate practice.
So why is it 10,000 hours? It’s just a number requiring such a large investment of time that most people are simply not willing to invest it into practice. There are actually many things we’ve mastered that even the most complex computer hasn’t: non-routine physical tasks, recognizing and empathizing with people or animals, and most forms of pattern recognition (like reading one’s own really bad handwriting). That’s pretty awesome, but because a lot of these things come to most people easily, they’re not considered “mastery.”
What does all this have to do with learning to code? Well, simply to focus less on the number of hours, and more on doing those things that are deliberate practice.
Luckily, computers have a low tolerance for errors in writing, so you are going to be hit with lots of feedback in your practice of learning. So all you have to do is do a lot of it, and constantly challenge yourself to get better.
Now is that so hard? ?
Have you met someone who seems to program circles around you? It’s because they’ve solved more problems with programming than you. Think of the most creative programmers you know or might heard of, and I guarantee they perform the basic tasks of programming with an ease and automaticity that can only have happened through repetition.
Creativity can only occur when everything around it that can be done without creativity has done so many times that those parts are automatic. This way, mental energy is not wasted on such tasks and is saved where it is needed.
When you are learning to code, constantly challenge yourself with more coding problems. You will be rewarded with the ability to express yourself in code perhaps even easier than you do with words… and the reward will not just allow you to make the easy things automatic, or the hard things seem easy, but also the nearly impossible things suddenly possible.
(By the way, one day in the last quarter of my sophomore year, the head of the Physics department was actually on campus, and that is how I became a physicist.)