You can achieve better compression ratios resulting in significantly smaller file sizes by pre-compressing files as part of the deployment process. That’s because brotli compression can be somewhat resource intensive, so edge computing tends to dial back the amount of compression to compensate.

Loading a ‘Public Database’ Roam Research note takes 1.65 seconds and 5.59MB of assets.

Subsequent note loading is faster so it looks like the majority of the weight comes from downloading the application the first time.

Modern JS toolchains like npm and webpack optimize for ease of adding third-party libraries over keeping bundle size (and page bloat) small.

For example, using aws-sdk by default you end up including the entire library which is a few MB. There are numerous bugs in trying to import parts of the library despite claims of modularity. I needed to find the right tsconfig setting to import it in a certain way, then hack around a bug with importing the Lambda client which involved changing the Webpack configuration to resolve the util module. The default is bloat and requires large effort to reduce bundle size making it unlikely people will do it (convenience is king).

People tend to take the path that requires the least effort to satisfy a need or want. You can often predict people’s behavior by merely understanding the convenience of each option.

See also:

• Atomic Habits: you can improve the likelihood of forming a habit by making it easier to take an action (e.g. sleeping in your workout clothes so you don’t need to change to do a morning workout).

On it’s surface, AWS Lambda seems simple—it merely invokes a function with some arguments. However, the complexity is deceptively high. This is best highlighted when something goes wrong.

Debugging can’t be done remotely so you need to rely on logging, which you need to get from CloudWatch (which is clunky in it’s own way). If you don’t have a log line in just the right place you need to do a full deploy which includes zipping all files that are needed to execute the function—for Node, that includes the entirety of node_modules which, even for simple things, can be 10s of MBs.

You also need to contend with the async nature of Node. It’s easy to write your handler only to find that it runs, but doesn’t fully execute. Somewhere you are not awaiting a result and so an early return means the event loop is empty and the runtime thinks you are done. In one case, I could invoke the function locally and it worked just fine (using the serverless cli tool), but in Lambda it failed.

Finally, the arguments passed in (an event and a context object) are themselves opaque. If you invoke a Lambda from a specific context, it may or may not include some authentication information when using AWS Cognito. You need to keep all of these details in your head, most of which can only be discovered by runtime failures (which I already mentioned are clunky to debug).

The overall feedback loop is slow (slowness begets more slowness) and difficult to debug due to incidental complexity.

Throughout history, humans have shown incredible ability to acquire power (wealth, natural resources, technology, empires), but continually fail to turn it into increased happiness. For example, it’s unclear that modern humans are any happier than their nomadic ancestors from 10,000 years ago despite the clear progress in acquiring sources of power.

See also:

• Interview with Yuval Harari (author of Sapiens)

Modern websites are filled with javascript, assets, tracking, and third-party tracking. This makes websites slow and sluggish (bloat). This is partly due to developers not having the right mental models for how the size of requests impacts performance and taking for granted that modern network speeds and browsers are fast. By replacing kb (kilobytes) with lbs (pounds) when looking at request size you can better internalize the weight of the requests your website is serving.

Imagine delivering a package (some page request) to a user based on weight. 10 kb -> 10 lbs, no problem! 500 kb -> 500 lbs and that’s like trying to deliver two refrigerators.

See also:

• Use Lighthouse to measure website performance

A way of making concepts and abstractions easier to understand is to project them onto another dimension and scale. For example, the passage of time and what you can do with it is difficult to fully comprehend so a common projection is ‘time is money’. We understand money as a tangible asset and generally how much things cost (another projection is what you can buy with that money) which makes it easier to value time appropriately.

However, choosing the wrong dimension is a logical fallacy. For example, asking ‘how red is the temperature?’

A common rebuttal from police brutality apologists is that it is ‘just a few bad apples’ and therefore not all cops are bad. However, the complete saying is, ‘A few bad apples spoil the bunch.’ The toleration of the few undermines the integrity of the whole.

A metaphor for mindfulness, we can get caught up in the moment and swept up in our emotions and impulses (watching the movie), but if you can step back and recognize that it’s all light and shadow on a screen you can be reminded that everything arises in consciousness (looking at the screen).

