To master a new discipline

After learning on Engineering as a language of mine, I derived with three principles to master new things:

1. Challenge my previous notion that I cannot be good at many things: I used to accept the social idea that I can only be good at a few things so I need to be carefully pick. Yet, I was shown the possibility to be quite decent or even excellent at multiple domains if I can immerse myself with dedication. Currently, I’m challenging the concept of “specialization” as merely a concept from industrialization.
2. Learning as a transformation of self-perception: What constrains us from learning new things is the notion of incapability. Once we are able to break it and gain new capacity, our identity of self also transformed. For example, some data scientists can never deploy a server in their lifetime, which is a self-limited confirmation bias.
3. Self-transformation by integration of knowledge: If we can deeply learn the knowledge, we can merge ourselves with the knowledge. We let go of learning as a means to social validation or entertainment of intellectual self, but truly allow the knowledge to expand us as a person.

In essence, can vs cannot learn is a tricky confirmation bias that most people withhold.

With the desire to master using engineering as an example domain, I’m coming up with my self-designed curriculum.

Improve precision and speed to achieve basic fluency for the foundation.

For engineering, I hypothesize basic fluency as algorithms. Depending on the level, fluency can mean basic algorithms (leetcode) for a general engineer, transformer algorithms for a deep learning engineer, and hook, state… for a front-end engineer. I’m going to start with the basics.

Take basic algorithms questions for example; I can solve most of them at this moment. However, I’m still like a person who can speak a foreign language that locals can understand, but in an inelegant way. Therefore, the metric for measuring my algorithmic fluency is no longer the ability to solve, but speed and precision.

For me, the practice of basic algorithms is to build necessary foundations, like the Gojūon (fifty sounds) in Japanese. If you cannot remember it, you can still learn Japanese, but it will be slow and painful. I think it’s similar to engineering problems; you can still build without learning algorithms. Yet, if you encounter complex problems that involve maths, system knowledge, concepts, and algorithms, algorithmic fluency will help you decrease the mental loading, and hence free up your learning in other problem dimensions.

After achieving fluency in basic algorithms, I want to delve deeper into more advanced algorithms in machine learning and deep learning. So far, I know everything, but as I said, not fluently.

Create problem sets to drill down critical concepts

Have you ever learned piano? One thing I notice is that building projects becomes a dumb way of learning. It’s like playing the entire song every time you practice it. Instead, I should isolate the piece that makes me feel uncomfortable and drill down into it.

I want to rethink it as a problem set, and there are two ways of defining a set:

• Constantly practice one concept in different scenarios: For instance, I found myself weak in the idea of hooks in React. Rather than building tons of React projects, setting intentional practice on comparing and contrasting different hooks probably is more beneficial for my own learning. Put it in leetcode language, it’s like seeing a problem and can immediately identify if it belongs to graph, stack, queue…
• One function as one problem set: One thing I find helpful is to isolate the problem set using different functions or features. For instance, just building an isolated Google authentication or deployment. It gives me clarity on how these functions actually work than one thing nested inside of a complicated project.

The purpose of it is to (1) untie the pressure from performing (aka making the project work) (2) create good concept mapping from problem set to a good problem representation and solutions. After the concept is constructed, these problems should be put into the basic fluency practice bucket.

Supply myself with cultural knowledge

Beyond familiarizing myself with concepts and later on to speak them with precision, I have been noticing that I’m missing small pieces of external and cultural knowledge. Most people usually describe this situation as “Hey! It took me 3 hours to solve it but 1 sec to change the code!”

Under most of these situations, there is no concept that is fundamentally challenging, but some external knowledge that I don’t know. For instance, not knowing the communication layer design between the browser and backend is almost like not knowing you should take off your shoes when you visit a mosque. Even if you can speak Arabic perfectly, you will not be allowed to get in.

This knowledge is usually under a big umbrella of the design that our ancestors established. In engineering terms, it’s called system design, while in language terms, it’s called culture. No matter if it’s big or small, the design of machines and how they should be interacting is the engineering culture where traditions and rules exist.

Hence, if I want to live comfortably in a new foreign land, I not only need to practice the language, but also need to accustom myself with the culture.

Do you have a new identity and personality when you speak different languages in a foreign country? I do. It’s almost a new discovery of a whole new world. I imagine the mastery of a new discipline is similar.

When you move to that country, speak the language fluently with immersion in the culture, you are exposed to a new identity of self. With the strong intention of mastering and extending my perception of self, learning engineering becomes much less of a career move, but an integration of who I am now and an explanation of who I can become.