The last week of 2022! And this is easily the best week of the year. My company is closed for the week, and I have a week off. While the other three adults still need to work for some of the days, they formed a rotation schedule so that one of them can pair with me for the whole week. This turned out to be a great plan: we brought the kids to hiking, amusement parks, the beach on highway 1, light show on various days. And when we are all at home, the kids just play together all the time with no need for me to intervene. Therefore, I spent some high-quality family time with them, and also got a ton of work done.

Projects

It kinds of become a tradition that I tweak around my blog around the end of the year. This year is no exception. I repurpose this site to be a log site, and I am planning to write a status update for each week, and likely some non-tech articles as well. I also take this opportunity to clean up the theme, and publish it at github. Currently, it is very minimalistic and very light on features, and I want to keep it that way. I move my technical articles to blog.ziyun.rocks, which has better supports for things like diagrams, math equations, and comments.

I become interested in system programing recently. Zig is a fairly new language that caught my attention. Therefore, I started to learn Zig and write some code in it. I have completed ziglings to learn the basic syntax and semantics of the language. The next step is to go through Zig Learn and do some Advent of Code in Zig.

Meanwhile, it's fair to say that Zig is still a bit early and has many rough edges. Therefore, I also want to spend some time in Go. goraytracing is a work-in-progress project to implement Ray Tracing in One Weekend in Go.

Reading

Books

I started Thinking in Systems: A Primer based on the recommendation of Will Larson. Currently at 12%. This book is written in a terse, textbook style that needs more focus to read and therefore hard to read with fragmented time. I hope to allocate bigger chunk of time for reading it when I am back home, and I am hoping to finish it before the end of January.

Articles

I did a ton of reading this week! But I am not very good at writing a summary while they are still fresh in my mind. I need to manage my reading better, maybe by introducing a rate limiter to the new articles/books I can start reading until I write a summary for the previous ones.

How We Went All In on sqlc/pgx for Postgres + Go teaches me how to use sqlc instead of ORM to interact with Postgres with better type supports. This is something I wish to try out in a Go web project.

How DoorDash can avoid Groupon’s mistake that cost it 98% of its market cap. The title feels a bit clickbaity: it argues DoorDash should not sacrifice its marketplace health to maximum take rate. It shows some data about vertical SaaS for restaurants to go against the aggregator model with their much-lower blended take rate of ~11% v.s. 30%. I do not fact check the data, but the vertical business is something worth to keep an eye on.

The Uses of Friction talks about the importance of friction in the product design and some counter=intuitive examples to use friction.

For an obviously-better product, reducing friction means reducing the effort it takes someone to test out the product, realize it's superior, and never go back. But for something in a completely new category, where learning is part of the process of using it, a little friction can be a useful thing.

Six weeks into the podcasting life, a few early learnings

• No one place to get analytics
• More work to do for each episode (compare to writing): scheduling, aligning on topics, recording, editing, show notes, ads, music, intro, outro, promotion

My first impressions of web3 a great great read about the current state of web3 and its problems. So many takeaways:

• why centralized platforms emerged:
  • People don’t want to run their own servers, and never will
  • A protocol moves much more slowly than a platform

The lack of "distributedness" in the current web3:

All the network diagrams are of servers, the trust model is between servers, everything is about servers. Blockchains are designed to be a network of peers, but not designed such that it’s really possible for your mobile device or your browser to be one of those peers.

Almost all dApps use either Infura or Alchemy in order to interact with the blockchain. In fact, even when you connect a wallet like MetaMask to a dApp, and the dApp interacts with the blockchain via your wallet, MetaMask is just making calls to Infura!

Why bitcoin will fail also a great read about the problems of bitcoin. I like the reasoning of Fail #1 :

FAIL #1: If you like bitcoin, then you must think the gold standard was a good idea.

Believing in the gold standard is disbelieving in capitalism. The magic of capitalism is entirely contained in the following two words: MAKING MONEY

Turing Social: Twitter, For Bots is an interesting idea: a social network for bots. There doesn't seem to be a lot of (or any?) contents there yet, but I am curious to see how this idea will evolve.

Explore the fediverse, but use block like it's a machine gun in a zombie apocalypse demonstrates some of the interesting problems of the fediverse, partly technical and partly social. I am slowly losing confidence in decentralized protocols

Career Advice is a great read about career and life in general, even for a 30-year-old. It's a great reminder of how much your job can change you.

