DEV Community: lxy-yz

A regret maximization framework

lxy-yz — Sun, 17 Sep 2023 18:26:58 +0000

https://blog.liallen.me/a-regret-maximization-framework

React state management in 3 lines

lxy-yz — Sun, 17 Sep 2023 12:42:36 +0000

TL;DR

npm install unstated-next immer use-immer
create a store.ts file with 3 lines of code (👇)
🎉🎉🎉

// store.ts
import { createContainer } from 'unstated-next'
import { useImmer } from 'use-immer'
export default createContainer(state => useImmer(state))

Have you ever experienced analysis paralysis in the world of React while trying to understand what The Paradox of Choices means? The fact that React is so unopinionated that it offloads the burden of having strong opinions onto you, the developer, who is responsible for building something more than a "Hello World" demo.

Problem

Every day, a new state management solution emerges, such as Redux, Mobx, React.Context, Jotai, Zustand, you name it. Each has its distinct features, which is why there are numerous online tutorials about them. However, the question remains: which one should we choose if we want to simply Get Stuff Done instead of getting stuck in an endless comparison rabbit holes?

Inspiration

If we can suspend our judgement temporarily and let go of the pride of winning the popularity contest for a moment, we may find something quite pragmatic from our peer frameworks. And of course, we will. There will always be inspirations to draw from others, similar to how they learn from React.

In Vue 3, there is a new Composition API paired with Immer.js that literally turns Vue into React. See how Evan weaves his magic in just a few lines of code.

const { state: items, update } = useImmer([
  {
     title: "Learn Vue",
     done: true
  },
  {
     title: "Use Vue with Immer",
     done: false
  }
])

https://twitter.com/youyuxi/status/1493146218142208001

Although it looks simple and clean, it doesn't provide much of a selling point to me because Vue and Immer.js have many similarities in terms of state mutations, especially from a developer point of view. They both allow us to update state in a way that's similar to how we mutate JavaScript objects, without working against the JavaScript language.

But how about React? Could it be possible to bring the same idea to React and make React more Vue-ish?

Solution

Turns out, it's not that difficult to achieve (you only need 2 libaries https://github.com/jamiebuilds/unstated-next + https://github.com/immerjs/immer). It has the same benefit of using React.Context, unlike hooks, state can be shared across components. What is more is that it enhances React.Context with Immer so that you can update state just like you’re mutating object in JavaScript.

Additionally, it enhances React.Context with Immer, allowing you to update state just like you would mutate an object in JavaScript. Think of it as replacing React's setState with Immer's update function, while everything else remains the same.

import store from './store'

// useContainer is a React hook from https://github.com/jamiebuilds/unstated-next 
const [ state: items, update ] = store.useConatiner([
  {
     title: "Learn React",
     done: true
  },
  {
     title: "Use React with Immer",
     done: false
  }
])

https://twitter.com/radicalblind/status/1699581033996562800

Embrace simplicity by not fighting against the language. Boost productivity by avoiding decision-making. Easy peasy.

Thanks for reading. Until next time 👋

How to be regretful from a 5 YOE

lxy-yz — Sun, 17 Sep 2023 12:40:41 +0000

TL;DR

My regret maximization recipe

Specializing prematurely by going with the flow
Cracking LeetCode to let the market decide what’s best for you
Learning Vim to impress others
Avoiding examining your beliefs
“It can’t be my fault.”

Following the footsteps of the legendary investor Munger who delivered a speech about how to guarantee a life of misery, I’ve stumbled across the formula for a career of regrets. I had my skin in the game, i.e. 5 years of continuous mistakes backed by ignorance and folly, to assure me its effectiveness. If you’re looking for a recipe to minimize regret, stop reading here and consider forwarding a resume to Jeff Bezos instead.

Let’s debrief how my regret maximization framework works.

Going with the flow

One of the biggest mistakes I made early in my career is specializing too soon. In hindsight, albeit a painful realization, it all makes sense by going with the flow. I won't delve into the broader debate between specialists and generalists here, but a tweet by @Patio11 encapsulates it well: 'People underestimate how effective a generalist can be at things which are done by specialists. People underestimate how deep specialties can run.'.

I had zero experience about web development until I was introduced to React and Node.js in my first internship. Since then, I've specialized in frontend web development, regardless of what my job title might suggest.

However, the challenge arises during those meetings where you're frequently asked to introduce yourself to different groups. What do you mention beyond your name? Often, it's nothing more exciting than 'I'm X, and I work as a Y at Z.' Yet, this 'Y' designation becomes an integral part of our identity, translating into our credentials at work, and it's often remembered faster than our names.

