People prefer to keep things the same due to loss aversion and take actions to inhibit or minimize change. This can be seen in work environments where there is stark resistance to a change in the product (product work is hard because it necessitates change), processes, or organization.

The rise, and stagnation, of serverless computing could be interpreted as it was too hard (security, reliability, speed) and expensive to run your own server (configuring linux, wordpress/rails). With static websites and serverless compute APIs we get the speed, security, and price that are much more attractive, but it comes at the cost of being more complicated for interactivity (applications, auth, email list subscriptions, payments). You are then forced to patch together a hard to test and brittle series of tools to do more than host static pages such as AWS API Gateway + Lambda + SQS + SES.

See also:

• Why the Serverless Revolution Has Stalled

A formula for figuring out how much you should bet to maximize the outcome.

Simplified formula:

O = (P * 2) - 1

Where O is the optimal wager size, P is the probability to win a game that pays out 1:1 (even money payoff where you gain what you bet if you win).

For example, with a game that has a 60% chance to win with an even money payoff, the optimal wager as a percentage of available funds is (0.6 * 2) - 1, or 20% of available funds.

See also:

• What would be optimal to bet when the odds are unknown i.e. the Ellsberg paradox?
• Game theory

People are bad at understanding exponential growth. They over estimate short term results and under estimate long term results.

Full quote:

Most people overestimate what they can achieve in a year and underestimate what they can achieve in ten years.

Due to the nature of compounding interests growing exponentially over time, the immediate benefits of such an effect are small compared to the benefits at the end. This can make it hard to see how certain actions and behaviors lead to compounding because it can take a long time. It makes intuitive sense for things like money (people understand to contribute to a 401k for example), but requires more faith for actions like reading a lot. This explains why a lot of good advice is unlikely to be followed and example of Gate’s Law.

See also:

• Naval Ravikant talks about the importance of compounding interests in life and wealth creation.

Skepticism when building something new occurs in two ways 1) personally (worry of building something that is not good, failing) and 2) externally (others telling you your idea is bad or that your implementation sucks).

There are a few ways to overcome skepticism. Be slightly overconfident—you will think you have something better than you do. Surround yourself with people who are simultaneously encouraging and critical to get the right kind of feedback (also smart people working on hard problems tend to converge). Make incremental progress—starting with a hack lowers expectations. Finally, lead with curiosity—following idea to it’s conclusion because you are curious where it ends up.

Read Paul Graham’s essay on early work.

Former founder, lisp hacker, writer, who started Y Combinator. His views on startups and venture capital have heavily influenced the startup zeitgeist.

Essays:

• Revenge of the nerds
• Maker’s schedule, manager’s schedule
• Ramen profitable

We tend to judge early versions of work too harshly due to skepticism. This causes us to fail to push through the ugly early work of ambitious projects (or not try at all). By having a better understanding of what early work looks like we can push past skepticism from ourselves and those around us.

See also:

• Techniques for dealing with skepticism
• Paul Graham

Short form podcast episodes with a single idea or concept is like note blogging. For example, Naval Ravikant’s podcast often takes a recent tweet and expands on the context and concept behind it. He’s previously remarked that ‘he thinks out loud’ on Twitter and they serve as reminders so he can recall that information again later and notes clarify understanding. In that way it is not just beneficial to listeners, but also to himself.

Founder of AngelList and investor, Naval is known for his advice and philosophy on startups and life. His well known tweetstorm How to get rich without getting lucky is advice for accumulating wealth and thinking long term. While the tweets seem overly simplistic and feel like truisms, he provides more context and explanation in audio interviews on his podcast.

See also:

• Interview and transcript with Naval on his ‘how to get rich’ tweetstorm

Below is a list of JavasScript libraries that support markdown. Static content can be syntax highlighted using libraries with a much smaller footprint, but editing text with syntax highlighting takes significantly more code. I’ve attempted to make syntax highlighters into a simple editor, but quickly ran into issues with pre elements, cursor positioning, and cross-browser quirks of contenteditable.

For the initial stack for the Noteland web app, I need a library that is small and fast like prismjs, but with basic editing capabilities. There’s an opportunity for a focused markdown-only editor in the 10s of Kb range.

