The programmer as the government

Currently, I have been reading Seeing Like a State by James C. Scott, a book that describes the history of how government has shaped society.

Scott’s general thesis is that human societies under one government have had wildly varying cultural practices regarding personal surnames, agricultural land use, forestry, and urban planning.

The government then attempts to standardize all of those cultural practices–at first for the purpose of efficient taxation, easy conscription of soldiers, and other classic desires of governments.

I find the book fascinating because the governments are behaving as computer programmers defining a schema, with the exception that the government can enforce the schema with literal military and police force.

An example:

By roughly the fourth century B.C. (although the exact timing and comprehensiveness are in dispute), the Qin dynasty had apparently begun imposing surnames on much of its population and enumerating them for the purposes of taxes, forced labor, and conscription. (p. 65)

This reminds me of how programmers will often make implicit assumptions about their users’ names, with the software’s schema acting as an enforcer. Patrick McKenzie, in his famous blog post Falsehoods Programmers Believe About Names, describes the various mistakes that programmers make when dealing with human names.

He lists 40 assumptions, but the first seven are particularly relevant to the states described in Scott’s book.

  1. People have exactly one canonical full name.
  2. People have exactly one full name which they go by.
  3. People have, at this point in time, exactly one canonical full name.
  4. People have, at this point in time, one full name which they go by.
  5. People have exactly N names, for any value of N.
  6. People’s names fit within a certain defined amount of space.
  7. People’s names do not change.

All this is surprising to me, but maybe it shouldn’t be. Scott notices as much that capitalism (including engineers and designers of all stripes) is another state-like enforcer of schema.

…large-scale capitalism is just as much an agency of homogenization, uniformity, grids, and heroic simplification as the state is, with the difference being that, for capitalists, simplification must pay. (p. 7)

The comparison reminds me of the following obvious truths:

  1. The schema will never be sufficiently complicated enough to match reality.
  2. Programmers have to use their ability to simplify with responsibility, as simplification can happen in ways that are bad for society.

Products and their implicit main features

Recently Robinhood came under fire for offering “Checking & Savings” accounts that were not backed by SIPC.Screen Shot 2018-12-18 at 1.18.44 PM


This got me thinking that the implicit main feature of a financial product is, like Sar says, trust.

I don’t think it ever makes sense for a company to launch a (secondary) feature that undermines their implicit main feature, which is why it is alarming that Robinhood would take a gamble that could result in the loss of trust.

Ideally, in a company with strong cultural values, the implicit main feature is protected at all costs. But it is easy to lose one’s way.

Anyway, this got me thinking… what are some implicit main features of other products?

Uber: the fast ETA and ETD. ETA is how long the driver-partner takes to arrive at your location, and ETD is how long it takes to arrive at the rider’s chosen destination. If Uber wasn’t the fastest option, then riders would switch over to a faster competitor, and drivers would surely follow them.

Facebook / Instagram / WhatsApp / Snapchat: connection with your friends. If your friends aren’t on these platforms, then they aren’t much fun. However, the ability to follow celebrities on Facebook, Instagram, and Snapchat add single-player utility to the products.

YouTube / Twitch: information and entertainment from personalities that you love. Most of my friends don’t upload YouTube videos or Twitch streams for their friends, but instead, follow a small number of content creators.

Twitter: connection with like-minded people of varying influence. Since shortly after its launch, Twitter has been a network where it is easy to follow celebrities and other personalities. It’s harder to find your friends on the timeline if you happen to follow a bunch of celebrities.

Docker: write once, deploy everywhere. The two useful features of Docker are the easy ways they enable the packaging of software into runnable containers, and the ability to orchestrate the running of those containers over large deployments.

Google: the world’s information, and your personal information, accessible to you within seconds. This one is an easy pick because because Google has long described their mission as to, “organize the world’s information and make it universally accessible and useful.”

Amazon / Walmart: a store to buy, or subscribe to, everything. I’m looking for a better definition for this one, as I’m copying the idea from the Brad Stone book The Everything Store. But it’s too easy to say a business’s desire is to sell everything because many retailers could optimistically state that as their north star.

Turning Dropbox Paper notes into LaTeX

Lately, I have been obsessed with note-taking, and my new love is Dropbox Paper.

Among the regular features that you’d expect in a collaborative text editor include:

  1. Inline LaTeX rendering
  2. Source code highlighting
  3. Export to PDF, Microsoft Word, or Markdown

I’ve demonstrated some of the advantages of Dropbox Paper in this Dropbox Paper document here, but here I’ll summarize my workflow for turning Dropbox Paper notes into more professionally-typeset-looking documents.

Continue reading “Turning Dropbox Paper notes into LaTeX”