Notes can be organized and structured into heterarchies (nodes with multiple relationships without a strict hierarchy) by creating an entry note that encompasses other notes (a note of notes). In Zettelkasten, this is referred to as a ‘structure note’. This has the advantage of late binding, you don’t need to worry about the hierarchy of information up front and multiple associations can be created using the same notes (which would not be possible without duplication in a strictly hierarchical system).

Heterarchies provide a layer of abstraction over the constituent notes which makes it easier to make connections between areas of thinking. For example, when creating a new note you could review a structure note’s contents to spark ideas for how it might be related without doing an O(n) search through every note in the collection to see if there are connections.

See also:

• Structure notes provide a place to “hang ideas off of”
• Zettelkasten is a mind map where nodes are notes

I’ve noticed that discussions on Zettelkasten forums and comment threads in HackerNews when a new Zettelkasten-like tool is shared are overly fixated on the tools and correctness of the process. Because there is an original source implementation (Niklas Luhmann), people judge the ‘purity’ of an implementation rather than focusing on the activity itself. This makes some intuitive sense, it’s hard to judge the effectiveness of a tool because note taking has compounding effects and most compounding benefits occur at the end so instead people judge in a more near-term way.

This tendency makes practitioners more administrative than creative. When all your time is focused on tending to your tools, workflows, and management of notes, there is less time to actually produce valuable work.

Below are some shapes of engineers I’ve managed in my career and what I’ve learned about them. Pattern matching based on experience is important in an experiential field like management.

See also:

• Performance management
• Engineering management

Lowering the interest rate has the effect of decreasing the risk for every asset class. This causes the expected return to go up and thus the value of the asset which leads to more buying of assets (for example getting a mortgage for fear of missing out) and greater optimism in the market (more risk taking). This is how the Fed tries to stimulate the economy.

However, this also makes it harder for lower risk investing (for example pension funds with a 5-7% target return), they will need.

Low rates make risk aversion harder to practice and risk taking more palatable.

See also:

• Coming into focus memo by Howard Marks

Prior to perfomance management calibrations, each manager writes a document that briefly summarizes the performance of each person they managed during the review period. The document needs to highlight specific projects and behaviors with examples to support a facts-based discussion (reduces bias) and reasoning behind the designation decision.

See also:

• Engineering management

A process for managers and senior leaders to discuss the performance across the organization with the goal of consistently and fairly applying expectations for all roles and levels. This helps to decrease the importance of individual’s personal judgment and biases—managers are more of an instrument of the performance process rather than the sole arbiter.

Calibration meetings are scheduled where managers and org leaders review all the performance snapshot packets for the organization and decide on final performance designations. The outcomes are reviewed by organizational leaders and the leadership team to spot check for consistency/fairness and review special cases (low performance, high performance, promotions). Sometimes follow-up information is needed to finalize the designation the manager will be asked to gather.

See also:

• Engineering management

Accumulated short-term compromises and hacks in a codebase that must be paid down over time. Side effects large amounts of tech debt include decreased velocity of making changes and frequent breakages. However, used well, tech debt can increase the velocity of a team and get more done in less time.

See also:

• Engineering management

High performing engineering teams continuously raise the bar for technical quality. Previous technical decisions are likely to not meet the current technical quality bar. Closing the gap between the two helps address tech debt and adopt a growth mindset about the team and codebase. All teams that are improving quality will notice the gap and that is to be expected. Failure to close that gap leads to more tech debt.

Read Managing technical quality from Lethain.

See also:

• Engineering management

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.

People are generally bad at thinking and making decisions about long-term consequences. Gate’s Law observes that people overestimate the short term and underestimate the long term. People are motivated by loss aversion which leads to status quo preserving behavior and biases people towards keeping things the same.

Individually, people find evidence for whichever mindset they have, reinforcing beliefs and making them more rigid. This makes it difficult to change the default behavior of thinking short-term. As groups, these effects are amplified—it’s even harder to think long-term when many people need to change their minds, especially if it involves the out-group (in-group favoritism).

Because long-term thinking is generally done poorly, people and businesses that operate on longer time horizons have a competitive advantage.

People find it more painful to lose something than to gain something equivalent. One interpretation is that people overvalue what they have because it is theirs. This leads to status quo preserving behavior.

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.