1. You won’t remember if you don’t write it down
2. You won’t write it down if it’s difficult to capture immediately
3. You won’t accumulate knowledge if you don’t consistently and frequently add to it
4. You won’t find value if you don’t reference it
5. Thinking out loud (I.e. publishing notes) applies social pressure to understand what you write and the right kind of self-filtering
6. Publishing amplifies the intrinsic feedback loop (signaling, friend catching)
7. 1:1 relationship of a note to an idea lowers friction to writing
8. Better notes leads to better work (writing essays, creative ideas, critical thinking)
9. Bi-directional linking creates flexible networks of ideas without difficult to plan hierarchy
10. Links are as valuable as the notes themselves

Arthur Schopenhauer describes the will-to-life as the inherent driving force behind all human beings to stay alive and reproduce. This gives rise to suffering. Examples include marriage where picking a partner based on compatibility is overridden by having the ideal offspring. In this, Schopenhauer was ahead of his time—describing evolution as ‘the composition of the next generation’.

Characteristics of a cult that include opposition of critical thought, self-doubt is encouraged, leaders have supreme knowledge who are not accountable to anyone, information is tightly controlled, members are isolated from former lives, zealous commitment, ostracizing members who leave, controlling what you eat or drink, exploitation (financial, sexual), and deception as a means of control.

German philosopher and pessimist, best known for ‘The World as Will and Representation’ where he describes the will-to-life as the overriding force that compels humans and leads to suffering. His work and philosophies have parallels with Buddhist teachings such as the rejection of the concept of self (ego) and the essence of suffering.

Below is a list of values and principles I keep in mind when developing Noteland:

• Last forever: notes you write should be able to live beyond Noteland. Similarly, the service should continue to exist even if I’m the only user because it is so valuable.

• Refreshingly fast: apps seem slower and less responsive then they did before, the experience should be a breath of fresh air to those that forgot how fast things should be.

• Easy to maintain: adding new features and maintaining a high bar for reliability should be easy for one engineer to run.

• Single player first: primary value should be to the note taker, any other values are secondary. For example, publishing is in service of the single-player–helping clarify thoughts and encourage growing one’s knowledge–not to encourage others to make backlinks (although that would be a positive second order effect).

This note does not have a description yet.

It’s easier to work on projects intermittently when a strongly typed programming language is used like Rust. That’s because becoming proficient in a codebase often entails holding the whole program in you head. Types provide mental shortcuts around the flow of data–you can skim the program by reading the static types to trace the flow of data and transformations (read the input arg types and return type) without needing to fully read or understand the contents of a method or function. In dynamic programming languages like Clojure you need to pay closer attention to what each step of the program does to anticipate what values are being used where.

My initial values and principles for developing Noteland helps to narrow down some guidelines for choosing a stack for the web app:

• It should be easy to maintain because I’m not working on it full time. I need to be able to jump in quickly, iterate, and fix bugs. Resolving bugs and adding new features should happen ‘refreshingly fast’.
• Visual feedback should be fast and support a quick iterative loop since it’s still experimental and will need frequent, small changes along the way. ‘Refreshingly fast’ extends to my own environment because speed is undervalued.
• The app should be very fast for users (e.g. initial download size, time to render, snappy interface), page reloads should feel nearly as fast as a single page application loading in-place, and Google Lighthouse measurements of website performance should be 100 for desktop and mobile.
• Rely on the web stack and have good support for a langua franca like markdown.

To try out different stacks, I’m building a prototype note editor that displays a full screen text editor with minimal syntax highlighting for GitHub flavored markdown and dev server that can do live reload.

Frontend

Stack 1: TypeScript and Webpack

My experience thus far has not been good. In a tweet, I mentioned the difficulty getting a simple hello world web app with typescript and css set up with webpack. In the end it worked, I can compile and live reload the page, but it takes over 8 seconds for a program with 10 lines of code (excluding imports). Webpack suffers from aiming to be so powerful and generic it is a platform which does just about nothing. From my beginner eyes, Webpack merely organizes a myriad plugins and extensions to execute in an unknown sequence–which feels like a hulking mess with bad performance on page load and development feedback loop.

This commit implements the prototype in Typescript and Webpack.

Update: I was able to get the reload speed down to 3 seconds and the production bundle down to ~300 kb by setting the development and production flags in Webpack config. There’s seems to be more options for tree shaking, so it’s an acceptable page weight for now.

Stack 2: Vanilla js

What if we could ditch all the machinery used by modern js? I could drastically reduce the amount of js code that would need to be shipped to the client by using contenteditable (introduced in HTML5) which forms a psuedo text editor that is supported directly by most browsers. There’s some notable quirks between browser implementations, but it would support syntax highlighting too (or even wysiwyg rendering). Live reloading is fast and easy because there is nothing to compile.

