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:
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:
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:
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:
Trait
Behaviors
Lessons learned
Brilliant, unfocused
Extremely productive and helpful, spends time on the wrong thing and spreading their impact too wide
Reduce quantity of extracurricular activities, taking on tasks outside of the team should meet the ‘uniquely capable’ threshold
Unproductive, un-engaged
Has the skills, but not delivering enough impact
This is very difficult to recover, move them off to another team or manage out
High output, needs to be pointed at the right problem
Highest output on the team, but needs guidance on applying that raw output to be effective
Defining the right problem on their own can be difficult, identify the right altitude of problem for them to work on to unlock their abilities
Technically focused on a product team
Tends to raise the importance of building higher quality or new abstractions not taking into account the context of the product, market, or user
Set a decision framework for incremental code improvements, avoid rewrites, coach on the business needs and product thinking
Hard working, low skill
Works really late, always busy, but low output or low quality
Improve hiring bar, don’t overvalue hard work and avoid spending large amounts of time with low-performers
Learned helplessness, blames others or codebase often
Avoids accountability, low quality output or slow, very unhappy or pessimistic
Tends to be an environment mismatch, deliver strong and clear feedback and move quickly to manage out
Self-righteous, dogmatic, disruptive
Strong opinions tightly held, thinks everyone else is wrong or doing a bad job, teammates complain about code reviews
Coaching can work, but if there is any negative impact (e.g. people don’t like working with them) need to act very quickly or top performers will leave
Higher ownership, generalist
Tend to act as the founders would act, with a wide range of skill they are company builders
Nurture by giving stretch opportunities, encourage stepping out of role, build a better framework for measuring their success
Disagrees in private, disruptive to management
Talking to them everything is fine, even when addressing a disagreement, but shares resentment privately
Disruptive for the management team, can be difficult to address. Address directly, if there’s a pattern then move on
Low output, says all the right things
When given feedback they say all the right things, some immediate improvement made, but same issue recurs
Recurring low output feedback is a big red flag, especially for senior engineers
Highly skilled, entitled
Doesn’t feel fully utilized, complains about compensation, moves around a lot
Ask if they really want to be here, turn their feelings into a challenge and action
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:
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:
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:
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:
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:
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:
A formula for figuring out how much you should bet to maximize the outcome. Simplified formula: 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:O = (P * 2) - 1
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:
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:
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: