Work Vipassana

Do you know Vipassana? Vipassana is an intense meditation retreat where you can’t even talk or move during meditation for 10 days. Inspired by Jeremy’s 100-hour work week and wanting to silence the telenovela that my mind generates, I experimented with intense mindful working this week.

I carefully logged what and how long I was doing work

My total work time is 2355 min (39.25 hr) if I didn’t include other types of “work” such as dance training.

• Monday: 550 min (9.2 hr)
• Tuesday: 470 min (6.8 hr)
• Wednesday: 480 min (8 hr)
• Thursday: 390 min (6.5 hr)
• Friday: 465 min (7.75 hr)

It seems that it is a complete failure from my initial imagination of working 100 hours a week. I needed to halt the project on Friday as my body was screaming with fatigue and dizziness. Yet, my goal is working in the most mindful and engaging way possible and there are many observations and learnings to share. This is my observations.

My mind screamed and rejected me in the beginning.

Initially, I imagined the “flow state” all the time. However, as I set a strong intention to focus and demanded lots of mental effort from it, the moment I took a quick short break from work, my mind screamed, rejected, and bargained. It fetched all the painful memories even though they were completely irrelevant. I experienced this in the first two days of work because I wasn’t used to it and felt overwhelmed. On the third day and onward, I started to find the rhythm and follow my instructions.

I told new stories to myself.

I thought I would free myself from the telenovela, but it’s the opposite. I need to tell more stories to go through the discomfort. I told myself the story of determination, “we are going to be better than yesterday. We desire to realize ourselves.” The determination has overthrown the fear of incompetence and the stress of this moonshot experiment. I’m definitely in a big war in my mind, not on planet Earth. However, what’s surprising is that under stress, my mind is the most flexible to modify. As I realize the old me would not be able to go through it myself, I can change my self-perception by telling myself a new story me.

My performance greatly benefited from a sharpened mind.

Interestingly, I solved all the programming problems during this experiment. Yes, I might be lucky, but the truth is that I didn’t have any desperate frustration during any debugging process. Why?

My attentive mind can carefully distinguish hard thinking work (thinking about algorithms) vs lazy comfortable work (just coding and trying). Usually, our mind gets lazy when it’s tired, and that’s why the work is ineffective. However, now my mind doesn’t get into stupid rabbit holes. Whenever I’m aware of my slight frustration, it will pause and ask me, “Are we on the right track?” or “What do we know now?” or “What other ways can we get around it?” This creates a very good intuition when I try to solve problems.

It doesn’t get overthrown by emotions. A lot of the time when we cannot solve a problem, we feel frustrated and tell ourselves we gotta push through. I realize that deters you from thinking clearly and doing the right thing at the moment. Even if you know that you will be better off taking a break, your emotions want you to sit there and try, try, try. But as my awareness increases, I have a better attitude and emotional regulation. I tell myself to stop, to write all the information down, and to ideate other angles to rethink the problems. I become smarter by simply noticing my emotions and stopping to react to them.

That’s why I’m able to solve all the problems in a relatively short amount of time without frustration.

Here are some of my learnings about work.

Pain shouldn’t be a reward system for hard work.

I learned that the amount of pain does not equate to the amount of effort. I implicitly reward myself for pain during problem-solving because that’s emotional labor. But it doesn’t contribute to output. In fact, it negatively correlates with it. It’s like hearing someone proudly say that they stayed up overnight working, while you know overwork results in a stupid mind, not more output.

If I really care about something, I should spend more time rethinking how to approach it intelligently, not how much pain I feel. This unlocks lots of new problem-solving ideas. For instance, I learned that I need to put more emphasis on my practice of detachment from problems. I haven’t allowed myself to do that often because I think it’s procrastinating. However, the incubation period from detachment actually allows us to solve problems creatively.

Fixing bugs is the wrong attitude to take when working on programming problems.

Fixing bugs is a terrible way to talk about programming because it assumes the system should work well, but sometimes there are bugs that we need to address. That’s why a lot of the time, we aren’t patient with the process and just want to finish it ASAP without deeply understanding it. I’ve learned that I should treat a bug as a math problem, a problem that is worth paying attention to in itself. It often implies a bigger system and knowledge that I haven’t known about. For instance, this is what I learned (software communication system) when I rethought the CORS bug.