The context of one’s life defines not just what but how one thinks, and a job tends to dominate the context of one’s life — particularly when that job is considered to be part of a career. Your job will change you.

And you are expected to attend for the rest of your life. The article gives a piece of advice that I would offer to my kids in the future: before choosing your career, observe the older people working there.

As a young person, though, I think the best thing you can do is to ignore all of that and simply observe the older people working there.

They are the future you. Do not think that you will be substantially different. Look carefully at how they spend their time at work and outside of work, because this is also almost certainly how your life will look.

The harder to follow suggestion is to discover yourself before discover a career. I agree with the author that the surrounding environment and its supporting structures constitutes one's decision, which might lead to a career path that is not perfectly aligned with one's personality. However, removing the supporting structures effectively create another artificial environment that constrains one's choices. I do not believe this is the only way to find one's true calling. But I take the author's point that this search should be made uncomfortable, and more importantly, make it count.

My career advice usually falls within the framework of doing the absolute minimum amount of work necessary to prevent starvation, and then doing something that’s not about money, completely outside of supporting structures, and not simply a matter of “consuming experience” with the remaining available time.

This reminds me my internship in Shanghai. I should write it down at some point just so that I can tell this story to my kids in the future.

Stanford CS309A: 7 Life Lessons from Dr. Timothy Chou good talk about career. My takeaways:

• selling is teaching: the best salespeople are "challenges"; challengers teach.
• teach insight, teach the not
  • insight is the gap between "what is" current, and "what will be" desired
  • NO "my baby is beautiful" speech
  • Examples: MLK; Salesforce first logo; sandisk
• teach stories
  • 3 kinds of stories:
    • man v.s. man
    • man v.s. nature
    • man v.s. himself
  • All stories of conflicts
• power of language
  • manage is own mind
  • create your words/vocabulary
  • Don't be sloppy with words
• manage your career
  • 10-year cycle
  • Learn (2-4 years) -> Do (4-8 years) -> Learn...
• not work-life balance:
  • ikigai: find the intersection of
    • What you love
    • What you are good at
    • What the world needs
    • What you can be paid for

Life is Short is a great read about life and career. I have read it probably three times. The first time, I didn't have kids, so I kind of understood it on the surface but never internalized it. The second time, I was a new dad, but I didn't know what the enjoyment would feel like. The third time, I am expecting my second kid, and I am understanding it better. I have my career ambitions, but I do not want to sacrifice my time with my kids for it. The key is to focus on delivery high impact work and not to be distracted by the noise.

Relentlessly prune bullshit, don't wait to do things that matter, and savor the time you have. That's what you do when life is short.

Books that explain (parts of) how the world really works. The book list:

• Crossing the Chasm, by Geoffrey Moore in 1991
• Inside the Tornado, also by Geoffrey Moore
• The Innovator's Dilemma, by Clayton M. Christensen, in 1997
• The Art of War, by Sun Tzu, in the 5th century BC
• The Death and Life of Great American Cities, by Jane Jacobs, in 1961
• The New Economics, by W. Edwards Deming, in 2000 But do read the post for the author's explanation of why these books are important!

Don't Call Yourself A Programmer, And Other Career Advice: it's a bit long but has a lot of good points. My takeaway:

• Create values is the goal, coding is just (one of) the means
• Your most important professional skill is communication
• Learn to network
• Learn to negotiate
• Be helpful, both at work and outside of work
• Instead of modesty, be confident

  The right tone to aim for in interviews, interactions with other people, and life is closer to “restrained, confident professionalism.”

  ...“It was a privilege to assist my team by leading their efforts with regards to $YOUR_SPECIALTY.”

Beyond Functional Programming: The Verse Programming Language. It's a pretty ambitious project to build a functional programming language for metaverse.

What's an effect system? From ChatGPT:

An effect system is a system used to specify, track, and enforce the side effects of a program. In programming, a side effect is any change to the state of a program that is observable outside the scope of a particular function or operation. Examples of side effects include modifying a global variable, modifying a file on the filesystem, or making a network request.

Effect systems are used to help manage and control the side effects of a program, particularly in functional programming languages that aim to minimize or eliminate side effects. They provide a way to specify the side effects of a function or operation, and can be used to ensure that these effects are properly handled and managed.

There are several different approaches to implementing effect systems, and the specific details can vary depending on the programming language and the particular needs of the application. However, in general, an effect system will include mechanisms for specifying the side effects of a function, tracking the side effects that have occurred, and enforcing rules around the use and handling of side effects.