+8 -8

Blockchain.md

reviewed

··· 2 2 3 3 - [A blockchain is a decentralized database](https://www.youtube.com/watch?v=bBC-nXj3Ng4). 4 4 - Blockchain solve the Byzantine Generals Problem: [How do participants in a decentralized network communicate and coordinate with each other towards some action without relying on a trusted third-party?](https://a16z.com/2019/11/08/crypto-glossary/). 5 5 - - Blockchains are "trustless". There are mechanisms in place by which all parties in the [[Systems |system]] can reach a consensus on what the canonical truth is. 6 6 - - Power and trust is distributed (or shared) among the network's stakeholders (e.g. developers, miners, and consumers), rather than concentrated in a single individual or entity (e.g. banks, governments, and financial institutions). 7 7 - - Blockchains put the code in charge. 8 8 - - Blockchains allow permisionless innovation. 5 5 + - Blockchains are "trustless". There are mechanisms in place by which all parties in the [[Systems |system]] can reach a consensus on what the canonical truth is. 6 6 + - Power and trust is distributed (or shared) among the network's stakeholders (e.g. developers, miners, and consumers), rather than concentrated in a single individual or entity (e.g. banks, governments, and financial institutions). 7 7 + - Blockchains put the code in charge. 8 8 + - Blockchains allow permisionless innovation. 9 9 - Blockchains is useful when these conditions are met: 10 10 - - The resource is scarce (limited). 11 11 - - Fungible (there isn't a difference between two items. eg. storing files). All the coins are mutually interchangeable. 12 12 - - The resource can be provided by a lot of people. 10 10 + - The resource is scarce (limited). 11 11 + - Fungible (there isn't a difference between two items. eg. storing files). All the coins are mutually interchangeable. 12 12 + - The resource can be provided by a lot of people. 13 13 - Smart contracts can be defined as code that's replicated and executed on all the blockchain nodes. 14 14 - - Smart contracts allow permissionless composability. [Composability allows anyone in a network to take existing programs and adapt or build on top of them, it unlocks completely new use cases that don’t exist in our world](https://future.a16z.com/how-composability-unlocks-crypto-and-everything-else/). 14 14 + - Smart contracts allow permissionless composability. [Composability allows anyone in a network to take existing programs and adapt or build on top of them, it unlocks completely new use cases that don't exist in our world](https://future.a16z.com/how-composability-unlocks-crypto-and-everything-else/). 15 15 - [Blockchains could replace networks with markets](https://twitter.com/naval/status/877467629308395521). 16 16 - One of the main downsides of blockchains is that most humans are not good at protecting their passwords, credentials or private keys. 17 17 - Blockchains can be used to ensure the best output in prisoner dilemma style interactions. Write a smart contract that does X when everyone has added the money and no one will be able to betray.

+3 -3

COVID-19.md

reviewed

··· 11 11 - [Justified Practical Advice](https://www.lesswrong.com/posts/LwcKYR8bykM6vDHyo/coronavirus-justified-practical-advice-thread) and [What should we do once infected with COVID-19](https://www.lesswrong.com/posts/F3q7eL7pdQqhWFTYh/what-should-we-do-once-infected-with-covid-19#NR3wH8DxZX2eBBvG7) are useful once infected. 12 12 - [COVID-19 Resources for the Elderly and Families](https://nanha.org/2020/09/17/covid-19-resources-for-the-elderly-and-families/). 13 13 - [Distant Socializing, during Physical Distancing](https://github.com/Pezmc/distant-socializing/blob/master/README.md) - Suggested distant socializing tools, games and activities to help keep in touch with family, friends and loved ones during social distancing and the coronavirus (COVID-19) pandemic. 14 14 - - There are lots of [[Social Games]] out there! 15 15 - - [Activity List](https://www.reddit.com/r/nosurf/wiki/activities). 16 16 - - [40 meaningful things to do when stuck at home in a pandemic](https://www.clearerthinking.org/post/2020/03/19/40-meaningful-things-to-do-when-stuck-at-home-in-a-pandemic). 14 14 + - There are lots of [[Social Games]] out there! 15 15 + - [Activity List](https://www.reddit.com/r/nosurf/wiki/activities). 16 16 + - [40 meaningful things to do when stuck at home in a pandemic](https://www.clearerthinking.org/post/2020/03/19/40-meaningful-things-to-do-when-stuck-at-home-in-a-pandemic). 17 17 - [How to have a happy quarantine](https://www.lesswrong.com/posts/eeZQunErdm6oWyhTy/how-to-have-a-happy-quarantine).

+12

Cooperatives.md

reviewed

··· 1 1 + # Cooperatives 2 2 + 3 3 + - A cooperative is an autonomous association of persons united voluntarily to meet their common economic, social and cultural needs and aspirations through a jointly- owned and democratically- controlled enterprise. 4 4 + 5 5 + ## Resources 6 6 + 7 7 + - [Tech coop resources](https://tech-coops.xyz/#resources). 8 8 + - [Tech coop list](https://tech-coops.xyz/#coops). 9 9 + - [Coophub](https://coophub.io/). 10 10 + - [Hypha](https://github.com/hyphacoop). 11 11 + - [Catalyst](https://github.com/catalyst-cooperative). 12 12 + - [DisCO.coop](https://linktr.ee/DisCO.coop).

-8

Coordination.md

reviewed

··· 30 30 - Graduated sanctions for those who violate community rules. 31 31 - Cheap, accessible means of conflict resolution. 32 32 - Self-determination. 33 33 - 34 34 - [Teamwork]: Teamwork.md "Teamwork" 35 35 - [Cooperatives]: Cooperatives.md "Cooperatives" 36 36 - [Decentralized Autonomous Organizations]: <Decentralized Autonomous Organizations.md> "Decentralized Autonomous Organizations" 37 37 - [Teamwork|groups of actors to work together]: Teamwork.md "Teamwork" 38 38 - [organizations]: Organizations.md "Organizations" 39 39 - [Governance]: Governance.md "Governance" 40 40 - [processes]: Processes.md "Processes"

+4 -4

Curiosity.md

reviewed

··· 6 6 - Knowledge is a powerful tool. The more you [feel like a noob](http://paulgraham.com/noob.html), the better. Feeling stupid now is better than feeling stupid in 10 years. 7 7 - [Reality has a surprising amount of detail](http://johnsalvatier.org/blog/2017/reality-has-a-surprising-amount-of-detail). Knowing more about the world makes you enjoy it more. [Understanding how music is made increases the pleasure you get from music](https://youtu.be/JbVfcZxfIZo). 8 8 - Do stuff! Whatever is you work on, is worthwhile as long as you share your learnings. In the worst case, if your [[ideas]] don't work out, the community will learn why that approach doesn't make sense. 9 9 - - Remix ideas. Ideas are impacted by [[evolution]]. The most useful ones survive and evolve. [Innovation is product of the combinations of ideas](https://youtu.be/XUAIIQFoufs). 10 10 - - Fail early and often. There is only one guaranteed way you'll won't get something you want, and that's not to pursue it. [Mistakes](https://meta.wikimedia.org/wiki/So_you%27ve_made_a_mistake_and_it%27s_public...) are the portals of discovery. 11 11 - - [If you think you're going to regret not doing something, you should probably do it](https://blog.samaltman.com/the-days-are-long-but-the-decades-are-short). Most people regret far more things they didn't do than things they did do. 9 9 + - Remix ideas. Ideas are impacted by [[evolution]]. The most useful ones survive and evolve. [Innovation is product of the combinations of ideas](https://youtu.be/XUAIIQFoufs). 10 10 + - Fail early and often. There is only one guaranteed way you'll won't get something you want, and that's not to pursue it. [Mistakes](https://meta.wikimedia.org/wiki/So_you%27ve_made_a_mistake_and_it%27s_public...) are the portals of discovery. 11 11 + - [If you think you're going to regret not doing something, you should probably do it](https://blog.samaltman.com/the-days-are-long-but-the-decades-are-short). Most people regret far more things they didn't do than things they did do. 12 12 - [Find your way around the inertia of helpless mentality](https://www.youtube.com/watch?v=YMPzDiraNnA). You probably have control of more things that you think! Knowing this fact changes the way you see your circle of control. 13 13 - - [Practice hunting for bugs](https://radimentary.wordpress.com/2018/01/29/hammertime-day-1-bug-hunt/?utm_source=pocket_mylist)! A bug is anything in life that needs improvement. Even if something is going well, if you can imagine it going better, there’s a bug. 13 13 + - [Practice hunting for bugs](https://radimentary.wordpress.com/2018/01/29/hammertime-day-1-bug-hunt/?utm_source=pocket_mylist)! A bug is anything in life that needs improvement. Even if something is going well, if you can imagine it going better, there's a bug.

+34 -34

Data/Dashboards.md

reviewed

··· 5 5 ## Best Practices 6 6 7 7 - [Before you dive into how to build a dashboard, the first thing you should ask yourself is whether this is the right tool for your situation.](https://shopify.engineering/make-dashboards-using-product-thinking-approach) Understand your problem and your audience; design a dashboard that does one thing really well, for a clear set of users. 8 8 - - Answer three specific questions: [How, What, How](https://youtu.be/g2-dkJkZjiI)? 8 8 + - Answer three specific questions: [How, What, How](https://youtu.be/g2-dkJkZjiI)? 9 9 - Strive to create dashboards that are either standalone or include links to provide the relevant context. Without meaning, data is just digits. 10 10 - [Add all the possible context into the dashboard](https://www.youtube.com/watch?v=Kub2bXrKmOE): 11 11 - - Instructions. 12 12 - - Purpose and explanation of the data being shown. 13 13 - - Caveats and assumptions. 14 14 - - Extra Context: 15 15 - - Why this dashboard exists. 16 16 - - Who it’s for. 17 17 - - When it was built, and if and when it’s set to expire . 18 18 - - What features it’s tracking via links to team repositories, project briefs, screenshots, or video walkthroughs. 19 19 - - Take Aways. 20 20 - - Metadata (owner, related OKRs, TTL, …). 11 11 + - Instructions. 12 12 + - Purpose and explanation of the data being shown. 13 13 + - Caveats and assumptions. 14 14 + - Extra Context: 15 15 + - Why this dashboard exists. 16 16 + - Who it's for. 17 17 + - When it was built, and if and when it's set to expire . 18 18 + - What features it's tracking via links to team repositories, project briefs, screenshots, or video walkthroughs. 19 19 + - Take Aways. 20 20 + - Metadata (owner, related OKRs, TTL, …). 21 21 - Make them so its easy to go one layer down (X went down in Y location, or for Z new users, etc). 22 22 - Recreate dashboard from first principles periodically. 23 23 - When plotting a rate, add the top of funnel and bottom of funnel numbers to make sure things are as expected. ··· 29 29 The value is that now discussions are happening about the data. 30 30 31 31 - Self-serve Analytics is a tricky balance: 32 32 - - The more questions people can theoretically self-serve, the fewer they can practically self-serve. The complexity of the stack grows with each option that gets added to give more flexibility. 33 33 - - In the other hand, people will self serve anyways. Control and clean the environment so they don’t have to rely on odd methods to get the probably wrong data. The people that can write SQL are not usually the same people that need the data. 32 32 + - The more questions people can theoretically self-serve, the fewer they can practically self-serve. The complexity of the stack grows with each option that gets added to give more flexibility. 33 33 + - In the other hand, people will self serve anyways. Control and clean the environment so they don't have to rely on odd methods to get the probably wrong data. The people that can write SQL are not usually the same people that need the data. 34 34 35 35 ## Issues with Dashboards 36 36 37 37 - Dashboards were created to monitor and not to derive insights. 38 38 - - Dashboards report on current status. Users don’t act on status. They act on change in status. 39 39 - - Dashboards (lines and rectangles) are useful to notice if something goes wrong. 40 40 - - **It's usually not possible to generate meaningful insight simply by looking at line charts in a dashboard** A chart alone cannot possibly convey everything, and that kind of thinking inhibits our ability to influence the business with our work. 41 41 - - Specially, if [there are 10 unrelated charts in the same dashboard](https://www.deathofdashboards.com/). 38 38 + - Dashboards report on current status. Users don't act on status. They act on change in status. 39 39 + - Dashboards (lines and rectangles) are useful to notice if something goes wrong. 40 40 + - **It's usually not possible to generate meaningful insight simply by looking at line charts in a dashboard** A chart alone cannot possibly convey everything, and that kind of thinking inhibits our ability to influence the business with our work. 41 41 + - Specially, if [there are 10 unrelated charts in the same dashboard](https://www.deathofdashboards.com/). 42 42 - Building a dashboard requires gathering lot of context. Once built, only a few users aware of all the context can really use it in the proper way. 43 43 - Dashboards shouldn't be single-use 44 44 - - Ask this: 45 45 - - Can this new dashboard request be added into an existing one? 46 46 - - What are you going to do differently by looking at the Dashboard? Focus on that [[Metrics |metric]] and add it to the main Dashboard 47 47 - - Beware of the death by 1,000 filters: After a dashboard had gone live, you'll be flooded with requests for new views, filters, fields, pages, everything 48 48 - - Dashboards are decision-making infrastructure, and infrastructure needs to be maintained. Be explicit about which Dashboards are disposable and add a TTL to them. 49 49 - - The numbers and charts on a dashboard very rarely have any direct personal meaning to the people using it. There’s tons of other work to do, and unless that dashboard is directly tied to your performance or compensation, there are probably more important things to look at. People are more likely to check stock prices when they actually own (and thus benefit from) the stock. 44 44 + - Ask this: 45 45 + - Can this new dashboard request be added into an existing one? 46 46 + - What are you going to do differently by looking at the Dashboard? Focus on that [[Metrics |metric]] and add it to the main Dashboard 47 47 + - Beware of the death by 1,000 filters: After a dashboard had gone live, you'll be flooded with requests for new views, filters, fields, pages, everything 48 48 + - Dashboards are decision-making infrastructure, and infrastructure needs to be maintained. Be explicit about which Dashboards are disposable and add a TTL to them. 49 49 + - The numbers and charts on a dashboard very rarely have any direct personal meaning to the people using it. There's tons of other work to do, and unless that dashboard is directly tied to your performance or compensation, there are probably more important things to look at. People are more likely to check stock prices when they actually own (and thus benefit from) the stock. 50 50 - While democratization of data is certainly an awesome thing, pure democracy is anarchy (poorly curated and contextualized data shared through a bunch of channels). 51 51 - - Poor curation leads to confusion (which dashboard do I use), distrust (dashboards are wrong) and waste (unused content, unnecessary maintenance). 51 51 + - Poor curation leads to confusion (which dashboard do I use), distrust (dashboards are wrong) and waste (unused content, unnecessary maintenance). 52 52 - If you make data scientist do reporting and dashboards all day all the good ones will quit and the ones left will be mediocre at best ([1](https://twitter.com/sethrosen/status/1306605742452076548), [2](https://twitter.com/sethrosen/status/1383148819441913857), [3](https://greatexpectations.io/blog/one-more-stratification/)). 53 53 - [Some of the problems of dashboards](https://twitter.com/EmilyGorcenski/status/1397066345947308034): 54 54 - - They’re hard to version control. 55 55 - - They’re hard to test. 56 56 - - They let you hide code. 57 57 - - That hidden code becomes de-facto business logic. 58 58 - - They are a terminator in an [[automation]] chain 59 59 - - Dashboards represent an endpoint in an automated workflow. Which means they create an open-loop system. It’s very hard to link the dashboard that was observed to the decisions, and therefore the effect of those decisions, taken based on what was observed. 54 54 + - They're hard to version control. 55 55 + - They're hard to test. 56 56 + - They let you hide code. 57 57 + - That hidden code becomes de-facto business logic. 58 58 + - They are a terminator in an [[automation]] chain 59 59 + - Dashboards represent an endpoint in an automated workflow. Which means they create an open-loop system. It's very hard to link the dashboard that was observed to the decisions, and therefore the effect of those decisions, taken based on what was observed. 60 60 - Dashboards enable managers to look at data and make decisions. There are a lot of assumptions here: 61 61 - - That sufficient context is presented with the data. 62 62 - - That the data is correct. 63 63 - - That the transformation logic is correct. 64 64 - - That the data is complete. 61 61 + - That sufficient context is presented with the data. 62 62 + - That the data is correct. 63 63 + - That the transformation logic is correct. 64 64 + - That the data is complete.

+7 -7

Data/Data Request Template.md

reviewed

··· 15 15 - What kind of deliverable would be most helpful for your request? 16 16 - Will you need this data again in the future? 17 17 - Which stats is this going to change or which action will be taken based on this data and by whom? 18 18 - - How can we measure our progress/success for each step? 19 19 - - What happens if we don’t hit the target? 20 20 - - What is the real problem you’re trying to solve? 18 18 + - How can we measure our progress/success for each step? 19 19 + - What happens if we don't hit the target? 20 20 + - What is the real problem you're trying to solve? 21 21 - Frame the (initially vague) data questions this way: [How does _lever_ impact _KPI_?](https://www.narrator.ai/blog/how-i-frame-data-questions-to-make-analyses-more-useful/) 22 22 - What is the business question you're trying to answer? 23 23 - What decision will you make or action will you take with this data? 24 24 - **Request Description** 25 25 - Do you know where is the related data? 26 26 - Can this analysis be done in our current BI tools? 27 27 - - If yes, do you have a starting link? 28 28 - - If no, can [[Reverse ETL]] help? 27 27 + - If yes, do you have a starting link? 28 28 + - If no, can [[Reverse ETL]] help? 29 29 - Which is more important? 30 30 - - Getting the answer quickly 31 31 - - Getting an accurate answer 30 30 + - Getting the answer quickly 31 31 + - Getting an accurate answer 32 32 - Any gotchas we should know about? 33 33 - What is the priority for this request? _Optional_ 34 34 - Who will see this deliverable?

+25 -18

Data/Metrics.md

reviewed

··· 3 3 ![[Quotes#^a5049d]] 4 4 5 5 - There should probably be a single "North Star Metric" with 3-5 additional supporting metrics. You may also want to consider counter-metrics (or pairing metrics) that keep you from [over-rotating on a singular metric](https://www.dataliftoff.com/wp-content/uploads/2022/10/tennis_balls-1536x2048.jpeg). 6 6 - - [Design **north star metrics that capture value to the customer** rather than value to your organization](https://roundup.getdbt.com/p/the-perfect-north-star-metric). 6 6 + - [Design **north star metrics that capture value to the customer** rather than value to your organization](https://roundup.getdbt.com/p/the-perfect-north-star-metric). 7 7 - Metrics should use the SMART framework (Specific, Measurable, Achievable, Results-Oriented, Targeted). 8 8 - - Pick the simplest metric that works for you. Metrics definitions should be as easy as a tool-tip away to find. 8 8 + - Pick the simplest metric that works for you. Metrics definitions should be as easy as a tool-tip away to find. 9 9 - [Metrics are a tool, but not the destination](https://breakingpoint.substack.com/p/you-have-too-many-metrics)! You want to use the fewest metrics possible to cover all the fundamentals of your business. 10 10 - Common understanding of a metric matters more than the metric precision. That understanding requires some standardization (names, time spans, ...) and that needs [[Coordination]]. 11 11 - - Teams need to cooperate when defining metrics. 11 11 + - Teams need to cooperate when defining metrics. 12 12 - Organizations need three things related to metrics: 13 13 - 1. A [[Metrics |process for defining metrics]]. 14 14 - 2. A single source of truth for the metrics. 15 15 - 3. A way to get metrics to all systems. 13 13 + 14 14 + 1. A [[Metrics |process for defining metrics]]. 15 15 + 2. A single source of truth for the metrics. 16 16 + 3. A way to get metrics to all systems. 17 17 + 16 18 - Product metrics allow measuring product progress and creating alignment in an outcome-oriented way. There are many product frameworks available to help us think about the right key things to track. Think about **[product metrics that matter](https://uxdesign.cc/product-metrics-that-matter-951b9e4d4eca)** for you. 17 19 - Push a culture of metrics and goals as a source of learning, not promotions or success delegation. 18 18 - - Your job isn’t to measure things. Your job is to change the product for the better — to create value for the customers in a viable way for the business. 20 20 + - Your job isn't to measure things. Your job is to change the product for the better — to create value for the customers in a viable way for the business. 19 21 20 22 ## Good Metric Checklist 21 23 22 24 - **Specific and sensitive**: Metrics should be specific to the product or feature, and need to be explicitly and quantitatively defined. The metric should also be sensitive enough to measure the impact we expect to see. 23 23 - - **Robust**: To complement the **sensitivity** criteria above, we also need to make sure the metric is measuring only the effect of the product of interest, and that it is not reactive to things we expect to change but don’t control. Related to [internal validity](https://en.wikipedia.org/wiki/Internal_validity), we should try to avoid using a metric that can be significantly influenced by anything other than the product/feature we care about. 24 24 - - **Measurable**: A metric must be something that we can actually measure. It’s not uncommon to ideate a bunch of “ideal” metrics that would perfectly measure the impact of your product, but end up being impossible or infeasible to really capture. 25 25 - - **Interpretable**: Metrics should be easy to understand and agreed upon by those whose success is measured by the metric. There’s often a trade-off between simplicity and accuracy. Prefer simplicity, a metric that’s hard to understand provides none of the benefits listed in the section below. 25 25 + - **Robust**: To complement the **sensitivity** criteria above, we also need to make sure the metric is measuring only the effect of the product of interest, and that it is not reactive to things we expect to change but don't control. Related to [internal validity](https://en.wikipedia.org/wiki/Internal_validity), we should try to avoid using a metric that can be significantly influenced by anything other than the product/feature we care about. 26 26 + - **Measurable**: A metric must be something that we can actually measure. It's not uncommon to ideate a bunch of “ideal” metrics that would perfectly measure the impact of your product, but end up being impossible or infeasible to really capture. 27 27 + - **Interpretable**: Metrics should be easy to understand and agreed upon by those whose success is measured by the metric. There's often a trade-off between simplicity and accuracy. Prefer simplicity, a metric that's hard to understand provides none of the benefits listed in the section below. 26 28 27 27 - Remember that there are no objectively right answers. [There is no correct win rate waiting to be unearthed](https://mobile.twitter.com/bennstancil/status/1428837214545395712); one version is not true while another is false. Each version is equally accurate because they are tautological: They measure precisely what they say they measure, no more and no less. Your job as analysts is not to do the math right so that you can figure out which answer is in the back of the book; it’s to determine which version, out of a subjective set of options, helps you best run a business. 29 29 + Remember that there are no objectively right answers. [There is no correct win rate waiting to be unearthed](https://mobile.twitter.com/bennstancil/status/1428837214545395712); one version is not true while another is false. Each version is equally accurate because they are tautological: They measure precisely what they say they measure, no more and no less. Your job as analysts is not to do the math right so that you can figure out which answer is in the back of the book; it's to determine which version, out of a subjective set of options, helps you best run a business. 28 30 29 31 ### [North Star Metric Design](https://roundup.getdbt.com/p/the-perfect-north-star-metric) 30 32 31 33 - Define your customer [jobs to be done](https://hbr.org/2016/09/know-your-customers-jobs-to-be-done) and measure all of the ways this shows up in your product. 32 32 - - Measure more than one kind of activity if there's more than one job to be done. 34 34 + - Measure more than one kind of activity if there's more than one job to be done. 33 35 - Decide how often you expect to see these activities from your customer when your product is fully utilized. You aren't measuring velocity of activity based on how fast you want your business to move and iterate, you're focusing on how often your customer is getting value. 34 36 - Test your assumptions. Is your resulting metric is explainable and predictable? Is it **easy** to communicate who you're building for and what problems you're solving, and is it **easy** to trace work being done in the company to positive customer outcomes? 35 37 ··· 37 39 38 40 1. Metrics before Strategy. Your metrics are a reflection of your strategy. They help answer, is the strategy working? Metrics without strategy is looking at a bunch of random numbers. Define the strategy before you define your metrics. 39 41 2. Definition Is More Important Than A Dashboard. People focus on "building a dashboard." Much more important is choosing which metrics are important and defining those metrics well. Defining is more complicated than people think... 40 40 - - There are many ways to define a retention metric depending on your product. Your dashboard is a method to communicate your metrics, which is important, but useless if you choose and define them poorly. 42 42 + 43 43 + - There are many ways to define a retention metric depending on your product. Your dashboard is a method to communicate your metrics, which is important, but useless if you choose and define them poorly. 44 44 + 41 45 3. Outputs vs Inputs. Most metrics like a retention metric or revenue metric are output metrics. These are metrics you should monitor. Giving output metrics to teams as [[Goals]] can be dangerous. They need to break them down into input metrics to make them actionable. 42 42 - - When output metrics are given as goals, teams can often focus on the wrong inputs or thrash between inputs. 43 43 - - Focus on usage first (not revenue first). This is the most common version of outputs vs inputs. Usage creates revenue, revenue does not create usage. As a result, the most important metrics in terms of creating growth are not your revenue metrics, they are your usage metrics. 46 46 + 47 47 + - When output metrics are given as goals, teams can often focus on the wrong inputs or thrash between inputs. 48 48 + - Focus on usage first (not revenue first). This is the most common version of outputs vs inputs. Usage creates revenue, revenue does not create usage. As a result, the most important metrics in terms of creating growth are not your revenue metrics, they are your usage metrics. 49 49 + 44 50 4. Mixing Up Retention and Engagement. Retention and engagement are not the same things. Retention is binary. It answers the question, was this person active within my defined time period? Yes or no. Engagement is is depth. It answers the question, how active were they within the defined timed period? 0→N. Engagement is one of three major inputs into driving retention. 45 51 5. Customers vs Users. A customer and a user is not the same thing in most business models. A customer is defined as the person/group that is paying you. A user is a person using the product. 46 46 - - In subscription products, oftentimes there are multiple users associated with a single customer. Or people are users before they are a customer. You need to separate the definition and language between these two things for teams to clearly act on them. 52 52 + 53 53 + - In subscription products, oftentimes there are multiple users associated with a single customer. Or people are users before they are a customer. You need to separate the definition and language between these two things for teams to clearly act on them. 47 54 48 55 ## Principles for a [Metrics Platform](https://medium.com/airbnb-engineering/airbnb-metric-computation-with-minerva-part-2-9afe6695b486) 49 56 ··· 56 63 57 64 ## Proxy Metrics 58 65 59 59 - Proxy metrics are a stand-in for your high-level engagement metric — the metric that defines your product’s overall quality. First, you seek a correlation between your high-level metric and the proxy metric. Later you work to prove causation. 66 66 + Proxy metrics are a stand-in for your high-level engagement metric — the metric that defines your product's overall quality. First, you seek a correlation between your high-level metric and the proxy metric. Later you work to prove causation. 60 67 61 61 - One of the simplest way to define a proxy metrics is: ** [Percentage of customers who do at least (the minimum threshold for user action) by (X period in time)](https://gibsonbiddle.medium.com/4-proxy-metrics-a82dd30ca810)**. 68 68 + One of the simplest way to define a proxy metrics is: **[Percentage of customers who do at least (the minimum threshold for user action) by (X period in time)](https://gibsonbiddle.medium.com/4-proxy-metrics-a82dd30ca810)**. 62 69 63 70 As you evaluate potential metrics, sure the proxy metric: 64 71

+2 -10

Decentralized Autonomous Organizations.md

reviewed

··· 3 3 - A Decentralized Autonomous [[Organizations |Organization]] is a mechanism that enables online communities to form and coordinate economically. 4 4 - DAOs make it possible for an online group with members from anywhere in the world to pool capital and hard-code rules — entirely in software — for how that capital will be managed and deployed. Those rules are then enforced by the underlying blockchain. 5 5 6 6 - ### Resources 6 6 + ## Resources 7 7 8 8 - [A beginner’s guide to DAOs](https://linda.mirror.xyz/Vh8K4leCGEO06_qSGx-vS5lvgUqhqkCz9ut81WwCP2o). 9 9 - [Everything you need to know about DAOs](https://foundation.app/blog/everything-you-need-to-know-about-daos). 10 10 - [The Handbook of Handbooks for Decentralized Organizing](https://hackmd.io/@yHk1snI9T9SNpiFu2o17oA/Skh_dXNbE?type=view). 11 11 - [Resources For Decentralized Organizing](https://commonslibrary.org/resources-for-decentralised-organising/). Also [summarized in slides](https://geo.coop/sites/default/files/patterns_of_decentralized_organizing.pdf). 12 12 13 13 - #### Cooperatives 14 14 - 15 15 - - [Tech coop resources](https://tech-coops.xyz/#resources). 16 16 - - [Tech coop list](https://tech-coops.xyz/#coops). 17 17 - - [Coophub](https://coophub.io/). 18 18 - - [Hypha](https://github.com/hyphacoop). 19 19 - - [Catalyst](https://github.com/catalyst-cooperative). 20 20 - 21 21 - #### Tools 13 13 + ### Tools 22 14 23 15 - [DAO Tool List](https://messari.io/governor/tools). 24 16 - [Snapshot](https://snapshot.org/#/).

+25 -25

Design Docs.md

reviewed

··· 4 4 5 5 - These are relatively informal documents that the primary author or authors of a software system or application create before they embark on the coding project. If code is the bricks and mortar, then these docs are the blueprints. 6 6 - Short specs are more likely to be read. The purpose of a spec is to briefly communicate the "why", "what" and "how" of the project to the rest of the team. Ideally these short documents force teams to scope out work so priorities are clear and teams avoid building the wrong thing. 7 7 - - [The longer your document is, the more likely people will only read the comments and not the body.](https://twitter.com/hamiltonulmer/status/1562817324184440832) 7 7 + - [The longer your document is, the more likely people will only read the comments and not the body.](https://twitter.com/hamiltonulmer/status/1562817324184440832) 8 8 - A tech spec forces you to think through complicated issues and to get everyone on the same page. This helps to avoid wasting time on dead-end solutions or building the wrong thing. 9 9 - It's hard to make technical decisions while remote. [Build a Proposal Culture](https://hamiltonulmer.com/writing/building-a-proposal-culture) to enable effective distributed technical decision making via [[Writing]] and collecting [[Feedback]] on a written document in an inclusive, async-friendly way. 10 10 - Even if no one else reads them, they force you to clarify my thinking before you start the (more expensive) process of implementation. 11 11 - Design docs fulfill the following functions in the software development life-cycle: 12 12 - - Early identification of design issues when making changes is still cheap. 13 13 - - Achieving consensus around a design in the organization. 14 14 - - Ensuring consideration of cross-cutting concerns. 15 15 - - Scaling knowledge of senior engineers into the organization. 16 16 - - Form the basis of an organizational memory around design decisions. 12 12 + - Early identification of design issues when making changes is still cheap. 13 13 + - Achieving consensus around a design in the organization. 14 14 + - Ensuring consideration of cross-cutting concerns. 15 15 + - Scaling knowledge of senior engineers into the organization. 16 16 + - Form the basis of an organizational memory around design decisions. 17 17 - Write them in whatever form makes the most sense for the particular project. 18 18 - A good-to-start-with structure can be: 19 19 - 1. Context and scope. Overview of the landscape in which the new system is being built and what is actually being built. Focused on objective background facts. Keep it short. 20 20 - 2. Goals and non-goals. What the goals of the system are, and, sometimes more importantly, what non-goals are. 21 21 - 3. Design. This is the place to write down the trade-offs you made in designing your software. Given the context (facts), goals and non-goals (requirements), the design doc is the place to suggest solutions and show why a particular solution best satisfies those goals. 22 22 - 4. APIs. If the system under design exposes an API, then sketching out that API is usually a good idea. 23 23 - 5. Data storage. Systems that store data should likely discuss how and in what rough form this happens. 24 24 - 6. Alternatives considered. Share alternative designs that would have reasonably achieved similar outcomes. 25 25 - 7. Cross-cutting concerns. This is where your organization can ensure that certain cross-cutting concerns such as security, privacy, and observability are always taken into consideration. These are often relatively short sections that explain how the design impacts the concern and how the concern is addressed. Teams should standardize what these concerns are in their case. 19 19 + 1. Context and scope. Overview of the landscape in which the new system is being built and what is actually being built. Focused on objective background facts. Keep it short. 20 20 + 2. Goals and non-goals. What the goals of the system are, and, sometimes more importantly, what non-goals are. 21 21 + 3. Design. This is the place to write down the trade-offs you made in designing your software. Given the context (facts), goals and non-goals (requirements), the design doc is the place to suggest solutions and show why a particular solution best satisfies those goals. 22 22 + 4. APIs. If the system under design exposes an API, then sketching out that API is usually a good idea. 23 23 + 5. Data storage. Systems that store data should likely discuss how and in what rough form this happens. 24 24 + 6. Alternatives considered. Share alternative designs that would have reasonably achieved similar outcomes. 25 25 + 7. Cross-cutting concerns. This is where your organization can ensure that certain cross-cutting concerns such as security, privacy, and observability are always taken into consideration. These are often relatively short sections that explain how the design impacts the concern and how the concern is addressed. Teams should standardize what these concerns are in their case. 26 26 - In many docs a diagram can be useful. 27 27 - The steps in the life-cycle of a design document are: Create, Iterate, Review, Implement, Iterate and Learn. 28 28 - [The RFC and feedback should be posted publicly. Everyone can join the discussion. The goal is to include as many people as possible to access more points of view and spread the knowledge simultaneously](https://candost.blog/how-to-stop-endless-discussions/). 29 29 - The process brings accountability. Whoever writes the proposal should be kept accountable. When people know that they will be accountable, they tend to approach more carefully and consider different aspects seriously. Ways to hold yourself and others accountable for showing your work: 30 30 - - Start by stating the problem you’re trying to solve and why. 31 31 - - Enumerate what your goals were and what principles you followed. 32 32 - - Communicate not just what, but how, and why the decision came to be. 33 33 - - Link to any source materials or prior art that you used to make the decision. 34 34 - - Include what alternatives you evaluated and why they were ultimately dismissed 35 35 - - If it’s not apparent, explain who was involved with the decision along with their roles. 36 36 - - Set expectations around opportunities for feedback, improvement, or participation, if any. 37 37 - - Explain the state of the decision (e.g., final, proposed), and when it will be revisited, if ever. 38 38 - - Distill meeting recordings and chat transcripts to create a concise and easily consumed historic record. 39 39 - - Avoid using “best practice”, “industry standard”, or “parent company/former employer does X” as a justification. 40 40 - - Establish clear timelines and provide regular updates to avoid the perception that lack of visibility is lack of movement. 30 30 + - Start by stating the problem you're trying to solve and why. 31 31 + - Enumerate what your goals were and what principles you followed. 32 32 + - Communicate not just what, but how, and why the decision came to be. 33 33 + - Link to any source materials or prior art that you used to make the decision. 34 34 + - Include what alternatives you evaluated and why they were ultimately dismissed 35 35 + - If it's not apparent, explain who was involved with the decision along with their roles. 36 36 + - Set expectations around opportunities for feedback, improvement, or participation, if any. 37 37 + - Explain the state of the decision (e.g., final, proposed), and when it will be revisited, if ever. 38 38 + - Distill meeting recordings and chat transcripts to create a concise and easily consumed historic record. 39 39 + - Avoid using “best practice”, “industry standard”, or “parent company/former employer does X” as a justification. 40 40 + - Establish clear timelines and provide regular updates to avoid the perception that lack of visibility is lack of movement. 41 41 42 42 - ### Resources 42 42 + ## Resources 43 43 44 44 - [Google Design Doc Template](https://docs.google.com/document/d/18hYAQCTsDgaFUo-VJGhT0UqyetL2LbAzkWNK1fYS8R0/edit#) 45 45 - [Rust RFCs](https://github.com/rust-lang/rfcs)

+19 -19

Mindfulness.md

reviewed

··· 1 1 # Mindfulness 2 2 3 3 - Enjoy Life. Enjoy people. Appreciate the fact that [you're alive](https://youtu.be/9D05ej8u-gU). Be grateful and [[Meditation |mindful]] about it. You take things for granted, and then they're gone. Don't wait to do things that matter, and savor the time you have. Be present and enjoy the moment as a child does. [Life is short](http://paulgraham.com/vb.html), [enjoy the silly bit in between](https://youtu.be/-mu780uB7mI). 4 4 - - [Humans quickly return to a relatively stable level of happiness despite major positive or negative events or life changes](https://en.wikipedia.org/wiki/Hedonic_treadmill). Optimize for tranquility in your life. 4 4 + - [Humans quickly return to a relatively stable level of happiness despite major positive or negative events or life changes](https://en.wikipedia.org/wiki/Hedonic_treadmill). Optimize for tranquility in your life. 5 5 - Make [[Time]] to reflect. Don't waste time doing anything by momentum if you don't enjoy it. Not doing something that isn't worth doing is a wonderful way to spend your [[Time]]. Look at the big picture and don't climb the current mountain out of inertia (ranks in business, status among friends, ...). [If you haven't done it already, schedule a day and time when you can realistically assess how you want your life to affect you and other people, and what you must change to better achieve this](https://www.lesswrong.com/posts/4psQW7vRwt7PE5Pnj/too-busy-to-think-about-life). 6 6 - One task at a time. [[Focus |No distractions]]. 7 7 - **KISS**. What would less/simple look like? 8 8 - - When [[Communication |communicating]], do it in a clear and concise way. 9 9 - - Sometimes, even if your intention is good, signal might turn into noise and won't be interpreted the way you expect. 10 10 - - When [[Problem Solving |facing a problem]], prefer a lean approach with a simple solution and built upon it. Re-framing problems will make easy to give simpler solutions. How would it look like if it was simple? 11 11 - - Remove friction. Focus on essentials. Complexity itself has costs. It makes life harder to manage, reduces our degrees of freedom, and so forth. Often people do not factor those costs into their decisions as they incrementally and inattentively complexify their lives. A person with the virtue of simplicity asks, of any decision they make, "does this make my life more complex, and if so is that worth it?" 8 8 + - When [[Communication |communicating]], do it in a clear and concise way. 9 9 + - Sometimes, even if your intention is good, signal might turn into noise and won't be interpreted the way you expect. 10 10 + - When [[Problem Solving |facing a problem]], prefer a lean approach with a simple solution and built upon it. Re-framing problems will make easy to give simpler solutions. How would it look like if it was simple? 11 11 + - Remove friction. Focus on essentials. Complexity itself has costs. It makes life harder to manage, reduces our degrees of freedom, and so forth. Often people do not factor those costs into their decisions as they incrementally and inattentively complexify their lives. A person with the virtue of simplicity asks, of any decision they make, "does this make my life more complex, and if so is that worth it?" 12 12 - Live smarter, not harder. Don't complain about stuff you can easily fix, [[Automation |automate]], or delegate. Money can buy [[time]]. 13 13 - Keep Calm. Own and deal with your emotions. [[Stoicism |Focus on what you can control]]. Try to plan the possible outcomes and don't rush. 14 14 - Think, understand, and listen before [[Communication |communicating]]. 15 15 - Don't worry too much about things that won't matter to you or your loved ones in 10 years. 16 16 - Assume positive intent. No one is your enemy, you're an NPC in their game. Everyone is the main character of their own movie (*sonder*). 17 17 - - Every person is inherently valuable independent of behavior and beliefs. Create safe spaces for people, and a dangerous space for ideas ([idea labs](https://twitter.com/waitbutwhy/status/1278035160454348800)). 18 18 - - When you have a nice thing to say about someone, say it to them right away, instead of waiting. You might not see them again. [Optimize for sincerity](https://www.neelnanda.io/blog/mini-blog-post-10-seek-positive-externalities). 19 19 - - Don't punish people for trying. You teach them to not try things or not to try them with you. 20 20 - - Most of the harm we do as humans is not due to cruelty, but rather to indifference. 17 17 + - Every person is inherently valuable independent of behavior and beliefs. Create safe spaces for people, and a dangerous space for ideas ([idea labs](https://twitter.com/waitbutwhy/status/1278035160454348800)). 18 18 + - When you have a nice thing to say about someone, say it to them right away, instead of waiting. You might not see them again. [Optimize for sincerity](https://www.neelnanda.io/blog/mini-blog-post-10-seek-positive-externalities). 19 19 + - Don't punish people for trying. You teach them to not try things or not to try them with you. 20 20 + - Most of the harm we do as humans is not due to cruelty, but rather to indifference. 21 21 - Prefer delayed gratification, making short term sacrifices to get long term benefits. 22 22 - Don't be a [whatever person](https://medium.com/@courtneyseiter/the-tribe-of-whatever-or-how-i-learned-to-make-a-decision-8ab0a76f1f0c#.vj7olnmm5). Don't be afraid to [[Making Decisions |make decisions]] and actively take them! All decision making — even if small ones — can be a good practice for the bigger ones you'll face. 23 23 - - Be the friend who makes a decisive call when everyone else is waffling about what to eat. 23 23 + - Be the friend who makes a decisive call when everyone else is waffling about what to eat. 24 24 - Don't judge. Reality is neutral. To a tree, there's no concept of right or wrong or good or bad. You're born, you have a whole set of sensory experiences... and then you die. How you choose to interpret that is up to you. And you do have that choice. Why are you taking something so seriously? 25 25 - - One person morally disgusting behavior is another person perfectly normal lifestyle. Most of the time you can't decide what is wrong or good because you have very limited experiences. 25 25 + - One person morally disgusting behavior is another person perfectly normal lifestyle. Most of the time you can't decide what is wrong or good because you have very limited experiences. 26 26 - Be aware of your internal state. Making this more visible makes a better [[Feedback Loops |feedback loop]]. Ask yourself, as many times as possible every day "Am I conscious now?". Our internal state shapes how we experience the external state. 27 27 - Humans are messy and life is messy. Yet we try to fit everything into [human made buckets](https://slatestarcodex.com/2014/11/21/the-categories-were-made-for-man-not-man-for-the-categories/), losing most of the nuance in the process. 28 28 - - [The discrete categories we apply to continuous concepts—from the colors we see and the sounds we hear, to the academic subjects we define and the races we project onto people—are both arbitrary and deeply consequential.](https://benn.substack.com/p/gerrymandering) 29 29 - - The categories we create, though necessary to keep us from being overwhelmed by this infinite spectrum, affect what we can actually see. **The artificial boundaries we define eventually come to define us.** 30 30 - - [When you think in categories, you underestimate how different (in may other dimensions) two facts are when they are in the same category, you overestimate how different they are when there is a boundary between them and, when you pay attention to these boundaries you don't realize about the big picture](https://www.youtube.com/watch?v=NNnIGh9g6fA). 31 31 - - We rationalize things through one lens. Real causes are gray and hard to understand. 28 28 + - [The discrete categories we apply to continuous concepts—from the colors we see and the sounds we hear, to the academic subjects we define and the races we project onto people—are both arbitrary and deeply consequential.](https://benn.substack.com/p/gerrymandering) 29 29 + - The categories we create, though necessary to keep us from being overwhelmed by this infinite spectrum, affect what we can actually see. **The artificial boundaries we define eventually come to define us.** 30 30 + - [When you think in categories, you underestimate how different (in may other dimensions) two facts are when they are in the same category, you overestimate how different they are when there is a boundary between them and, when you pay attention to these boundaries you don't realize about the big picture](https://www.youtube.com/watch?v=NNnIGh9g6fA). 31 31 + - We rationalize things through one lens. Real causes are gray and hard to understand. 32 32 - Recognize that tradeoffs happen everywhere. List them explicitly. 33 33 - - We trade [[Time]] against money against effort against happiness against social capital — we can do so blindly, and hope for the best, or we can think about them carefully and deliberately, and take advantage of opportunities to get more of everything (arbitrage). Identify all your relevant currencies, and note which are being spent faster or are more valuable. 33 33 + - We trade [[Time]] against money against effort against happiness against social capital — we can do so blindly, and hope for the best, or we can think about them carefully and deliberately, and take advantage of opportunities to get more of everything (arbitrage). Identify all your relevant currencies, and note which are being spent faster or are more valuable. 34 34 - Appreciate what you have. [Don't overestimate the hedonic impact of future events](https://waitbutwhy.com/2013/11/life-is-picture-but-you-live-in-pixel.html). [Showing gratitude for the good things you have is the most powerful happiness boosting activity there is](https://youtu.be/WPPPFqsECz0). 35 35 - There's no second chance at life. [This is the one chance you have to live as a talking monkey in space at the best point in history as the smartest species on the planet using magic on a daily basis like the internet and jet planes and smartphones with access to all human knowledge at your fingertips and the chance to talk about how cool being alive is](https://youtu.be/VLAAy_pM-k8). 36 36 - Do not change because of what others or society want, change because of what you want. It's easy to get carried by the environment and start doing things you don't want to do. 37 37 - Ignore the irrational and [unproductive obsession](https://waitbutwhy.com/2014/06/taming-mammoth-let-peoples-opinions-run-life.html) with what other people think of you. Figure out what actually matters to you and live according to it. 38 38 - [What gives you energy and what sucks your energy?](https://twitter.com/rrhoover/status/1346268904239161344) Figure it out and act accordingly. 39 39 - Avoid conspicuous consumption. 40 40 - - Overcome the bystander effect: there is something that everyone wants to _happen_ but nobody wants to be the one to _do_ it. Develop the reflex of noticing bystander apathy in your environment, and actively do the thing. E.g. ask a question when there’s a confusing point in a talk, notice tiny tragedies of the commons (an empty jug of water that nobody wants to refill), notice when everyone feels uncomfortable being the first to, say, dance at a party, and just do it. 40 40 + - Overcome the bystander effect: there is something that everyone wants to *happen* but nobody wants to be the one to *do* it. Develop the reflex of noticing bystander apathy in your environment, and actively do the thing. E.g. ask a question when there's a confusing point in a talk, notice tiny tragedies of the commons (an empty jug of water that nobody wants to refill), notice when everyone feels uncomfortable being the first to, say, dance at a party, and just do it. 41 41 - [Our behavior is made up of a complex and chaotic soup of so many factors that it's downright silly to think there's a singular, autonomous "you" calling the shots](https://youtu.be/GRYcSuyLiJk). 42 42 - Tools and ideas are not neutral. They have baked some principles and values. 43 43 - - E.g: [[Social Media Issues]], [[Blockchain]] protocols that use PoW wasting energy. 44 44 - - A person holding a hammer interacts with the world in a different way and could be considered a different entity. Same with ideas. 43 43 + - E.g: [[Social Media Issues]], [[Blockchain]] protocols that use PoW wasting energy. 44 44 + - A person holding a hammer interacts with the world in a different way and could be considered a different entity. Same with ideas.

+49 -49

Programming.md

reviewed

··· 3 3 A programmer should know [lots](http://programmer.97things.oreilly.com/wiki/index.php/Contributions_Appearing_in_the_Book) [of](http://www.artima.com/weblogs/viewpost.jsp?thread=331531) [concepts](http://programmer.97things.oreilly.com/wiki/index.php/Other_Edited_Contributions). Try to keep in mind the following principles: 4 4 5 5 - **Small is beautiful**. 6 6 - - Small things have tremendous advantages over their larger counterparts. Among these is the ability to combine with other small things in unique and useful ways. 7 7 - - The more you can decompose, the more innovation you'll drive. 8 8 - - The best code is no code, or code you don’t have to maintain. 6 6 + - Small things have tremendous advantages over their larger counterparts. Among these is the ability to combine with other small things in unique and useful ways. 7 7 + - The more you can decompose, the more innovation you'll drive. 8 8 + - The best code is no code, or code you don't have to maintain. 9 9 - **Design for simplicity**. 10 10 - - Do the [simplest thing](https://landing.google.com/sre/book/chapters/simplicity.html) that could possibly work. 11 11 - - Benefits of simplicity: ease of understanding, ease of change (improvement), ease of debugging, flexibility. [The goal of software design is to create chunks or slices that fit into a human mind](https://mobile.twitter.com/KentBeck/status/1354418068869398538). The software keeps growing but the human mind maxes out, so we have to keep chunking and slicing differently if we want to keep making changes. 12 12 - - We can't change our brain to grasp something complex. We need to simplify complexity so we can handle it. 13 13 - - Eliminate state. If you can’t, make it visible. 14 14 - - Design is an iterative process. The necessary number of iterations is one more than the number you have currently done. This is true at any point in time. 15 15 - - Complexity is the single major difficulty in the successful development of large-scale software systems. 16 16 - - Write code that's easy to delete. 10 10 + - Do the [simplest thing](https://landing.google.com/sre/book/chapters/simplicity.html) that could possibly work. 11 11 + - Benefits of simplicity: ease of understanding, ease of change (improvement), ease of debugging, flexibility. [The goal of software design is to create chunks or slices that fit into a human mind](https://mobile.twitter.com/KentBeck/status/1354418068869398538). The software keeps growing but the human mind maxes out, so we have to keep chunking and slicing differently if we want to keep making changes. 12 12 + - We can't change our brain to grasp something complex. We need to simplify complexity so we can handle it. 13 13 + - Eliminate state. If you can't, make it visible. 14 14 + - Design is an iterative process. The necessary number of iterations is one more than the number you have currently done. This is true at any point in time. 15 15 + - Complexity is the single major difficulty in the successful development of large-scale software systems. 16 16 + - Write code that's easy to delete. 17 17 - **Do one thing and do it well**. 18 18 - - By focusing on a single task, a program or function can eliminate much extraneous code that often results in excess overhead, unnecessary complexity, and a lack of flexibility. [Good software makes hard things easy](https://medium.com/s/story/notes-to-myself-on-software-engineering-c890f16f4e4d). 19 19 - - Design composable primitives. 18 18 + - By focusing on a single task, a program or function can eliminate much extraneous code that often results in excess overhead, unnecessary complexity, and a lack of flexibility. [Good software makes hard things easy](https://medium.com/s/story/notes-to-myself-on-software-engineering-c890f16f4e4d). 19 19 + - Design composable primitives. 20 20 - **Make it work, make it right, make it fast**. 21 21 - - Build a prototype as soon as possible to get a sense of the entire process. 22 22 - - Once you have a working prototype, apply guidelines and previous learnings. Then, focus on performance. 23 23 - - There is nothing so useless as doing efficiently that which should not be done at all. 24 24 - - Writing program code is a good way of debugging your thinking. 25 25 - - Apply small improvements at each iteration. Running the program will make it more resilient and robust as more errors get fixed. 26 26 - - Premature optimization is the root of all evil. Abstraction is a form of optimization and shouldn't be done before the space has been properly explored to know what abstractions should be built. Standardization is a form of optimization and shouldn't be proposed until there's a body of evidence to support what's being standardized. 27 27 - - [Increased efficiency can sometimes, counterintuitively, lead to worse outcomes](https://sohl-dickstein.github.io/2022/11/06/strong-Goodhart.html). 28 28 - - You should be able to "punch through" your abstraction layer and get to the code behind it in cases you need that. 29 29 - - Sometimes you have to stop sharpening the saw, and just start cutting. 30 30 - - Software which is broken because there is no incentive to ship good software is going to stay broken until the incentives change. 21 21 + - Build a prototype as soon as possible to get a sense of the entire process. 22 22 + - Once you have a working prototype, apply guidelines and previous learnings. Then, focus on performance. 23 23 + - There is nothing so useless as doing efficiently that which should not be done at all. 24 24 + - Writing program code is a good way of debugging your thinking. 25 25 + - Apply small improvements at each iteration. Running the program will make it more resilient and robust as more errors get fixed. 26 26 + - Premature optimization is the root of all evil. Abstraction is a form of optimization and shouldn't be done before the space has been properly explored to know what abstractions should be built. Standardization is a form of optimization and shouldn't be proposed until there's a body of evidence to support what's being standardized. 27 27 + - [Increased efficiency can sometimes, counterintuitively, lead to worse outcomes](https://sohl-dickstein.github.io/2022/11/06/strong-Goodhart.html). 28 28 + - You should be able to "punch through" your abstraction layer and get to the code behind it in cases you need that. 29 29 + - Sometimes you have to stop sharpening the saw, and just start cutting. 30 30 + - Software which is broken because there is no incentive to ship good software is going to stay broken until the incentives change. 31 31 - **Choose portability over efficiency**. 32 32 - - If today's hardware just about runs a program with just about adequate efficiency, tomorrow's will run it with power to spare. 33 33 - - The developer task is to make sure his program will run on that new hardware with minimal effort. 32 32 + - If today's hardware just about runs a program with just about adequate efficiency, tomorrow's will run it with power to spare. 33 33 + - The developer task is to make sure his program will run on that new hardware with minimal effort. 34 34 - **Data is only useful as long as it's being used**. 35 35 - - Flat files help ensure that data is usable for the longest possible time. 36 36 - - For complex data structures where plain text really isn't appropriate, use a structured text format instead. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. [Data structures, not algorithms, are central to programming](https://users.ece.utexas.edu/~adnan/pike.html). 35 35 + - Flat files help ensure that data is usable for the longest possible time. 36 36 + - For complex data structures where plain text really isn't appropriate, use a structured text format instead. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. [Data structures, not algorithms, are central to programming](https://users.ece.utexas.edu/~adnan/pike.html). 37 37 - **A programmer who can't re-use other programs is condemned to re-write them**. 38 38 - - Use software leverage to your advantage. 39 39 - - Many programmers have only a superficial understanding of the importance of re-usable code modules. 40 40 - - [Code isn't just meant to be executed. Code is also a means of [[Communication]] across a team, a way to describe to others the solution to a problem](https://medium.com/s/story/notes-to-myself-on-software-engineering-c890f16f4e4d). 38 38 + - Use software leverage to your advantage. 39 39 + - Many programmers have only a superficial understanding of the importance of re-usable code modules. 40 40 + - [Code isn't just meant to be executed. Code is also a means of [[Communication]] across a team, a way to describe to others the solution to a problem](https://medium.com/s/story/notes-to-myself-on-software-engineering-c890f16f4e4d). 41 41 - **Silence is golden**. 42 42 - - A silent command is often more usable, providing the function asked for and nothing more. 42 42 + - A silent command is often more usable, providing the function asked for and nothing more. 43 43 - **Think parallel**. 44 44 - - Most tasks are composed of sub-tasks which may be attacked in parallel. This also applies to user interactions. 45 45 - - Parallelism can save a great deal of time and frustration. 44 44 + - Most tasks are composed of sub-tasks which may be attacked in parallel. This also applies to user interactions. 45 45 + - Parallelism can save a great deal of time and frustration. 46 46 - **The sum of the parts is greater than the whole**. 47 47 - - A large application built from a collection of smaller programs is more flexible and hence more useful than a single large program. 48 48 - - The same functional capability may exist in both solutions, but the collection-of-small-programs approach is the more forward-looking of the two. 49 49 - - [The computer is a machine, but a codebase is an organism](https://meltingasphalt.com/a-codebase-is-an-organism/). The organic nature of code manifests itself in the dual forces of growth and decay. It also suggests that you should know your code smells. These smells won't be causing problems during execution, on the machine. Instead, it's going to cause problems during [[Evolution]] of the codebase. 47 47 + - A large application built from a collection of smaller programs is more flexible and hence more useful than a single large program. 48 48 + - The same functional capability may exist in both solutions, but the collection-of-small-programs approach is the more forward-looking of the two. 49 49 + - [The computer is a machine, but a codebase is an organism](https://meltingasphalt.com/a-codebase-is-an-organism/). The organic nature of code manifests itself in the dual forces of growth and decay. It also suggests that you should know your code smells. These smells won't be causing problems during execution, on the machine. Instead, it's going to cause problems during [[Evolution]] of the codebase. 50 50 - **Look for the 80% solution**. 51 51 - - Doing 100% of anything is difficult. [Don't focus on perfection](https://youtu.be/pYIho556BS8). 52 52 - - Focusing in the 80% is far more efficient and cost-effective. "Better" is the enemy of "good". 53 53 - - Handle the 80% and let the 20% fend for themselves. 54 54 - - [[Pareto Principle |80% of the impact comes from 20% of the work]]. 55 55 - - [Software is never finished, only abandoned](https://stackoverflow.blog/2020/02/20/requirements-volatility-is-the-core-problem-of-software-engineering/). 51 51 + - Doing 100% of anything is difficult. [Don't focus on perfection](https://youtu.be/pYIho556BS8). 52 52 + - Focusing in the 80% is far more efficient and cost-effective. "Better" is the enemy of "good". 53 53 + - Handle the 80% and let the 20% fend for themselves. 54 54 + - [[Pareto Principle |80% of the impact comes from 20% of the work]]. 55 55 + - [Software is never finished, only abandoned](https://stackoverflow.blog/2020/02/20/requirements-volatility-is-the-core-problem-of-software-engineering/). 56 56 - **Treat all the data as an event log**. 57 57 - - Use a central log where consumers can subscribe to the relevant events. 58 58 - - Having a central place ([the log](https://engineering.linkedin.com/distributed-systems/log-what-every-software-engineer-should-know-about-real-time-datas-unifying)) for continuous events make easy to create a stream of data to process and sets a source of truth. 57 57 + - Use a central log where consumers can subscribe to the relevant events. 58 58 + - Having a central place ([the log](https://engineering.linkedin.com/distributed-systems/log-what-every-software-engineer-should-know-about-real-time-datas-unifying)) for continuous events make easy to create a stream of data to process and sets a source of truth. 59 59 - **There is no silver bullet**. 60 60 - - Accept that many programming decisions are opinions. 61 61 - - Make the trade-offs explicit when making judgments and decisions. With almost every decision you make, you're either deliberately or accidentally trading off one thing for another thing. 62 62 - - Discuss [trade-offs](https://twitter.com/kelseyhightower/status/774076482637312001), which you prefer, and reach a resolution. 63 63 - - [Every system eventually sucks](https://www.simplethread.com/20-things-ive-learned-in-my-20-years-as-a-software-engineer/). Assume everything has bugs. 60 60 + - Accept that many programming decisions are opinions. 61 61 + - Make the trade-offs explicit when making judgments and decisions. With almost every decision you make, you're either deliberately or accidentally trading off one thing for another thing. 62 62 + - Discuss [trade-offs](https://twitter.com/kelseyhightower/status/774076482637312001), which you prefer, and reach a resolution. 63 63 + - [Every system eventually sucks](https://www.simplethread.com/20-things-ive-learned-in-my-20-years-as-a-software-engineer/). Assume everything has bugs. 64 64 - **Keep the [[Feedback Loops |iteration loop]] short**. 65 65 - - Invest in tools to [[Automation |automate]] and improve the development cycle (CI, CD). Decreasing build times a few seconds actually saves a lot of time over time. Deploy often to make the loop end to end. If you need to do something manually more than twice, then write a tool for the third time. 65 65 + - Invest in tools to [[Automation |automate]] and improve the development cycle (CI, CD). Decreasing build times a few seconds actually saves a lot of time over time. Deploy often to make the loop end to end. If you need to do something manually more than twice, then write a tool for the third time. 66 66 - **Avoid implicit rules**. 67 67 - - Implicit rules should always be made explicit and shared with others or automated. Ideally, all processes should be written as code, stored, and versioned. Minimize the cognitive load imposed on your users. 68 68 - - The best way to understand something is to break it. The second best way is to rewrite it from scratch without using any external libraries. 67 67 + - Implicit rules should always be made explicit and shared with others or automated. Ideally, all processes should be written as code, stored, and versioned. Minimize the cognitive load imposed on your users. 68 68 + - The best way to understand something is to break it. The second best way is to rewrite it from scratch without using any external libraries. 69 69 70 70 Like any other field, the world of Software Development has some interesting and famous "laws". These are some of them I've found interesting, funny or worth knowing: 71 71

+2 -2

Routine.md

reviewed

··· 3 3 A way to keep yourself on track with your [[habits]] is to have a morning routine. 4 4 5 5 1. Rules. Remind yourself on the current set of rules, constrains, various addictions, time-draining things. E.g. limit social media, do some stretching, ... 6 6 - 2. Gratitude. Visualize and [[Mental Health#Meditation |meditate]] on the idea that you might die today. 6 6 + 2. Gratitude. Visualize and [[Meditation|meditate]] on the idea that you might die today. 7 7 3. Long-term goals and short-term [[goals]]. Review big goals that you would like to achieve in the next years and the short term goals that lead to them that you can act on. 8 8 4. Visualize the day. Visualize yourself going through the day challenges and wins. 9 9 5. Review your core [[values]]. ··· 20 20 - Be specific (time, words, actions). 21 21 - Take [[time]] to reflect and make time for ([[mindfulness]]). 22 22 - Hike often with friends. 23 23 - - [[Writing |Write]] more. 23 23 + - [[Writing|Write]] more. 24 24 - Consume content mindfully. 25 25 - Do experiments with life (A/B tests). 26 26 - Automate one thing.

+34 -34

Thinking.md

reviewed

··· 1 1 # Thinking 2 2 3 3 - Aim to get an accurate picture of reality, even when that's unpleasant. 4 4 - - Be self-aware about what you know and what you don't know. Aim to stay close to the [humility sweet spot](https://twitter.com/waitbutwhy/status/137655374551809638). 5 5 - - See things as they are, not as you wish they were ([Scout Mindset](https://www.lesswrong.com/posts/yFJ7vCjefBxnTchmG/outline-of-galef-s-scout-mindset)). 4 4 + - Be self-aware about what you know and what you don't know. Aim to stay close to the [humility sweet spot](https://twitter.com/waitbutwhy/status/137655374551809638). 5 5 + - See things as they are, not as you wish they were ([Scout Mindset](https://www.lesswrong.com/posts/yFJ7vCjefBxnTchmG/outline-of-galef-s-scout-mindset)). 6 6 - For each subject you think you know, ask the following questions: 7 7 - - How could I be wrong about this? [In general, be less sure about what you know than intuition implies](https://www.lesswrong.com/tag/epistemic-modesty). 8 8 - - What evidence would convince me I'm wrong? 9 9 - - We use the same term - “[no evidence](https://astralcodexten.substack.com/p/the-phrase-no-evidence-is-a-red-flag)” - to mean: 10 10 - - This thing is super plausible, and honestly very likely true, but we haven’t checked yet, so we can’t be sure. 11 11 - - We have hard-and-fast evidence that this is false, stop repeating this easily debunked lie. 7 7 + - How could I be wrong about this? [In general, be less sure about what you know than intuition implies](https://www.lesswrong.com/tag/epistemic-modesty). 8 8 + - What evidence would convince me I'm wrong? 9 9 + - We use the same term - “[no evidence](https://astralcodexten.substack.com/p/the-phrase-no-evidence-is-a-red-flag)” - to mean: 10 10 + - This thing is super plausible, and honestly very likely true, but we haven't checked yet, so we can't be sure. 11 11 + - We have hard-and-fast evidence that this is false, stop repeating this easily debunked lie. 12 12 - Be [specific](https://www.lesswrong.com/posts/XosKB3mkvmXMZ3fBQ/specificity-your-brain-s-superpower). Ask yourself the question, "What's an example of that?" Or more bluntly, "Can I be more specific?" 13 13 - Run your brain in debug mode so you understand why you're thinking in that way. The brain hasn't changed that much in the last few thousands years and was built for a different world. 14 14 - Believing you're rational makes it easier to fool yourself mistaking your intuitions with rational decision. 15 15 - Stress test your ideas/assumptions/beliefs with experiments and facts as many times as possible. 16 16 - - Anything you know or do could be wrong. You get less dumb by saying things and getting feedback. [We all have crony beliefs](https://meltingasphalt.com/crony-beliefs/). From time to time, do a self-audit and figure out which ideas you've come to hold sacred and remind yourself that they're just ideas. 17 17 - - A great way to do that is to [bet on everything](https://www.lesswrong.com/posts/ybYBCK9D7MZCcdArB/how-to-measure-anything) where you can or will find out the answer. Even if you're only testing yourself against one other person, it's a way of calibrating yourself to avoid both overconfidence and under-confidence, which will serve you in good stead emotionally when you try to do [[Fallacies |inadequacy reasoning]]. It'll also force you to do falsifiable predictions. 18 18 - - A tool to assign a percentage to a belief is [the equivalent bet test](https://www.lesswrong.com/posts/EtxTDPMXrbmpheiAt/how-the-equivalent-bet-test-actually-works). 19 19 - - Instead of thinking "I'm sure X is fake!", try to think in terms of probabilities. E.g: I think there's a 90% chance X is fake. Instead of thinking in terms of changing your mind, think in terms of updating your probabilities. [This mindset](https://astralcodexten.substack.com/p/book-review-the-scout-mindset) makes it easier to remember that it’s not a question of winning or losing, but a question of being as accurate as possible. “Probability update” is less emotionally devastating than "I said X, but actually ~X, so I was wrong"). 16 16 + - Anything you know or do could be wrong. You get less dumb by saying things and getting feedback. [We all have crony beliefs](https://meltingasphalt.com/crony-beliefs/). From time to time, do a self-audit and figure out which ideas you've come to hold sacred and remind yourself that they're just ideas. 17 17 + - A great way to do that is to [bet on everything](https://www.lesswrong.com/posts/ybYBCK9D7MZCcdArB/how-to-measure-anything) where you can or will find out the answer. Even if you're only testing yourself against one other person, it's a way of calibrating yourself to avoid both overconfidence and under-confidence, which will serve you in good stead emotionally when you try to do [[Fallacies |inadequacy reasoning]]. It'll also force you to do falsifiable predictions. 18 18 + - A tool to assign a percentage to a belief is [the equivalent bet test](https://www.lesswrong.com/posts/EtxTDPMXrbmpheiAt/how-the-equivalent-bet-test-actually-works). 19 19 + - Instead of thinking "I'm sure X is fake!", try to think in terms of probabilities. E.g: I think there's a 90% chance X is fake. Instead of thinking in terms of changing your mind, think in terms of updating your probabilities. [This mindset](https://astralcodexten.substack.com/p/book-review-the-scout-mindset) makes it easier to remember that it's not a question of winning or losing, but a question of being as accurate as possible. “Probability update” is less emotionally devastating than "I said X, but actually ~X, so I was wrong"). 20 20 - You can try things to find out which ideas are right or wrong. It requires asking "What else would be true if this thing were true?" or "What would be different depending on whether X versus Y were true?". 21 21 - Knowledge decays. Things you learned in the past might not be true nowadays (_status of Pluto as a planet, dinosaurs with feathers, number of people living, ..._). [Facts decay over time until they are no longer facts or perhaps no longer complete](https://fs.blog/2018/03/half-life/). 22 22 - Don't fully trust Science (or History) as is not perfect. Studies are based on incorrect assumptions (from other studies), might have experimental issues, or might be manipulated by external factors (e.g: tobacco companies paying for studies). 23 23 - Avoiding stupidity is easier than seeking brilliance. Think backward so that you can avoid failures. 24 24 - Research before judging! We do not know what we don't know. Gather as much context as you can before making any final statement. 25 25 - - [Absolute truth is relative and everyone is doing the best they can](https://letterstoanewdeveloper.com/2019/08/12/there-are-no-adults-in-the-room/). These are opportunities for you to help and learn more about the world. 25 25 + - [Absolute truth is relative and everyone is doing the best they can](https://letterstoanewdeveloper.com/2019/08/12/there-are-no-adults-in-the-room/). These are opportunities for you to help and learn more about the world. 26 26 - Think in distributions instead of [magic answers](http://cassandraxia.com/cogbiases). The world is [analog and not digital](https://waitbutwhy.com/2019/12/political-disney-world.html), continuous and not discrete. Nuance is everywhere. 27 27 - - Real people are complex and flawed, [full of faults and biases](https://upload.wikimedia.org/wikipedia/commons/6/65/Cognitive_bias_codex_en.svg). Each turn of events is mired in potential positives and potential negatives, which is a mess to sort out. 28 28 - - [Fundamental Attribution Error](http://www.aaronsw.com/weblog/nummi): we attribute people’s behavior to their personality, not their situation. 29 29 - - Digitizing an analog view will result in some loss of information. In that world, everything is good or bad, everyone is smart or ignorant, ones and zeros. Mistrust simple comparisons. 27 27 + - Real people are complex and flawed, [full of faults and biases](https://upload.wikimedia.org/wikipedia/commons/6/65/Cognitive_bias_codex_en.svg). Each turn of events is mired in potential positives and potential negatives, which is a mess to sort out. 28 28 + - [Fundamental Attribution Error](http://www.aaronsw.com/weblog/nummi): we attribute people's behavior to their personality, not their situation. 29 29 + - Digitizing an analog view will result in some loss of information. In that world, everything is good or bad, everyone is smart or ignorant, ones and zeros. Mistrust simple comparisons. 30 30 - You need a view of both the micro and the macro, the forest and the trees — and how both perspectives slot together. 31 31 - Local Validity: Some argument steps are allowed steps and some argument steps aren't ([Non-Central Fallacy](https://www.lesswrong.com/posts/yCWPkLi8wJvewPbEp/the-noncentral-fallacy-the-worst-argument-in-the-world)), independently of whether they arrive at an answer you agree with. 32 32 - People can fool you by saying they saw things that they didn't see, telling you some things they know but not others or by using flawed steps when drawing conclusions. When you try to make an argument come out with a particular answer, you can fool yourself in the same way. ··· 35 35 - [Notice when your mind is flinching away from a thought and flag that area as requiring more deliberate exploration](https://www.lesswrong.com/posts/ttGbpJQ8shBi8hDhh/checklist-of-rationality-habits). 36 36 - [Notice](https://agentyduck.blogspot.com/2014/12/how-to-train-noticing.html) your internal state (cognitive and emotional). 37 37 - Notice when you are in a failure mode, and step out. For example: 38 38 - - [Motivated Reasoning or Soldier Mindset](https://youtu.be/w4RLfVxTGH4?list=WL): 39 39 - - You are fighting to make sure an argument wins. 40 40 - - You are fighting to make another argument lose. 41 41 - - You are [[incentives |incentivized]] to believe something, or not to notice something, because of social or financial rewards or because it'd be physically inconvenient/annoying. 42 42 - - You are [offended/angered/defensive/agitated](https://www.lesswrong.com/posts/yCWPkLi8wJvewPbEp/the-noncentral-fallacy-the-worst-argument-in-the-world). 43 43 - - You are afraid you'll lose something important if you lose a belief. 44 44 - - You are arguing about definitions of words instead of ideas. 45 45 - - You are confused or surprised. Treat this as a red flag that something about your models is wrong. 38 38 + - [Motivated Reasoning or Soldier Mindset](https://youtu.be/w4RLfVxTGH4?list=WL): 39 39 + - You are fighting to make sure an argument wins. 40 40 + - You are fighting to make another argument lose. 41 41 + - You are [[incentives |incentivized]] to believe something, or not to notice something, because of social or financial rewards or because it'd be physically inconvenient/annoying. 42 42 + - You are [offended/angered/defensive/agitated](https://www.lesswrong.com/posts/yCWPkLi8wJvewPbEp/the-noncentral-fallacy-the-worst-argument-in-the-world). 43 43 + - You are afraid you'll lose something important if you lose a belief. 44 44 + - You are arguing about definitions of words instead of ideas. 45 45 + - You are confused or surprised. Treat this as a red flag that something about your models is wrong. 46 46 - Notice if someone else seems to be in one of the above failure modes. 47 47 - Tactfully disagree in a way that arouses [[curiosity]] rather than defensiveness. 48 48 - - Leave your colleague a line of retreat. 48 48 + - Leave your colleague a line of retreat. 49 49 - [Be prejudiced in favor of tolerating dissent](https://www.lesswrong.com/posts/ZQG9cwKbct2LtmL3p/evaporative-cooling-of-group-beliefs#fn3x57). 50 50 - Socially reward people who change their mind. 51 51 - The real costs aren't always what is shown. Costs and [[Values]] are often made of multiple parts. Beware of repeated costs—they add up! 52 52 - Take into account second and third order effects. 53 53 - Do your philosophical thinking in advance ([cached thoughts](https://www.lesswrong.com/posts/2MD3NMLBPCqPfnfre/cached-thoughts)), so you can concentrate on explaining well. Above all, practice staying within the one-inferential-step bound. 54 54 - - [Think for yourself about "wise" or important or emotionally fraught topics](https://www.lessestwrong.com/posts/aSQy7yHj6nPD44RNo/how-to-seem-and-be-deep) rather than letting your brain complete the pattern. If you don't stop at the first answer, and cast out replies that seem vaguely unsatisfactory, in time your thoughts will form a coherent whole, flowing from the single source of yourself, rather than being fragmentary repetitions of other people's conclusions. 55 55 - - Sometimes inferential distances can be very far apart. You need [willingness to entertain and explore ideas before deciding that they are wrong](https://slatestarcodex.com/2020/05/12/studies-on-slack/). The other person might be on a self-consistent equilibria (someone christian, creationism, ...) and only changing one view of the world wouldn't work. You have to convince them for all the views. [A clear argument has to lay out an inferential pathway, starting from what the audience already knows or accepts](https://www.lesswrong.com/posts/HLqWn5LASfhhArZ7w/expecting-short-inferential-distances). Same applies when working with a group or even for you! _Change your mind a little at a time_. 56 56 - - You cant reason someone out of a notion that they didn’t reason themselves into. 54 54 + - [Think for yourself about "wise" or important or emotionally fraught topics](https://www.lessestwrong.com/posts/aSQy7yHj6nPD44RNo/how-to-seem-and-be-deep) rather than letting your brain complete the pattern. If you don't stop at the first answer, and cast out replies that seem vaguely unsatisfactory, in time your thoughts will form a coherent whole, flowing from the single source of yourself, rather than being fragmentary repetitions of other people's conclusions. 55 55 + - Sometimes inferential distances can be very far apart. You need [willingness to entertain and explore ideas before deciding that they are wrong](https://slatestarcodex.com/2020/05/12/studies-on-slack/). The other person might be on a self-consistent equilibria (someone christian, creationism, ...) and only changing one view of the world wouldn't work. You have to convince them for all the views. [A clear argument has to lay out an inferential pathway, starting from what the audience already knows or accepts](https://www.lesswrong.com/posts/HLqWn5LASfhhArZ7w/expecting-short-inferential-distances). Same applies when working with a group or even for you! _Change your mind a little at a time_. 56 56 + - You cant reason someone out of a notion that they didn't reason themselves into. 57 57 - There's a distinction between tacit knowledge and explicit knowledge: 58 58 - - Tacit knowledge is like the knowledge that you use to ride a bicycle—it's complex, experiential, intuitive, hard to put into words. There is knowledge experts have, but cannot explain or write down. 59 59 - - Explicit knowledge is clear and concrete and transferable and (at least somewhat) objectively verifiable. How you ride a bicycle is tacit, but the fact that you can ride a bicycle is explicit. It's a binary fact that can be completely and compactly transferred through words, and that is verifiable through experiment. 58 58 + - Tacit knowledge is like the knowledge that you use to ride a bicycle—it's complex, experiential, intuitive, hard to put into words. There is knowledge experts have, but cannot explain or write down. 59 59 + - Explicit knowledge is clear and concrete and transferable and (at least somewhat) objectively verifiable. How you ride a bicycle is tacit, but the fact that you can ride a bicycle is explicit. It's a binary fact that can be completely and compactly transferred through words, and that is verifiable through experiment. 60 60 - An event or fact is common knowledge among a group of people if everyone knows it, everyone knows that everyone knows it, everyone knows that everyone knows that everyone knows it, and so on. 61 61 - You do not think about things the same way as everyone else. 62 62 - - You may approach something analytically while others approach it intuitively — and both styles can yield the same end results! 62 62 + - You may approach something analytically while others approach it intuitively — and both styles can yield the same end results! 63 63 - Humans think in very different styles, related to how they use their senses while thinking. For example, some people see images during a conversation for each concept, others "feel" concepts in their body, others have explicit models that they update, and many have some combination. Also, some people can't imagine in images, and others can't store faces. It's very strange that we enter adult life without a shared understanding of this. 64 64 - Don't model the minds inside other people's brains as exactly the same as your own mind. Humans lack insight into their own minds and what is [common among everyone](https://slatestarcodex.com/2014/03/17/what-universal-human-experiences-are-you-missing-without-realizing-it/) or [unusually specific to a few](https://www.lesswrong.com/posts/baTWMegR42PAsH9qJ/generalizing-from-one-example). 65 65 - [We're all biased to our own personal history](https://www.collaborativefund.com/blog/ideas-that-changed-my-life/). Your personal experiences make up maybe 0.00000001% of what's happened in the world but maybe 80% of how you think the world works. 66 66 - - When thinking about any question, imagine yourself considering a similar question, under circumstances that would bias you the opposite direction. If you stick with your opinion, it’s probably honest; if you’d change your opinion in the counterfactual, you probably had it because of bias. 66 66 + - When thinking about any question, imagine yourself considering a similar question, under circumstances that would bias you the opposite direction. If you stick with your opinion, it's probably honest; if you'd change your opinion in the counterfactual, you probably had it because of bias. 67 67 - [Counterfactual tests to improve rationality](https://astralcodexten.substack.com/p/book-review-the-scout-mindset): 68 68 - - **Status Quo Test**: If you’re defending the status quo, imagine that the opposite was the status quo. Would you be tempted to switch to what you have now? 69 69 - - **Conformity Test:** Imagine that some common and universally-agreed idea was unusual; would you still want to do it? If not, you might be motivated by conformity bias. 70 70 - - **The Selective Skeptic Test:** How credible would you consider the same evidence if it supported the other side? 68 68 + - **Status Quo Test**: If you're defending the status quo, imagine that the opposite was the status quo. Would you be tempted to switch to what you have now? 69 69 + - **Conformity Test:** Imagine that some common and universally-agreed idea was unusual; would you still want to do it? If not, you might be motivated by conformity bias. 70 70 + - **The Selective Skeptic Test:** How credible would you consider the same evidence if it supported the other side? 71 71 - [Predictive processing](https://slatestarcodex.com/2017/09/05/book-review-surfing-uncertainty/) gives us more confidence in an admission that bias is possible, and a hope that there's something other than bias which we can latch onto as a guide. It helps provide a convincing framework we can use to figure out what's going on at all levels of cognition. 72 72 - An estimate is better than a guess. An measurement is better than an estimate. 73 73 - All points of view have complex context, many of which are predetermined by chance of birth, biology, and environment. There's no such thing as, "I only believe (x) because of (y)." our brains like simple, binary thinking, but real life is constantly challenging that impulse.

+5 -5

Writing Team Key Results.md

reviewed

··· 1 1 # Writing Team Key Results 2 2 3 3 - [One of the keys to effective team key results is making sure the whole team contributes to, and feels invested in, the process](https://clrcrl.com/2021/04/07/setting-team-krs.html) — it shouldn’t just be the team lead setting them for the team, or one team member setting them on behalf of everyone else. While we want every team member to contribute, it’s likely that not every team member is going to contribute in the exact same way — for example, a newer team member might not have enough context to generate KR ideas, but might have previous experience seeing KRs so can easily give feedback on a peer’s ideas. 3 3 + [One of the keys to effective team key results is making sure the whole team contributes to, and feels invested in, the process](https://clrcrl.com/2021/04/07/setting-team-krs.html) — it shouldn't just be the team lead setting them for the team, or one team member setting them on behalf of everyone else. While we want every team member to contribute, it's likely that not every team member is going to contribute in the exact same way — for example, a newer team member might not have enough context to generate KR ideas, but might have previous experience seeing KRs so can easily give feedback on a peer's ideas. 4 4 5 5 ## Properties 6 6 7 7 - The key result is a result, not a task (another framing: it's an outcome, not an input). 8 8 - The key result is measurable, both in the sense of we can clearly define what success looks like, and we have the data points available to you. 9 9 - - It may include a component that measures magnitude, and one that controls quality. 9 9 + - It may include a component that measures magnitude, and one that controls quality. 10 10 - The key result does not pre-suppose the exact program of works to do (and in fact leaves room for creative solutions). 11 11 - The key result states assumptions about why the team KR affects the top-level KR. 12 12 - The key result target should be informed by analysis. ··· 15 15 ## Process 16 16 17 17 1. Brainstorm draft KRs focusing more on the “shape” than the content. 18 18 - 2. State your assumptions. 19 19 - - Why does this team KR affect our company KR? 20 20 - - Why this target number? 18 18 + 2. State your assumptions: 19 19 + - Why does this team KR affect our company KR? 20 20 + - Why this target number? 21 21 3. Iterate and get feedback. 22 22 4. Lock it in. 23 23

+19 -19

Writing.md

reviewed

··· 3 3 ![[Quotes#^645051]] 4 4 5 5 - Writing things down helps clarifying [[Ideas]]. One of the tests of whether you understand something is whether you can explain it to someone else. [Writing doesn't just communicate ideas; it generates them](http://www.paulgraham.com/writing44.html). 6 6 - - Writing down your ideas shows you whether they have substance. Detecting when you're wrong is the first step to becoming right. There are many ways to record thought. Writing is the best for improving your [[Thinking]]. 7 7 - - Ideas can feel complete. It's only when you try to [put them into words](http://paulgraham.com/words.html) that you discover they're not. If you never subject your ideas to that test, you'll not only never have fully formed ideas, but also never realize it. 8 8 - - [Drawing can help visualize ideas](https://ralphammer.com/how-to-draw-ideas/). 6 6 + - Writing down your ideas shows you whether they have substance. Detecting when you're wrong is the first step to becoming right. There are many ways to record thought. Writing is the best for improving your [[Thinking]]. 7 7 + - Ideas can feel complete. It's only when you try to [put them into words](http://paulgraham.com/words.html) that you discover they're not. If you never subject your ideas to that test, you'll not only never have fully formed ideas, but also never realize it. 8 8 + - [Drawing can help visualize ideas](https://ralphammer.com/how-to-draw-ideas/). 9 9 - [Style is a small part of writing well. Most of writing is thinking clearly.](https://www.julian.com/guide/write/intro) The act of simply putting a thought into words makes it immediately obvious to you if you really understand it or not, and if not, where your blind spots are. For style: 10 10 - - **Be concise**. Understand the topic you're writing about. [Use simple words and sentences](http://www.paulgraham.com/simply.html). Put the most important things first. Never use a long word when a short one will do. 11 11 - - **Be Useful**. Before you start writing, ask yourself: What purpose does this serve? Who is going to read it? What do they need to know? 12 12 - - **Be specific**. Avoid vague language (remove qualifiers). Cut the fluff. Delete unnecessary words. Say what you mean. Make positive statements about reality. 13 13 - - **Be consistent**. 14 14 - - **Add rhythm**. Vary the sentence length to break the monotony. 10 10 + - **Be concise**. Understand the topic you're writing about. [Use simple words and sentences](http://www.paulgraham.com/simply.html). Put the most important things first. Never use a long word when a short one will do. 11 11 + - **Be Useful**. Before you start writing, ask yourself: What purpose does this serve? Who is going to read it? What do they need to know? 12 12 + - **Be specific**. Avoid vague language (remove qualifiers). Cut the fluff. Delete unnecessary words. Say what you mean. Make positive statements about reality. 13 13 + - **Be consistent**. 14 14 + - **Add rhythm**. Vary the sentence length to break the monotony. 15 15 - Use the active voice. 16 16 - Write in a conversational tone. Think about readers when writing. 17 17 - [Divide things into small chunks and if you have multiple points in a text, number them to make replies easier](https://slatestarcodex.com/2016/02/20/writing-advice/). List the points you want to make in a logical order. This allows you to remove the clutter and avoid confusion. Use the [Minto Pyramid](https://scqa.lifeitself.org/) or another standard structure like this one: 18 18 - - Define a clear thesis. State the main point before you 19 19 - give the reasoning that leads to it. 20 20 - - Support your thesis with arguments. 21 21 - - Declare and reject the antithesis. 22 22 - - Conclusions. 18 18 + - Define a clear thesis. State the main point before you 19 19 + give the reasoning that leads to it. 20 20 + - Support your thesis with arguments. 21 21 + - Declare and reject the antithesis. 22 22 + - Conclusions. 23 23 - Use positive language rather than negative language. 24 24 - Human beings are wired to respond to storytelling. A story arc is a way to structure ideas to tap into this response, typically by describing a change in the world. This applies to everything, e.g: [[Public Speaking]] 25 25 - Don't fully think through your ideas before writing. It's inefficient. The best way to think is by writing. It compels your brain to connect the dots. [Write whatever helps you think better](https://twitter.com/eugeneyan/status/1256828197410201601). 26 26 - - [Don’t try to _persuade_ people that the idea is true/good. Instead, try to accurately _describe_ where the idea came from, the path which led _you_ to think it’s true/plausible/worth a look. In the process, you’ll probably convey your own actual level of uncertainty, which is exactly the right thing to do.](https://www.lesswrong.com/posts/Psr9tnQFuEXiuqGcR/how-to-write-quickly-while-maintaining-epistemic-rigor) 26 26 + - [Don't try to _persuade_ people that the idea is true/good. Instead, try to accurately _describe_ where the idea came from, the path which led _you_ to think it’s true/plausible/worth a look. In the process, you'll probably convey your own actual level of uncertainty, which is exactly the right thing to do.](https://www.lesswrong.com/posts/Psr9tnQFuEXiuqGcR/how-to-write-quickly-while-maintaining-epistemic-rigor) 27 27 - Separate the processes of creation from improving. **You can't write and edit**. Write the first draft fast, then iterate on it editing things. Much of this editing will be cutting, and that makes simple writing even simpler. 28 28 - [Beware of "this"](https://www.lesswrong.com/posts/5e49dHLDJoDpeXGnh/editing-advice-for-lesswrong-users). Scan your words for words like "this" or "that", and when in doubt about clarity, replace them with whatever their intended antecedents are. 29 29 - You can use tools like [Hemingway](http://www.hemingwayapp.com/) or [Ludwig](https://ludwig.guru/) to improve. 30 30 - When writing tutorials or guides, use the second-person and describe actions to a user. These types of content talks to people when humans can't. [Technical documentation follows the same rules than normal writing](https://developers.google.com/tech-writing/one). 31 31 - - [Make it fun](https://davnicwil.com/tips-for-making-writing-more-fun/)! 31 31 + - [Make it fun](https://davnicwil.com/tips-for-making-writing-more-fun/)! 32 32 - The skills you learn by writing transfer to speaking. Being good at speaking makes you more persuasive. 33 33 - If it's not written down, it's not. 34 34 - - Good nonfiction has three qualities. 35 35 - 1. It gets to the point. 36 36 - 2. It is interesting. Written from your own experience, in your personal voice. 37 37 - 3. It is grounded in reality. 34 34 + - Good nonfiction has three qualities: 35 35 + 1. It gets to the point. 36 36 + 2. It is interesting. Written from your own experience, in your personal voice. 37 37 + 3. It is grounded in reality. 38 38 39 39 ## Executable Writing 40 40