Treat a bug as a math problem. So don’t say, “It’s bugging me so much!” Say, “I’ve been working on this problem for a while now. Maybe I should come back later.” Code with the intention of mastering a technology is better than building or finishing a product.

I decide to be more mindful of my language when learning engineering, not to fix bugs, but to think about problem-solving and learning technology.

If I feel frustrated, I’m probably on the wrong track.

If I feel frustrated about spending too much time on one problem, my emotions might be right. It’s too much time on the wrong rabbit hole. Rather than pushing myself through it, I need to listen to it and rethink what I do.

For instance, I noticed that I can get frustrated with algorithm problems when I need to walk through every step in a test case again and again. And that’s a strong and good signal. If my problem representation is correct, why would I need to do complicated manual walkthroughs? Instead, take a step back and notice if the problem representation is wrong or if there are some details (usually indexing) that I forget. Don’t keep insisting on the wrong rabbit hole.

This applies to all my engineering problem-solving processes. If I feel frustrated, maybe it’s time to rethink how to have a new perspective when I approach it.

Multiple problem representations are underrated.

The variety of solutions is encouraged, but not the variety of representing the problems. We often want to deeply dive into the problem to solve it. We think that’s how we understand the problem to come up with ideas to solve, but it only makes our minds cluttered and the problem becomes even more complicated. At the moment, I learned that finding a new problem representation is essential.

For instance, when I was having a problem with backend and frontend communication, I needed to put my test code into my existing code. However, since I know so much about my existing code, too many neurons fire and I have less bandwidth to think about my current problem. Instead, when I generate a simple code frontend that only has a text box to talk to my backend, I feel comfortable playing with the code, trying new things out, and solving the problem quickly and sweetly.

Another example is the deployment of AWS Lambda. Deployment is often painful because the problem is hard to find under many nitty-gritty details. Instead of putting all my existing code into deployment where problems get tangled and complicated, I learn horizontally by:

1. Mapping information under parallel scenarios: I test the deployment on multiple environments. I test on both Python and Node.js, so I can compare and contrast, withdrawing useful information from it. e.g. Oh! My Python deployment works, and so this information can be mapped to this on Node.js. (In technical terms, it is called structural similarity)
2. Reducing to the simplest working version: I only fit my deployment code into my existing codebase when I am sure that all the deployment code has essential functions and works successfully on the cloud, so I get a baseline of what it works. Instead of top-down figuring out all the tangling parts, I fit each part one by one. Whenever there is a problem, I know what it is.

This contributes to my next learning.

The process of creative coding should be about manipulating information and problems creatively.

Most people associate creative coding with art creation. I think that’s a narrow frame. For math, algorithms, for engineering, I want to expand the definition of creativity after testing multiple methodologies to approach problems. If there are so many ways to rethink and reimagine engineering problems (not “fix bug” anymore!) to play around with, we should invite and encourage more creativity for problem-solving itself.

I want to stop using “brilliant” or “stupid” when facing problems or trying to do it in a way everyone is doing now. I can be free, I can play, and I can imagine by massaging information.

Self-imposed stress can still unlock potential and further change your self-perception.

Since I push myself to aim for 100 work hours, I don’t stop when I feel tired. For instance, I probably will only do an hour or two of algorithm problems a day. Now, I push for three under the time limit for each problem. Miraculously, I learn more and faster. I quickly grasp and apply the problem structure for dynamic programming in a few mornings (1. State 2. Recurrence relations 3. Base case) because I’m forced to learn faster and smarter. As I learn what I am capable of doing, my identity changes.

Being the best isn’t a good incentive structure for learning.

I can think I’m good because I’m learning a lot, but I can also think I’m good because I’m better than anyone else around me. If identity can be changed through learning, social comparison isn’t the best incentive. Why?

Because being the best only accounts for a short amount of contemporary periods. If you are the finest programmer in this snapshot of the world, so what? Do you stop learning? How about all the great historical figures that inspire the modern engineering system?

Now, I rather think of engineering as a language I want to master and a capability I want myself to internalize. The relative position in modern society is only a reference for my progress.

There are lots of things I already know but have not internalized enough yet. Thanks for listening to my words vomiting today hehe.