D3 is not a visualization library as it is described, but an API to svg and canvas elements. In order to create visualizations, one must set all of the svg objects and attributes in a pipeline of operations managed by D3. This allows the user to script over it much easier to create complicated visualizations, but I would describe the API as low-level.

Antikythera Mechanism is a mechanical model of the positions of celestial bodies. What’s remarkable is the complexity of the device and it’s ability to predict astronomical events—it’s essentially a very old analog computer.

It was built around 100 BC and re-discovered in 1901. Fragments were missing, which made reconstruction difficult. The back was recreated, but the front gears held significantly fewer clues. A recent paper published in Nature reveals an accurate recreation.

See also:

• The Antikythera Mechanism is an example of a deep time model, capable of showing future events that would be difficult to conceive.

Vega is a high level charting and visualization library that uses a declarative grammar (a data structure) that is translated into a D3 rendered chart.

See also:

• It’s a very data-oriented API similar to how you might build things with Clojure. The advantage is using functions to transform the data (grammar).

We tend to think of supply and demand as curves that companies neatly fit into and move proportionally. However, post-Keynesianism economics shows that effective demand is a better way to understand how supply and demand works in reality.

For example, supply can be constrained (e.g. by labor to make the product) and excess demand spills over elsewhere (e.g. maybe they buy something else). Similarly, when demand is in deficit (i.e. less than supply) it causes companies to lay people off resulting in unemployment which decreases demand in other markets.

See also:

• 4.3 million people quit their job in August 2021

In the early days of a pre-product startup there is little to measure. There’s no sales, there’s no product KPIs, no press releases, and so on.

A good indicator at this stage is product and hiring velocity. How quickly is the product being made into something valuable for customers and how fast is the team growing. It’s a simple heuristic, but potentially useful—without one or the other, there’s a problem (e.g. hiring without product could mean papering over a bad product, slow hiring indicates poor scalability and attracting talent).

Read the blog post

See also:

• Slowness begets more slowness
• Speed is undervalued

An expression for Bayesian thinking where you think in ranges of outcomes based on prior information. When new information arrives, to get a more accurate range of solutions you ‘update your priors’.

See also:

• Rigorously updating priors can prevent path dependence and reduce priming and implicit bias
• Product work is a pursuit of facts about the user, market, and their problems, as the facts, user or market changes so should the product.

The likelihood that something will continue to be done the same way it was done from the outset. This can be readily observed in technology. For instance, the width of train rails is the width of a horse pulled cart (or “two horses asses”) and led to the width of rockets on the space shuttle being set to a size not based on what is optimal, but based on what can be transported via train.

See also:

• The significance of persistence in predicting economic outcomes
• Update your priors and Bayesian thinking could counteract this somewhat

Scientific research can sometimes suffer from a form of path dependence where a single study can be cited repeatedly for many years even when it is found out to be incorrect. For example, in 2015 a literature review found that 900 peer-reviewed studies used a cell line derived from a breast cancer patient in 1976 that was found to actually be skin cancer. For eight years (and maybe more) studies kept citing it even though it was incorrect.

See also:

• The Unstoppable Momentum of Outdated Science (what this note is derived from)
• Is this another side of convenience is king? Scientists are people too and it’s easier to cite a source that’s previously cited rather than re-check the findings.

Common advice from the YC crowd (Paul Graham et al) is to build an initial product that a small group of users love. You’ll know that they love it because they tell all of their friends. The logic goes, unless you have built something someone loves, you will eventually fail.

From Startup Playbook by Sam Altman

A form of music characterized by being made using tracker software such as the original Ultimate Soundtracker on Amiga or more modern Renoise. In a tracker, notes are laid out vertically with each column as a track and using letters/numbers to represent a note and parameters. Each point in time is a discrete row so playback continuously scrolls vertically.

See also:

• A distant cousin of this approach to music sequencing is a programmable music environment

Counter to the common advice given by people in Silicon Valley (Paul Graham ‘Startup Mistakes’ for instance), solo founders are more likely to build companies that survive and generate more revenue than multiple founders.

This is thought to be because of the lack of co-founder drama (a leading cause of premature startup death) and fast, consolidated decisions making.

The study referenced here used Kickstarter funded companies to draw these conclusions, but similar insights can be found in Crunchbase data (more than half of startups that had a single founder).

A large amount of the cost (time) of maintaining code is keeping up with breaking changes and incompatability. This is multiplied by the entire ecosystem of developers and libraries.

If compatibility were better understood and library and platform authors made compatibility a higher priority goal the result would be a massive amount of leverage from the time previously spent on this kind of maintenance burden.

