The Year of Exploration

published on 2022-02-18

I don't write summaries of the year. They are prone to be too personal to be interesting to others. But 2021 has been different to me.

The Chinese New Year has just passed. Looking back at the passing year, I realized an overarching theme that runs through various events. It's about entering new areas and having new perspectives. It makes me rethink many things that I have been taking for granted for a long time.

It's been a year of exploration.


At the beginning of the year, I started working at Logseq, an open-source note-taking app with bidirectional linking. It's a new experience for me in many ways. I will list them in the order of ascending significance.

First Full-time Remote Job

The obvious advantage is that I get to work with amazing people all around the world. For example, Logseq mostly uses the Clojure programming language, which I have never used before. But since the founder Tienshen and other team members are excellent Clojure programmers, I picked it up by learning from them pretty fast.

As a programmer, my duties are mostly the same. But the flow of work has changed a lot.

I make my own schedule and work alone most of the time. This optimizes efficiency and flexibility. On the other hand, sometimes it makes me feel lonely and directionless, missing the social interactions of an office.

The communication cost is much higher. Zoom calls can be tiring and lose many subtleties of an in-person talk. Instant-messaging apps can be nerve-wracking. Ideally, this will be mitigated by asynchronous communication. Basecamp has a good guide on this topic.

There are many other things that I've learned working remotely. To make it short, I'd say it comes with its unique pros and cons and requires a different mindset and work culture to be successful.

First Time Working on an Open-Source Project as a Day Job

Getting to work a on fairly large (and popular) open-source project is the most attractive thing when applying for the job, from which the most important thing I learned is that it's all about the community.

At Logseq, the whole development process is centered around the community. We take feature requests and bug reports from the users. After each milestone, we base the next one on user feedback. To encourage contribution to the project, we spend much effort writing docs and tutorials. It's a remarkable lesson that you can learn so much by talking and listening to the community carefully.

First Entrance to the Tools for Thought Territory

Before joining Logseq I've only lightly used traditional note-taking apps. Upon first trying apps like Logseq and Roam Research, I'm overwhelmed by all the new features. Bidirectional links? Networked thoughts? Digital gardens?

Not for long, it all click for me. I see why these features are useful and better than traditional ones. More importantly, I understand that computers as a tool for thought have so many unfulfilled potentials.

As I build features for Logseq, I start to explore the tools for thought landscape. There are many ongoing efforts and some early products, yet we are still at a very early stage of using computers to empower the human mind. This sensation is best captured in Andy Matuschak's How can we develop transformative tools for thought.

Local-First Software

As a web developer, most of the apps that I have built so far can be categorized as cloud-based web apps - browser GUIs connected to data and business logic on the server.

On the contrary, Logseq is local-first. Most of the user data is stored on the device and can be synced optionally. This is good for performance, privacy, and data ownership while being much more complicated to build than their cloud counterparts.

I learned a lot from the article Local-first software. The article not only illustrates the concept of local-first software but also recommends CRDT as a foundational technology. The team behind it even build some interesting libraries and prototypes.

There is one caveat. The proposed methods are suitable for building peer-to-peer apps instead of client-server apps. And I'm more interested in the latter. After some research, I find a few helpful resources and libraries. Similar to tools for thought development, this area is at a rather young age.

I managed to build a prototype and to write an article about it, which gained some love from Hacker News.

Currently, I'm building a side project that helps people learn better, combining what I've learned from my probe into tools for thought and local-first software. I have no idea what will come out of it. Let's keep on exploring.


I'm a big podcast listener. One late night in September, I played one episode from the CoRecursive podcast named From Competitive Programming to APL. It's an interview with the programmer Conor Hoekstra.

In the beginning, it sounds like a usual programmer interview. How the protagonist got interested in computers. How he got into the field. What is he doing right now. Etc.

But about halfway through the episode, Conor starts to talk about how he coincidentally discovered an ancient programming language called APL and fell in love with it. He mentions that the APL is weird at first look because it consists of hieroglyphic symbols like Chinese characters, which can be combined to write extremely terse code. And the only data structure APL has is the multi-dimensional array.

I was instantly hooked, partly because I'm Chinese and partly because I feel there's something both alien and profound about this lost art. So I delve in, learning the language, reading its history, and watching many videos of people talking about it. It's a fascinating journey.

When some people encourage fellow programmers to learn Lisp, they often quote from Alan J. Perlis,

A language that doesn't affect the way you think about programming, is not worth knowing.

APL fits this saying well. More than Lisp, it has changed how I think about programming and computer science. What's more, it reminds me to always be humble and open-minded.