The CAP Theorem of Choosing a Project: LIE

| July 16, 2021

In theoretical computer science, the CAP theorem, also named Brewer’s theorem after computer scientist Eric Brewer, states that it is impossible for a distributed data store to simultaneously provide more than two out of: Consistency, Availability and Partition tolerance.

I recently had a similar thought while looking back at all the previous projects I worked on. It is impossible to hunt for a project inside a big company (or any environment with great competition) that simultaneously provides more than two out of:

  • Low risk: High probablity to launch it once it achieves the quality bar to become usable
  • Impactful: Large impact if launched
  • Easy: Low techinical difficulty

So it’s a LIE when someone tells you that you should go for a project with all the three attributes above.

My Thoughts After Leaving Google for 3 Months

| May 9, 2021

I left Google after a bit more than 5 years. Google was my first job and my dream company. It feels like a blink how fast the time passed by.

Many friends asked me why. Working for Google is definitely a privilege. I will always be grateful how much I learned and gained in these 5 years. It worths a separate blog to document what actually drove my decision making process and led to leave Google. In this one I would only write down my thoughts in the last 3 months after I left Google.

Am I happier in the last 3 months with my new job?

Yes!

As an engineer, Google (when I joined in 2015) provided me the 2nd best environment: largest data, mature infrastructure, billions of users. You might ask what is the best if Google is secondary? The best environment is challenging problems, innovative people and an infrastructure with less limitation.

A great infrastructure is both weapons and shackles. It demonstrates what was the correct way to solve a problem. However in real world problems are always different with their cousins. A lot of times in order to make sure we are utilizing the “great” existing infra, we either cut the toes to fit the shoes or kill the flies with a cannon. It is seldom encouraged to spin up a new infra to solve a new problem since the belief is deep in a lot of people if not everyone: our existing infra is great you should reuse it.

Yeah I know it’s always a trade-off.

In my new job, the infra basically does not exist compared with what I have seen in Google. This actually makes me really excited since no one will ever use “we have a X infra that solved a Y problem, you should use it as well” as a reason to oppose an effort of building another something.

In fact I won’t recommend any new grads to join my current job: it is very chaotic, though full of opportunities. As a first job it definitely requires a lot of effort and proper mentorship to figure out a career path. I do recommend my current job to many seasoned engineers and my Googler friends, especially people who are great problem solvers and willing to think differently. The years in Google provided me a very good view of how the infrastructure evolves with larger and larger traffic, where it settles, how to mitigate tech debt while still be able to deliver new features. These are like golden standards in some sense that always come to my mind while I’m facing the chaotic problem space.

I began to appreciate more of Google’s infrastructure after I left Google. It began to guide me through the fogs of uncertainty.

I still recommend a good engineer should be aware of not being spoiled by “Google-level” infra. You stop growing when you start to believe the existing infra will handle all your new features and take it for granted. Try to understand as much as you can and even dig into ancient docs to understand how it evolves into this shape. In the future these will be the best knowledge you can keep with yourself.

Right I started to miss Google after 3 months. But I know I’m a better engineer than 3 months ago.