See also:

• Lockfiles let you deal with breaking changes on your own terms
• The fundamental theorem of software engineering might indicate that we are over abstracting or that we need another layer of abstraction to deal with compatibility (often the case!)

California passed legislation that makes it significantly harder to classify workers as independent contractors. The ‘ABC’ test is used to determine whether someone meets the exception that they are an independent contractor. This test is significantly stricter and has led to companies going under as a result of misclassification lawsuits.

More States are following California’s lead—New York and New Jersey are considering similar legislation.

See also:

• Back office

A theoretical tool that checks a piece of business writing against a set of rules from The Minto Pyramid Principle. Like a code linter, this would serve as a ratchet for improving the output of others—in this case, those sharing business writing like strategy memos, 1 pagers, and project briefs.

See also:

• This is an example of an ‘organizational linter’

We tend to put off happiness—only once this problem is solved or this goal is achieved will I be happy. There will always be more problems to solve and achieving a goal is yields temporary contentment before we find something new to want. Because we spend most of our time in the journey, the quality of our mind is essential to being happy now and in the majority of moments in life.

See also:

• Mindfulness is the practice of doing just that—improving the quality of your mind
• This comes from Sam Harris in the Waking Up app

Carveth Reed, a British logician and philosopher is attributed with the quote, “It is better to be vaguely right than exactly wrong” (sometimes attributed to the economist John Maynard Keynes). This is a useful idiom for a number of problems where information is limited or lacking precision.

For example, in growth investing much of the value of a tech company is in future potential rather than something concrete like historical performance of revenue. It’s not possible to accurately predict the future and so valuations are imprecise. But in this case it’s better to be vaguely right than to try to precisely analyze and be wrong.

See also:

• This sentiment is like a Kalman filter where you still need to do something with imprecise information

Charlie Munger’s first rule of compounding is to never interrupt it unnecessarily. Because of the way compounding works over time, to prematurely interrupt it (e.g. selling your shares or stopping to contribute) will forgo the largest upside—most compounding interest benefits occur at the end.

See also:

• Naval Ravikant talks about things that compound over time extensively

Since gains from bond trading are capped by the yield at maturity, but only returns if the bond pays out, the value generated is not from what you buy but what you exclude—avoiding bonds that don’t pay out i.e. the losses you don’t take.

This is a kind of determinate negation, bond management is defined by what it is not.

This note does not have a description yet.

See also:

• Web3

The internet brought digital abundance—content and media can be freely consumed at massive scale. The blockchain provides digital scarcity using mathematics to prove uniqueness. NFTs built on top of blockchain can be applied to digital art to transfer ownership as a token (in whole, non-fungible) to another party. By proving ownership and that there is only one owner, digital art can be valued higher with these guarantees.

While the application is novel, it’s unclear that the technology led to a digital art boom or merely the centralization of digital artists into marketplaces like SuperRare. It also seems to feature heavily in any kind of distributed metaverse with marketplaces for digital goods.

To get the COVID-19 vaccine approved quickly, companies focused on proving the efficacy. They did not run trials to find the optimal dosage or storage to maximize public health. For example, delaying the second dose, fractional dosing, removing freezer temperature requirements are all ways of increasing the distribution and reaching herd immunity faster.

Read the article

It’s difficult to start with microservices because that requires knowing more about the domain and boundaries within the domain that one could know up front. Due to lack of understanding, a microservices-first architecture often fails and it’s easier to start with a monolith and slowly peel away services.

In my own experience, I’ve found this to be largely true. You don’t yet know the right abstractions, even if it’s a familiar problem.

See also:

• Software architectural pattern
• Integrating between AWS services adds incidental complexity is a corollary and this occurs even with using a small number of services.

Notion is a popular wiki that I started using more seriously recently. Looking at Notion through the lens a text editor (the predominant way users create content) reveals a number of quirks.

• Keyboard shortcuts are inconsistent. For example, typing `ctrl-p` might move the cursor one line down or all the way to the bottom of the page.
• Tables are difficult to manage. You can’t create or fillout the table entirely using the keyboard and there are multiple modes when clicking cells (open linked page, edit) that don’t behave the same as editing other text blocks (e.g. editing external links in a cell is difficult).
• Inserting a link works differently if it’s an internal page or an external link. Relatedly, markdown link syntax doesn’t work.
• Creating a markdown checklist requires using the `[]` with no spaces which I think is unique to Notion (I might be wrong)
• There’s no such thing as normal tables, just ‘databases’

See also:

• Plain text files are a universal storage medium, Notion greatly extends plain text which hurts it’s portability
• UX (user experience)