If we don't define our own priorities, someone else will do it for us. Our environment plays a significant role in shaping our behavior and values, ****even if the cues are subtle. An example of this is job credentials being omnipresent, from internal employee portals and messaging platforms to our external LinkedIn profiles. Our personal preferences matter little, as long as they convey to our managers, teammates, and HR what they can expect from us.

The more specialized you become in a particular domain, the more tasks within that domain are assigned to you, propelling your growth toward becoming an expert. This creates a self-reinforcing cycle that benefits overall productivity, making it irrational for your employer not to do it. The flywheel perpetuates unless you consciously put it on hold. It’s easy to put the hat on, but much harder to remove it.

I eventually came to the realization that not hating what I'm doing isn't the same as being passionate about it. The cost of this realization was several years invested in the wrong direction. This late awakening can be attributed to a lack of self-accountability in determining what truly matters to me, leading to a default 'going with the flow' mentality and causing lots of anxiety and pains.

Money, not your heart

No doubt money is important. But software engineers are paid quite generously in the US and many other places. Once you cross certain income threshold, you reach a point of diminishing returns where other psychological factors kick in and become substantial to your drive.

I had a weird relationship with LeetCode - an online technical interview preparation platform. When it comes to cracking a coding interview, I doubt if there’s anything more effective than practicing LeetCode. But it’s a rather contentious take.

Many people simply can’t accept the fact that a brilliant hacker could fail a Google interview because of not knowing how to reverse a binary tree. I’m one of those people because it reminds me of the old days of memorizing textbooks to pass exams in China. It’s a misfortune when we’re trapped in a rigid system like this, all under the guise of identifying talents (by rejecting real talent).

Despite my contempt about the LeetCode style technical interviews, I still used the platform to prepare my interviews before. I can’t find better reason other than peer pressure and survivorship bias prevalent on the internet. Many share success stories of hopping between jobs to secure higher salaries, creating pressure to follow suit.

However, every time I tackled these coding questions, an inner voice questioned, "What on earth are you doing with your life, wasting it on these mechanical problems?" I found no excitement in solving them. Even when I received job offers, I didn't feel proud. It's a peculiar feeling that not everyone can relate to. It raises a fundamental question: What's the purpose of pursuing something that neither your current nor future self enjoys?

To be fair, LeetCode does deliver on its promise as an interview preparation platform. However, the value you derive from it depends on how well it aligns with your personal values. For those whose values don't align with the current interview system's emphasis on algorithmic challenges, I suggest not sacrificing your peace of mind if money isn't your top priority. Instead, let your heart guide your actions, not the market.

You'll find much greater happiness by staying congruent with your values.

Impressing others, not yourself

As we step out of school and into the professional world, we often find ourselves standing on a blank slate with limited knowledge about the chosen field, yet surrounded by lofty expectations. We don’t always recognize the insecure novice within us, but we do see the need to outshine our peers. After all, who wants to be viewed as an imposter?

This was the backdrop of my early career, and I felt compelled to take action. I decided to emulate what I believed many great programmers would do - I embarked on the journey of learning Vim (apologies to Emacs enthusiasts), a text editor beloved and crafted by hackers. I was convinced that this was the path to greatness.

The learning curve is a bit deep but that’s to be expected for taking “the road less traveled”. The allure of dancing on the keyboard shortcuts was addictive, and I poured countless hours into refining my vimrc file, much like a musician fine-tunes their instrument. Besides, the motivation isn’t grounded on personal growth, but rather a desire to impress others.

It was a humbling realization that the connection I had drawn between great programmers and the tools they used was completely flawed. I did not emerge as a Vim guru or a superior programmer. The delusion of superiority driven by personal preferences is, to put it mildly, counterproductive. Falling into the vanity trap of constant comparison distracted me from the actual work needed to improve my craft - skills can only earned through the sweat equity.

Don’t examine your beliefs

Companies often establish guiding tenets like "Own it," "Do the right thing," or "Have Backbone; Disagree and Commit" to aid decision-making. These principles ring true because they can be interpreted in various ways.

However, it's crucial to realize that corporate values don't necessarily align with your personal values. Merging them into a single mix can create problems.

Do we genuinely want to take ownership of numerous tasks that no one else cares about, not even ourselves?
Are we certain that penny-pinching on things that boost our productivity is the right course of action?
Should we automatically oppose a colleague's opinion without first understanding the basis of their arguments?

