Category: Notes

I’m a compulsive note taker – I love consolidating information and storing it for easy access later. My note-taking tool of choice is Roam Research. These notes are taken directly from my personal Roam database.

Roam Notes on “RailsConf 2017: How to Write Better Code Using Mutation Testing” by John Backus

  • "Author::" [[John Backus]]
  • "Source::" [[YouTube]]
  • "Recommended By::" [[John Backus]]
  • "Tags::" #programming #testing #Videos
  • "Roam Notes URL::" https://www.marknagelberg.com/roam-notes-on-railsconf-2017-how-to-write-better-code-using-mutation-testing-by-john-backus/
  • "Anki Tag::" backus_mutation_testing
  • "Anki Deck Link::" link
  • {{[video]: https://www.youtube.com/watch?v=uB7m9T7ymn8&feature=emb_title}}
  • Overview
    • [[John Backus]] gives an overview of [[mutation testing]] and why you should use it.
  • Introduction #Ankified
    • Line Coverage Formula = Lines of Code run by Test / Total Lines of code in the Project
    • Mutation Coverage: How much of your code can I change without breaking your tests?
      • If you can remove a line of code or meaningfully change the code without breaking a test, something is probably wrong: you’re missing a test or it’s dead code.
  • Benefits of [[mutation testing]]:
    • Learning about your programming language and the code you rely on
      • Mutation testing frameworks have many special case mutations baked into the tool that you likely wouldn’t think of on your own. They teach you things about your language and the code you rely on, and you learn about them just-in-time.
      • It makes you a better developer: "Mutation testing has been the most powerful source of growth for me in the past few years"
      • You not only learn more about the code, but you learn faster. The feedback loop is fast, and you learn more per unit of time spent coding.
    • Ship code with fewer bugs
      • Introduce fewer regressions to code, since it lets you see hotspots where you could break the code without failing the test, resulting in a bug that you would only find in production. #Ankified
      • It teaches you better testing skills – it forces you to think more about different conditions that can happen and the expected behaviour of your code.
    • X-Raying Legacy Code #[[legacy]]
      • Helps you find hot spots in legacy code, where you could potentially introduce a regression and the tests won’t fail. It gives you a checklist, and in each case you determine if you should change your tests or your code.
    • Dead Code Detection
      • Dead Code: code that is never executed, or when executed has no effect on the program. #Ankified
      • Often shows you’re using redundant code, without consulting programming language’s documentation or coworkers.
    • Better Test Coverage
  • Is it Practical? (30:15) #Ankified
    • You might be wondering – I open PRs that are hundreds of lines long and my tests take hours to run. How is this practical?
    • You can run mutation test only on code that has changed since a specified Git revision.
    • You can specify a particular method you want to run the mutation tests on.
  • Mutation Testing on the Job
    • You should run mutation tests before you push code. You’ll learn more, write better code, and grow faster than your colleagues that refuse to use it.
    • If you’re a team lead, incorporate mutation tests into [[continuous integration]]. You don’t need 100% mutation coverage to benefit.

For access to my shared Anki deck and Roam Research notes knowledge base as well as regular updates on tips and ideas about spaced repetition and improving your learning productivity, join “Download Mark’s Brain”.

Roam Notes and Anki Deck on “Notes on Technology in the 2020s” by Eli Dourado

  • Title:: Notes on Technology in the 2020s
  • Author:: [[Eli Dourado]]
  • Recommended By:: [[Patrick Collison]] on Twitter https://twitter.com/patrickc/status/1345405936240742400
  • Reading Status:: #complete
  • Review Status:: #[[third pass]]
  • Tags:: #articles #technology #progress #innovation
  • URL:: https://elidourado.com/blog/notes-on-technology-2020s/
  • Source:: #instapaper
  • Anki Tag:: dourado_2020_tech
  • Anki Deck Link:: link

  • Notes

    • Overview
      • [[Eli Dourado]] thinks through how various promising technologies could evolve over the next decade. (View Highlight)
    • End of [[the great stagnation]]?
      • Metric marking the end of [[the great stagnation]] – sustained growth in utilization-adjusted [[total factor productivity]] of 2 percent per year. It was 2.1 percent over 1947-1972, only .17 percent since 2005. (Note: utilization-adjusted version is important since it corrects for the business cycle.) (View Highlight) #Ankified
      • Scientific breakthroughs alone are not enough to end the Great Stagnation. "TFP only budges when new technologies are adopted at scale, and generally this means products, not just science…This means building businesses, surmounting regulatory obstacles, and scaling production. (View Highlight) #commercialization #Ankified
    • [[Biotech]] and [[health]] (View Highlight)
      • [[mRNA vaccines]] provides the ability to encode and deploy arbitrary mRNA in our bodies—"it allows us to essentially program our cells to make whatever proteins we want". For [[COVID-19]], the vaccine instructs our cells to make the spike protein (View Highlight). mRNA technology can be deployed against non-viruses, like [[cancer]] (e.g. [[BioNTech]] treatment). (View Highlight) #[[Moderna]]
      • [[CRISPR]] is a technique for editing [[DNA]] discovered in 2012, but haven’t made a meaningful economic contribution yet—no treatment using CRISPR has been approved outside of [[clinical trials]]. (View Highlight) #Ankified
      • "[[DeepMind]] [[protein-folding]] breakthrough signals a promising decade for the science of [[proteomics]]. Most directly, being able to predict protein shapes will enable us to discover drugs more rapidly." But this is still a way off due to drug trials taking a long time. (View Highlight).
      • [[life extension]]: [[Conboy Lab at Berkeley]] helped prove that replacing plasma rejuvinates germ layer tissues and improves cognition by reducing neuroinflammation. (View Highlight) This is a product that could actually come to market – [[therapeutic plasma exchange]] is [[FDA]]-approved for other conditions (not aging), but could be provided off-label, and it’s cheap – "An automated [[plasmapheresis machine]]—which lets you do treatment after treatment—can be bought online for under $3,000". (View Highlight)
        • Another related product is [[aging clocks]] to know how biologically old you are – these are available today. (View Highlight)
        • [[metformin]] is something to look into if you are metabolically unhealthy. (View Highlight)
      • [[health sensors]] on [[wearables]] like Apple Watch are becoming better and more prevalent every year. (View Highlight)
      • "Let’s salute and cheer for the discoveries, but spare many thoughts for the entrepreneurs trying to bring treatments to market." (View Highlight) #commercialization
    • [[Energy]]
      • [[wind power]] and [[solar power]]: costs of these have decreased significantly over the 2010s but deployment is only 9% of utility-scale electricity generation in the US as of 2019. Going forward, cost reductions will stall, but deployment will increase. (View Highlight) #Ankified
        • Intermittency is a challenge. To reach a grid powered entirely by today’s renewables, we would need storage at a price of $20 per kWh (with caveats). To power the grid today entirely with renewables, would need price to be about $20 per kWh, while current prices are in the $500-$600 per kWh range. Increased demand could make price reductions in the future challenging. (View Highlight)
      • [[nuclear power]] or [[geothermal power]] seem to be required for scalable zero-carbon baseload energy.
        • [[nuclear power]] is challenging due to high costs
        • [[geothermal power]] is the most plausible this decade. This is apparently an area ripe for innovation: "The startups I have spoken to think with today’s technology they can crack 3.5¢/kWh without being confined to volcanic regions." Possibly 1¢/kWh by the 2050s, making it difficult for [[nuclear power]] to compete (View Highlight) #Ankified
      • [[sustainable alternative fuels (SAF)]] will be big in 2020s. Airlines can’t electrify since batteries can’t match fossil fuel energy density, which means airlines must go with [[hydrogen fuel]] or SAF. Dourado is betting on SAF over Hydrogen (esp. fuel made from CO2 from the atmosphere), since they are more energy dense. (View Highlight) #Ankified
    • [[transportation]]
      • [[electric cars]] – they’re better than regular cars due to lower fuel costs, lower maintenance costs (fewer moving parts), faster acceleration, higher low-end torque. (View Highlight) One exception is trucking, which may have to shift to hydrogen. This shift will significantly reduce air pollution from unregulated ultrafine particles; resulting in fewer premature birth, asthma, cancer, and mystery illness.
      • [[autonomous vehicles]] could happen at scale in 2020, and autonomy is inevitable eventually with constantly improving sensors and machine learning algorithms. (View Highlight)
      • [[supersonic aircraft]] will have a big impact on global business when it comes, but this is likely not in the 2020s. (View Highlight) [[urban air mobility]] may also happen (e.g. Joby, Wisk).
      • [[drone delivery]] is likely in the 2020s, with the [[FAA]] about to issue a rule expanding operations at night and flights over crowds. (View Highlight)
      • [[tunnels]] are a possible route in countries like the US where it is extremely difficult to build above-ground due to "promiscuous distribution of the veto power" (View Highlight). [[The Boring Company]] has a couple promising projects here, and Dourado is optimistic about the impact on commerce since time and hassle cost of travel is a key input to the [[gravity model of trade]].
    • [[space]]
      • [[SpaceX]] seems poised to dramatically reduce the cost of space exploration with [[Starship (SpaceX)]]. The Space Shuttle was about $65,000/kg to low earth orbit, [[Falcon 9 (SpaceX)]] is only $2,600/kg, and reasonable estimates suggest Starship could reach $10/kg. (View Highlight) #Ankified
      • Some consequences: commerce between Earth and space expands (e.g. manufacturing materials that can only be made in space, [[Starlink (SpaceX)]]), and less engineering required on payloads due to the consequences of losing them being lower. #[[gravity model of trade]] (View Highlight)
    • [[information technology]]
      • "[[custom silicon]] is going to be huge", due to incredible performance gains. Another name for this is [[system on a chip (SoC)]]. [[Apple M1]] is a notable example. "Almost all computer hardware—anything that has any scale to it—will move in this direction"
    • Conclusion
      • "It all depends on [[execution]]. The underlying science is there. The engineers are willing. Even the funding is available in most cases. But, as a society, how much urgency do we feel? Our culture does not prioritize [[progress]]—it fights, destructively, for [[status]]. And our politics reflects our culture." (View Highlight)

For access to my shared Anki deck and Roam Research notes knowledge base as well as regular updates on tips and ideas about spaced repetition and improving your learning productivity, join “Download Mark’s Brain”.

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).

For access to my shared Anki deck and Roam Research notes knowledge base as well as regular updates on tips and ideas about spaced repetition and improving your learning productivity, join “Download Mark’s Brain”.

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

https://www.youtube.com/watch?v=29AgSo6KOtI}
  • {{[[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.

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

  • {{[[youtube]]: https://www.youtube.com/watch?v=3jPYk7ucrjo}}
  • Title:: Applications: Today & 2025
  • Author:: [[Balaji Srinivasan]]
  • Source:: https://www.youtube.com/watch?v=3jPYk7ucrjo
  • Reading Status:: [[complete]]
  • Review Status:: [[complete]]
  • Tags:: #Entrepreneurship #startups #Technology #crypto #decentralization #shared
  • Roam Notes URL:: https://www.marknagelberg.com/roam-notes-on-balaji-srinivasans-applications-today-2025/
  • Anki Tag:: srinivasan_apps_today_2025
  • Anki Deck Link:: link

  • Notes

    • 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]]

For access to my shared Anki deck and Roam Research notes knowledge base as well as regular updates on tips and ideas about spaced repetition and improving your learning productivity, join “Download Mark’s Brain”.

Roam Notes: Elon Musk Interview from Air Warfare Symposium 2020

  • Author:: [[Elon Musk]] [[General John F. Thompson]]
  • Source:: link
  • Tags:: #Business #Management #Leadership #Innovation #SpaceX #Tesla #Government #shared
  • Roam Notes URL:: link
  • Anki Tag:: musk_2020_air_warfare_symposium
  • Anki Deck Link:: link
  • Reading Status:: [[complete]]
  • Review Status:: [[complete]]
  • {{[[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.

For access to my shared Anki deck and Roam Research notes knowledge base as well as regular updates on tips and ideas about spaced repetition and improving your learning productivity, join “Download Mark’s Brain”.

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]]
  • Review Status:: [[complete]]
  • Recommended By:: [[Tyler Cowen]]
  • Tags:: #Book #Parenting #genetics #[[nature vs nurture]] #[[reasons to have kids]] #[[impact of parenting]] #shared
  • 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.

For access to my shared Anki deck and Roam Research notes knowledge base as well as regular updates on tips and ideas about spaced repetition and improving your learning productivity, join “Download Mark’s Brain”.

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

  • {{[[youtube]]: https://www.youtube.com/watch?v=WhnDvvNS8zQ}}
  • Title:: Taking on the Challenge
  • Author:: [[Jeff Bezos]]
  • Source:: https://www.youtube.com/watch?v=WhnDvvNS8zQ
  • Reading Status:: [[complete]]
  • Review Status:: [[complete]]
  • Tags:: #Business #entrepreneurship #innovation #Amazon #Management
  • Roam Notes URL:: link
  • Anki Tag:: bezos_taking_on_the_challenge
  • Anki Deck Link:: link

  • 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: #Ankified
      • 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]] #Ankified
    • Barriers to Innovation #[[barriers to innovation]] #Ankified
      • [[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. (4:30)
      • [[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]]. (10:00)
    • 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.
    • 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.
    • 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 #Ankified

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]]
  • Roam Notes URL:: link
  • Reading Status:: [[complete]]
  • Review Status:: [[complete]]
  • Anki Tag:: dan_luu_weekend
  • Anki Deck Link:: link

  • 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. #Ankified
      • 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.

  • Notes

    • Technical Reasons you can’t "Build it in Weekend"
      • Hiring more engineers can improve site performance, which simultaneously increases revenue (there’s a wide body of research that’s found that decreasing [[latency]] has a roughly linear effect on revenue) while also reducing costs.
      • Engineers also help create features, and seemingly trivial [[features]] can add integer percentage points to revenue. 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, which is often many engineers. #Hiring
        • [[features]] are often much more complex than outsiders realize. For a weekend [[MVP]], you can ignore things like [[internationalization]], but in a real business that would be ignoring a huge market.
    • Organizational Reasons you can’t "Build it in a Weekend"
      • Compared to [[organizational problems]], [[technical problems]] are straightforward.
        • [[Dan Luu]] uses the example of [[distributed systems]] to illustrate this
          • "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]]
    • Successful organizations will inevitably grow and hire many staff, not because it’s necessary to run the service, but because they would be leaving money on the table if they didn’t.
    • This is related to a common fallacy in programming [[reliable systems]]: engineers build the happy path thinking that’s the “real” work, and [[error handling]] can be added later. For reliable systems, error handling is more work than the happy path. The same is true for big companies — everything people think isn’t “real” work is actually more work than the core service.

Roam Notes on “The Checklist Manifesto” by Atul Gawande

  • Title:: The Checklist Manifesto: How to get Things Right
  • Author:: [[Atul Gawande]]
  • Reading Status:: [[complete]]
  • Review Status:: [[complete]]
  • Tags:: #Productivity #organization #process #Management #coordination #checklists #planning
  • Roam Notes URL:: link
  • Anki Tag:: atul_gawande_checklist_manifesto
  • Anki Deck Link:: link

  • Overview

    • [[Atul Gawande]] is a famous surgeon, writer, and public health researcher. This book is an ode to simple checklists as an extremely powerful tool to aid process and quality improvement, especially in situations where there is a lot of [[complexity]] and [[coordination]] required. The author became interested in checklists as a tool in his surgical practice, and the book points to many examples of how checklists improve [[efficiency]] and [[safety]] in a variety of situations.
    • A common theme in the book is the fallibility of human beings and the importance of acknowledging these shortcomings. The author points to examples where excellent surgeons and other professionals have made serious and "obvious" errors. It’s easy to dismiss these errors by blaming the person committing them as incompetent or lazy, but the fact is, without proper systems, these mistakes will happen regardless of how well trained or skilled a person is. Properly designed checklists can provide a crucial safeguard.

  • Excerpts

    • Three Different Levels of Complexity for Problems in the World (pg. 49) #complexity #[[problem solving]] #Ankified
      • Simple: there is a recipe. Sometimes there are a few basic techniques to learn. But once mastered, following the recipe bring a high likelihood of success. #[[simple problems]]
      • Complicated: Can sometimes be broken down into a series of simple problems, but there is no straightforward recipe. Success often requires multiple people, multiple teams, and specialized expertise. Unanticipated difficulties are frequent. Timing and coordination are serious concerns. E.g. sending man to the moon. #[[complicated problems]]
      • Complex: Problems where the solution is not repeatable, and outcomes remain highly uncertain. Expertise is valuable but not sufficient. E.g. raising a child. [[complex problems]]
      • This distinction was developed by [[Brenda Zimmerman]] of [[York University]] and [[Sholom Glouberman]] of [[University of Toronto]] in their study of the science of complexity.
      • Note that many problems in engineering and operating a business are simple or complicated, and thus can be aided by [[checklists]].
    • How Skyscraper Engineers Build Checklists (pp. 62, 70) #engineering #coordination
      • Since every building is a new creature with its own particularities, every building checklist is new, too. It is drawn up by a group of people representing each of the sixteen trades. Then the whole checklist is sent to the subcontractors and other independent experts so they can double-check that everything is correct, that nothing has been missed.
      • They rely on one set of checklists to make sure the simple steps are not missed or skipped and in another set to make sure that everyone talks through and resolves all the hard and unexpected problems.
      • The biggest cause of serious error in this business is a failure of [[communication]] #Ankified
      • [[Mark’s Notes]]: This almost magical process ensures that the knowledge of hundreds or thousands is used in the right place at the right time in the right way.
    • Why Dictating from the Top Fails in Complex Situations (pg. 79) #micromanaging #decentralization #centralization #complexity #Management #[[central planning]]
      • … under conditions of true complexity – where the knowledge required exceeds that of any individual and unpredictability reigns – efforts to dictate every step from the center will fail. People need room to act and adapt. Yet they cannot succeed as isolated individuals, either – that is anarchy. Instead, they require a seemingly contradictory mix of [[freedom]] and [[expectation]] – expectation to coordinate, for example, and also to measure progress toward common goals. #leadership
      • [[Mark’s Notes]]: The example in the book is the [[Katrina disaster]]. [[FEMA]] tried to centrally control everything. In contrast, [[Walmart]] helped the community very effectively – its leadership sent a clear message to do what’s right, and do what you can to help these people in trouble.
        • Also, the skyscraper builders understand this, and learned to codify this type of [[decentralization]] in [[checklists]]. They have checklists for simple tasks, combined with checklists to make sure everyone is coordinating and communicating with each other. There must be judgement, but judgement must be aided / enhanced by procedure.
    • Good Checklists Versus Bad Checklists (pg. 120) #checklists #[[how to make checklists]]
      • Bad [[checklists]] are vague and imprecise. They are too long; they are hard to use; they are impractical. They are made by desk jockeys with no awareness of the situations in which they are to be deployed. They treat the people using the tools as dumb and try to spell out every single step. They turn people’s brains off rather than turn them on.
      • Good checklists, on the other hand, are precise. They are efficient, to the point, and easy to use even in the most difficult situations. They do not try to spell out everything – a checklist cannot fly a plane. Instead, they provide reminders of only the most critical and important steps – the ones that even the highly skilled professionals using them could miss. Good checklists are, above all, practical.
    • The Most Common Obstacle to Effective Teams (pg. 163) #coordination #teamwork #communication #Ankified
      • The most common obstacle to effective teams, it turns out, is not the occasional fire-breathing, scalpel-flinging, terror-inducing surgeon, though some do exist … No, the more familiar and widely dangerous issue is a kind of silent disengagement, the consequence of specialized technicians sticking narrowly to their domains. ‘That’s not my problem’ is possibly the worst thing people can think, whether they are starting an operation, taxiing an airplane full of passengers down a runway, or building a thousand-foot-tall skyscraper.
    • Key Decisions to Make when Building Checklists (pp. 123-124) #checklists #[[how to make checklists]]
      • Define a clear pause point (point at which the checklist is supposed to be used)
      • Decide on whether you want a DO-CONFIRM checklist or READ-DO checklist.
        • DO-CONFIRM – team members perform a job from memory and experience, often separately. But then they stop. They pause to run the check-list and confirm that everything that was supposed to be done was done.
        • READ-DO – people carry out the tasks as they check them off – more like a recipe
      • Test it: “no matter how careful we might be, no matter how much thought we might put in, the checklist has to be tested in the real world, which is inevitably more complicated than expected” #testing
        • [[Mark’s Notes]]: Sometimes, testing is not easy to do. That’s why they have simulations in aviation and the author tried a similar test for surgery with his surgical team and a dummy.
    • How Not to Respond to Failure (pp. 185-186) #failure #Systems #fallibility
      • We are all plagued by failures – by missed subtleties, overlooked knowledge, and outright errors. For the most part, we have imagined that little can be done beyond working harder and harder to catch the problems and clean up after them. We are not in the habit of thinking the way army pilots did as they looked upon their shiny new Model 299 bomber – a machine so complex no one was sure human beings could fly it. They too could have decided just to ‘try harder’ or to dismiss a crash as the failings of a ‘weak’ pilot. Instead they chose to accept their fallibilities. They recognized the simplicity and power of using a checklist. #Ankified
        • [[Mark’s Notes]]: It is such a common sentiment to blame failure on people’s abilities or motivations.