chore: 🎨

Antifragility.md

@@ -3,7 +3,7 @@
 Antifragility is a property of [[systems]] that increase in capability, resilience, or robustness as a result of stressors, shocks, volatility, noise, mistakes, faults, attacks, or failures. It's fundamentally different from the concepts of resiliency (ability to recover from failure) and robustness (ability to resist failure).
 
 - Antifragility is beyond resilience or robustness. **The resilient resists shocks and stays the same. The antifragile gets better**.
-- Antifragile systems benefit from a process of trial and error. [[Experimentation]] and [[Learning]] from failures are essential for improving and evolving.
+- Antifragile systems benefit from a process of trial and error. [[experimentation]] and [[learning]] from failures are essential for improving and evolving.
 - [[Evolution]] is antifragile.
   - In a stable system, animals won't evolve. In a volatile system, they will.
   - [A little bit of disorder is good](https://astralcodexten.substack.com/p/book-review-antifragile). [[Evolution]] is a system that allows volatility rather than unwisely trying to buffer against it.

Company Knowledge Management.md

@@ -57,10 +57,10 @@ There are some basic principles and [[values]] that will make maintaining and ev
 Whenever you need to thoroughly brief a group of people on an important matter, consider using a [5-paragraph format](https://xahteiwi.eu/resources/presentations/no-we-wont-have-a-video-call-for-that/):
 
 1. Situation. What position you're in, and **why** you set out to do what you want to do.
-2. Objective.  **What** you want to achieve.
-3. Plan.  **How** you want to achieve it.
+2. Objective. **What** you want to achieve.
+3. Plan. **How** you want to achieve it.
 4. Logistics. What budget and resources are available, and how they are used.
-5. Communications.  How you’ll be coordinating among yourselves and with others in order to achieve your goal.
+5. Communications. How you’ll be coordinating among yourselves and with others in order to achieve your goal.
 
 ## Resources
 

Conceptual Compression.md

@@ -2,6 +2,6 @@
 
 ![[Quotes#^7fe266]]
 
-From time to time, look for abstractions that can compress the information behind them. This way you can reduce mental space. When needed, you can expand the abstraction and go deeper. This is used a lot in [[Programming]], where a new tool or package emerges taking care of that was previously done by human minds (OMRs vs hand written SQL)!
+From time to time, look for abstractions that can compress the information behind them. This way you can reduce mental space. When needed, you can expand the abstraction and go deeper. This is used a lot in [[programming]], where a new tool or package emerges taking care of that was previously done by human minds (OMRs vs hand written SQL)!
 
 Conceptual compression also allows lazy [[learning]]. If you're using the compressed version you don't need to care about what's behind. If you need, you can learn it at that time. Not everything needs to be learned upfront.

Curiosity.md

@@ -2,7 +2,7 @@
 
 ![[Quotes#^307613]]
 
-- Never stop [[Learning|learning]], practice [[Thinking|rational]] thinking and internalize [[mental models]] and other concepts that will help you think more effectively.
+- Never stop [[learning]], practice [[Thinking|rational thinking]] and internalize [[mental models]] and other concepts that will help you think more effectively.
 - 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.
 - [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).
 - 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.
@@ -11,5 +11,5 @@
   - [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.
 - [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.
 - [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.
-- Knowing we really want is hard and takes effort. Explore yourself and your [[Values]].
+- Knowing we really want is hard and takes effort. Explore yourself and your [[values]].
 - Experiment more! It is very very easy to do what comes naturally and never deviate from that. Break the pattern.

Data/Analytics Engineering.md

@@ -1,8 +1,9 @@
 # Analytics Engineering
 
-- Analytics engineering is the organization of an organization’s information.
+- Analytics Engineering is the organization of an organization's information.
 - [Real impact comes from continuous decision-making and implementing actions with feedback](https://news.ycombinator.com/item?id=22808006).
-- [Analytics is a mess](https://benn.substack.com/p/analytics-is-a-mess). Explicitly create separate workspaces for curated (production) and messy (experimental, not-yet-production) work.
+- Accept that [analytics is a mess](https://benn.substack.com/p/analytics-is-a-mess).
+  - Explicitly create separate workspaces for curated (production) and messy (experimental) work.
 - Reports are rarely read, and often forgotten. [[Data Culture|Decision-making involves getting data, summarizing and predicting ad then taking action]].
   - One of the best ways to communicate data is telling stories. Stories are more captative and present a coherent view around a topic.
 - [The analytics engineer workload is a lot like being a data librarian](https://www.youtube.com/watch?v=T0Z_ibd3Hx0).
@@ -14,16 +15,16 @@
 - Analytics work can be roughly split in two buckets:
   1. Building automated [[Systems]], from metrics to [[Dashboards]], to enable self-service use cases for business users. This is what we now typically call analytics engineering.
   2. Doing ad-hoc analyses, to answer some questions directly.
-- Attach date to data team resources ([[Dashboards]], analysis, ...) so they exist as artifacts that were true at a certain point on time.
 - Make your modeling approach explicit (e.g. [Dimensional Modeling](https://youtu.be/lWPiSZf7-uQ)).
-- Modeling reality always get complex quickly. There are always small nuances, special conditions, things that changed, edge cases and, of course, errors.
-- Imagine your company today as a human society where only half the population can read (understand the data), one tenth can write (SQL queries), where half a dozen languages are spoken, and where most of the books ([[Dashboards]]/insight reports) in the library contain things that once were true but have since been outdated (but you don’t know which ones). Not a highly productive information ecosystem.
-- [[Teamwork|Collaborate with your team]] and break down complex models into reusable pieces.
+- Modeling reality gets complex quickly. There are small nuances, special conditions, things that changed, edge cases and, of course, errors.
+- Imagine your company today as a human society where only half the population can read (understand the data), one tenth can write (SQL queries), where half a dozen languages are spoken, and where most of the books ([[Dashboards]]/insight reports) in the library contain things that once were true but have since been outdated (but you don't know which ones). Not a highly productive information ecosystem.
 - Domain knowledge is more important than your coding skills.
-- Ground truth isn't a single place. Start by joining on common unique keys and counting things, then figure out what’s different and why.
+- Ground truth isn't a single place. Start by joining on common unique keys and counting things, then figure out what's different and why.
+- [[Teamwork|Collaborate with your team]] and break down complex models into reusable pieces.
 - Working with data is like exploring the horizon. It changes as soon as you look it from a higher place (more data).
-- Reduce the areas where business logic can be injected, create “time to live” policies on last mile transforms, build a culture of standardizing + celebrating access to cross-functional codebases.
-  - People default to writing business logic in the tool they are most comfortable with. The best way for data teams to prevent sprawling business logic is not just to limit last mile transforms in other tools, but also to invite others into their tools. [This logic will be written, and if the data team gate-keeps, it will be written outside of their visibility](https://ian-macomber.medium.com/data-systems-tend-towards-production-be5a86f65561). If a data team can educate and encourage contributions to their codebase, they invite code to be written where it most belongs.
+- Attach a date to your team output resources ([[Dashboards]], analysis, ...) so they exist as artifacts that were true at a certain point on time.
+- Reduce the areas where business logic can be injected, create "time to live" policies on last mile transforms, build a culture of standardizing + celebrating access to cross-functional codebases.
+  - People default to writing business logic in the tool they are most comfortable with. The best way for data teams to prevent sprawling business logic is to limit last mile transforms in other tools and invite others into their tools. [The logic will be written, and if the data team gate-keeps, it will be written outside of their visibility](https://ian-macomber.medium.com/data-systems-tend-towards-production-be5a86f65561)! If a data team can educate and encourage contributions to their codebase, they invite code to be written where it most belongs.
 - Modern data warehouses [might need new model design paradigms](https://github.com/ActivitySchema/ActivitySchema/blob/main/2.0.md).
 
 ## Resources

Data/Experimentation.md

@@ -45,7 +45,7 @@ You can use [online calculators](http://experimentcalculator.com/) to estimate t
   - Define Guardrail metrics: This helps us ensure we are not harming the business in the long run for short-term gains.
 - Experiment design & implementation
   - Rollout plan
-  - Implementation [[Checklist]] (docs are present, tested on staging, marketing coordination, ...)
+  - Implementation [[checklist]] (docs are present, tested on staging, marketing coordination, ...)
 - Known Assumptions
 
 ## Experimentation Mindset

Data/Metrics.md

@@ -2,21 +2,20 @@
 
 ![[Quotes#^a5049d]]
 
-- 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).
+- Aim for a single **"North Star Metric"** alongside 3 to 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).
   - [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).
-- Metrics should use the SMART framework (Specific, Measurable, Achievable, Results-Oriented, Targeted).
-  - Pick the simplest metric that works for you. Metrics definitions should be as easy as a tool-tip away to find.
-- [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.
 - Common understanding of a metric matters more than the metric precision. That understanding requires some standardization (names, time spans, ...) and that needs [[Coordination]].
   - Teams need to cooperate when defining metrics.
+- Rely on the SMART framework (Specific, Measurable, Achievable, Results-Oriented, Targeted).
+  - Pick the simplest metric that works for you. Metrics definitions should be as easy as a tool-tip away to find.
+- [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.
 - Organizations need three things related to metrics:
   1. A [[Metrics|process for defining metrics]].
   2. A single source of truth for the metrics.
   3. A way to get metrics to all systems.
 - 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.
 - Push a culture of metrics and goals as a source of learning, not promotions or success delegation.
-- 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.
-- Vanity metrics are surface-level metrics. They’re often large measures, like number of downloads, that impress others. **Clarity metrics** are operational metrics, like the number of minutes a day your product actually gets used or how long it took for a user to get service. These are the hidden gears that drive growth.
+- Vanity metrics are surface-level metrics. They're often large measures, like number of downloads, that impress others. **Clarity metrics** are operational metrics, like the number of minutes a day your product actually gets used or how long it took for a user to get service. These are the hidden gears that drive growth.
 
 ## Good Metric Checklist
 
@@ -38,7 +37,7 @@ Remember that there are no objectively right answers. [There is no correct win r
 
 - 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.
 - 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... 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.
-- 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.
+- 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.
   - When output metrics are given as goals, teams can often focus on the wrong inputs or thrash between inputs.
   - 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.
 - 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.

Data/Open Source Data Projects.md

@@ -6,7 +6,6 @@
 - [Seafowl](https://github.com/splitgraph/seafowl)
 - [Risingwave](https://github.com/risingwavelabs/risingwave)
 - [Databend](https://github.com/datafuselabs/databend)
-- [Tensorbase](https://github.com/tensorbase/tensorbase)
 
 ## Data Tracking