Stack 3: Vanilla js + wasm

Markdown rendering in webassembly is faster than JavaScript and nearly the same weight as a comparable js dependency. Using the pre tag with contenteditable creates a live rendering while typing similar to Dropbox Paper. It might even be good enough to skip a build step server side when publishing a new note.

Backend

S3

In some ways S3 is ideal—the frontend can make requests directly securely using AWS Cognito, no setup to start storing documents, and plays nicely with AWS Lambda for doing things like generating the published version of notes.

On the other hand, reading data out is too constrained. Implementing a list of notes, for example, would require making a call to list keys and then fetching each object. Because keys are stored in chronological order that could require multiple calls to list keys to get a recent time range. All together, this would introduce a large amount of latency without additional caching or storing data on the client. It might be possible to keep an index file with the keys and titles up-to-date manually.

S3 with client-side offline storage

localstorage has a limit of 5MB per domain, which won’t be enough for large note sets. IndexedDB can store considerably more, ~500MB per domain. There is a new Storage API that attempts to abstract over the various local storage backends, but it’s not fully supported by all browsers (notably Microsoft Edge).

Storing more locally has the added advantage of being fast and the ability to work offline (or install as a PWA).

S3 + RDS as an index

You can set up a Lambda hook to update an index stored in a database. Then you could query the DB when you need an index. Based on the pricing model (writes, reads, storage), it should be cheap to run just an indexing service. However, if we’re going to have a database, you could simplify everything by just storing all the notes in a database too and cut out the middle man (S3).

S3 + Algolia

Eventually full text search will be needed of both note titles and contents. An event would be triggered whenever an S3 object is created/updated/deleted so we could index the document in Algolia and make it available for search. There is a free tier that should be good enough for an MVP.

AWS Aurora

It seems likely that a full database will be needed eventually, so what if we jumped right to it? We could still keep it serverless (low cost) by using something like AWS Aurora which can auto-scale and turn on only when needed. However, there is a 5-30 second cold start time depending on what blog post you read. The recommendations around it are to… keep a single instance running at all times which is expensive and defeats the purpose.

There’s a lot of other neat tools which might be useful in the future like AWS App Sync (graphql, offline sync). For now though, it adds too much complexity for such a simple app.

Postgres

Similar to the argument above, if we can’t actually get away without having a DB, and Aurora isn’t acceptable serverless due to cold starts, we could go back to ol' reliable Postgres running a full time instance on AWS RDS.

The downside is that this ends up looking like a more typical centralized CRUD app which goes against the ‘last forever’ part of the principles of Noteland since data is no longer files that have a 1:1 relationship with what shows up when publishing and the user wouldn’t have any other options for how they store the data.

Git

This is an intriguing option because the user would more or less own the storage layer and Noteland would operate as a client and publisher. Git can inter-operate on many platforms and open up many different workflows (such as my current note taking workflow). If a user doesn’t want to add their own git repo, one could be created for them and operate transparently.

You can use CSS vars to create responsive layouts. One technique called css-media-vars (repo) is a sort of mixin for CSS selectors that have the effect of named breakpoints analogous to a media query, but with much less boilerplate.

See also:

• Discussion on HN about whether this is using or abusing CSS vars
• Demo of the technique in an example web page

A philosopher from the age of enlightenment, Kant is best known for writings about morality and the categorical imperative. He observed the need to replace religion as the source of morality with rationality.

Immanual Kant, in his book Groundwork of the Metaphysic of Morals, argues for a universal imperative that we should treat people as the ends rather than the means. A similar Christian teaching is ‘do unto others as you would have them do unto you’.

The media tends to focus on the amount of lying that President Trump does–you can often find headlines that quantify it to some large number. The Trump paradox is not that he lies frequently (to some extent all politicians will lie), but that he says the truth about things that are obviously bad or embarrassing for him. This ‘saying the quiet part out loud’ and immunity to repercussions is the real horror.

See also:

• Interview with Slavoj Žižek by Dr. Robert Eikmeyer

From Hegel’s Dialectics, an object that is what it is not. Slavoj Žižek describes the concept in a joke, a person goes to a coffee stand and asks for coffee without milk. The barista says, “Sorry, we only have coffee without cream”. In reality, both are the same coffee, but they are also different because of what they are lacking (coffee, cream).