I recall a friend who worked for a major tech company. He joined as a recent graduate, facing the common dilemma of navigating a new job. However, the company had a tenet that encouraged every employee to embrace ownership, aligning perfectly with his personal values. Consequently, he accepted every work request that came his way.

The result? He became the designated owner of the team's on-call ticket queue, a repository of operational tasks that experienced colleagues shied away from. Despite this, he perceived tackling these tickets as a sign of productivity and excellence in his role. Additionally, he received positive feedback from peers for his ownership.

However, his performance review told a different story. This disconnect between positive peer feedback and managerial evaluation prompted him to question what had gone wrong. How could he be held accountable for job performance that had deteriorated? He had always been lauded as a responsible student and friend before.

Dealing with workplace issues is challenging, but even more so is accepting that a belief, once beneficial, may become outdated. Understand that every belief is context-dependent and warrants careful examination before becoming a part of your identity. Beware of fruitless debates like determining the best programming language, framework, or IDE. When we attach our identity to tools, we risk losing sight of the actual problems we're addressing.

A victimhood mindset

This is the most powerful force that can counter all of above. By putting on this armor, no challenge or setbacks could ever approach us. Under its influence we’ll be rewarded with no self doubt, no responsibility, no rationality and so on.

I couldn’t be more familiar with this, here are some examples I draw from personal experience:

Automated build failed? Flaky pipeline.
Bug reports piling up? Go talk to the QA.
Missing a deadline? Software is inestimable.
Career ceiling? Favoritism.
Disagreement with management/PM? They got no technical background.
And the list goes on…

The common theme is clear - It’s always someone else’s fault. And the situation never improves; only getting worse. The resentment accumulates, the morale plummets, and eventually, the only viable choice seems to be leaving the place.

But why leave? Because it’s the f*** toxic working environment’s fault.

We will embark on a new journey, after a short honeymoon period, the same vicious circle repeats itself. I don’t know where exactly you’ll end, but in my case, it culminated a career collapse that marks the pinnacle of my regrets.

Conclusion: steering clear of regrets

To summarize the key points I've shared:

Going with the flow results in a career scripted by external forces.
Prioritizing money over your passion leads to inner conflict.
Focusing solely on impressing others leads to a depletion of motivation.
Neglecting to examine your beliefs risks squandering your efforts.
Embracing a victimhood mindset can make you feel invincible, but it's a perilous illusion.

I’ve testified above rules under different circumstances with reproducible regrettable outcomes. Maximum regret is achieved when all of them combined in synergy.

However, I genuinely hope that no one has to go through this because it's an unpleasant experience. In parting, let me leave you with another quote from Mr. Munger:

“All I want to know is where I'm going to die so I'll never go there.“

Reverse engineering a GPT Bot

lxy-yz — Sun, 09 Apr 2023 05:41:13 +0000

https://blog.liallen.me/reverse-engineer-a-gpt-chatbot

Talk to ChatGPT in BDD

lxy-yz — Tue, 21 Feb 2023 06:16:03 +0000

https://blog.liallen.me/talk-to-chatgpt-in-bdd

What’s your favorite reading list in 2022

lxy-yz — Sat, 07 Jan 2023 22:18:09 +0000

Inspired by YouTuber Ali Abdaal’s tweet, which is an awesome reading list to me, I compiled a list of articles that I personally get inspired the most in 2022 https://blog.liallen.me/2022-articles

Curious to see what’s yours 🧐? Excited to learn from them!

React Vite Starter kit for app or component library

lxy-yz — Tue, 13 Dec 2022 14:58:44 +0000

I created some light weight starter kits for building app/libs with React + Vite. Hope it helps. https://blog.liallen.me/vite-3-react

File system based routing with webpack

lxy-yz — Tue, 06 Dec 2022 05:51:20 +0000

Ever missed nextjs style file system based routing in webpack?

Heroku👋 Fly.io

lxy-yz — Tue, 06 Dec 2022 05:49:21 +0000

https://blog.liallen.me/bye-heroku-hey-flyio

Debugging Life Problems

lxy-yz — Thu, 09 Jun 2022 03:25:40 +0000

It is a painful thing
To look at your own trouble and know
That you yourself and no one else has made it
-- Sophocles, Ajax

Debugging, despite being one of the most valuable engineering skills to have for programmers, is a hard science to master. But what’s the matter with life?

We know that life is just like mountain climbing, filled with all sorts of ups and downs. There are moments or periods of time we are suffering badly that we want to know the reason desperately. The process of figuring out the why of those life struggles is similar to how programs are debugged. To debug effectively, we need to stabilize the error first, or in other word, make it reproducible. Many bug reports mandate reproduction examples. Anthony Fu had a great article explaining the why. Equally in life, if the same mental problem consistently drains our motivation, it might be a good time to dive a bit deeper than simply tolerate it.

