Roam Notes on “Working in Public” by Nadia Eghbal

  • Title:: Working in Public: The Making and Maintenance of Open Source Software
  • Author:: [[Nadia Eghbal]]
  • Recommended By:: [[Patrick Collison]]
  • Reading Status:: #complete
  • Review Status:: #[[first pass]]
  • URL:: link
  • Tags:: #books #[[Open Source]] #[[Open Collaboration]] #[[platforms]] #[[history of software]] #[[history of open source]] #[[online creators]] #[[online content creation]]
  • Source:: #kindle
  • Roam Notes URL:: link
  • Anki Tag:: working_in_public_eghbal
  • Anki Deck Link:: Get Anki Deck
  • Summary
    • [[Nadia Eghbal]] examines how [[Open Source] works today, how it has evolved to this state over time, and where it may be headed. Although the book is specifically about open source on the surface, much of it applies to all [[online content creation]] and [[online creators]]. Some of the main themes of the book include:
      • Creator attention is a [[common pool resource]] that must be protected through [[curation]] and filtering, rather than blindly encouraging more open participation.
      • Key [[open source contributions]] coming from a small number of very important creators / maintainers, rather than a large community.
      • Trends toward [[modularity]] of code and other online content.
      • Increased importance of [[curation]] for creators as the key problem to solve as they grow.
      • The extractive nature of many activities masked as "contributions", such as low-quality comments, questions, [[feature requests]], or [[pull requests]] that consume the limited [[attention]] of creators. #[[extractive contributions]] #[[casual contributors]]
        • ""Casual contributors are like tourists visiting New York City for a weekend. Just as we wouldn’t expect, or even want, tourists to participate in local governance decisions, we shouldn’t assume that casual contributors are part of a project’s contributor community simply because they are physically present." (Location 1569)"
        • ""The problem with the Christmas lights isn’t that anyone can drive by and view them. A problem only surfaces if we think our neighbor owes us anything; if we cross the invisible boundary and knock on his door, making demands and requesting changes." (Location 2535)"
      • Trends toward following creators themselves rather than particular artifacts (e.g. code repositories) produced by creators.
    • Nadia also expounds a valuable nomenclature for talking about open source and online content. I particularly liked her categorization of open-source projects based on the ratio of contributors to users:
      • "4 main influencers that determine the ratio of a project’s users to contributors: (Location 809) #[[growing open source projects]]"
    • The book is filled with lots of interesting stories and quotes from open-source developers.
  • Introduction
    • People typically think [[open source software]] is built by large communities where many pitch in. In reality, they are typically developed by a small number of important [[maintainers]], who often are overwhelmed and stressed by having to deal with a large number of low-quality contributions. (Location 70) (Location 74) #Ankified
    • "One study found that, in a sample of 275 popular [[GitHub]] projects across various programming languages, nearly half of all contributors only contributed once. These [[contributors]] accounted for less than 2% of total commits, or overall contributions." (Location 85) #Ankified
    • This isn’t necessarily a problem, but many see it as an issue, as there is even a term called [[bus factor]] to measure project health: the number of developers that would need to get hit by a bus before the project is in trouble. (Location 106) #Ankified
    • "Code, like any other type of content available online today, is trending toward [[modularity]]: a mille-feuille layer cake of little libraries instead of one big, jiggling Jell-O mold." (e.g. [[npm]]). This contributes to the small number of maintainers per project. (Location 114)
    • "The role of a [[maintainer]] is evolving. Rather than coordinating with a group of [[developers]], these maintainers are defined by the need for [[curation]]: sifting through the noise of interactions, such as user questions, [[bug reports]], and [[feature requests]], which compete for their [[attention]]." (Location 129)
    • "The problem facing [[maintainers]] today is not how to get more [[contributors]] but how to manage a high volume of frequent, low-touch interactions. These developers aren’t building communities; they’re directing air traffic." The role of [[maintainer]] is evolving to [[curation]], sifting through many things that compete for their [[attention]], like [[bug reports]] or [[feature requests]] (Location 134) #Ankified
    • "In the late 1990s, open source was the poster child for a hopeful vision of widespread public collaboration, then dubbed “[[peer production]]."" (Location 180) #Ankified
  • Part 1: How People Make
    • 01. [[GitHub]] as a Platform
      • THE LIBERATION OF CODE
        • Before code hosting platforms, developers passed around code as a [[tarball]] (.tar file). Most open source code was published this way on a self-hosted website, and developers used [[mailing lists]] to collaborate. (Location 222) #Ankified
        • [[distributed version control]] (e.g. [[Git]]) was an important innovation for open source, since it make it technically possible for developers to work independently from one another, working on their own copy. [[centralized version control]] required developers to commit code back to the same server (Location 231) #Ankified
        • "[[Richard Stallman]] (also known as RMS) was the hacker who kicked off the [[free software movement]] at [[MIT]] in the [[1980s]]. [[Eric S. Raymond]] (also known as ESR), the programmer who helped rebrand [[free software]] to “[[Open Source]]” in the [[1990s]], is widely viewed as early open source’s unofficial anthropologist. And [[Linus Torvalds]] is the programmer who created both [[Linux]], the open source kernel that powers many of today’s operating systems, in 1991, and [[Git]], in 2005." (Location 260)
      • THE TRIUMPH OF CONVENIENCE (Location 325)
        • Another big innovation popularizing open source was code hosting, particularly [[GitHub]]. "[[GitHub]] wasn’t the first [[code-hosting platform]]. It was preceded by [[SourceForge]], founded in 1999. If GitHub is like Facebook, SourceForge was the MySpace of code-hosting platforms: the first significant product of its kind, and, though still alive today, mostly remembered as a blueprint." (Location 328) #Ankified
        • [[GitHub]] popularized [[permissive licensing]], increasing reach and distribution of open source code, whereas [[free software movement]] emphasized [[copyleft licensing]] (e.g. [[GNU General Public License (GPL)]]). The problem with copyleft licenses is they require any other code used with the GPL code to be GPL licensed as well (not commercial friendly): a private company would have to make all their code licensed under GPL if they used GPL licensed code. [[permissive licensing]] allows developers to do pretty much anything they want with the code (e.g. [[Berkeley Software Distribution (BSD)]], [[Massachusetts Institute of Technology (MIT) license]]) without changing the terms of their own projects. (Location 349) #Ankified
        • [[Massachusetts Institute of Technology (MIT) license]] is by the most popular license used by [[GitHub]] projects. "A 2015 company blog post claimed that 45% of open source projects use it." (Location 356) #Ankified
        • [[platforms]] like [[GitHub]] add value to [[creators]] by providing [[distribution]] (i.e. an audience). This is like a talent agency, except creators can take their audience elsewhere once they get it. So, platforms build convenient features for creators that encourage them to stay (Location 392) (Location 397) action=open&asin=B08BDGXVK9&location=404)) #Ankified
      • FROM HACKERS TO HUSKIES (Location 447)
        • Developers are increasingly known not for a specific project they work on (e.g. [[Linus Torvalds]] and [[Linux]]), but for who they are (Location 478).
        • This is particularly true in the [[JavaScript]] community.
      • THE GITHUB GENERATION (Location 548)
    • 02. The Structure of an Open Source Project
      • HOW CONTRIBUTIONS ARE MADE (Location 631) #[[contributing to open source]]
        • Changes to [[Open Source]] are not completely open to anyone. Developers submit a [patch] (aka [[pull request]] in [[GitHub]]) and these are reviewed and approved by prior trusted contributors. (Location 634)
        • "Some developers have permission to merge changes into the trunk (or master), which is the baseline version of the project. Having these permissions is often referred to as [[commit access]], which is like being able to edit a shared document." (Location 637) #Ankified
          • "The process by which a developer gains [[commit access]] varies widely between projects and is subject to preexisting social norms." (Location 656)
        • "Bigger projects often use a formal “request for comments” ([[RFC]]) process to allow communities to discuss these changes before they are merged." (Location 641)
        • Developer reputation as well as complexity of the change are some of the biggest factors determining whether a [[pull request]] is merged. (Location 673) (Location 680)
      • WHERE INTERACTIONS TAKE PLACE (Location 711) #[[open source work]]
        • An open source project isn’t just code. Typically [[repository]] refers to the code, while [[project]] refers to the broader tools and communication channels surrounding the code. (Location 714)
        • [[GitHub]] [[issues]] and [[pull request]] help it maintain a competitive advantage, since it’s not easy to migrate these between platforms. (Location 733)
      • HOW PROJECTS CHANGE OVER TIME (Location 754) #[[open source project evolution]]
        • Stages of open source project evolution (Location 757): #Ankified
          • Creation: Early stage, with few developers and closed development.
          • Evangelism: Project release, promotion, and distribution, transitioning to more open development.
          • Growth: Project more widely used, maintainers start doing more non-code than code work (e.g. triaging issues, reviewing pull requests).
            • Maintainers typically follow one of two paths here: i) If there’s few contributors they’ll start pull back to closed, focused development. ii) If the contributors are growing rapidly, they may follow a distributed model that passes off work more widely.
      • CLASSIFYING PROJECT TYPES (Location 804)
        • 4 main influencers that determine the ratio of a project’s users to contributors: (Location 809) #[[growing open source projects]]
          • Technical scope: Projects with more to do attract more contributors.
          • Support required: Including writing code (the stuff considered fun work by developers) and other supporting tasks like reviewing pull requests.
          • Ease of participation: The ease of contributing to the project.
          • User adoption: More users usually means more contributors.
        • The ratio of contributors to users lets us classify open source projects into four main categories (Location 862): #Ankified
          • [[federations (open source)]]: Many contributors, many users (e.g. [[Rust]], [[Node.js]], [[Linux]])
          • [[clubs (open source)]]: Many contributors, few users (many users are contributors).
          • [[toys (open source)]]: Few contributors, few users (side project / weekend project).
          • [[stadiums (open source)]]: Few contributors, many users (e.g. [[webpack]], [[Babel]]).
    • 03. Roles, Incentives, and Relationships
      • Open source projects are often best described as a [[commons]]: a resource that is owned, used, and managed by a community. (Location 1041)#Ankified
      • A THEORY OF THE COMMONS (Location 1044) #commons
        • Economist [[Elinor Ostrom]] studied conditions leading to well-managed commons that avoid the [[tragedy of the commons]]. [[Ostrom commons design principles]]:
          • Membership boundaries are clearly defined.
          • The rules that govern the commons should match the actual conditions.
          • Those who are affected by these rules can participate in modifying them.
          • Those who monitor the rules are either community members or are accountable to the community, rather than outsiders.
          • Those who violate the rules are subject to graduated sanctions, which vary depending on the seriousness and context of the offense. #punishment
          • Conflicts should be resolved within the community, using low-cost methods. #[[conflict resolution]]
          • External authorities recognize the right of community members to devise their own [[institutions]].
          • If the commons is part of a larger system, its governing rules are organized into multiple “nested” layers of [[authority]]. (Location 1044)
      • WHY WE PARTICIPATE IN THE COMMONS (Location 1074) #commons
        • [[Yochai Benkler]] expanded upon [[Elinor Ostrom]]’s model by applying her findings to the online world. He terms this [[communal structure commons-based peer production]] (CBPP) in a 2002 essay called “Coase’s Penguin, Or, Linux and ‘The Nature of the Firm.’” (Location 1075) #[[To Read]]
        • His work focuses on why people participate in [[commons]]. Conditions for it to work include: [[intrinsic motivation]], modular and granular tasks, and low [[coordination]] costs. (Location 1082) (Location 1103). In open source, the main coordination costs are [[reviewing code]] and merging [[pull requests]] (Location 1122). #modularity
        • Projects that involve a [[commons]] ([[federations (open source)]] and [[clubs (open source)]]) are focused on resolving coordination issues, while projects without a commons ([[stadiums (open source)]]), focus on curation due to the scarcity of attention of the creator. (Location 1142)
      • HOW PLATFORMS BROKE APART THE COMMONS (Location 1156) #commons
        • Communities need to protect themselves from potentially damaging actions of newcomers, who can destabilize the community’s pre-existing [[social norms]]. (Location 1220)
        • It’s difficult for maintainers to defer decisions to the community, given the lack of clear membership boundaries. "Countries have citizenships and constituencies, but open source projects are open to anyone." (Location 1235) #[[Ostrom commons design principles]]
      • THE ROLE OF A MAINTAINER (Location 1346) #maintainers
        • "although maintainers are few in number, their impact on an open source project is far-reaching, because they’re the bottleneck to everyone else’s contributions." (Location 1366)
        • Ideally, a project will attract [[creators]] and [[curators]] to serve as co-maintainers (developers tend to be more excited about creating, so curators are particularly valuable) (Location 1421)
        • Long-term maintenance does not typically sharpen your developer skills. After a while, maintainers typically take one of the following paths:
          • They might enjoy cultivating non-development skills like [[project management]] or [[leadership]].
          • They figure out how to distribute the work to contributors and users or other methods to reduce the overall time they spend on undesirable tasks.
          • They step down, find a replacement, or disappear. (Location 1445)
        • Like a CEO, maintainers tend to be locked into the project – leaving would have serious consequences for the health of the project. (Location 1462)
        • Another interesting property of project maintainers is that publication of the project is not the end of the work, in contrast to publishing books. Once published, maintainers are expected to maintain as long as people use it. (Location 1487)
      • ACTIVE AND CASUAL CONTRIBUTORS (Location 1495) #contributors
        • Typical active contributor motivations are [[community]], [[reputation]], and [[learning]]. (Location 1537)
        • [[casual contributors]] (aka “drive-by contributors”) have a transactional relationship with the project. They mainly just want to see their contributions merged. "self oriented rather than community oriented" (Location 1547) (Location 1566)
        • "Casual contributors are like tourists visiting New York City for a weekend. Just as we wouldn’t expect, or even want, tourists to participate in local governance decisions, we shouldn’t assume that casual contributors are part of a project’s contributor community simply because they are physically present." (Location 1569)
        • [[GitHub]] has encouraged growth of casual contributors by lowering the friction to contribute and increasing the number of users of open source projects (Location 1597)
      • ACTIVE AND PASSIVE USERS (Location 1616) #users
        • Active users are like active contributors, but they tend to operate independently from the project’s contributors, and possibly haven’t interacted with the project’s repository at all. (Location 1656)
      • ASSESSING THE HEALTH OF A PROJECT (Location 1673) #[[open source project health]]
        • 3 success metrics: (Location 1677)
          • POPULAR: # people using the project. (Location 1678)
          • DEPENDED UPON: how much other software actively uses the project (Location 1679)
          • ACTIVE: the project is actively developed (Location 1681)
            • Commits, issues, pull requests (# open issues and pull requests, average time to first response, average time to close an issue or pull request)
            • Some projects don’t require much maintenance. In these cases, look at activity off [[GitHub]] (e.g. Stack Overflow) (Location 1740)
        • [[bus factor]]: is the number of contributors that would need to get hit by a bus before the project is compromised. (Location 1697)
        • Contributor count can be misleading, especially for [[stadiums (open source)]], since this metric assumes contributors are fungible (i.e. interchangeable). (Location 1709)
  • Part 2: How People Maintain
    • 04: The Work Required by Software
      • CODE AS ARTIFACT, CODE AS ORGANISM (Location 1801)
        • Software evolves over time and requires continuous maintenance. [[greenfield projects]], where developers get to write code from scratch, are actually rare (and coveted) – developers spend more time tending to code others wrote. (Location 1808)
        • "[[Fergus Henderson]], a software engineer at [[Google]], states that “most software at Google gets rewritten every few years.” Software changes over time as its environment—the other technology around it—changes. Henderson also points out that regularly rewriting software is inherently beneficial. It helps cut away unnecessary complexity that has accumulated over time, as well as transfer knowledge and a sense of ownership to newer team members." (Location 1816) #[[rewriting software]]
        • "The cost of maintenance, coupled with a lack of intrinsic motivation to maintain, is why large open source projects tend to become modular as they grow." (Location 1820) #modularity
        • [[forking]] is an option to exit a project, but you have to consider dependencies and upkeep required. Most projects in reality are unforkable due to these other factors. The project is more than just the code. (Location 1913)
      • THE HIDDEN COSTS OF SOFTWARE (Location 1926) #[[software costs]]
        • Three major types of software costs: [[creation]], [[distribution]], and [[maintenance]]. (Location 1927)
          • Creation is intrinsically motivated, distribution powered by platforms such as [[GitHub]] and cheap. Maintenance is a bit of a mystery, and it’s a big cost: "A 2018 Stripe study of software developers suggested that developers spend 42% of their time maintaining code." (Location 2074)
        • Two main kinds of maintenance costs: [[marginal maintenance costs]] and [[temporal maintenance costs]]. Software incurs ongoing maintenance costs, both marginal (costs that are a function of its users) and temporal (entropy, or costs associated with decay over time). (Location 1931)
          • [[marginal maintenance costs]]
            • Software has low [[marginal costs]] but, contrary to popular belief, they are not 0. If you think of code as static, then yes it’s 0 marginal cost, but when maintenance is involved marginal costs add up. Software is not quite completely [[non-rivalrous]] – if 10 people use software compared to 10,000 the developers will feel the difference. (Location 1941)
            • Some of the costs that increase with users include physical inrastructure (Location 1977), developer tools (Location 2009), user support (Location 2011), and community moderation (Location 2050).
          • [[temporal maintenance costs]] (Location 2069)
            • These costs are a function of [[entropy]]: the inevitable decay of systems over time.
            • [[technical debt]] (Location 2079): Choosing easier, faster options today that cost time and money to address later on.
            • [[test infrastructure]] (Location 2092): Tests are added over time as the project expands, with increased opportunity for slow or flaky tests. "One maintainer of a large open source project told me that running his CI service took an hour and a half per pull request, yet he was expected to review and merge forty to fifty pull requests per day."
            • [[dependency management]] (Location 2110)
            • Adapting to user needs (Location 2168)
      • MEASURING THE VALUE OF CODE (Location 2219)
        • DEPENDENCIES (Location 2323) #[[dependencies]]
          • Dependencies are an indicator of the value of software, because it means others are using it.
          • That being said, dependency doesn’t tell the whole story of value, since it might still be really easy to replace (i.e. high [[substitutability]]).
          • Open source code tends to be highly [[elastic]] (i.e. consumers sensitive to price changes, willing to switch to competitors).
        • REPUTATION (Location 2380)
    • 05: Managing the Costs of Production
      • If open source software is a [[public good]], should it be provided by the government? (Location 2475). Government is ill-suited to do this given that open source code is transnational (governments are beholden to national interests). Also, software moves too fast – the law can’t keep up.
      • A good example of government failure in this area is open source [[cryptography]]. In the [[1970s]] and [[1980s]], developers used [[Data Encryption Standard (DES)]], but the [[National Security Agency (NSA)]] changed it to make it weaker so they could break it. Open source developers eventually created [[Pretty Good Privacy (PGP)]], but this cryptography was considered a form of munitions in the United States because it overlapped with national security – developers working on open source cryptography had to become licensed arms dealers if they wanted to "[[export]]" (i.e. distribute) their code! Eventually, the US dropped these export controls. (Location 2484)
        • Hilarious workaround: the US State Department ruled code on a floppy disk couldn’t be exported, but books containing code was allowed (protected under [[freedom of speech]]). So the PGP developers published a book called PGP Source Code and Internals.
      • This is a big reason why [[Elinor Ostrom]]’s work is gaining popularity – she provides a framework for understanding how people can self-manage [[non-excludable]] resources without resorting to government. (Location 2503)
      • "The problem with the Christmas lights isn’t that anyone can drive by and view them. A problem only surfaces if we think our neighbor owes us anything; if we cross the invisible boundary and knock on his door, making demands and requesting changes." (Location 2535)
      • PRODUCTION AS A ONE-WAY MIRROR (Location 2548)
        • Managing open source code requires separating its [[production]] from [[consumption]]. (Location 2551)
        • From a consumption perspective, static open source code is a [[public good]]. Its value can be measured by its number of [[dependencies]] and [[substitutability]].
        • From a production perspective, open-source code is more like a [[commons]] (i.e. [[non-excludable]] and [[rivalrous]]), where maintainer [[attention]] is the rivalrous resource. (Location 2572) "When developers make contributions, they appropriate this attention from the commons." (Location 2584)
        • "To reduce the over-appropriation of attention in open source software, we can think of its production as a one-way mirror, where we design for the parasocial, or one-sided, relationships that are endemic to [[stadiums (open source)]], rather than for the interpersonal relationships that are associated with [[clubs (open source)]]." (Location 2589)
        • In this model, users can consume the code, but would have limited access to things that consume maintainer time, like pull requests or mail lists. Maintainers should avoid [[extractive contributions]], i.e. contributions where the marginal cost of reviewing and merging outweighs the marginal benefit to the project’s producers (e.g. comments, questions, feature requests). (Location 2632) Fear of appearing unsympathetic or unwelcoming often keeps maintainers reviewing extractive contributions. (Location 2681) #Ankified
        • Non-extractive casual contributions are often modular, granular, and require little input from maintainers. (Location 2666)
      • MANAGING PRODUCER ATTENTION (Location 2700) #maintainers #attention
        • Typical patterns maintainers use to manage their [[attention]]: (Location 2700)
          • Reduce up-front costs
          • Make themselves less available
          • Distribute costs onto users
          • Increase total attention available
        • REDUCING UP-FRONT COSTS (Location 2726)
          • [[continuous integration]] and [[automated tests]] are valuable for open source, as it makes maintainers more confident in merging code from people they don’t know (Location 2774) (Location 2781)
          • [[bots]] (Location 2786)
          • [[Code style guides]] and [[linters]] (Location 2799)
          • Templates and [[checklists]] for [[issues]] and [[pull requests]]. "Among the top hundred projects on GitHub by issue volume in 2018, 93% of projects used issue templates." (Location 2806)
        • LIMITING AVAILABLE ATTENTION: THE N=1 APPROACH (Location 2824)
          • Some developers make themselves less available. One technique coined by [[Philip Guo]] is the "n=1 approach", where you only have 1 developer, since going from 1 to 2 developers is the biggest jump. Don’t accept pull requests, although they may look at them for ideas – they serve more as comments or suggestions. This may inspire the developer, without imposing the technical and social costs of merging others’ code. (Location 2845) #Ankified
          • Some use a tiered approach, devoting more personal attention as a person makes more contributions (e.g. [[Mike McQuaid]] – Homebrew’s lead maintainer). (Location 2846)
        • DISTRIBUTING COSTS: USER-TO-USER SYSTEMS (Location 2860)
        • MEETING DEMAND: INCREASE AVAILABLE ATTENTION (Location 2911)
          • Bring on more active contributors or find ways they can personally spend more attention on the project (Location 2921)
      • THE ROLE OF MONEY IN OPEN SOURCE (Location 2961)
        • Maintainers can make their attention [[excludable]] by charging for access (e.g. paid support, [[patronage]], [[bounties]]) (meaning, paid rewards for certain tasks or contributions) (Location 2991)
        • WHO FUNDS OPEN SOURCE DEVELOPERS, AND WHY (Location 2995)
          • Two types of funders of open source: institutions (usually companies) and individuals (usually developers who are users). (Location 2996)
          • Companies tend to fund due to their desire for [code quality] – they pay for support or [[service level agreements (SLAs)]]. Essentially, they pay for a direct line to a project’s maintainers (Location 3012). Some maintainers host office hours for high-paying supporters, while others may work on retainer to provide corporate support. This can sometimes lead to a full-time hire. These kind of arrangements aren’t usually publicized (Location 3030)
          • Companies may pay for brand association (Location 3044).
          • People often use the words "should" or "ought" when talking about individuals funding open source. This book focuses on why an individual might be happy to drop cash on a project (Location 3112).
          • Individual developers are less likely to pay for open source code and instead sponsor people behind the code, based on reputation (Location 3113). As content creators, the typical reward is reputation gains, which they can convert into [[attention]] (i.e. an audience), which they can then convert into [[money]] (Location 3115).
          • [[patronage]] is increasingly popular, and not to be confused with donations. It’s more of a subscription – people pay to be closely connected with the creator’s work (Location 3118). We should think of open source developers as content creators, and content creators can make money in ways other than being hired be someone: "Can we imagine telling Tfue, who rose to fame by livestreaming himself playing Fortnite Battle Royale on Twitch, that the most he could hope for was to get hired by ESPN" (Location 3146)
        • WHERE THE MONEY GOES (Location 3214)
          • Compensating casual contributors makes no sense, because it’s like paying people to leave comments on a creator’s work, there’s no shortage of casual contributions, and casual contributors are already motivated to participate. (Location 3259) "If anything, it’s casual contributors who should be paying for access to maintainers, not the other way around" (Location 3266)
          • [[bounties]] work well for well-scoped, finite tasks that are specialized or difficult to attract talent for (e.g. design work, database migrations, security bugs) (Location 3279)
          • Funding individuals is an option which avoids centralized governance issues that come from funding projects. To fund projects, the developers need a legal entity to accept the funds, and define governance processes to manage who gets paid and how much. As projects get smaller and smaller, funding people becomes even more attractive (Location 3309)
          • Funding individuals is more difficult for organizations – they prefer funding projects for the benefits of code security and stability, influence, attracting talent to hire. Funding individuals is more like hiring to them – hard to pull off in terms of execution and making the case internally (Location 3349).
  • CONCLUSION
    • The value of [[platforms]] comes mostly in the [[social graph]] you build on it, not the content itself. "Our relationship to content matters less than our relationships to the people who make it. As a result, we’re starting to treat content not as a private economic good but as the externalization of our social infrastructure." (Location 3402)
    • "I’ll spend the final pages zooming out in order to explore how what we’ve learned can be applied not just to open source developers but other [[online creators]]. I’ll focus on two areas in particular: the problem of [[managing over-participation]] and the problem of [[making money]]." (Location 3441)
    • MANAGING OVER-PARTICIPATION (Location 3445)
      • Similarly to what was described with open source maintainers, growing audience engagement extracts attention from the creators. It’s essential to find a way to manage this demand, especially when it is extractive (e.g. comments, direct messages). (Location 3447)
      • Options for creators at these later stages include: hiding / muting interactions (Location 3517) and encouraging the role of curator (Location 3524).
    • MAKING MONEY (Location 3557) #[[making money]]
      • [[paywalls]] are not to monetize content. They monetize community by allowing the audience to get closer to the creator, meet like-minded people, or get away from extractive contributors. (Location 3571) "A paywall is more like the ticket kiosk at a theme park than a price tag on a car." (Location 3573) See "Something Awful" – a forum popular in the 2000s that anyone could read but only users paying an "activation fee" could comment. (Location 3575) This had the nice side-effect of keeping out idiots.
      • Putting all content behind [[paywalls]] is unlikely to work well, and neither are [[micropayments]] to unlock individual articles or other content. "Micropayments make the transaction about content, rather than about creators, but because there is so much freely available, highly substitutable content they create decision fatigue for consumers" (Location 3582).

Roam Notes on “Why Now? A Quest in Metaphysics” by Jaan Tallinn

  • {{[youtube]: https://www.youtube.com/watch?v=29AgSo6KOtI}}
  • "Author::" [[Jaan Tallinn]]
  • "Source::" YouTube
  • "Recommended By::" [[Conor White-Sullivan]] (see this Twitter thread)
  • "Tags::" #singularity #metaphysics
  • "Anki Tag::"
  • "Anki Deck Link::"
  • Overview

  • [[Jaan Tallinn]] lays out an argument for why being at the cusp of a [[singularity]] might not be that unusual.
  • Summary Notes

  • Basic idea behind [[singularity]]: resources will be increasingly devoted to computation, morphing from economic to astronomic phenomenon. The entire universe will turn into [[computronium]]: matter arranged in the most efficient form for computations. Once computers can design other computers, the process explodes ("our last invention"), eventually leading to a new equilibrium when each quark is put to work for computation. If this is true, we’re at the most important point in the universe since the big bang: the moment where computronium goes from 0% to 100%.
  • It seems improbable that we would happen to find ourselves at the cusp of the [[singularity]], since it’s such a pivotal and unusual moment in the history of the universe. #[[Anthropic Principle]]
  • We seem to live in a world that is, at least in principle, completely computable. #[[algorithms]] #[[computation]]
  • Our world seems finely tuned to support the existence of stars, cells, and life. So either the parameters were finely tuned to support that, or the universe is sufficiently large to contain all configurations ([[multiverse]]).
  • If you accept the [[multiverse]] theory and the [[singularity]] argument, there are post-human universes out there with supercomputers running universe simulations, that increases the number of singularity simulations, and we should be less surprised we may be experiencing the edge of the singularity. #[[simulation]]
    • Consider a world where the [[singularity]] has run its course. This should be a common situation: post-singularity periods would be at least a trillion trillion times longer than the pre-singularity period. There would be one or more [[superintelligence]] in this place, and they are likely interested in talking to other superintelligences. A practical way for them to do this would be [[simulation]], since all superintelligences are just the computational result of atoms bouncing off one another. They would also want to do many simulations of possible scenarios to pick the most interesting superintelligences, doing something like a [[tree search algorithm]] which would produce many simulations as you approach the [[singularity]]. This would mean that it is actually not unusual for a simulated world to be approaching the singularity as we possibly are now.

The Triple-Pass Method to Remember What you Learn, Forever

You read books. You watch videos. You listen to podcasts. There is a firehose of high-quality information available at your fingertips.

But how much do you actually get out of your media consumption? How much do you remember? For a long time, my answer was “not a whole lot”. I was often shocked at how few key points I could recall from material I had read only days or weeks earlier.

To me, this is unacceptable. Why bother doing so much reading if I’m just going to forget it all? Sure, if reading for entertainment, then no big deal. But most of the material I spend my time on is highly relevant to my professional and personal life. I want this knowledge to compound.

I’ve spent years experimenting, testing, and tweaking systems to get more value out of the media I consume and remember key points forever. I’ve eventually landed on a solution that I want to share with you: the “triple-pass” system. Using this system, I’m confident I’m getting everything I can out of my reading, and not a moment is wasted.

High-level Overview of the Triple-Pass System

At the highest level, the triple-pass system consists of the following stages:

  • First Pass: Active Media Consumption. Take notes and highlight important points from the media you consume (e.g. books, articles, videos).
  • Second Pass: Consolidate and Summarize Notes. Export notes and highlights from the first pass to a central note-taking system, then review, refine, and consolidate. This pass produces what Tiago Forte calls your “second brain“: an external system storing your knowledge in a format that can be easily searched and retrieved for use.
  • Third Pass: Commit to Long-Term Memory using Spaced Repetition. Add the most important parts of your notes from the second pass to a spaced repetition system. This stores the information efficiently in your long-term memory so you can access it in-the-moment when needed.

I go into each of these three stages in more detail below, including the technologies I use at each stage.

First Pass: Active Media Consumption

At this stage, you consume the media that you want to absorb. The key feature about this stage is that it is active media consumption, i.e. highlighting and taking notes as you read.

Here are some tips for getting the most out of the first pass:

  • Err on the side of more highlighting rather than less. It’s good to have a lot of context in your highlights. You can always eliminate things that are redundant or unnecessary in the second pass.
  • Highlight chapter titles. Titles provide useful context for organizing your notes and understanding the broader picture for an excerpt.
  • Prioritize the new, useful, and the interesting. There is no need for anything useless and uninteresting to exist in your knowledge base. Also, avoid including things you already know well.
  • Look for scaffolding. Keep an eye out for material that provides a “platform” to tackle more advanced concepts. For example, I always highlight definitions of important terms I’m unfamiliar with. I also like information about people, places, or things, since I can use these as context to learn related topics faster.

Technology I use for the First Pass

The tools I use at this stage vary depending on the type of media I’m consuming. There are two main criteria: i) the tool must allow me to record highlights and notes digitally, and ii) the tool must allow me to export materials to my note taking system (Roam) with little effort.

  • Books: Usually I purchase books on Kindle, which has excellent highlighting. I then use Readwise to automatically sync highlights to Evernote, and can copy and paste from Evernote to Roam (apparently Readwise now has a direct export to Roam, so it looks like I can cut out the Evernote middleman). For physical books, I use the Readwise mobile application, which has an OCR feature that lets you take a picture of the page you are reading and highlight it.
  • Articles / Blogs: I try to read all articles and blog posts on Instapaper, which allows me to highlight and take notes on articles. Again, Readwise allows me to import these notes into Evernote, which I copy / paste into Roam.
  • PDFs: At the moment I don’t have a good solution for PDFs. Since I can’t highlight them easily, I’ll often just take notes directly to Roam as I read, with the PDF open in one window and Roam open in another.
  • Videos: Typically I’ll sit at my computer when watching videos. So, I keep Roam open while watching the video and take notes, with timestamps. Here’s an example of video notes I put together for a Jeff Bezos Lecture on innovation.
  • Podcasts: I do listen to some podcasts (especially Conversations with Tyler), although I haven’t found a great tool for taking podcast notes. I usually listen to podcasts when I’m on the go, so note taking in the browser is typically not possible. Usually, if there’s a podcast that I listen to that’s really good, I’ll just revisit it and take notes while I listen at my computer desk.

Second Pass: Consolidate and Summarize Notes

In this pass, edit the highlights and notes that you’ve exported to your note-taking system. Activities here can include:

  • Deleting irrelevant or redundant notes
  • Summarizing excerpts into key points, while keeping some direct quotes from the material that is notable or quote-worthy
  • Reformulating material into your own words
  • Bold-facing the most important points so your notes are “glanceable”
  • Creating commentary on the material, expanding on points that you liked, critiquing points you disagreed with, filling in missing arguments, creating connections to other material in your knowledge base, or creating a high-level “book-review” style summary
  • Marking particularly important material for long-term memory

A key advantage of the second pass is it produces a valuable digital asset that you can draw on the rest of your life: you now have a searchable, quick-to-read summary of what you have read. The knowledge is now part of your “second brain” for easy access and connection to your existing knowledge.

Yet another advantage of this second pass is that the act of editing helps you absorb the material. This is because it requires elaboration and recall, which are both well-known to foster learning and memory.

Technology I use for the Second Pass

My note taking tool of choice is Roam. It is a fantastic piece of software, although it’s difficult to explain its value in words (you really just have to try it). I recommend looking into it if you are not already heavily invested in an existing note taking app. I find it allows me to easily make connections between knowledge, and its incredible functionality has led me to ditch Evernote, Asana, and 90% of Google Drive.

Third Pass: Commit to Long-Term Memory Using Spaced Repetition

In this third and final pass, add material material flagged “long-term memory” in the second pass to a spaced repetition system.

Spaced repetition is reviewing material at increasing intervals of time, allowing you to remember material with minimal effort. I won’t go into more detail here, but I highly recommend this overview by Gwern Branwen. You can also subscribe to my Spaced Repetition Newsletter.

The advantage of this third pass is access to your knowledge in the moment, when it matters, without any external note taking tools. This is useful for the many situations where it’s not feasible to consult your notes. For example: job interviews, meetings, or creative work where speed of thought is important and you need lots of in-memory scaffolding to make progress.

One nice feature of this third pass is you’ve thoroughly vetted the material in the first two passes. This means you’ll be less likely to add things you don’t need to your spaced repetition system, and you’ll only add information you understand (see rule 1 of flashcard knowledge construction: do not learn what you do not understand).

Technology I use for the Third Pass

Personally, I use Anki, which is probably the most popular spaced repetition software tool today. Some examples of other options include Mnemosyne, SuperMemo or even paper flashcards if you’re a technophobe.

Examples of the Triple-Pass System in Action

To get a feel for what the end result of this system looks like, here are a couple of examples:

This Seems like a lot of Work…

It’s true that using this system will almost certainly mean you’ll take more time to consume media. Compared to just passively reading a book, the highlighting, summarizing, and spaced repetition all add time.

But before you dismiss it, ask yourself a couple questions.

First: are you a genius that effortlessly absorbs the materials you consume? I don’t mean this sarcastically. People like this exist, like Tyler Cowen. If yes, there’s no real benefit to you from this system. It would just slow you down.

Second: why are you consuming the media in the first place? Is it something you really want to remember? If the answer is yes, then I believe using a system like this is a no-brainer.

Yes, it takes some extra time. But if you are consuming high-quality material relevant to your life, the benefits of that extra 10-30% of effort is well worth it.

To receive content like this weekly in your inbox, subscribe to my Spaced Repetition Newsletter, which provides latest news, tips, and ideas about spaced repetition, using learning tools like Anki, and improving your learning productivity.

Roam Notes on Balaji Srinivasan’s “Applications: Today & 2025”

  • {{[youtube]: https://www.youtube.com/watch?v=3jPYk7ucrjo}}
  • "Author::" [[Balaji Srinivasan]]
  • "Source::" https://www.youtube.com/watch?v=3jPYk7ucrjo
  • "Tags::" #Entrepreneurship #startups #Technology #crypto #decentralization
  • "Anki Tag::" srinivasan_apps_today_2025
  • "Anki Deck Link::" link
  • Overview: [[Balaji Srinivasan]] discusses about crypto applications in 2020 and also beyond that point to 2025. Also includes a history of how we got to the present moment, and some underpinning concepts of all [[crypto]] projects.
  • 1:45 Talk begins
  • 2:20 Why [[Bitcoin]] was invented in the first place. It represents the latest step in a progression of digital cash: #money #payments #Ankified
    1. Physical cash: A hands B cash and B no longer has it.
    2. Naive digital cash solution: A sends B serial number via email, but A still has a copy, so this doesn’t work
    3. Centralized digital cash: A bank C acts as trusted intermediary – debits A and credits B.
    4. Decentralized digital cash: Centralized bank C is replaced by decentralized networks of competing miners updating a [[blockchain]].
  • 5:25 [[blockchain]] is the fundamental innovation behind [[Bitcoin]]. There are many blockchains; for example [[Ethereum]], which is more programmable than bitcoin and allows for [[smart contracts]]. Allows for more complex transactions than simple "debit A and credit B".
  • 8:06 Technological concepts underlying [[blockchain]] projects
    • [[blockchain]] is a database for storing things of value. Although slower than centralized databases, they provide tamper-resistant shared state in an adversarial environment.
    • 9:15 [[Bitcoin]] is a [[protocol]] – you can open [[Wireshark]] and see raw packets updating the underlying [[blockchain]]. Entirely packet-driven without reference to a bank. So, machines can now hold and send money.
    • 13:30 [[blockchain]] means having a greater choice over who to [[trust]]. Previously you had to store money at one of a few banks; now you can store at a bank, exchange, or any computer.
    • 13:54 [[blockchain]] enables internet-scale [[cap tables]]. Cap tables are tables examining who owns what percentage of a company. #Ankified
    • 16:10 [[blockchain]] breaks [[network effects]] because token upside is inversely proportional to network effects. For example, competitor to Facebook could issue tokens to new users, giving value to early users that decline in value as the network size increases. Turns customers into investor-like entities. #Ankified
    • 17:30 [[blockchain]] will transform [[Social Networks]], moving from liking and poking and messaging to real value being create (paid DMs, surveys, task)
    • 18:00 [[blockchain]] is a partial move from [[the cloud]] toward more privacy. Users increasingly keep private keys local and private, and this will be an anchor leading other data being encrypted and moved locally. The bulk of data will still be remote, but it will only be decrypted when you download it locally.
  • 19:15 The [[blockchain]] community
    • A blockchain community is economically aligned. "If they’re holders, none of them can win unless they all win". #incentives #[[crypto cliff]]
      • For example, with [[DNS]] if someone seizes a lol.cat domain, you keep your .com domain so you don’t really care. In contrast, seizing a person’s .ens domain means interfering with the [[Ethereum]] blockchain. "You now have a monetary incentive to defend another’s rights". He calls this the [[crypto cliff]]. #Ankified
    • 21:30 This allows for experiments in [[self-governance]]. Suddenly, [[macroeconomics]] becomes an experimental science. "If [[federalism]] meant the laboratory of the states, [[decentralization]] is creating the laboratory of the networks.
  • 23:08 Applications: 2020, i.e. what are the successful things currently built with [[crypto]]?
    • These are things already built at scale at 2020: [[exchanges]], [[hardware wallets]], [[miners]], [[issuance]], [[stablecoins]], [[defi]]
  • 25:30 Applications: 2025, i.e. the stuff that’s up-and-coming and might be big in 2025 in [[crypto]]? #[[startup ideas]]
    • [[privacy coins]] (e.g. [[Dash]], [[Monero]], [[ZCash]]).
    • [[Lending]] and [[Interest]] (e.g. [[Compound]], [[Maker]])
    • [[Scaling]] (e.g. [[Starkware]] and many others)
    • [[Decentralized Cold Storage]] (e.g. [[Casa]]) helping people store at home that don’t technically know how to do that, so this provides services that allow you to do that.
    • [[SaaS-for-gas]] (e.g. [[Starkware]] and others). Smart contracts that are on-chain and charge for each API call. Right now you have to do a Stripe billing layer, but maybe put in a code snippet and you have a function that executes and makes you money.
    • [[Insurance]]
    • [[Multiwallets]] which add more functionality than send/receive, adding new verbs like buy, sell, sign, vote, stake, register, etc.
    • [[Security]]
    • Novel [[financial instruments]]
    • Blockchain games
    • Crypto [[Social Networks]]
    • Decentralized [[DNS]]
    • Automated Market Making
    • Decentralized [[Identity]]
    • [[Personal Tokenization]]: issuing an equity-like token for your time or some function of your time.
    • [[Mutuals]] and [[Guilds]]: Attempt to incentivize collective action (e.g. [[Moloch]], [[Gitcoin]])
    • [[Founder’s Rewards]]: New business model for funding developers from rewards (e.g. [[Zcash]], [[BCH]]).
    • On-Chain Developer Bounties (e.g. [[Tezos]])
    • Clients for [[dApps]] to make it easy to interface with these applications (e.g. [[InstaDApp]])
    • [[Developer Tools]]
    • Oracles and [[Prediction Markets]]
    • [[Decentralized Autonomous Organizations]] – semi-autonomous programs, many of which make you money.
    • [[Community-Owned Organizations]]
  • 36:33 Q&A
    • Internet companies have captured a lot of value from [[data monopolies]] or [[attention]]? Where do you think the value capture will come from for the [[crypto]] applications in the next 10-15 years?
      • Balaji is bullish on [[tasking]]. "It’s the better-than-free economy. Rather than trying to hack your [[attention]], they are paying you for it".
        • [[crypto]] uniquely enables this for a lot of reasons, but one big reason in ease of [[pay-outs]]. [[pay-ins]] are hard, and [[Stripe]] has succeeded by making them easier, but pay-outs are even harder. As an example, think about how many sites where you’ve entered in a credit card to pay for something (pay-in). Probably 50-100 sites. Now, think about how many sites you’ve entered in your bank account information to get paid yourself for a service? Probably no more than 5, possibly none, because a website with your bank account information could potentially debit as well as credit. #[[pay-outs vs pay-ins]]

Roam Notes: Elon Musk Interview from Air Warfare Symposium 2020

  • "Author::" [[Elon Musk]] [[General John F. Thompson]]
  • "Source::" https://www.youtube.com/watch?v=sp8smJFaKYE
  • "Tags::" #Business #Management #Leadership #Innovation #SpaceX #Tesla #Government
  • "Anki Tag::" musk_2020_air_warfare_symposium
  • "Anki Deck Link::" link
  • {{[youtube]: https://www.youtube.com/watch?v=sp8smJFaKYE}}
  • Overview

  • [[General John F. Thompson]] interviews [[Elon Musk]] with a focus on [[innovation]], and how organizations such as the [[US Air Force]] can become more innovative. The interview contains practical information for senior management in large organizations that want to improve innovation.
  • Notes

  • 6:15 Interview Begins. How do you ensure products don’t remain static and incrementally improve over time? #[[radical innovation]]
    • It’s important to push for radical [[breakthroughs]]. If you don’t push for these, you won’t get radical outcomes. To get a big [[reward]], you must have a big [[risk]]. The [[US]] will fall behind in [[innovation]] if it doesn’t continue to do this. It’s a risk today and wasn’t in the past.
  • 13:00 Is this need driven by competition with other countries? Or is this regardless of competition? #competition
    • Without a doubt, if the [[US]] doesn’t make big moves in [[space]], it will be second place in space. [[Innovation]] is the key attribute of the US and it needs to use it.
  • 14:00 What does the US need to do to maintain that innovative competitive edge? #Ankified
    • [[Outcome-Based Procurement]] is very important. You say "this is the outcome sought" and whoever can achieve this outcome to a greater degree the [[government]] will do business with. #Procurement
  • 17:45 The workforce is a key component in radical innovation. What do you do to motivate a workforce to help them become more radically innovative? #Hiring #incentives #[[encouraging innovation in an organization]] #Ankified
    • The most important thing to do is to make sure that you have an incentive structure where innovation is rewarded and lack of innovation is punished. Carrot and stick. People that are innovating should be promoted sooner, and if someone’s in a role where innovation should be happening and it’s not, then they should not be promoted or exited. "Then let me tell you, you’ll get [[innovation]] real fast. How much do you want?"
  • 19:40 Wouldn’t that make people too risk averse?
    • You have to have some acceptance of failure – failure has to be an option. If you don’t allow trying and failing you might get something worse than lack of innovation – things may go backwards. "You want reward and punishment to be proportionate to the actions you seek." Reward for trying and succeeding, minor consequences for trying and failing, and major negative consequences for not trying. "With that incentive structure you’ll get innovation like you won’t believe."
  • 21:20 What about processes – are there processes you recommend to bring about radical change?
    • Designing a production system of a new product is at least 1-2 orders of magnitude harder than designing the initial prototype.
    • Designing a rocket easy. Making one of it is hard. The making of a production line that builds and launches many is extremely hard.
  • 26:00 [[Starlink]] – as you scale to build more and more satellites and launch them, what are challenges you’ve had to overcome? #Ankified
    • It’s important to have a tight feedback loop between the [[design]] of the object and the [[manufacturing]] system. When you design, you don’t realize the parts that are difficult to manufacture, so bring manufacturing and design up together. Counterintuitively, it can be the right thing to do to manufacture the wrong thing, i.e. build it before design is done, because you discover what’s hard to manufacture.
  • 29:15 To figure out what to build, you could query customers ("customer pull", e.g. improving a [[Tesla]] based on customer feedback), or innovate and push something into the customer base ("company push", e.g. iPad). How do you think about that balance? #Ankified
    • [[Henry Ford]] once said that if you ask the public what they want, they would have said "a faster horse". When it’s a radically new product, people don’t know they want it because it’s not in their scope. Customer feedback once they have the fundamental product is a good thing, though. #[[market research]] #[[customer research]]
  • 34:00 In the next 5 years, what technology do you think will see the most advancement?
    • [[AI]] will be the most fundamentally transformative. Computer science and physics is what you would want to study to prepare for this future. If you want to understand the nature of the universe, these two fields have great predictive power.
  • 35:23 What should the Air Force be investing more in for innovation, other than reusable rockets?
    • Once you have dramatically reduced cost access to space, many things are enabled. Analogy: the [[Union Pacific Railroad]] made travel across the country much faster and less dangerous.
  • 41:30 The failures you’ve had to endure would drive many nuts. What’s the mindset to get through that?
    • You want the net useful output to be maximized. In baseball, it’s three strikes and you’re out. What you mostly care about is not any individual at-bat but the overall batting average. [[Failure]] is irrelevant unless it’s catastrophic.
  • 44:00 Intellectual property – how do you protect it in a world where information is constantly under attack? #[[intellectual property]]
    • [[Tesla]] open sourced their [[patents]] a few years ago. The goal of Tesla is to encourage the use of sustainable energy, so they want to help others that want to make an electric car.
    • The real way you achieve protection is by innovating fast enough. If innovation is high, you won’t need to worry about [[intellectual property]] because competitors will be copying something you did years ago. Innovation per unit of time is what matters. What is your rate of innovation, and is that accelerating or decelerating? [[Big Business]] tends to get less innovative per employee and also sometimes in absolute terms, and it’s likely because of incentives. Incentives must be aligned with innovation. #Ankified
  • 47:30 What are your thoughts on the competition between the [[US]] and [[China]].
    • [[China]] economy is going to be 2-3 time the size of the [[US]] economy, due to their huge population advantage. So, innovation has to close this massive gap in economic output. Economics are the foundation of war.
  • 50:40 How do you create a culture of enthusiasm at [[Tesla]] and [[SpaceX]]?
    • There is a pretty big selection effect, because especially in important engineering roles, they look for people that have demonstrated innovation. As mentioned earlier, the incentives in the company help – they reward innovation and punish lack of innovation.

Tips From Anki Flashcard Refactoring: Add Enough Knowledge to your Deck and Review your Sources

My flashcard refactoring for today is a reminder of the classic knowledge construction advice: do not add what you do not understand. It is also a reminder of the importance of providing enough related cards in your deck for a piece of knowledge.

Here’s the card I came across that was giving me trouble, related to SQL programming (double-sided):

  • Side 1: Oracle SQL syntax for creating object table
  • Side 2: CREATE TABLE (table name) OF (object type)

When revisiting this card, I realized that I didn’t have a good concept of what “object tables” are, so this is definitely a case of not understanding the material before committing it to spaced repetition.

But the thing is, I wouldn’t have added it if I didn’t have a good understanding of object tables, at the time of adding knowledge to my spaced repetition system. The problem is I forgot the concept of “object tables”, and seeing the answer to this card was not enough to bring it back. I didn’t have any other cards in my deck about “object tables” and how they differ from other related concepts in Oracle SQL such as nested tables.

In a situation like this, it helps to go back to the source, clarify any misunderstanding, and add new cards that solidify your knowledge.

So, in this case, I looked up Oracle documentation and found a great article almost immediately that clarified the meaning. It also provided a bunch of useful nomenclature for closely related concepts, providing further scaffolding for the knowledge. This lead me to add a bunch of cards:

  • Card 1 (Cloze): Objects can be stored in two types of tables: [object tables] and [relational tables].
  • Card 2 (Basic 1-sided Q&A):
    • Q: What’s the difference between object tables and relational tables? (Oracle SQL)
    • A: Object tables store only objects Relational tables store objects with other table data
  • Card 3 (Basic 1-sided Q&A):
    • Q: What does each row represent in an object table? (Oracle SQL)
    • A: An Object

So to recap, here the main lessons from this refactoring:

  1. Don’t add stuff to spaced repetition that you don’t understand
  2. Make sure you add enough knowledge about the concept in your deck, so there is sufficient context for you to understand again when you forget
  3. When dealing with 1 or 2, the solution is to go back to the original source to understand the knowledge and add more relevant material.

To receive content like this weekly in your inbox, subscribe to my Spaced Repetition Newsletter, which provides latest news, tips, and ideas about spaced repetition, using learning tools like Anki, and improving your learning productivity.

Roam Notes on “Selfish Reasons to Have More Kids” by Bryan Caplan

  • "Title::" Selfish Reasons to Have More Kids: Why Being a Great Parent is Less Work and More Fun Than you Think
  • "Author::" [[Bryan Caplan]]
  • "Reading Status::" #Complete
  • "Recommended By::" [[Tyler Cowen]]
  • "Tags::" #Book #Parenting #genetics #[[nature vs nurture]] #[[reasons to have kids]] #[[impact of parenting]]
  • "Roam Notes URL::" link
  • "Anki Tag::" caplan_selfish_reasons
  • "Anki Deck Link::" link
  • Overview

    • [[Bryan Caplan]] takes a dive into the research on parenting impact, and finds answers that fly in the face of the current Western parenting assumptions and cultural norms. Caplan convincingly argues that many of our common attitudes about our impact on our kids are an illusion and not supported by the best academic research (i.e. Twin Studies that effectively distinguish nature vs nurture). In light of this lack of impact, parents are placing unnecessarily large burdens on themselves.
    • The book is the antithesis to Tiger Mom. It raises a firm, but polite equivalent of the middle finger to spartan, obsessive, anxiety-ridden, stress-inducing style of helicopter parenting that is surprisingly common today. It also rails against a common assumption that parenting must always be hard, and its hardness is an indication that you’re doing a better job.
    • Given that modern parenting is unnecessarily hard, and you can do less work in many areas without sacrificing your child’s development, Caplan concludes that, at the margin, you should consider having more kids, and there are indeed selfish reasons to do so.
  • Summary Notes

    • Four Big Selfish Reasons to Have More Kids (pg. 2) #[[reasons to have kids]]
      • There are many selfish reasons to have more [[kids]], but there are four big reasons we can put on the table right away: #Ankified
        • Parents can sharply improve their lives without hurting their kids. Nature, not nurture, explains most family resemblance, so parents can safely cut themselves a lot of additional slack. #[[nature vs nurture]]
        • Parents are much more worried than they ought to be. Despite the horror stories in the media, kids are much safer today than they were in the “Idyllic Fifties”. #worry #safety
        • Many of the benefits of children come later in life. Kids have high start-up costs, but wise parents weight their initial [[sleep]] deprivation against a lifetime of rewards – including future [[grandchildren]].
        • Self-interest and altruism point in the same direction. Parents who have another child make the world a better place, so you can walk the path of enlightened selfishness with a clear conscience. #[[self-interest]] #altruism
    • Four First Places to Look to Adjust Parenting to be Less Work and More Fun (pp. 22-30) #[[easier parenting]]
      • Before you do something for your child, good to ask yourself three questions: do I enjoy it, does my child enjoy doing it, and are there any long-run benefits. #Ankified
      • There are many potential adjustments to make your life easier, but here are four first places to look:
        • Sleep: Getting your kid to sleep is crucial for livable parenting. The [[Ferber method]] is great for this. Also, mandate regular naps until kids old enough to quietly entertain themselves for an hour. The author kept their kids on nap schedule until they were almost 6 (1-2 years more than needed). Then, switch from nap time to quiet time.
        • Activities: These are often not a break for a parent. Let kids drop any activities enjoyed by neither parent or child. Also, no need to be so negative about “electronic babysitters” (television, video games, computers). If you give mature adults free time, they’ll often relax in front of a TV or computer – what’s so bad about that?
        • Discipline: Remember [[discipline]] is for the child’s welfare, but also to prevent the child from abusing you and the people around them. Discipline should have 3 characteristics: Clarity, Consistency, Consequences. #Ankified
        • Supervision: If your kids want to stretch their wings, you don’t feel like supervising them, and everyone is safe, go for it! #[[supervision]]
    • On Paying Your Kids for Work (pg. 31) #allowance #[[paying your kids]]
      • Caplan recommends paying kids for actual work, and don’t be so stingy about compensation. Don’t pay them for every little thing, but when you want to give kids a major project or recurring chore, make it worth their while.
      • If generous terms fall on deaf ears, you’re probably giving them too much for free. Handing out goodies “just because” is fun, but don’t expect a child with a $40 a week allowance to be hungry for work. #[[To Ankify]]
    • Parent Wish List for Kid Outcomes and their Actual Influence (pp. 46-71) #[[impact of parenting]]
      • [[Health]]: Parents have little / no effect on life expectancy and overall health, maybe a small effect on smoking, drinking, and drug problems.
      • [[Intelligence]]: Parents have little to no long run effect on their children’s intelligence.
      • [[Happiness]]: Parents have little to no long run effect on happiness, self-esteem, unhappiness.
      • [[Success]]: Parents typically want high-[[income]] and fancy degrees for their [[kids]]. Turns out parents have little effect on how much school their kids get, they have little or no effect on how much [[money]] their kids make when they grow up, and no effect on [[grades]].
      • [[Character]]: Parents have little to no effect on conscientiousness or agreeableness (i.e. hardworking, diligent, honest, polite, cooperative, kind, etc), little or no effect on criminal behaviour.
      • [[Values]]: Parents have big effect on religious / political labels, but little on religious / political attitudes and behaviour, moderate influence over when daughters start having sex, little / no effect on teen pregnancy, adult sexual behaviour, marriage, marital satisfaction, divorce, or childbearing.
      • [[Appreciation]]: Parents have a large effect on child’s long-run feeling about their parents and views about their [[childhood]].
    • Are children like clay? (pg. 80) #[[nature vs nurture]]
      • “We often compare children to clay. When they’re soft, you can mold them into any shape you like; after they harden, they stay the way you made them. What common sense and science tell us, however; is that children are more like flexible plastic. Both respond to pressure. Yet when you remove the pressure, both tend to return to their original shape.” #Ankified
    • What the Science of Nature and Nurture Means for Parents (pp. 86-90)
      • Lighten up – If parental investments don’t typically pay off, relaxed parenting is a free lunch – better for parents, no worse for kids.
      • Choose a spouse who resembles the kids you want to have
      • If you want to drastically improve a child’s life, adopt from the third world #adoption
      • Raise your children with kindness and respect
      • Share your creed, but don’t expect miracles
      • Don’t write off your teens (parents affect juvenile antisocial behaviour and sexual behaviour for girls, also good to discourage smoking / drinking / drug use) #Ankified
      • Have more kids
    • Why More People in the World is not a Source of Poverty (pg. 127) #[[zero-sum thinking]] #population #poverty
      • Those who see more people as a source of [[poverty]] are missing half the story: Over the course of their lives, human beings do not just consume, they also produce. Kids eventually grow up and pull their own weight. The world economy is not like a party where everyone splits a birthday cake; it is more like a potluck where everyone brings a dish. #Ankified
    • The Best Way to Understand a Position (pg. 163) #thinking #reasoning #debate #criticism #Ankified
      • The best way to understand a position is to argue on its behalf. You learn as you speak. Sometimes you find that objections are stronger than you realized; other times you discover that they’re weaker than they looked. You may end up abandoning the position – or improving it and returning to the fray. Critics don’t just keep you honest; they show you the light.

Roam Notes on “Taking on the Challenge” Lecture by Jeff Bezos

Overview

  • [[Jeff Bezos]] talks about the [[Amazon]] approach to [[innovation]].

Excerpts

  • 0:45 [[Betty Graham]] invented white-out because she was annoyed by the inability to erase on a typewriter. She sold it to [[Gillette]] for $45M, and it was just white paint!
  • 2:07 Two approaches to solving problems with innovation: #[[To Ankify]]
    • Encounter a problem, and find a solution for it.
    • Work backwards by taking a new technology or understanding and finding important problems to solve with it. This is common in technology. E.g. [[carbon dating]].
  • 2:45 Persistence is a key attribute of innovators. E.g. WD-40 stands for "Water Displacement, 40th attempt". They originally made the product to keep water off [[Atlas 5]] rocket on US government contract. #[[persistence]] #[[characteristics of innovators]]
  • 4:30 One of the most pernicious obstacles to innovation: [[learned helplessness]]. Ordinary things bother innovators, while non-innovators become complacent and accept things as they are. E.g. windshield wipers – people used to stop every mile and use a rag. The inventor had to push through criticism that the wipers would be distracting, but in 10 years they were standard. Once people tried it they saw the value.
  • 10:00 A big impediment to innovation is [[either/or thinking]]. [[Amazon]] is always trying to reduce the number of [[customer contacts]]. This is a win-win for [[Amazon]] and its [[customers]]. It saves money for Amazon, and customers enjoy not having to deal with support. Eliminating defects saves money because you don’t have to handle customer contact and you improve the customer experience. There’s no [[trade-off]]. #[[barriers to innovation]]
  • 13:34 To innovate, you need to maximize the rate of [[experimentation]]. To do that, the cost experimentation has to be low. [[Amazon]] has built infrastructure to make experimentation easy, in a self-service way, without huge coordination or approval. #[[To Ankify]]
  • 18:00 [[Amazon]] is [[customer]] focused rather than [[competitor]] focused. Competitor strategy changes all the time, but the core things that customers want do not change: selection, low prices, and convenience. In 10 years, that’s going to stay the same. #[[customer vs competitor focus]]
  • 22:00 You need to have small, separate, empowered teams that aren’t subject to [[dependencies]] across the organization. They need to know whether they’re getting better or not. It’s easy to do that in a broad way (e.g. company profits) but difficult for individual teams – that’s the key. #KPIs
  • 29:00 The [[internet]] makes the customer experience a [[fixed cost]] rather than [[variable cost]]. "Buy With 1 Click" costs [[Amazon]] the same amount to develop whether they had 1000 customers or 1,000,000 customers. For retail stores, it’s not the same – with more customers, an improved experience costs more. #[[To Ankify]]
  • 35:00 Invention will always lead you down paths that people think are weird. #invention #innovation
  • 45:00 Hire builders. To have an innovative company, the single most important thing (more important than reducing the cost of experimentation) is to make sure you’re hiring the correct people in your organization. Hire people that like to build, like to invent. Get people that do this at all levels of granularity: some people are only interested in inventing at the grandest whiteboard level, but they can’t make progress in the real world, because they’re unwilling to figure out how to mount the camera on top of the truck. It turns out, that’s incredibly important. #Hiring #innovation

Tips from Flashcard Refactoring

Include your Sources, Have a Single Answer, and Break-Down Your Cards

Here’s a flashcard related to Oracle SQL that was giving me trouble (lapsed 8 times and was automatically marked as a leech):

  • Side 1: Collection (Oracle SQL)
  • Side 2: Data types in Oracle SQL that lets you internalize parent-child relationships between tables in the parent table.

This was a double-sided card, so both Side 1 and 2 serve as the question. Let’s see if we can improve this one.

First things first: do I need this card at all? Yes: SQL is highly relevant to my career in Data Science, and the organization I work for relies heavily on Oracle database. It’s important knowledge for me that I didn’t want to remove.

Next, figure out the issue with the card. Looking at the card statistics, it turns out I was always getting Side 2 wrong. After some consideration, I realized that this is actually a poor definition of a “Collection”. In fact, it’s not really the “definition” of a Collection, but a characteristic of a Collection. In other words, the flashcard doesn’t have a unique answer: it’s true that a Collection internalizes parent-child relationships, but it does a lot of other things too.

I consulted the original source of the material and there isn’t a clear definition of a Collection there. I did some Googling for other sources and apparently there isn’t really a great definition of an Oracle Collection. It turns out that Collection refers to a generic programming idea not specific to Oracle.

So, rather than trying to define Collection, I’ve opted to break the existing card down into multiple cards, following Rule Number 4 of Knowledge Construction: stick to the minimum information principle, which means if you can break a card into multiple simpler, easier-to-answer cards, do it.

Card 1 (one-sided):

  • Side 1: What Oracle SQL data type lets you internalize parent-child relationships in the parent table?
  • Side 2: Collection

Card 2 (one-sided):

  • Side 1: What kind of relationship does an Oracle SQL Collection help you represent?
  • Side 2: Parent-child (aka “one to many”)

Card 3 (one-sided):

  • Side 1: Does the Oracle SQL Collection data type internalize parent-child relationships in the parent table or child table?
  • Side 2: Parent table

I also tracked down a good definition of the generic “Collection” concept in Computer Science, and added it:

Card 4-5 (double-sided):

  • Side 1: Collection (Computer Science)
  • Side 2: Object that groups multiple items together as a single unit (Computer Science)

I feel confident these cards will be easier to remember, cost less time and frustration, and help me remember the concept much better.

Lessons learned:

  • Flashcards should have a single answer. Multiple correct answers for a card is a recipe for confusion and frustration. Interestingly, this isn’t included in Poitr Wozniak’s Twenty Rules for Formulating Knowledge, although you could interpret this as a form of interference (Rule #11)
  • Keep track of your source material when making cards. It makes it easy to look up more details when needed. 
  • Browse related sources through Google search if you’re unsure about what to do to an item. This will give you more context around the card to see whether the knowledge is even required at all. You may also come across a clarification or better formulation. In the example above, I discovered the generic concept of “Collection” in programming and realized that it was futile to try to include a definition specific to Oracle SQL.
  • Break cards down into a larger number of simpler cards. This is classic knowledge construction advice that is often not heeded, because it feels like more cards means more work. Counterintuitively, it is really a free lunch: you remember the concept better, you spend less time reviewing than you would have with the single complicated card, and reviews become much more enjoyable. 

To receive content like this weekly in your inbox, subscribe to my Spaced Repetition Newsletter, which provides latest news, tips, and ideas about spaced repetition, using learning tools like Anki, and improving your learning productivity.

Roam Notes on “I Could Do That in a Weekend! by Dan Luu

  • "Author::" [[Dan Luu]]
  • "Source::" https://danluu.com/sounds-easy/
  • "Tags:: " #software #programming #[[Dunning-Kruger Effect]] #[[Big Business]]
  • Summary

    • Outside developers often look at a large software company and think "that’s easy, I could build that in a weekend". This article describes why that’s misguided.
    • Reasons why are divided into two categories: technical and organizational. #[[To Ankify]]
      • Technical: Large businesses find it profitable to do lots of optimization and build new features that are often more complex than outsiders realize. This requires hiring engineers. You want to keep hiring engineers until the marginal benefit of hiring 1 more engineer = marginal cost of hiring 1 more engineer. Companies that are smart do this math and often find they should hire many, many engineers.
      • Organizational: Large organizations have complex communication barriers that outsiders underestimate.
  • Excerpts

    • I can’t think of a single large software company that doesn’t regularly draw internet comments of the form “What do all the employees do? I could build their product myself.”
    • Businesses that actually care about turning a profit will spend a lot of time (hence, a lot of engineers) working on optimizing systems, even if an MVP for the system could have been built in a weekend. There’s also a wide body of research that’s found that decreasing [[latency]] has a roughly linear effect on revenue over a pretty wide range of latencies for some businesses. Increasing performance also has the benefit of reducing costs. Businesses should keep adding engineers to work on [[optimization]] until the cost of adding an engineer equals the revenue gain plus the cost savings at the margin. This is often many more engineers than people realize. #[[To Ankify]] #Hiring
    • And that’s just performance. Features also matter: when I talk to engineers working on basically any product at any company, they’ll often find that there are seemingly trivial individual features that can add integer percentage points to revenue. Just as with performance, people underestimate how many engineers you can add to a product before engineers stop paying for themselves. #features
    • Additionally, features are often much more complex than outsiders realize. If we look at search, how do we make sure that different forms of dates and phone numbers give the same results? How about [[internationalization]]? Each language has unique quirks that have to be accounted for.
    • It’s fine to ignore this stuff for a weekend-project [[MVP]], but ignoring it in a real business means ignoring the majority of the market! Some of these are handled ok by open source projects, but many of the problems involve open research problems.
    • Everything we’ve looked at so far is a technical problem. Compared to [[organizational problems]], [[technical problems]] are straightforward.
    • Distributed systems are considered hard because real systems might drop something like 0.1% of messages, corrupt an even smaller percentage of messages, and see latencies in the microsecond to millisecond range. When I talk to higher-ups and compare what they think they’re saying to what my coworkers think they’re saying, I find that the rate of lost messages is well over 50%, every message gets corrupted, and latency can be months or years. #communication #[[communication issues]]
    • It’s entirely plausible that someone will have an innovation as great as PageRank, and that a small team could turn that into a viable company. But once that company is past the VC-funded hyper growth phase and wants to maximize its profits, it will end up with a multi-thousand person platforms org, just like Google’s, unless the company wants to leave hundreds of millions or billions of dollars a year on the table due to hardware and software inefficiency.
    • It’s not that all of those things are necessary to run a service at all; it’s that almost every large service is leaving money on the table if they don’t seriously address those things. #[[To Ankify]]
    • This reminds me of a common fallacy we see in unreliable systems, where people build the happy path with the idea that the happy path is the “real” work, and that [[error handling]] can be tacked on later. For [[reliable systems]], error handling is more work than the happy path. The same thing is true for large services — all of this stuff that people don’t think of as “real” work is more work than the core service