Belated post. I was busy with the move and the new home. I thought we already got rid of a lot when we moved from Canada last year, but we still have a lot of stuff. Some of them are reasonable: our son is growing up and therefore has more belongings. Some of them are totally unnecessary: we have a lot of books, and I am not sure if we will ever read them again. I also have a lot of old electronics that I don't use anymore. Once we settle down, I should figure out a way to get rid of them. I always have a dream that my wife and I will travel with two suitcases at some point in our life. And now the distance between us and that dream is about a 60% loaded truck of stuff.

While being very busy with the move, I happened to have a productive week at work. The project is getting better clarity and kicked off with a lot of progress. My team is reliable and making a lot of progress to figure out the possible solutions. This frees me up to focus on planning the project and making sure we are on the right track.

Reading

I completed the book Build by Tony Fadell on audible, as I did a ton of driving this week. The book is a collection of stories about building products, and most of the stories are about iPod and Nest. The suggestions make sense, but not particularly actionable. The more interesting part is the stories about the people and the culture, which is anecdotal and entertaining. I do feel I missed many details because I was listening to the book instead of reading it. Therefore I grab a physical book and plan to read it again. Hopefully I would be able to internalize the ideas better.

I also read The Prophet by Kahlil Gibran. Originally I picked up the English version, but I found it quite hard to read. I switched to the Chinese version, and completed the book in a day. As a parent, I enjoyed the chapter on children.

Another book that I almost forgot to mention is 遗忘，刑警. And honestly there is not much memorable about the story.

What If Railroads Didn’t Change the World? is a good reminder that we tend to overestimate the impact of the new technology.

When things take off, there is a tendency to say that they’ve made a significant contribution. But Fogel reminds us to ask: “What is it substituting for?” The fact that an innovation replaced something else tells you it had a cost advantage, but not the size or importance of that cost advantage. That gives us a framework for thinking about newer goods and processes.

Moreover, having a winner and a loser between competing technologies tells us something about the difference between the two technologies or processes, but not about the aggregate gains.

If you like startups you should love anti-trust makes a good point about why public companies walk to their demise.

The key sin of the public markets is that companies are expected to maintain growth until the heat death of the universe.

The bigger a tech company gets the worse it becomes at providing consumer and customer surplus, because it needs to eat that margin (of a sort) to keep growing. Growth demands that tech companies eventually consume that which first engendered them good will.

Theory-building and why employee churn is lethal to software companies

This is the first time I read about the concept of programming as theory building. I think this provides a different perspective when you look at source code, and realize the code is a liability because anyone new to the codebase has to understand the theory and mental model behind it before they can make any good changes. Note that, I think, you can still make changes to the codebase without understanding the theory, but this is why all sorts of hacks and leaky abstractions eventually creep into the codebase.

Its complain about the document resonates with me.

Most internal documentation only begins to make sense to a developer after they’ve developed an internal mental model of how it all hangs together. Most code documentation becomes useful after you have built the theory in your mind, not before. It operates as a mnemonic for what you already know, not as a tool for learning.

But how to make the documentation more useful? I don't know. More illustrated examples? More hand-on exercises with some guidance from a senior member? And more importantly, how to effectively transfer the theory to the new hires? I don't know, and the author doesn't have a good answer either.

Tech Companies Are Irrational Pop Cultures is about the similar topic. The author is trying to convince against the layoff trends that's happening in the industry. But to me, it's a weaker argument that tries to link with the pop culture.

Names should be cute, not descriptive

This is a very controversial one and gets a lot of hate on Hacker News. I think I understand the author's point though, and I personally find that descriptive but wrong names for services can be so confusing in communication. There is a comment on HN that suggests to distinguish between a marketing name and a code name. I think it's a good idea if your marketing/business team is not siloed from your engineering team. Otherwise, you will still run into a lot of confusion when you put an engineer and a marketing person in the same room. In my current company, we name projects after all kinds of produces. I think it's okay, as long as you prepare a elevator-pitch style one-liner to explain what the project is about.

Emojis in domain names, punycode and performance for a TIL:

...domain names are made of labels (e.g., in microsoft.com, microsoft is a label) and each label can use at most 63 bytes. In total, a domain name cannot exceed 255 bytes, and that is after encoding it to punycode if necessary.

How to store your app's entire state in the url

This happens to be a solution that we are using for one of our projects. A minor difference is that we store a much smaller state in the path instead of the query string. But it's still an interesting experience that you just wrote down the project proposal, opened Hacker News for a quick break, and saw an article about the exact same thing sitting #1 on the front page.