However, we know that the root cause of a bug may not be on the surface, it could lurk somewhere deep. If we only look at what goes wrong at the moment, which is what people tend to do, we might only catch the surface. If we attempt to fix what’s on the surface, say having a workaround with some hard coded values, it may get the test suites to pass, but it’s a false positive. Instead, we need to understand what brings us to the situation. In program, we get the help from reading stack trace. In life, a series of events or choices we’ve made in the past may give us more clue. To leverage stack trace for debugging, we need some degree of “logging”. This is usually done by searching our memories. The problem with counting on memories is that they aren’t as reliable as we would wish. This is where journaling comes into the scene. It may require a bit extra effort, but it gives a more undistorted view of what had happened before.

When debugging computer programs, those “Caused by” lines worth more attention. The lowest caused by may often be the root cause, besides they hide deeply that you need a lot of patience to uncover them. Similarly, five whys is a good technique for root causing real world issues, including the struggles we’re dealing with. Patience is the key, don’t panic.

After carefully analyzing the available evidences, we form our assumption. Making the right assumption is critical. For example, assuming it’s my fault is a good assumption while pointing fingers is not. When bugs popup, they’re much more likely caused by application code we wrote rather than framework or language constructs, thus it’s wiser to chop down the stack trace to lines associated with our own code. Jeff Atwood even calls this first rule of programming. When things didn’t work as expected, like when betrayal happens or relationship sinks, it’s always more rational to take the responsibility to reflect on ourselves rather than blaming others. This isn’t easy either, our ego will keep us blind from our mistakes. Self-defense is part of human nature, but true growth often comes from taking the harder road.

Don’t forget to validate our assumptions. It’s usually done by taking actions and reviewing results. Again, journaling helps. It could be a repeated process since we might fail a couple times and our assumptions turned out to be totally wrong. But persistence is the key, as long as there is progress, we’re slowly moving towards the goal. Eventually the bug will be fixed, time to party right? Yes, but hold on for a second. Conducting a post-mortem reflection that summarizes lessons learnt, plus diligently asking ourselves where else in our life the same lesson can be applied, this will curate a long-term thinking that our future selves will be grateful for and save us from making the same mistake again.

Fitting goals into a job, not in it

lxy-yz — Sat, 09 Apr 2022 05:01:07 +0000

Programming into a language, not in it.

I came across this concept in Code Complete 2 and it resonates deeply with me. A language is just a mean towards a goal (e.g. communication). Regardless it is a human language to connect human, or programming language to instruct computers. Without knowing what the end purpose is, we can hardly assign any meaning to the process.

In the meantime, same as any other tools in life, it comes with constraints and limitations. If we simply programming “in” the language, we are guaranteed to be bound by the limitations of the language and stuck at the implementation details. In order not to lose sight, we should always stay close to the problem we’re aiming to solve. After all, if the problem isn’t worth solving, why are we bother spending time on it at all.

The same idea applies to job as well. Lots of jobs are filled with mundane tasks and not designed for intellectual growth. When I first enter the workplace, I have no idea about what a job is. I told myself that as long as I am willing to grow, the rest will follow. However, that is simply not true. Later I realized that I set the expectation too high on a job. There might be some job full of excitement and challenges, but that’s not for ordinary people. Dream job, if there is any, doesn’t come easy.

If we can’t control what we are asked to do in a job, what else can we do? Complaining about the system is broken? Fuck no, this is the least useful thing to do in life. Finding another job? It still feels like gambling though. Until recently, inspired by above quote, another option pops into my mind. It is simply taking a step back and thinking very hard about our goals first, then fitting the goal into the job. They don’t need to align perfectly, in fact, most of time they don’t. But the priority is clear. I got to admit that this is easy to say than done due to all the ambiguities to deal with when setting goals, but it’s a necessary step to redefine what a job actually means in our life.

Why we {}

lxy-yz — Fri, 25 Mar 2022 16:38:02 +0000

Life is short so

If you {} for bread , I can understand, so do I.

If you {} for making, I can understand, much want I.

If you {} for craftsmanship, I can understand, with much respect.

If you {} for interest, I can understand, a bit jealous maybe.

If you {} for … I’m not sure … 🤔

If you {} for [], sorry forgive me, I can’t understand it.

Notes

{}, [] are placeholders. E.g. replace {} with Coding, [] with LeetCode
Inspired by reading The Moon and Sixpence