Merge pull request #445 from dwmkerr/release-please--branches--main

chore(main): release 0.3.0
2025-12-17 12:45:20 +01:00 · 2025-03-31 09:40:38 +01:00 · 2025-03-31 08:40:21 +00:00 · 2025-03-31 09:39:34 +01:00 · 2025-03-31 08:30:31 +01:00 · 2025-03-31 07:28:31 +00:00
39 changed files with 4502 additions and 297 deletions
--- a/.github/CHANGELOG.md
+++ b/.github/CHANGELOG.md
@@ -0,0 +1,41 @@
 # Changelog
 ## [0.3.0](https://github.com/dwmkerr/hacker-laws/compare/v0.2.1...v0.3.0) (2025-03-31)
 ### Features
 * add Koomey's Law ([dcdcfdf](https://github.com/dwmkerr/hacker-laws/commit/dcdcfdfc25ee121b6bcb931a71e185fa7ffeedcd))
 ## [0.2.1](https://github.com/dwmkerr/hacker-laws/compare/v0.2.0...v0.2.1) (2025-03-31)
 ### Bug Fixes
 * remove frontmatter ([2140429](https://github.com/dwmkerr/hacker-laws/commit/2140429b959a8284b452c3fa05e1c9fd03e5ebab))
 ## [0.2.0](https://github.com/dwmkerr/hacker-laws/compare/v0.1.0...v0.2.0) (2025-03-31)
 ### Features
 * 90-90 rule ([4477907](https://github.com/dwmkerr/hacker-laws/commit/44779074caa6495198214100e5bd0a886cc1e680))
 * add section for Kerckhoff's principle ([5f74607](https://github.com/dwmkerr/hacker-laws/commit/5f74607c63d3a76009ec0546ba515f8f7c1d3864))
 * add ukranian language to README ([#320](https://github.com/dwmkerr/hacker-laws/issues/320)) ([015d251](https://github.com/dwmkerr/hacker-laws/commit/015d25197f808d66c4dfebcdd0b54675af6a3eae)), closes [#236](https://github.com/dwmkerr/hacker-laws/issues/236)
 * Dunning Kruger Effect ([3dbc237](https://github.com/dwmkerr/hacker-laws/commit/3dbc237c1f1c59e809969320cc0ae4347a4b45c3))
 * Dunning-Kruger Effect ([#318](https://github.com/dwmkerr/hacker-laws/issues/318)) ([34c38d8](https://github.com/dwmkerr/hacker-laws/commit/34c38d87edba4b0e36d2ad9488b97d0c77f9b550))
 * **pages:** update index.html and pages.yaml for deployment ([beb3d57](https://github.com/dwmkerr/hacker-laws/commit/beb3d57a6a5a3a38aa9e692ed13eb01060b85ded))
 * principle of least astonishment ([4be4827](https://github.com/dwmkerr/hacker-laws/commit/4be482731b6a6009453af7d303d3cd2470a2e73e))
 * principle of least astonishment ([e4662cb](https://github.com/dwmkerr/hacker-laws/commit/e4662cbc27d04fb968220837633034420b7fb11a))
 * the scout rule ([716aef8](https://github.com/dwmkerr/hacker-laws/commit/716aef807e758bd8df976f323089db525da9f708))
 * the scout rule ([c6fccf4](https://github.com/dwmkerr/hacker-laws/commit/c6fccf4978d9483637fba8c7887127abad3de581)), closes [#144](https://github.com/dwmkerr/hacker-laws/issues/144)
 * twyman's law ([b9ad4c6](https://github.com/dwmkerr/hacker-laws/commit/b9ad4c6f99f991a1bda9a2cfdddef62787e6ae82))
 ### Bug Fixes
 * correct facebook link on website ([6f9b1e3](https://github.com/dwmkerr/hacker-laws/commit/6f9b1e33345bc1332428f0fba8c7aa2900147500))
 * correct formatting around quote ([d83d439](https://github.com/dwmkerr/hacker-laws/commit/d83d439df89e8af50ae53bafa3a791f8d92a6991))
 * Fix section's links ([#317](https://github.com/dwmkerr/hacker-laws/issues/317)) ([7b341fc](https://github.com/dwmkerr/hacker-laws/commit/7b341fc0d205f076e25ff8fedb972e652201c3c6))
 * image paths ([692b7cc](https://github.com/dwmkerr/hacker-laws/commit/692b7cca1a97eb62384db170297b504f51ea408e))
 * remove superfluous 'is' ([3b78ae6](https://github.com/dwmkerr/hacker-laws/commit/3b78ae65f02fca457bb8adbf113135e1ed042a46))
--- a/.github/contributing.md
+++ b/.github/contributing.md
@@ -2,11 +2,18 @@
 <!-- vim-markdown-toc GFM -->
-* [Example Law: The Law of Leaky Abstractions](#example-law-the-law-of-leaky-abstractions)
+- [Goal of the Project](#goal-of-the-project)
-* [Localisation](#localisation)
+- [Example Law: The Law of Leaky Abstractions](#example-law-the-law-of-leaky-abstractions)
 - [Translations](#translations)
 - [How do I know if a law is relevant?](#how-do-i-know-if-a-law-is-relevant)
 - [How do I know if a law is 'well known' enough?](#how-do-i-know-if-a-law-is-well-known-enough)
 - [Use of Images](#use-of-images)
 - [Developer Guide](#developer-guide)
 <!-- vim-markdown-toc -->
 ## Goal of the Project
 The goal of this project is to have a set of _concise_ definitions to laws, principles, methodologies and patterns which hackers will find useful. They should be:
 1. Short - one or two paragraphs.
@@ -30,7 +37,7 @@ An example law is shown below, which covers most of the key points:
 ---
-### Example Law: The Law of Leaky Abstractions
+## Example Law: The Law of Leaky Abstractions
 [The Law of Leaky Abstractions on Joel on Software](https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/)
@@ -54,10 +61,45 @@ Real-world examples:
 - [Photoshop Slow Startup](https://forums.adobe.com/thread/376152) - an issue I encountered in the past. Photoshop would be slow to startup, sometimes taking minutes. It seems the issue was that on startup it reads some information about the current default printer. However, if that printer is actually a network printer, this could take an extremely long time. The _abstraction_ of a network printer being presented to the system similar to a local printer caused an issue for users in poor connectivity situations.
-### Localisation
+## Translations
 We are currently using [GitLocalize](https://gitlocalize.com) to handle translations. This provides features to make it easier for people to manage translations as changes come in:
 ![GitLocalize Screenshot](../images/gitlocalize.png)
-This is still work in progress - if you would like to be a maintainer for a language just open an issue to get in touch!
+If you would like to moderate a language, please follow the steps below:
 1. Log in to [Git Localize](https://gitlocalize.com) with your GitHub account, this will create a GitLocalize account for you.
 0. [Open an Issue](https://github.com/dwmkerr/hacker-laws/issues/new) with the name of the language you would like to moderate/translate.
 0. [Open a Pull Request](https://github.com/dwmkerr/hacker-laws/compare) that adds your details and the language details to the [Translators](https://github.com/dwmkerr/hacker-laws#translations) section of the README.
 3. I will then make you a moderator of the language and ensure the language is listed properly.
 Thanks!
 ## How do I know if a law is relevant?
 In general, it should be reasonably applicable to the world of computer sciences, IT or coding in general.
 ## How do I know if a law is 'well known' enough?
 A good test is 'If I search for it on Google, will I find it in the first few results?'.
 ## Use of Images
 Please make sure to attribute images properly if you are referencing them. Also, include a white background, as some viewers will be viewing the site in 'Dark Mode' which can make images with a transparent background difficult to read.
 ## Developer Guide
 Where possible, anything which is not the core `README.md` file is kept in the `.github/` folder to keep the landing page for the repository as clean as possible.
 To use the makefile, pass its path explicitly, e.g:
 ```bash
 make -f .github/makefile
 ```
 Or create an alias:
 ```bash
 alias hlmake="make -f .github/makefile"
--- a/.github/makefile
+++ b/.github/makefile
@@ -0,0 +1,22 @@
 default: help
 .PHONY: help
 help: # Show help for each of the Makefile recipes.
 	@grep -E '^[a-zA-Z0-9 -]+:.*#'  Makefile | sort | while read -r l; do printf "\033[1;32m$$(echo $$l | cut -f 1 -d':')\033[00m:$$(echo $$l | cut -f 2- -d'#')\n"; done
 .PHONY: prepare-markdown
 prepare-markdown: # Prepare the markdown for PDF output.
 	./scripts/prepare-markdown-for-ebook.sh "README.md" "hacker-laws.md"
 .PHONY: create-pdf
 create-pdf: # Create the PDF.
 	docker run --rm \
 		--platform linux/amd64 \
 		-v ${PWD}:/data \
 		pandoc/latex:3.6 \
 		-V toc-title:"Table Of Contents" \
 		--toc \
 		--pdf-engine=lualatex \
 		--standalone \
 		--output hacker-laws.pdf \
 		hacker-laws.md
--- a/.github/release-please-config.json
+++ b/.github/release-please-config.json
@@ -0,0 +1,18 @@
 {
  "release-type": "simple",
  "bump-minor-pre-major": true,
  "packages": {
    ".": {
      "release-type": "simple",
      "extra-files": [
        {
          "type": "generic",
          "path": "README.md"
        }
      ],
     "changelog-path": ".github/CHANGELOG.md"
    }
  }
 }
--- a/.github/release-please-manifest.json
+++ b/.github/release-please-manifest.json
@@ -0,0 +1,3 @@
 {
  ".": "0.3.0"
 }
--- a/.github/website/backup/ideas.md
+++ b/.github/website/backup/ideas.md
--- a/.github/website/backup/index2.html
+++ b/.github/website/backup/index2.html
@@ -0,0 +1,189 @@
 <!DOCTYPE html>
 <html lang="en">
 <head>
  <meta charset="UTF-8" />
  <meta name="viewport" content="width=device-width, initial-scale=1" />
  <title>Hacker Laws</title>
  <!-- Bootstrap CSS -->
  <link href="https://cdn.jsdelivr.net/npm/bootstrap@5.3.0/dist/css/bootstrap.min.css" rel="stylesheet" />
  <!-- Bootstrap Icons -->
  <link href="https://cdn.jsdelivr.net/npm/bootstrap-icons@1.10.5/font/bootstrap-icons.css" rel="stylesheet" />
  <style>
    /* Soft pastel parchment background */
    body {
      background-color: #fdf6e3;
      color: #333;
      padding-top: 70px; /* to account for sticky navbar */
    }
    /* Navbar customization */
    .navbar-custom {
      background-color: #ffffff;
      box-shadow: 0 2px 4px rgba(0, 0, 0, 0.1);
    }
    /* Header styling */
    header h1 {
      font-size: 2.5rem;
      font-weight: bold;
    }
    header p.lead {
      font-size: 1.25rem;
      color: #555;
    }
    /* Law section container */
    .law-section {
      margin-bottom: 2rem;
      padding: 1.5rem;
      background-color: #fff;
      border-radius: 5px;
      box-shadow: 0 2px 5px rgba(0, 0, 0, 0.1);
    }
    /* Social sharing icons */
    .social-sharing a {
      margin-right: 0.75rem;
      font-size: 1.2rem;
      color: #555;
      text-decoration: none;
    }
    .social-sharing a:hover {
      color: #000;
    }
    /* Back to top link styling */
    .back-to-top a {
      font-size: 0.9rem;
      text-decoration: none;
      color: #007bff;
    }
    .back-to-top a:hover {
      text-decoration: underline;
    }
  </style>
 </head>
 <body id="top">
  <!-- Sticky Navbar -->
  <nav class="navbar navbar-expand-lg navbar-custom fixed-top">
    <div class="container">
      <a class="navbar-brand fw-bold" href="#top">Hacker Laws</a>
      <button class="navbar-toggler" type="button" data-bs-toggle="collapse" data-bs-target="#navMenu" aria-controls="navMenu" aria-expanded="false" aria-label="Toggle navigation">
        <span class="navbar-toggler-icon"></span>
      </button>
      <div class="collapse navbar-collapse" id="navMenu">
        <ul class="navbar-nav me-auto">
          <li class="nav-item">
            <a class="nav-link" href="#"><i class="bi bi-book"></i> Effective Shell</a>
          </li>
          <li class="nav-item">
            <a class="nav-link" href="#"><i class="bi bi-cup"></i> Sponsor</a>
          </li>
          <li class="nav-item">
            <a class="nav-link" href="#"><i class="bi bi-brain"></i> Terminal AI</a>
          </li>
        </ul>
        <ul class="navbar-nav ms-auto">
          <li class="nav-item">
            <a class="nav-link" href="#"><i class="bi bi-github"></i> GitHub</a>
          </li>
        </ul>
      </div>
    </div>
  </nav>
  <!-- Page Header -->
  <header class="container my-4">
    <h1>Hacker Laws</h1>
    <p class="lead">Laws, Theories, Principles and Patterns that developers will find useful.</p>
  </header>
  <!-- Main Content -->
  <main class="container">
    <!-- Introduction Section -->
    <section id="introduction" class="law-section">
      <h2>Introduction</h2>
      <p>There are lots of laws which people discuss when talking about development. This repository is a reference and overview of some of the most common ones. Please share and submit PRs!</p>
      <p><strong>Note:</strong> This repo contains an explanation of some laws, principles and patterns, but does not <em>advocate</em> for any of them. Whether they should be applied will always be a matter of debate, and greatly dependent on what you are working on.</p>
      <!-- Social Sharing Icons -->
      <div class="social-sharing">
        <a href="#" title="Share on Twitter"><i class="bi bi-twitter"></i></a>
        <a href="#" title="Share on Facebook"><i class="bi bi-facebook"></i></a>
        <a href="#" title="Share on LinkedIn"><i class="bi bi-linkedin"></i></a>
      </div>
      <!-- Back to Top Options (choose one) -->
      <div class="back-to-top mt-2">
        <a href="#top">↑ Top</a>
        <!-- Alternative options:
             <a href="#top">Back to Top</a>
             <a href="#top">Return to Top</a>
             <a href="#top">Go Up</a>
             <a href="#top">Scroll Up</a>
        -->
      </div>
    </section>
    <!-- 90–9–1 Principle (1% Rule) Section -->
    <section id="9091-principle" class="law-section">
      <h2>90–9–1 Principle (1% Rule)</h2>
      <p>The 90-9-1 principle suggests that within an internet community such as a wiki, 90% of participants only consume content, 9% edit or modify content and 1% of participants add content.</p>
      <p>Real-world examples:</p>
      <ul>
        <li>A 2014 study of four digital health social networks found the top 1% created 73% of posts, the next 9% accounted for an average of ~25% and the remaining 90% accounted for an average of 2%.</li>
      </ul>
      <p>See Also: <a href="#the-pareto-principle-the-8020-rule">Pareto Principle</a></p>
      <!-- Social Sharing Icons -->
      <div class="social-sharing">
        <a href="#" title="Share on Twitter"><i class="bi bi-twitter"></i></a>
        <a href="#" title="Share on Facebook"><i class="bi bi-facebook"></i></a>
        <a href="#" title="Share on LinkedIn"><i class="bi bi-linkedin"></i></a>
      </div>
      <!-- Back to Top Options -->
      <div class="back-to-top mt-2">
        <a href="#top">↑ Top</a>
      </div>
    </section>
    <!-- 90–90 Rule Section -->
    <section id="9090-rule" class="law-section">
      <h2>90–90 Rule</h2>
      <p>The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.</p>
      <p>This is a wry reinterpretation of the <a href="#the-pareto-principle-the-8020-rule">Pareto Principle</a> (or 80-20 rule) that highlights the real-world challenges of completing engineering work. This sentiment is also echoed in <a href="#hofstadters-law">Hofstadter's Law</a>.</p>
      <!-- Social Sharing Icons -->
      <div class="social-sharing">
        <a href="#" title="Share on Twitter"><i class="bi bi-twitter"></i></a>
        <a href="#" title="Share on Facebook"><i class="bi bi-facebook"></i></a>
        <a href="#" title="Share on LinkedIn"><i class="bi bi-linkedin"></i></a>
      </div>
      <!-- Back to Top Options -->
      <div class="back-to-top mt-2">
        <a href="#top">↑ Top</a>
      </div>
    </section>
    <!-- Additional law sections would follow the same structure -->
  </main>
  <!-- Footer -->
  <footer class="container text-center my-4">
    <p>&copy; 2025 Hacker Laws</p>
  </footer>
  <!-- Bootstrap Bundle with Popper -->
  <script src="https://cdn.jsdelivr.net/npm/bootstrap@5.3.0/dist/js/bootstrap.bundle.min.js"></script>
  <script>
    // Optional: Smooth scrolling for in-page links
    document.querySelectorAll('a[href^="#"]').forEach(anchor => {
      anchor.addEventListener('click', function(e) {
        e.preventDefault();
        const targetElem = document.querySelector(this.getAttribute('href'));
        if (targetElem) {
          targetElem.scrollIntoView({ behavior: 'smooth' });
        }
      });
    });
  </script>
 </body>
 </html>
--- a/.github/website/backup/index3.html
+++ b/.github/website/backup/index3.html
@@ -0,0 +1,194 @@
 <!DOCTYPE html>
 <html lang="en">
 <head>
  <meta charset="UTF-8" />
  <meta name="viewport" content="width=device-width, initial-scale=1" />
  <title>Hacker Laws</title>
  <!-- Google Font for elegant serif fonts -->
  <link href="https://fonts.googleapis.com/css2?family=Libre+Baskerville:wght@400;700&display=swap" rel="stylesheet">
  <!-- Bootstrap CSS -->
  <link href="https://cdn.jsdelivr.net/npm/bootstrap@5.3.0/dist/css/bootstrap.min.css" rel="stylesheet" />
  <!-- Bootstrap Icons -->
  <link href="https://cdn.jsdelivr.net/npm/bootstrap-icons@1.10.5/font/bootstrap-icons.css" rel="stylesheet" />
  <style>
    /* Use an elegant serif font and a clean, minimal palette */
    body {
      font-family: 'Libre Baskerville', Georgia, serif;
      background-color: #fff;
      color: #333;
      padding-top: 70px; /* account for sticky navbar */
    }
    .container {
      max-width: 800px;
    }
    /* Simplified Navbar */
    .navbar-custom {
      background-color: #fff;
      border-bottom: 1px solid #e5e5e5;
    }
    .navbar-brand,
    .nav-link {
      font-weight: 700;
    }
    /* Centered, minimal header */
    header {
      text-align: center;
      margin-bottom: 2rem;
    }
    header h1 {
      font-size: 2.5rem;
      margin-bottom: 0.5rem;
    }
    header p.lead {
      font-size: 1.25rem;
      color: #555;
    }
    /* Law section styling: simple borders instead of shadows */
    .law-section {
      margin-bottom: 2rem;
      padding: 1.5rem;
      background-color: #fff;
      border-bottom: 1px solid #e5e5e5;
    }
    /* Social sharing icons remain the same */
    .social-sharing a {
      margin-right: 0.75rem;
      font-size: 1.2rem;
      color: #555;
      text-decoration: none;
    }
    .social-sharing a:hover {
      color: #000;
    }
    /* Back to top link styling */
    .back-to-top a {
      font-size: 0.9rem;
      text-decoration: none;
      color: #007bff;
    }
    .back-to-top a:hover {
      text-decoration: underline;
    }
  </style>
 </head>
 <body id="top">
  <!-- Sticky Navbar -->
  <nav class="navbar navbar-expand-lg navbar-custom fixed-top">
    <div class="container">
      <a class="navbar-brand" href="#top">Hacker Laws</a>
      <button class="navbar-toggler" type="button" data-bs-toggle="collapse" data-bs-target="#navMenu" aria-controls="navMenu" aria-expanded="false" aria-label="Toggle navigation">
        <span class="navbar-toggler-icon"></span>
      </button>
      <div class="collapse navbar-collapse" id="navMenu">
        <ul class="navbar-nav me-auto">
          <li class="nav-item">
            <a class="nav-link" href="#"><i class="bi bi-book"></i> Effective Shell</a>
          </li>
          <li class="nav-item">
            <a class="nav-link" href="#"><i class="bi bi-cup"></i> Sponsor</a>
          </li>
          <li class="nav-item">
            <a class="nav-link" href="#"><i class="bi bi-brain"></i> Terminal AI</a>
          </li>
        </ul>
        <ul class="navbar-nav ms-auto">
          <li class="nav-item">
            <a class="nav-link" href="#"><i class="bi bi-github"></i> GitHub</a>
          </li>
        </ul>
      </div>
    </div>
  </nav>
  <!-- Page Header -->
  <header class="container my-4">
    <h1>Hacker Laws</h1>
    <p class="lead">Laws, Theories, Principles and Patterns that developers will find useful.</p>
  </header>
  <!-- Main Content -->
  <main class="container">
    <!-- Introduction Section -->
    <section id="introduction" class="law-section">
      <h2>Introduction</h2>
      <p>There are lots of laws which people discuss when talking about development. This repository is a reference and overview of some of the most common ones. Please share and submit PRs!</p>
      <p><strong>Note:</strong> This repo contains an explanation of some laws, principles and patterns, but does not <em>advocate</em> for any of them. Whether they should be applied will always be a matter of debate, and greatly dependent on what you are working on.</p>
      <!-- Social Sharing Icons -->
      <div class="social-sharing">
        <a href="#" title="Share on Twitter"><i class="bi bi-twitter"></i></a>
        <a href="#" title="Share on Facebook"><i class="bi bi-facebook"></i></a>
        <a href="#" title="Share on LinkedIn"><i class="bi bi-linkedin"></i></a>
      </div>
      <!-- Back to Top -->
      <div class="back-to-top mt-2">
        <a href="#top">↑ Top</a>
      </div>
    </section>
    <!-- 90–9–1 Principle (1% Rule) Section -->
    <section id="9091-principle" class="law-section">
      <h2>90–9–1 Principle (1% Rule)</h2>
      <p>The 90-9-1 principle suggests that within an internet community such as a wiki, 90% of participants only consume content, 9% edit or modify content and 1% of participants add content.</p>
      <p>Real-world examples:</p>
      <ul>
        <li>A 2014 study of four digital health social networks found the top 1% created 73% of posts, the next 9% accounted for an average of ~25% and the remaining 90% accounted for an average of 2%.</li>
      </ul>
      <p>See Also: <a href="#the-pareto-principle-the-8020-rule">Pareto Principle</a></p>
      <!-- Social Sharing Icons -->
      <div class="social-sharing">
        <a href="#" title="Share on Twitter"><i class="bi bi-twitter"></i></a>
        <a href="#" title="Share on Facebook"><i class="bi bi-facebook"></i></a>
        <a href="#" title="Share on LinkedIn"><i class="bi bi-linkedin"></i></a>
      </div>
      <!-- Back to Top -->
      <div class="back-to-top mt-2">
        <a href="#top">↑ Top</a>
      </div>
    </section>
    <!-- 90–90 Rule Section -->
    <section id="9090-rule" class="law-section">
      <h2>90–90 Rule</h2>
      <p>The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.</p>
      <p>This is a wry reinterpretation of the <a href="#the-pareto-principle-the-8020-rule">Pareto Principle</a> (or 80-20 rule) that highlights the real-world challenges of completing engineering work. This sentiment is also echoed in <a href="#hofstadters-law">Hofstadter's Law</a>.</p>
      <!-- Social Sharing Icons -->
      <div class="social-sharing">
        <a href="#" title="Share on Twitter"><i class="bi bi-twitter"></i></a>
        <a href="#" title="Share on Facebook"><i class="bi bi-facebook"></i></a>
        <a href="#" title="Share on LinkedIn"><i class="bi bi-linkedin"></i></a>
      </div>
      <!-- Back to Top -->
      <div class="back-to-top mt-2">
        <a href="#top">↑ Top</a>
      </div>
    </section>
  </main>
  <!-- Footer -->
  <footer class="container text-center my-4">
    <p>&copy; 2025 Hacker Laws</p>
  </footer>
  <!-- Bootstrap Bundle with Popper -->
  <script src="https://cdn.jsdelivr.net/npm/bootstrap@5.3.0/dist/js/bootstrap.bundle.min.js"></script>
  <script>
    // Smooth scrolling for in-page links
    document.querySelectorAll('a[href^="#"]').forEach(anchor => {
      anchor.addEventListener('click', function(e) {
        e.preventDefault();
        const targetElem = document.querySelector(this.getAttribute('href'));
        if (targetElem) {
          targetElem.scrollIntoView({ behavior: 'smooth' });
        }
      });
    });
  </script>
 </body>
 </html>
--- a/.github/website/backup/index4.html
+++ b/.github/website/backup/index4.html
--- a/.github/website/build/.gitignore
+++ b/.github/website/build/.gitignore
@@ -0,0 +1 @@
 *
--- a/.github/website/generate.py
+++ b/.github/website/generate.py
@@ -0,0 +1,161 @@
 """Generate the Hacker Laws website from the Hacker Laws README"""
 import argparse
 import os
 import shutil
 from jinja2 import Environment, FileSystemLoader
 import markdown
 from bs4 import BeautifulSoup
 def bisect_text(content: str, bisect_line: str) -> tuple[str, str]:
    lines = content.splitlines()
    head = []
    tail = []
    found = False
    for line in lines:
        if found is False and line == bisect_line:
            found = True
            continue
        if found:
            tail.append(line)
        else:
            head.append(line)
    return ("\n".join(head), "\n".join(tail))
 def load_template():
    """Load Jinja2 template from the specified directory."""
    env = Environment(loader=FileSystemLoader(TEMPLATE_DIR))
    return env.get_template(TEMPLATE_FILE)
 def prepare_markdown(path: str) -> str:
    """
    Pre-process the README markdown by removing content we will not show in
    the final website.
    """
    # Load the markdown content.
    with open(path, "r", encoding="utf-8") as f:
        content = f.read()
    return content
 def parse_markdown(markdown_content: str):
    (_, remains) = bisect_text(markdown_content, "---")
    (links, remains) = bisect_text(remains, "---")
    (_, content) = bisect_text(remains, "<!-- vim-markdown-toc -->")
    md = markdown.Markdown(extensions=['toc'])
    links = md.convert(links)
    print(f"links: {links}")
    md.convert(content)
    toc = md.toc
    markdown_sections = content.split("\n#")  # Split by Markdown headings
    sections = []
    laws = []
    for markdown_section in markdown_sections:
        if markdown_section.strip():
            lines = markdown_section.split("\n", 1)
            title = lines[0].strip("# ").strip()
            content = md.convert(lines[1] if len(lines) > 1 else "")
            full_content = md.convert(markdown_section)
            id = title.lower().replace(" ", "-")
            laws.append({"title": title, "content": content, "id": id})
            sections.append({
                "title": title,
                "content": content,
                "id": id,
                "full_content": full_content
            })
    return (links, toc, sections)
 def extract_static_files(html_content, output_dir):
    """
    Extract linked CSS, JS, and image files and copy them to the output
    directory.
    """
    soup = BeautifulSoup(html_content, "html.parser")
    files_to_copy = []
    # Extract <link> stylesheets
    for link in soup.find_all("link", href=True):
        href = link["href"]
        if not href.startswith(("http", "//")):  # Ignore external links
            files_to_copy.append(href)
    # Extract <script> files
    for script in soup.find_all("script", src=True):
        src = script["src"]
        if not src.startswith(("http", "//")):
            files_to_copy.append(src)
    # Extract <img> files
    for img in soup.find_all("img", src=True):
        src = img["src"]
        if not src.startswith(("http", "//")):
            files_to_copy.append(src)
    # Copy files to the output directory
    for file_path in files_to_copy:
        src_path = os.path.join(TEMPLATE_DIR, file_path)
        dest_path = os.path.join(output_dir, file_path)
        if os.path.exists(src_path):  # Ensure file exists before copying
            os.makedirs(os.path.dirname(dest_path), exist_ok=True)
            shutil.copy2(src_path, dest_path)
            print(f"📂 Copied: {src_path} → {dest_path}")
        else:
            print(f"⚠️ Warning: Missing file {src_path} (skipping)")
    return files_to_copy
 def generate_site(markdown_content: str, output_dir: str):
    """Generate the static HTML file from Markdown and Jinja2 template."""
    template = load_template()
    (links, toc, sections) = parse_markdown(markdown_content)
    # Ensure output directory exists
    os.makedirs(output_dir, exist_ok=True)
    # Render HTML
    html_output = template.render(links=links, toc=toc, sections=sections)
    # Save HTML to output directory
    output_file = os.path.join(output_dir, "index.html")
    with open(output_file, "w", encoding="utf-8") as f:
        f.write(html_output)
    print(f"✅ Static site generated: {output_file}")
    # Copy static files (CSS, JS, images)
    extract_static_files(html_output, output_dir)
 if __name__ == "__main__":
    parser = argparse.ArgumentParser(description="Generate a static site from Markdown.")
    parser.add_argument("-o", "--output-dir", default="build", help="Directory to save the generated site.")
    args = parser.parse_args()
    # Read environment variables with defaults
    TEMPLATE_FILE = os.getenv("TEMPLATE_FILE", "template.html")
    TEMPLATE_DIR = os.getenv("TEMPLATE_DIR", ".")
    template_path = f"{TEMPLATE_DIR}/{TEMPLATE_FILE}"
    markdown_path = os.getenv("MARKDOWN_FILE", "laws.md")
    output_dir = args.output_dir
    print(f"📝 Loading template from: {template_path}")
    print(f"📖 Loading markdown from: {markdown_path}")
    print(f"💾 Outputting files to: {output_dir}")
    # First, extract that markdown that we want to process.
    markdown_content = prepare_markdown(markdown_path)
    # Generate the site from the markdown.
    generate_site(markdown_content, args.output_dir)
--- a/.github/website/makefile
+++ b/.github/website/makefile
@@ -0,0 +1,38 @@
 SHELL := /bin/bash
 TEMPLATE_DIR=src
 TEMPLATE_FILE=index.html.jinja
 MARKDOWN_FILE=../../README.md
 OUTPUT_FILE=build/index.html
 default: help
 .PHONY: help
 help: # Show help for each of the Makefile recipes.
 	@grep -E '^[a-zA-Z0-9 -]+:.*#'  Makefile | sort | while read -r l; do printf "\033[1;32m$$(echo $$l | cut -f 1 -d':')\033[00m:$$(echo $$l | cut -f 2- -d'#')\n"; done
 .PHONY: install
 install: # 📦 install dependencies
 	@echo "📦 Installing dependencies..."
 	pip install -r requirements.txt
 .PHONY: build
 build: #🔨 building static site
 	@echo "🔨 Building static site..."
 	cp -rf ../../images ./build
 	TEMPLATE_FILE=$(TEMPLATE_FILE) MARKDOWN_FILE=$(MARKDOWN_FILE) OUTPUT_FILE=$(OUTPUT_FILE) TEMPLATE_DIR=$(TEMPLATE_DIR) \
 	python generate.py
 .PHONY: serve
 serve: # 🚀 start local server
 	@echo "🚀 Starting local server at http://localhost:8000..."
 	python3 -m http.server 8000
 .PHONY: watch
 watch: build # 👀 Watch for changes...
 	@echo "👀 Watching for changes..."
 	watchmedo shell-command --patterns="$(MARKDOWN_FILE);*.py;src/*" --command="make build" .
 .PHONY: clean
 clean: #🧹 Clean up generated files
 	@echo "🧹 Cleaning up generated files..."
 	rm -f $(OUTPUT)
--- a/.github/website/requirements.txt
+++ b/.github/website/requirements.txt
@@ -0,0 +1,4 @@
 markdown
 jinja2
 watchdog
 beautifulsoup4
--- a/.github/website/src/favicon.svg
+++ b/.github/website/src/favicon.svg
@@ -0,0 +1,3 @@
 <svg width="32" height="32" viewBox="0 0 32 32" fill="none" xmlns="http://www.w3.org/2000/svg">
 <path fill-rule="evenodd" clip-rule="evenodd" d="M16 0C7.16 0 0 7.16 0 16C0 23.08 4.58 29.06 10.94 31.18C11.74 31.32 12.04 30.84 12.04 30.42C12.04 30.04 12.02 28.78 12.02 27.44C8 28.18 6.96 26.46 6.64 25.56C6.46 25.1 5.68 23.68 5 23.3C4.44 23 3.64 22.26 4.98 22.24C6.24 22.22 7.14 23.4 7.44 23.88C8.88 26.3 11.18 25.62 12.1 25.2C12.24 24.16 12.66 23.46 13.12 23.06C9.56 22.66 5.84 21.28 5.84 15.16C5.84 13.42 6.46 11.98 7.48 10.86C7.32 10.46 6.76 8.82 7.64 6.62C7.64 6.62 8.98 6.2 12.04 8.26C13.32 7.9 14.68 7.72 16.04 7.72C17.4 7.72 18.76 7.9 20.04 8.26C23.1 6.18 24.44 6.62 24.44 6.62C25.32 8.82 24.76 10.46 24.6 10.86C25.62 11.98 26.24 13.4 26.24 15.16C26.24 21.3 22.5 22.66 18.94 23.06C19.52 23.56 20.02 24.52 20.02 26.02C20.02 28.16 20 29.88 20 30.42C20 30.84 20.3 31.34 21.1 31.18C27.42 29.06 32 23.06 32 16C32 7.16 24.84 0 16 0V0Z" fill="#24292E"/>
 </svg>
--- a/.github/website/src/index.html.jinja
+++ b/.github/website/src/index.html.jinja
@@ -0,0 +1,76 @@
 <!DOCTYPE html>
 <html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <title>Hacker Laws</title>
    <!-- Google tag (gtag.js) -->
    <script async src="https://www.googletagmanager.com/gtag/js?id=G-RGJ5TDHWY9"></script>
    <script>
      window.dataLayer = window.dataLayer || [];
      function gtag(){dataLayer.push(arguments);}
      gtag('js', new Date());
      gtag('config', 'G-RGJ5TDHWY9');
    </script>
    <link rel="icon" href="favicon.svg" type="image/svg+xml">
    <!-- Google Fonts -->
    <link href="https://fonts.googleapis.com/css2?family=Libre+Baskerville:wght@400;700&family=Inter:wght@400;600&display=swap" rel="stylesheet">
    <!-- Bootstrap CSS -->
    <link href="https://cdn.jsdelivr.net/npm/bootstrap@5.3.0/dist/css/bootstrap.min.css" rel="stylesheet" />
    <!-- Bootstrap Icons -->
    <link href="https://cdn.jsdelivr.net/npm/bootstrap-icons@1.10.5/font/bootstrap-icons.css" rel="stylesheet" />
    <link rel="stylesheet" href="styles.css">
  </head>
  <body id="top">
    <nav class="navbar navbar-expand-lg fixed-top bg-dark" data-bs-theme="dark">
      <div class="container">
        <a class="navbar-brand" href="#top">Hacker Laws</a>
        <button class="navbar-toggler" type="button" data-bs-toggle="collapse" data-bs-target="#navMenu">
          <span class="navbar-toggler-icon"></span>
        </button>
        <div class="collapse navbar-collapse  justify-content-end" id="navMenu">
          <ul class="navbar-nav me-auto">
            <li class="nav-item"><a class="nav-link" href="https://effective-shell.com" target="_blank"><i class="bi bi-book"></i> Effective Shell</a></li>
            <li class="nav-item"><a class="nav-link" href="https://github.com/dwmkerr/terminal-ai" target="_blank"><i class="bi bi-terminal"></i> Terminal AI</a></li>
            <li class="nav-item"><a class="nav-link" href="https://github.com/sponsors/dwmkerr" target="_blank"><i class="bi bi-cup-hot"></i> Sponsor</a></li>
          </ul>
          <a href="https://github.com/dwmkerr/hacker-laws" target="_blank"><button class="btn btn-outline-light" type="submit"><i class="bi bi-github"></i> GitHub</button></a>
        </div>
      </div>
    </nav>
    <header class="container">
      <h1>Hacker Laws</h1>
      <p class="lead">Laws, Theories, Principles and Patterns that developers will find useful.</p>
    </header>
    <main class="container">
      <!-- Quick links. -->
      {{ links }}
      <hr>
      <!-- The table of contents. -->
      {{ toc }}
      <hr>
      <!-- Each of the sections - most of which are laws. -->
      {% for section in sections %}
      <section id="{{ section.id }}" class="law-section">
        {{ section.full_content | safe }}
        <div class="social-sharing">
          <a href="https://twitter.com/intent/tweet?url=https://hacker-laws.com/#{{ section.id}}?hashtags=example" title="Share on Twitter" target="_blank"><i class="bi bi-twitter"></i></a>
          <a href="https://www.facebook.com/sharer/sharer.php?u=https://hacker-laws.com/&num;{{ section.id }}" title="Share on Facebook" target="_blank"><i class="bi bi-facebook"></i></a>
        </div>
      </section>
      {% endfor %}
    </main>
    <footer class="container text-center my-4">
      <p>&copy; 2025 Hacker Laws</p>
    </footer>
    <script src="https://code.jquery.com/jquery-3.6.0.min.js"></script>
    <script src="script.js"></script>
  </body>
 </html>
--- a/.github/website/src/script.js
+++ b/.github/website/src/script.js
@@ -0,0 +1,21 @@
 $(document).ready(function() {
    $("h1, h2, h3, h4, h5, h6").each(function() {
        var $heading = $(this);
        var headingId = $heading.attr("id") || $heading.text().trim().toLowerCase().replace(/\s+/g, "-");
        // Ensure a unique ID
        $heading.attr("id", headingId);
        // Create the anchor link
        var $anchor = $('<a>')
            .attr("href", "#" + headingId)
            .addClass("header-link")
            .html("#");
        // Append to the heading
        $heading.append($anchor);
    });
    //  Bootstrap requires that blockquote elements have the 'blockquote' class.
    $('blockquote').addClass('blockquote').addClass('.quote');
 });
--- a/.github/website/src/styles.css
+++ b/.github/website/src/styles.css
@@ -0,0 +1,80 @@
 html {
    scroll-behavior: auto !important;
 }
 body {
  font-family: 'Inter', sans-serif;
  background-color: #fff;
  color: #333;
  padding-top: 70px;
 }
 .container {
  max-width: 800px;
 }
 header {
  text-align: center;
  margin-bottom: 2rem;
  padding: 2rem 0;
  border-bottom: 1px solid #e5e5e5;
 }
 h1, h2, h3, h4, h5, h6 {
  font-family: 'Libre Baskerville', serif;
  /* Avoid scrolling under the sticky header. */
  scroll-margin-top: 80px;
 }
 blockquote {
  font-style: italic;
 }
 .law-section {
  margin-bottom: 2rem;
  padding: 1.5rem;
  background-color: #fff;
  border-bottom: 1px solid #e5e5e5;
  position: relative;
 }
 .law-section h2 {
  position: relative;
  display: flex;
  align-items: center;
 }
 .law-section h2 a.anchor {
  text-decoration: none;
  color: #999;
  margin-left: 0.5rem;
  visibility: hidden;
 }
 .law-section:hover h2 a.anchor {
  visibility: visible;
 }
 .social-sharing a {
  margin-right: 0.75rem;
  font-size: 1.2rem;
  color: #555;
  text-decoration: none;
 }
 .social-sharing a:hover {
  color: #000;
 }
 .back-to-top {
  margin-top: 1rem;
 }
 /* Initially hide the hash link */
 .header-link {
    text-decoration: none;
    margin-left: 12px; /* Increased left padding */
    opacity: 0;
    transition: opacity 0.2s;
    font-size: inherit; /* Matches the heading size */
 }
 /* Only show the hash when the whole section is hovered */
 section:hover .header-link,
 article:hover .header-link,
 div:hover .header-link {
    opacity: 1;
 }
--- a/.github/workflows/cicd.yaml
+++ b/.github/workflows/cicd.yaml
@@ -0,0 +1,108 @@
 name: CI/CD
 on:
  push:
    branches: [main]
  pull_request:
  workflow_dispatch:
 # Permissions to check contents and open PR (release pleases) and update pages.
 permissions:
  contents: write
  pull-requests: write
  pages: write
  id-token: write
 jobs:
  test-website-build:
    runs-on: ubuntu-24.04
    steps:
      - name: Checkout
        uses: actions/checkout@v4
      - name: Test Website Build
        run: |
          cd .github/website
          make install
          make build
          cp -r build/. '../pages'
          ls -al "../pages"
  release:
    needs: test-website-build
    runs-on: ubuntu-24.04
    outputs:
      released: ${{ steps.release-please.outputs.release_created }}
      tag: ${{ steps.release-please.outputs.tag_name }}
    steps:
      - uses: googleapis/release-please-action@v4
        id: release-please
        with:
          manifest-file: .github/release-please-manifest.json
          config-file: .github/release-please-config.json
  release-pdf:
    runs-on: ubuntu-24.04
    needs: release
    if: ${{ needs.release.outputs.released }}
    steps:
      - name: Checkout
        uses: actions/checkout@v4
      # Set a descriptive version. For PRs it'll be the short sha.
      - name: Check Version
        run: echo "${VERSION}"
        env:
          VERSION: ${{ needs.release.outputs.tag }}
      # Set a descriptive version. For PRs it'll be the short sha.
      - name: Prepare Markdown
        run: |
          # Set the env vars we use (version set for clarity).
          export DATE=$(date +%F)
          export VERSION="${VERSION}"
          make -f .github/makefile prepare-markdown
        env:
          VERSION: ${{ needs.release.outputs.tag }}
      # Create the PDF files.
      - name: Create PDF
        run: make -f .github/makefile create-pdf
      # Publish the PDF and intermediate markdown as an artifact.
      # - name: Publish PDF Artifact
      #   uses: actions/upload-artifact@3
      #   with:
      #     name: hacker-laws.pdf
      #     path: hacker-laws.pdf
      - name: Attach assets to GitHub Release
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: |
          gh release upload "${{ needs.release.outputs.tag }}" --clobber hacker-laws.pdf hacker-laws.md
  deploy:
    environment:
      name: github-pages
      url: ${{ steps.deployment.outputs.page_url }}
    runs-on: ubuntu-24.04
    steps:
      - name: Checkout
        uses: actions/checkout@v4
      - name: Setup Pages
        uses: actions/configure-pages@v5
      - name: Build Website
        run: |
          cd .github/website
          make install
          make build
          cp -r build/. '../pages'
          ls -al "../pages"
      - name: Upload artifact
        uses: actions/upload-pages-artifact@v3
        with:
          path: './.github/pages'
      - name: Deploy to GitHub Pages
        id: deployment
        uses: actions/deploy-pages@v4
--- a/2
+++ b/2
@@ -1,4 +1,4 @@
-Copyright (c) Dave Kerr 2020
+Copyright (c) Dave Kerr 2021
 # Attribution-ShareAlike 4.0 International
--- a/README.md
+++ b/README.md
@@ -1,72 +1,93 @@
-# 💻📖 hacker-laws
+<h1 align="center"><a href="https://hacker-laws.com" target="_blank">hacker-laws</a></h1>
 <h4 align="center">🧠 Laws, Theories, Principles and Patterns for developers and technologists.</h4>
-Laws, Theories, Principles and Patterns that developers will find useful.
+---
-[Translations](#translations): [🇮🇩](./translations/pt-BR.md) [🇧🇷](./translations/pt-BR.md) [🇨🇳](https://github.com/nusr/hacker-laws-zh) [🇩🇪](./translations/de.md) [🇫🇷](./translations/fr.md) [🇬🇷](./translations/el.md) [🇮🇹](https://github.com/csparpa/hacker-laws-it) [🇱🇻](./translations/lv.md) [🇰🇷](https://github.com/codeanddonuts/hacker-laws-kr) [🇷🇺](https://github.com/solarrust/hacker-laws) [🇪🇸](./translations/es-ES.md) [🇹🇷](https://github.com/umutphp/hacker-laws-tr) [🇯🇵](./translations/jp.md)
+- 📖 My new book [Effective Shell](https://effective-shell) on [Amazon](https://amzn.to/4ho0F91)
-
+- 🌍 Try [hacker-laws.com](https://hacker-laws.com)
-Like this project? Please considering [sponsoring me](https://github.com/sponsors/dwmkerr) and the [translators](#translations).
+- 🧠 Check out my new project [Terminal AI](https://github.com/dwmkerr/terminal-ai)
 - ☕️ Like this project? Consider [buying me a coffee with a one-off donation](https://github.com/sponsors/dwmkerr?frequency=one-time)
 - 🎧 Listen to the podcast [The Changelog - Laws for Hackers to Live By](https://changelog.com/podcast/403)
 - 📖 Download the [PDF eBook](https://github.com/dwmkerr/hacker-laws/releases/latest/download/hacker-laws.pd)
 - 🌏 See the [Translations](#translations)
 ---
 <!-- vim-markdown-toc GFM -->
-* [Introduction](#introduction)
+- [Introduction](#introduction)
-* [Laws](#laws)
+- [Laws](#laws)
-    * [90–9–1 Principle (1% Rule)](#9091-principle-1-rule)
+    - [90–9–1 Principle (1% Rule)](#9091-principle-1-rule)
-    * [Amdahl's Law](#amdahls-law)
+    - [90–90 Rule](#9090-rule)
-    * [The Broken Windows Theory](#the-broken-windows-theory)
+    - [Amdahl's Law](#amdahls-law)
-    * [Brooks' Law](#brooks-law)
+    - [The Broken Windows Theory](#the-broken-windows-theory)
-    * [CAP Theorem (Brewer's Theorem)](#cap-theorem-brewers-theorem)
+    - [Brooks' Law](#brooks-law)
-    * [Conway's Law](#conways-law)
+    - [CAP Theorem (Brewer's Theorem)](#cap-theorem-brewers-theorem)
-    * [Cunningham's Law](#cunninghams-law)
+    - [Clarke's three laws](#clarkes-three-laws)
-    * [Dunbar's Number](#dunbars-number)
+    - [Conway's Law](#conways-law)
-    * [Fitts' Law](#fitts-law)
+    - [Cunningham's Law](#cunninghams-law)
-    * [Gall's Law](#galls-law)
+    - [Dunbar's Number](#dunbars-number)
-    * [Goodhart's Law](#goodharts-law)
+    - [The Dunning-Kruger Effect](#the-dunning-kruger-effect)
-    * [Hanlon's Razor](#hanlons-razor)
+    - [Fitts' Law](#fitts-law)
-    * [Hick's Law (Hick-Hyman Law)](#hicks-law-hick-hyman-law)
+    - [Gall's Law](#galls-law)
-    * [Hofstadter's Law](#hofstadters-law)
+    - [Goodhart's Law](#goodharts-law)
-    * [Hutber's Law](#hutbers-law)
+    - [Hanlon's Razor](#hanlons-razor)
-    * [The Hype Cycle & Amara's Law](#the-hype-cycle--amaras-law)
+    - [Hick's Law (Hick-Hyman Law)](#hicks-law-hick-hyman-law)
-    * [Hyrum's Law (The Law of Implicit Interfaces)](#hyrums-law-the-law-of-implicit-interfaces)
+    - [Hofstadter's Law](#hofstadters-law)
-    * [Kernighan's Law](#kernighans-law)
+    - [Hutber's Law](#hutbers-law)
-    * [Metcalfe's Law](#metcalfes-law)
+    - [The Hype Cycle & Amara's Law](#the-hype-cycle--amaras-law)
-    * [Moore's Law](#moores-law)
+    - [Hyrum's Law (The Law of Implicit Interfaces)](#hyrums-law-the-law-of-implicit-interfaces)
-    * [Murphy's Law / Sod's Law](#murphys-law--sods-law)
+    - [Input-Process-Output (IPO)](#input-process-output-ipo)
-    * [Occam's Razor](#occams-razor)
+    - [Kernighan's Law](#kernighans-law)
-    * [Parkinson's Law](#parkinsons-law)
+    - [Koomey's Law](#koomeys-law)
-    * [Premature Optimization Effect](#premature-optimization-effect)
+    - [Linus's Law](#linuss-law)
-    * [Putt's Law](#putts-law)
+    - [Metcalfe's Law](#metcalfes-law)
-    * [Reed's Law](#reeds-law)
+    - [Moore's Law](#moores-law)
-    * [The Law of Conservation of Complexity (Tesler's Law)](#the-law-of-conservation-of-complexity-teslers-law)
+    - [Murphy's Law / Sod's Law](#murphys-law--sods-law)
-    * [The Law of Demeter](#the-law-of-demeter)
+    - [Occam's Razor](#occams-razor)
-    * [The Law of Leaky Abstractions](#the-law-of-leaky-abstractions)
+    - [Parkinson's Law](#parkinsons-law)
-    * [The Law of Triviality](#the-law-of-triviality)
+    - [Premature Optimization Effect](#premature-optimization-effect)
-    * [The Unix Philosophy](#the-unix-philosophy)
+    - [Putt's Law](#putts-law)
-    * [The Spotify Model](#the-spotify-model)
+    - [Reed's Law](#reeds-law)
-    * [Wadler's Law](#wadlers-law)
+    - [The Bitter Lesson](#the-bitter-lesson)
-    * [Wheaton's Law](#wheatons-law)
+    - [The Ringelmann Effect](#the-ringelmann-effect)
-* [Principles](#principles)
+    - [The Law of Conservation of Complexity (Tesler's Law)](#the-law-of-conservation-of-complexity-teslers-law)
-    * [The Dead Sea Effect](#the-dead-sea-effect)
+    - [The Law of Demeter](#the-law-of-demeter)
-    * [The Dilbert Principle](#the-dilbert-principle)
+    - [The Law of Leaky Abstractions](#the-law-of-leaky-abstractions)
-    * [The Pareto Principle (The 80/20 Rule)](#the-pareto-principle-the-8020-rule)
+    - [The Law of the Instrument](#the-law-of-the-instrument)
-    * [The Peter Principle](#the-peter-principle)
+    - [The Law of Triviality](#the-law-of-triviality)
-    * [The Robustness Principle (Postel's Law)](#the-robustness-principle-postels-law)
+    - [The Unix Philosophy](#the-unix-philosophy)
-    * [SOLID](#solid)
+    - [The Scout Rule](#the-scout-rule)
-    * [The Single Responsibility Principle](#the-single-responsibility-principle)
+    - [The Spotify Model](#the-spotify-model)
-    * [The Open/Closed Principle](#the-openclosed-principle)
+    - [The Two Pizza Rule](#the-two-pizza-rule)
-    * [The Liskov Substitution Principle](#the-liskov-substitution-principle)
+    - [Twyman's law](#twymans-law)
-    * [The Interface Segregation Principle](#the-interface-segregation-principle)
+    - [Wadler's Law](#wadlers-law)
-    * [The Dependency Inversion Principle](#the-dependency-inversion-principle)
+    - [Wheaton's Law](#wheatons-law)
-    * [The DRY Principle](#the-dry-principle)
+- [Principles](#principles)
-    * [The KISS principle](#the-kiss-principle)
+    - [All Models Are Wrong (George Box's Law)](#all-models-are-wrong-george-boxs-law)
-    * [YAGNI](#yagni)
+    - [Chesterton's Fence](#chestertons-fence)
-    * [The Fallacies of Distributed Computing](#the-fallacies-of-distributed-computing)
+    - [Kerckhoffs's principle](#kerckhoffss-principle)
-* [Reading List](#reading-list)
+    - [The Dead Sea Effect](#the-dead-sea-effect)
-* [Translations](#translations)
+    - [The Dilbert Principle](#the-dilbert-principle)
-* [Related Projects](#related-projects)
+    - [The Pareto Principle (The 80/20 Rule)](#the-pareto-principle-the-8020-rule)
-* [Contributing](#contributing)
+    - [The Shirky Principle](#the-shirky-principle)
-* [TODO](#todo)
+    - [The Peter Principle](#the-peter-principle)
    - [The Robustness Principle (Postel's Law)](#the-robustness-principle-postels-law)
    - [SOLID](#solid)
    - [The Single Responsibility Principle](#the-single-responsibility-principle)
    - [The Open/Closed Principle](#the-openclosed-principle)
    - [The Liskov Substitution Principle](#the-liskov-substitution-principle)
    - [The Interface Segregation Principle](#the-interface-segregation-principle)
    - [The Dependency Inversion Principle](#the-dependency-inversion-principle)
    - [The DRY Principle](#the-dry-principle)
    - [The KISS principle](#the-kiss-principle)
    - [YAGNI](#yagni)
    - [The Fallacies of Distributed Computing](#the-fallacies-of-distributed-computing)
    - [The Principle of Least Astonishment](#the-principle-of-least-astonishment)
 - [Reading List](#reading-list)
 - [Online Resources](#online-resources)
 - [PDF eBook](#pdf-ebook)
 - [Podcast](#podcast)
 <!-- vim-markdown-toc -->
@@ -74,11 +95,11 @@ Like this project? Please considering [sponsoring me](https://github.com/sponsor
 There are lots of laws which people discuss when talking about development. This repository is a reference and overview of some of the most common ones. Please share and submit PRs!
-❗: This repo contains an explanation of some laws, principles and patterns, but does not _advocate_ for any of them. Whether they should be applied will always be a matter of debate, and greatly dependent on what you are working on.
+Warning: This repo contains an explanation of some laws, principles and patterns, but does not _advocate_ for any of them. Whether they should be applied will always be a matter of debate, and greatly dependent on what you are working on.
 ## Laws
-And here we go!
+Laws can be opinions on inevitabilities in the world of software engineering, or wry observations on unavoidable realities.
 ### 90–9–1 Principle (1% Rule)
@@ -94,6 +115,19 @@ See Also:
 - [Pareto principle](#the-pareto-principle-the-8020-rule)
 ### 90–90 Rule
 [90-90 Rule on Wikipedia](https://en.wikipedia.org/wiki/Ninety%E2%80%93ninety_rule)
 > The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.
 A wry reinterpretation of the [Pareto Principe (or 80-20 rule)](#the-pareto-principle-the-8020-rule) that highlights the real-world challenges of completing engineering work. This sentiment is also echoed in [Hofstadter's Law](#hofstadters-law).
 See also:
 - [Hofstadter's Law](#hofstadters-law)
 - [The Pareto Principe](#the-pareto-principle-the-8020-rule)
 ### Amdahl's Law
 [Amdahl's Law on Wikipedia](https://en.wikipedia.org/wiki/Amdahl%27s_law)
@@ -106,7 +140,6 @@ The diagram below shows some examples of potential improvements in speed:
 <img width="480px" alt="Diagram: Amdahl's Law" src="./images/amdahls_law.png" />
 *(Image Reference: By Daniels219 at English Wikipedia, Creative Commons Attribution-Share Alike 3.0 Unported, https://en.wikipedia.org/wiki/File:AmdahlsLaw.svg)*
 As can be seen, even a program which is 50% parallelisable will benefit very little beyond 10 processing units, whereas a program which is 95% parallelisable can still achieve significant speed improvements with over a thousand processing units.
@@ -131,7 +164,7 @@ See also:
 Examples:
- [The Pragmatic Programming: Software Entropy](https://pragprog.com/the-pragmatic-programmer/extracts/software-entropy)
+- [The Pragmatic Programming: Software Entropy](https://flylib.com/books/en/1.315.1.15/1/)
 - [Coding Horror: The Broken Window Theory](https://blog.codinghorror.com/the-broken-window-theory/)
 - [OpenSource: Joy of Programming - The Broken Window Theory](https://opensourceforu.com/2011/05/joy-of-programming-broken-window-theory/)
@@ -141,7 +174,7 @@ Examples:
 > Adding human resources to a late software development project makes it later.
-This law suggests that in many cases, attempting to accelerate the delivery of a project which is already late, by adding more people, will make the delivery even later. Brooks is clear that this is an over-simplification, however, the general reasoning is that given the ramp up time of new resources and the communication overheads, in the immediate short-term velocity decreases. Also, many tasks may not be divisible, i.e. easily distributed between more resources, meaning the potential velocity increase is also lower.
+This law suggests that in many cases, attempting to accelerate the delivery of a project which is already late, by adding more people, will make the delivery even later. Brooks is clear that this is an over-simplification, however, the general reasoning is that given the ramp-up time of new resources and the communication overheads, in the immediate short-term velocity decreases. Also, many tasks may not be divisible, i.e. easily distributed between more resources, meaning the potential velocity increase is also lower.
 The common phrase in delivery "Nine women can't make a baby in one month" relates to Brooks' Law, in particular, the fact that some kinds of work are not divisible or parallelisable.
@@ -160,7 +193,7 @@ The CAP Theorem (defined by Eric Brewer) states that for a distributed data stor
 - Availability: when reading data, every request receives _a non error response_, without the guarantee that it is the _most recent_ data
 - Partition Tolerance: when an arbitrary number of network requests between nodes fail, the system continues to operate as expected
-The core of the reasoning is as follows. It is impossible to guarantee that a network partition will not occur (see [The Fallacies of Distributed Computing](#The_Fallacies_of_Distributed_Computing)). Therefore in the case of a partition we can either cancel the operation (increasing consistency and decreasing availability) or proceed (increasing availability but decreasing consistency).
+The core of the reasoning is as follows. It is impossible to guarantee that a network partition will not occur (see [The Fallacies of Distributed Computing](#the-fallacies-of-distributed-computing)). Therefore in the case of a partition we can either cancel the operation (increasing consistency and decreasing availability) or proceed (increasing availability but decreasing consistency).
 The name comes from the first letters of the guarantees (Consistency, Availability, Partition Tolerance). Note that it is very important to be aware that this does _not_ relate to [_ACID_](#TODO), which has a different definition of consistency. More recently, [PACELC](#TODO) theorem has been developed which adds constraints for latency and consistency when the network is _not_ partitioned (i.e. when the system is operating as expected).
@@ -173,14 +206,26 @@ Real world examples:
 See also:
 - [ACID](#TODO)
- [The Fallacies of Distributed Computing](#The_Fallacies_of_Distributed_Computing)
+- [The Fallacies of Distributed Computing](#the-fallacies-of-distributed-computing)
 - [PACELC](#TODO)
 ### Clarke's three laws
 [Clarke's three laws on Wikipedia](https://en.wikipedia.org/wiki/Clarke's_three_laws)
 Arthur C. Clarke, an british science fiction writer, formulated three adages that are known as Clarke's three laws. The third law is the best known and most widely cited.  
 These so-called laws are:  
 - When a distinguished but elderly scientist states that something is possible, they are almost certainly right. When they state that something is impossible, they are very probably wrong.
 - The only way of discovering the limits of the possible is to venture a little way past them into the impossible.
 - Any sufficiently advanced technology is indistinguishable from magic.
 ### Conway's Law
 [Conway's Law on Wikipedia](https://en.wikipedia.org/wiki/Conway%27s_law)
-This law suggests that the technical boundaries of a system will reflect the structure of the organisation. It is commonly referred to when looking at organisation improvements, Conway's Law suggests that if an organisation is structured into many small, disconnected units, the software it produces will be. If an organisation is built more around 'verticals' which are orientated around features or services, the software systems will also reflect this.
+This law suggests that the technical boundaries of a system will reflect the structure of the organisation. It is commonly referred to when looking at organisation improvements, Conway's Law suggests that if an organisation is structured into many small, disconnected units, the software it produces will be. If an organisation is built more around 'verticals' which are oriented around features or services, the software systems will also reflect this.
 See also:
@@ -204,12 +249,30 @@ See also:
 "Dunbar's number is a suggested cognitive limit to the number of people with whom one can maintain stable social relationships— relationships in which an individual knows who each person is and how each person relates to every other person." There is some disagreement to the exact number. "... [Dunbar] proposed that humans can comfortably maintain only 150 stable relationships." He put the number into a more social context, "the number of people you would not feel embarrassed about joining uninvited for a drink if you happened to bump into them in a bar." Estimates for the number generally lay between 100 and 250.
-Like stable relationships between individuals, a developer's relationship with a codebase takes effort to maintain. When faced with large complicated projects, or ownership of many projects we lean on convention, policy, and modeled procedure to scale. Dunbar's number is not only important to keep in mind as an office grows, but also when setting the scope for team efforts or deciding when a system should invest in tooling to assist in modeling and automating logistical overhead. Putting the number into an engineering context, it is the number of projects (or normalized complexity of a single project) for which you would feel confident in joining an on-call rotation to support.
+Like stable relationships between individuals, a developer's relationship with a codebase takes effort to maintain. When faced with large complicated projects, or ownership of many projects, we lean on convention, policy, and modeled procedure to scale. Dunbar's number is not only important to keep in mind as an office grows, but also when setting the scope for team efforts or deciding when a system should invest in tooling to assist in modeling and automating logistical overhead. Putting the number into an engineering context, it is the number of projects (or normalized complexity of a single project) for which you would feel confident in joining an on-call rotation to support.
 See also:
 - [Conway's Law](#conways-law)
 ### The Dunning-Kruger Effect
 [The Dunning-Kruger Effect on Wikipedia](https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect)
 > If you're incompetent, you can't know you're incompetent... The skills you need to produce a right answer are exactly the skills you need to recognize what a right answer is.
 >
 > ([David Dunning](https://en.wikipedia.org/wiki/David_Dunning))
 The Dunning–Kruger effect is a theoretical cognitive bias which was described by David Dunning and Justin Kruger in a 1999 psychological study and paper. The study suggests that people with a low level of ability at a task are likely to overestimate their ability of the task. The proposed reason for this bias is that a sufficient _awareness_ of the complexity of a problem or domain is required for a person to be able to make an informed opinion of their capability to work in that domain.
 The Dunning-Kruger effect has sometimes been used to describe a related, but not necessarily implied effect which could be described as "The less a person understands a domain, the more they are likely to believe they can easily solve problems in that domain, as they are more likely to see the domain as _simple_". This more general effect is highly relevant in technology. It would suggest that people who are less familiar with a domain, such as non-technical team members or less experienced team members, are more likely to _underestimate_ the effort required to solve a problem in this space.
 As a person's understanding and experience in a domain grows, they may well encounter another effect, which is that they tend to _overestimate_ the ability of _others_ or _underestimate_ their own ability, as they are have become so experienced in the domain. In all cases these effects are _cognitive biases_. As with any bias, an understanding that it may be present will often be sufficient to help avoid the challenges — as when there is awareness of a bias, more inputs and opinions can be included to attempt to eliminate these biases. A closely related bias is that of [Illusory superiority](https://en.wikipedia.org/wiki/Illusory_superiority).
 Real-world examples:
 ### Fitts' Law
 [Fitts' Law on Wikipedia](https://en.wikipedia.org/wiki/Fitts%27s_law)
@@ -218,11 +281,10 @@ Fitts' law predicts that the time required to move to a target area is a functio
 <img width="300px" alt="Diagram: Fitts Law" src="./images/Fitts_Law.svg" />
 *(Image Reference: By Foobar628 at English Wikipedia, Creative Commons Attribution-Share Alike 3.0 Unported, https://en.wikipedia.org/wiki/Fitts%27s_law#/media/File:Fitts_Law.svg)*
 The consequences of this law dictate that when designing UX or UI, interactive elements should be as large as possible and the distance between the users attention area and interactive element should be as small as possible. This has consequences on design, such as grouping tasks that are commonly used with one another close.
-It also formalises the concept of 'magic corners', the corners of the screen which a user can 'sweep' their mouse too to easily hit - which is where key UI elements can be placed. The Windows Start button is in a magic corner, making it easy to select, and as an interesting contrast, the MacOS 'close window' button is _not_ in a magic corner, making it hard to hit by mistake.
+It also formalises the concept of 'magic corners', the corners of the screen to which a user can 'sweep' their mouse to easily hit - which is where key UI elements can be placed. The Windows Start button is in a magic corner, making it easy to select, and as an interesting contrast, the MacOS 'close window' button is _not_ in a magic corner, making it hard to hit by mistake.
 See also:
@@ -290,7 +352,6 @@ In the equation below, `T` is the time to make a decision, `n` is the number of
 ![Hicks law](./images/hicks_law.svg)
 *(Image Reference: Creative Commons Attribution-Share Alike 3.0 Unported, https://en.wikipedia.org/wiki/Hick%27s_law)*
 This law only applies when the number of options is _ordered_, for example, alphabetically. This is implied in the base two logarithm - which implies the decision maker is essentially performing a _binary search_. If the options are not well ordered, experiments show the time taken is linear.
@@ -341,7 +402,6 @@ The Hype Cycle is a visual representation of the excitement and development of t
 ![The Hype Cycle](./images/gartner_hype_cycle.png)
 *(Image Reference: By Jeremykemp at English Wikipedia, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=10547051)*
 In short, this cycle suggests that there is typically a burst of excitement around new technology and its potential impact. Teams often jump into these technologies quickly, and sometimes find themselves disappointed with the results. This might be because the technology is not yet mature enough, or real-world applications are not yet fully realised. After a certain amount of time, the capabilities of the technology increase and practical opportunities to use it increase, and teams can finally become productive. Roy Amara's quote sums this up most succinctly - "We tend to overestimate the effect of a technology in the short run and underestimate in the long run".
@@ -356,13 +416,30 @@ In short, this cycle suggests that there is typically a burst of excitement arou
 >
 > (Hyrum Wright)
 Hyrum's Law states that when you have a _large enough number of consumers_ of an API, all behaviours of the API (even those not defined as part of a public contract) will eventually come to be depended on by someone. A trivial example may be non-functional elements such as the response time of an API. A more subtle example might be consumers who are relying on applying a regex to an error message to determine the *type* of error of an API. Even if the public contract of the API states nothing about the contents of the message, indicating users should use an associated error code, _some_ users may use the message, and changing the message essentially breaks the API for those users.
 See also:
 - [The Law of Leaky Abstractions](#the-law-of-leaky-abstractions)
 - [XKCD 1172](https://xkcd.com/1172/)
 ### Input-Process-Output (IPO)
 [Input–Process–Output on Wikipedia](https://en.wikipedia.org/wiki/IPO_model)
 Systems can be incredibly complex, but can typically be broken down into smaller parts that follow a simple pattern:
 1. Input is provided
 2. Some kind of processing or transformation is performed
 3. Output is returned
 A sort function in a programming language or system could be a classic example of the IPO pattern; where arbitrary input is sorted based on a predicate and returned back. A web server could be modelled as an IPO system, where HTTP requests are transformed into HTTP responses. A highly complex Generative AI system could likewise be modelled in this way, with user input being passed through a complex model and a response being generated.
 The IPO pattern is present in different forms across almost all technological domains, from [functional programming](https://en.wikipedia.org/wiki/Functional_programming) languages that explicitly follow IPO patterns to [The Unix Philosophy](#the-unix-philosophy), which suggests that highly complex systems can be built by chaining together many simple IPO programs.
 See also:
 - [The Unix Philosophy](#the-unix-philosophy)
 ### Kernighan's Law
 > Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.
@@ -381,6 +458,41 @@ See also:
 - [The Unix Philosophy](#the-unix-philosophy)
 - [Occam's Razor](#occams-razor)
 ### Koomey's Law
 [Koomey's Law on Wikipedia](https://en.wikipedia.org/wiki/Koomey%27s_law)
 > ...at a fixed computing load, the amount of battery you need will fall by a factor of two every year and a half.
 >
 > (Jonathan Koomey)
 In 2010 Professor Jonathan Koomey discovered that the trend in number of computations per joule of energy dissipated had been remarkably stable. This trend became known as Koomey's Law - that the amount of battery needed for a given computing load would half each 2.5 years.
 Koomey performed a follow-up analysis in 2010 and found that this trend had slowed, similar to how [Moore's Law](#moores-law) had slowed. This seemed to be related to limitations around how small transistors can be made, as well as [Dennard Scaling](https://en.wikipedia.org/wiki/Dennard_scaling).
 See also:
 - [Moore's Law](#moores-law)
 - [Dennard Scaling](https://en.wikipedia.org/wiki/Dennard_scaling)
 ### Linus's Law
 [Linus's Law on Wikipedia](https://en.wikipedia.org/wiki/Linus%27s_law)
 > Given enough eyeballs, all bugs are shallow.
 >
 > _Eric S. Raymond_
 This law simply states that the more people who can see a problem, the higher the likelihood that someone will have seen and solved the problem before, or something very similar.
 Although it was originally used to describe the value of open-source models for projects it can be accepted for any kind of software project. It can also be extended to processes - more code reviews, more static analysis and multi-disciplined test processes will make the problems more visible and easy to identify.
 A more formal statement can be:
 > Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and can be solved by someone who has encountered a similar problem before.
 This law was named in honour of [Linus Torvalds](https://en.wikipedia.org/wiki/Linus_Torvalds) in Eric S. Raymond's book "[The Cathedral and the Bazaar](https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar)".
 ### Metcalfe's Law
 [Metcalfe's Law on Wikipedia](https://en.wikipedia.org/wiki/Metcalfe's_law)
@@ -401,6 +513,10 @@ See also:
 Often used to illustrate the sheer speed at which semiconductor and chip technology has improved, Moore's prediction has proven to be highly accurate over from the 1970s to the late 2000s. In more recent years, the trend has changed slightly, partly due to [physical limitations on the degree to which components can be miniaturised](https://en.wikipedia.org/wiki/Quantum_tunnelling). However, advancements in parallelisation, and potentially revolutionary changes in semiconductor technology and quantum computing may mean that Moore's Law could continue to hold true for decades to come.
 See also:
 - [Koomey's Law](#koomeys-law)
 ### Murphy's Law / Sod's Law
 [Murphy's Law on Wikipedia](https://en.wikipedia.org/wiki/Murphy%27s_law)
@@ -447,7 +563,6 @@ Example:
 In its original context, this Law was based on studies of bureaucracies. It may be pessimistically applied to software development initiatives, the theory being that teams will be inefficient until deadlines near, then rush to complete work by the deadline, thus making the actual deadline somewhat arbitrary.
 If this law were combined with [Hofstadter's Law](#hofstadters-law), an even more pessimistic viewpoint is reached - work will expand to fill the time available for its completion and *still take longer than expected*.
 See also:
@@ -455,13 +570,12 @@ See also:
 ### Premature Optimization Effect
-[Premature Optimization on WikiWikiWeb](http://wiki.c2.com/?PrematureOptimization)
+[Premature Optimization on WikiWeb](http://wiki.c2.com/?PrematureOptimization)
 > Premature optimization is the root of all evil.
 >
 > [(Donald Knuth)](https://twitter.com/realdonaldknuth?lang=en)
 In Donald Knuth's paper [Structured Programming With Go To Statements](http://wiki.c2.com/?StructuredProgrammingWithGoToStatements), he wrote: "Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: **premature optimization is the root of all evil**. Yet we should not pass up our opportunities in that critical 3%."
 However, _Premature Optimization_ can be defined (in less loaded terms) as optimizing before we know that we need to.
@@ -484,7 +598,6 @@ See also:
 - [The Peter Principle](#the-peter-principle)
 - [The Dilbert Principle](#the-dilbert-principle)
 ### Reed's Law
 [Reed's Law on Wikipedia](https://en.wikipedia.org/wiki/Reed's_law)
@@ -497,6 +610,27 @@ See also:
 - [Metcalfe's Law](#metcalfes-law)
 - [Dunbar's Number](#dunbars-number)
 ### The Bitter Lesson
 [The Bitter Lesson by Richard S. Sutton](http://www.incompleteideas.net/IncIdeas/BitterLesson.html)
 > The biggest lesson that can be read from 70 years of AI research is that general methods that leverage computation are ultimately the most effective, and by a large margin.
 >
 > Richard S. Sutton (2019)
 The "Bitter Lesson", stated by [Rich S. Sutton](https://en.wikipedia.org/wiki/Richard_S._Sutton), says that scale (in terms of both data and computational power) has driven the most significant advancements in AI research, rather than the intricacies of the research methods themselves.
 He goes on to suggest that this indicates we should stop trying to build simplified (or even complex) models of the mind as history has shown that these have always in the long term been failures compared to (as an example) scaling the capacity of neural networks and applying existing methods such as convolution.
 ### The Ringelmann Effect
 [The Ringelmann effect on Wikipedia](https://en.wikipedia.org/wiki/Ringelmann_effect)
 The Ringelmann Effect is the tendency of an individual to become increasingly inefficient as more and more people are involved in a task. In other words, as more individuals are added to a team, the more the average individual performance decreases. Multiple causes are believed to be at work, including loss of motivation ("[social loafing](https://en.wikipedia.org/wiki/Social_loafing)") and challenges related to coordination.
 See also:
 - [Brooks' Law](#brooks-law)
 ### The Law of Conservation of Complexity (Tesler's Law)
 [The Law of Conservation of Complexity on Wikipedia](https://en.wikipedia.org/wiki/Law_of_conservation_of_complexity)
@@ -529,7 +663,6 @@ Following this principal limits the scope of changes, making them easier and saf
 This law states that abstractions, which are generally used in computing to simplify working with complicated systems, will in certain situations 'leak' elements of the underlying system, this making the abstraction behave in an unexpected way.
 An example might be loading a file and reading its contents. The file system APIs are an _abstraction_ of the lower level kernel systems, which are themselves an abstraction over the physical processes relating to changing data on a magnetic platter (or flash memory for an SSD). In most cases, the abstraction of treating a file like a stream of binary data will work. However, for a magnetic drive, reading data sequentially will be *significantly* faster than random access (due to increased overhead of page faults), but for an SSD drive, this overhead will not be present. Underlying details will need to be understood to deal with this case (for example, database index files are structured to reduce the overhead of random access), the abstraction 'leaks' implementation details the developer may need to be aware of.
 The example above can become more complex when _more_ abstractions are introduced. The Linux operating system allows files to be accessed over a network but represented locally as 'normal' files. This abstraction will 'leak' if there are network failures. If a developer treats these files as 'normal' files, without considering the fact that they may be subject to network latency and failures, the solutions will be buggy.
@@ -543,6 +676,25 @@ Real-world examples:
 - [Photoshop Slow Startup](https://forums.adobe.com/thread/376152) - an issue I encountered in the past. Photoshop would be slow to startup, sometimes taking minutes. It seems the issue was that on startup it reads some information about the current default printer. However, if that printer is actually a network printer, this could take an extremely long time. The _abstraction_ of a network printer being presented to the system similar to a local printer caused an issue for users in poor connectivity situations.
 ### The Law of the Instrument
 [The Law of the Instrument](https://en.wikipedia.org/wiki/Law_of_the_instrument)
 > I call it the law of the instrument, and it may be formulated as follows: Give a small boy a hammer, and he will find that everything he encounters needs pounding.
 >
 > _Abraham Kaplan_
 > If all you have is a hammer, everything looks like a nail.
 >
 > _Abraham Maslow_
 In the context of computer programming, this law suggests that people tend to use tools that are familiar with, rather than the best possible tool. This over-reliance on a familiar tool is an anti-pattern referred to as 'the golden hammer'.
 See also:
 - [Avoiding the law of the instrument](https://josemdev.com/avoiding-the-law-of-the-instrument/)
 - [Anti-Pattern - The Golden Hammer](https://archive.org/details/antipatternsrefa0000unse/page/111/mode/2up)
 ### The Law of Triviality
 [The Law of Triviality on Wikipedia](https://en.wikipedia.org/wiki/Law_of_triviality)
@@ -561,6 +713,26 @@ The Unix Philosophy is that software components should be small, and focused on
 Modern practices like 'Microservice Architecture' can be thought of as an application of this law, where services are small, focused and do one specific thing, allowing complex behaviour to be composed of simple building blocks.
 ### The Scout Rule
 [The Scout Rule on O'Reilly](https://www.oreilly.com/library/view/97-things-every/9780596809515/ch08.html)
 > Always leave the code better than you found it.
 >
 > (Robert C. Martin (Uncle Bob))
 Based on the "Scout Rule", which is "always leave the campground cleaner than you found it", the Scout Rule in programming is simply "always leave the code cleaner than you found it".
 This was introduced in the first chapter of the book [Clean Code](https://www.goodreads.com/book/show/3735293-clean-code) by Bob Martin. The rule suggests that developers should perform 'optimistic refactoring', which means to endeavour to improve the overall quality of the code when you work on it. If you see a mistake, attempt to fix it or clean it up. However, when making changes to code which seems incorrect, it may be worth remembering [Chesterton's Fence](#chestertons-fence)!
 See also:
 - [Reading List: Clean Code](#reading-list)
 - [Chesterton's Fence](#chestertons-fence)
 - [The Broken Windows Theory](#broken-windows-theory)
 https://www.amazon.sg/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
 ### The Spotify Model
 [The Spotify Model on Spotify Labs](https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/)
@@ -571,6 +743,30 @@ The Spotify Model also popularises the concepts of Tribes, Guilds, Chapters, whi
 Members of the organisation have described that the actual meaning of these groups changes, evolves and is an on-going experiment. The fact that the model is a _process in motion_, rather than a fixed model continues to lead to varying interpretations of the structure, which may be based on presentations given by employees at conferences. This means 'snapshots' may be 're-packaged' by third parties as a _fixed structure_, with the fact that the model is dynamic being lost.
 ### The Two Pizza Rule
 > If you can't feed a team with two pizzas, it's too large.
 >
 > (Jeff Bezos)
 This rule suggests that regardless of the size of the company, teams should be small enough to be fed by two pizzas. Attributed to Jeff Bezos and Amazon, this belief suggests that large teams are inherently inefficient. This is supported by the fact that as the team size increases linearly, the links between people increases quadratically; thus the cost of coordinating and communicating also grows quadratically. If this cost of coordination is essentially overhead, then smaller teams should be preferred.
 The number of links between people can be expressed as `n(n-1)/2` where n = number of people.
 <img width="200px" alt="Complete graph; Links between people" src="./images/complete_graph.png" />
 ### Twyman's law
 [Twyman's Law on Wikipedia](https://en.wikipedia.org/wiki/Twyman%27s_law)
 > The more unusual or interesting the data, the more likely they are to have been the result of an error of one kind or another.
 This law suggests that when there are particularly unusual data points, it is more likely that they are the result of errors or manipulation. For example, if a dataset of long-jump results from a sporting event showed a maximum value of 20 meters (more than twice the world record), it is more likely to be due to an error (such as recording a value in feet rather than meters) than due to an unusually long jump. It is also more likely in this case that the results could have been manipulated.
 See also:
 - [Sagan Standard](#TODO)
 ### Wadler's Law
 [Wadler's Law on wiki.haskell.org](https://wiki.haskell.org/Wadler's_Law)
@@ -606,6 +802,48 @@ Coined by Wil Wheaton (Star Trek: The Next Generation, The Big Bang Theory), thi
 Principles are generally more likely to be guidelines relating to design.
 ### All Models Are Wrong (George Box's Law)
 [All Models Are Wrong](https://en.wikipedia.org/wiki/All_models_are_wrong)
 > All models are wrong, but some are useful.
 >
 > _George Box_
 This principle suggests that all models of systems are flawed, but that as long as they are not _too_ flawed they may be useful. This principle has its roots in statistics but applies to scientific and computing models as well.
 A fundamental requirement of most software is to model a system of some kind. Regardless of whether the system being modeled is a computer network, a library, a graph of social connections or any other kind of system, the designer will have to decide an appropriate level of detail to model. Excessive detail may lead to too much complexity, too little detail may prevent the model from being functional.
 See also:
 - [The Law of Leaky Abstractions](#the-law-of-leaky-abstractions)
 ### Chesterton's Fence
 [Chesterton's Fence on Wikipedia](https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence)
 > Reforms should not be made until the reasoning behind the existing state of affairs is understood.
 This principle is relevant in software engineering when removing technical debt. Each line of a program was originally written by someone for some reason. Chesterton's Fence suggests that one should try to understand the context and meaning of the code fully, before changing or removing it, even if at first glance it seems redundant or incorrect.
 The name of this principle comes from a story by [G.K. Chesterton](https://en.wikipedia.org/wiki/G._K._Chesterton). A man comes across a fence crossing the middle of the road. He complains to the mayor that this useless fence is getting in the way, and asks to remove it. The mayor asks why the fence is there in the first place. When the man says he doesn't know, the mayor says, "If you don't know its purpose, I certainly won't let you remove it. Go and find out the use of it, and then I may let you destroy it."
 ### Kerckhoffs's principle
 [Kerckhoffs's principle on Wikipedia](https://en.wikipedia.org/wiki/Kerckhoffs%27s_principle)
 > "...design your system assuming that your opponents know it in detail."
 >
 > _Steven M. Bellovin's formulation of Kerckhoff's Principle_
 This principle of cryptography was an axiom created by cryptographer Auguste Kerckhoffs. He stated that a cryptosystem should be secure, even if everything about the system, except the key, is public knowledge. Not to be confused with [_"security through obscurity"_](#todo).
 The gold standard for any secret-keeping system is that implementation details should be publicly distributed, without sacrificing or compromising security of said system.
 The history of cryptography has shown that open discussion and analysis of cryptographic systems leads to better and more secure systems - as researchers are able to test for and expose potential vulnerabilities.
 - [Shannon's Maxim](#todo)
 ### The Dead Sea Effect
 [The Dead Sea Effect on Bruce F. Webster](http://brucefwebster.com/2008/04/11/the-wetware-crisis-the-dead-sea-effect/)
@@ -618,7 +856,6 @@ The "Dead Sea Effect" suggests that in any organisation, the skills/talent/effic
 Typically, highly skilled engineers find it easy to gain employment elsewhere and are the first to do so. Engineers who have obsolete or weak skills will tend to remain with the company, as finding employment elsewhere is difficult. This is particularly pronounced if they have gained incremental pay rises over their time in the company, as it can be challenging to get equivalent remuneration elsewhere.
 ### The Dilbert Principle
 [The Dilbert Principle on Wikipedia](https://en.wikipedia.org/wiki/Dilbert_principle)
@@ -656,6 +893,25 @@ Real-world examples:
 - In 2002 Microsoft reported that by fixing the top 20% of the most-reported bugs, 80% of the related errors and crashes in windows and office would become eliminated ([Reference](https://www.crn.com/news/security/18821726/microsofts-ceo-80-20-rule-applies-to-bugs-not-just-features.htm)).
 ### The Shirky Principle
 [The Shirky Principle explained](https://kk.org/thetechnium/the-shirky-prin/)
 > Institutions will try to preserve the problem to which they are the solution.
 >
 > _Clay Shirky_
 The Shirky Principle suggests that complex solutions - a company, an industry, or a technology - can become so focused on the problem that they are solving, that they can inadvertently perpetuate the problem itself. This may be deliberate (a company striving to find new nuances to a problem which justify continued development of a solution), or inadvertent (being unable or unwilling to accept or build a solution which solves the problem completely or obviates it).
 Related to:
 - Upton Sinclair's famous line, _"It is difficult to get a man to understand something, when his salary depends upon his not understanding it!"_
 - Clay Christensen's _The Innovator's Dilemma_
 See also:
 - [Pareto Principle](#the-pareto-principle-the-8020-rule)
 ### The Peter Principle
 [The Peter Principle on Wikipedia](https://en.wikipedia.org/wiki/Peter_principle)
@@ -666,7 +922,7 @@ Real-world examples:
 A management concept developed by Laurence J. Peter, the Peter Principle observes that people who are good at their jobs are promoted, until they reach a level where they are no longer successful (their "level of incompetence"). At this point, as they are more senior, they are less likely to be removed from the organisation (unless they perform spectacularly badly) and will continue to reside in a role which they have few intrinsic skills at, as their original skills which made them successful are not necessarily the skills required for their new jobs.
-This is of particular interest to engineers - who initially start out in deeply technical roles, but often have a career path which leads to _managing_ other engineers - which requires a fundamentally different skills-set.
+This is of particular interest to engineers - who initially start out in deeply technical roles, but often have a career path which leads to _managing_ other engineers - which requires a fundamentally different skill set.
 See Also:
@@ -689,16 +945,10 @@ See Also:
 - [Hyrum's Law](#hyrums-law-the-law-of-implicit-interfaces)
 ### SOLID
 This is an acronym, which refers to:
 * S: [The Single Responsibility Principle](#the-single-responsibility-principle)
 * O: [The Open/Closed Principle](#the-openclosed-principle)
 * L: [The Liskov Substitution Principle](#the-liskov-substitution-principle)
 * I: [The Interface Segregation Principle](#the-interface-segregation-principle)
 * D: [The Dependency Inversion Principle](#the-dependency-inversion-principle)
 These are key principles in [Object-Oriented Programming](#todo). Design principles such as these should be able to aid developers build more maintainable systems.
@@ -710,7 +960,7 @@ These are key principles in [Object-Oriented Programming](#todo). Design princip
 The first of the '[SOLID](#solid)' principles. This principle suggests that modules or classes should do one thing and one thing only. In more practical terms, this means that a single, small change to a feature of a program should require a change in one component only. For example, changing how a password is validated for complexity should require a change in only one part of the program.
-Theoretically, this should make the code more robust, and easier to change. Knowing that a component which is being changed has a single responsibility only means that _testing_ that change should be easier. Using the earlier example, changing the password complexity component should only be able to affect the features which relate to password complexity. It can be much more difficult to reason about the impact of a change to a component which has many responsibilities.
+Theoretically, this should make the code more robust, and easier to change. Knowing that a component being changed has a single responsibility only means that _testing_ that change should be easier. Using the earlier example, changing the password complexity component should only be able to affect the features which relate to password complexity. It can be much more difficult to reason about the impact of a change to a component which has many responsibilities.
 See also:
@@ -742,7 +992,7 @@ See also:
 The third of the '[SOLID](#solid)' principles. This principle states that if a component relies on a type, then it should be able to use subtypes of that type, without the system failing or having to know the details of what that subtype is.
-As an example, imagine we have a method which reads an XML document from a structure which represents a file. If the method uses a base type 'file', then anything which derives from 'file' should be able to be used in the function. If 'file' supports seeking in reverse, and the XML parser uses that function, but the derived type 'network file' fails when reverse seeking is attempted, then the 'network file' would be violating the principle.
+As an example, imagine we have a method which reads an XML document from a structure which represents a file. If the method uses a base type 'file', then anything which derives from 'file' should be usable in the function. If 'file' supports seeking in reverse, and the XML parser uses that function, but the derived type 'network file' fails when reverse seeking is attempted, then the 'network file' would be violating the principle.
 This principle has particular relevance for object-oriented programming, where type hierarchies must be modeled carefully to avoid confusing users of a system.
@@ -776,7 +1026,7 @@ See also:
 > High-level modules should not be dependent on low-level implementations.
-The fifth of the '[SOLID](#solid)' principles. This principle states that higher level orchestrating components should not have to know the details of their dependencies.
+The fifth of the '[SOLID](#solid)' principles. This principle states that higher-level orchestrating components should not have to know the details of their dependencies.
 As an example, imagine we have a program which read metadata from a website. We would assume that the main component would have to know about a component to download the webpage content, then a component which can read the metadata. If we were to take dependency inversion into account, the main component would depend only on an abstract component which can fetch byte data, and then an abstract component which would be able to read metadata from a byte stream. The main component would not know about TCP/IP, HTTP, HTML, etc.
@@ -795,7 +1045,7 @@ See also:
 > Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.
-DRY is an acronym for _Don't Repeat Yourself_. This principle aims to help developers reducing the repetition of code and keep the information in a single place and was cited in 1999 by Andrew Hunt and Dave Thomas in the book [The Pragmatic Developer](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer)
+DRY is an acronym for _Don't Repeat Yourself_. This principle aims to help developers reducing the repetition of code and keep the information in a single place and was cited in 1999 by Andrew Hunt and Dave Thomas in the book [The Pragmatic Programmer](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer)
 > The opposite of DRY would be _WET_ (Write Everything Twice or We Enjoy Typing).
@@ -803,7 +1053,7 @@ In practice, if you have the same piece of information in two (or more) differen
 See also:
- [The Pragmatic Developer](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer)
+- [The Pragmatic Programmer](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer)
 ### The KISS principle
@@ -813,7 +1063,7 @@ See also:
 The KISS principle states that most systems work best if they are kept simple rather than made complicated; therefore, simplicity should be a key goal in design, and unnecessary complexity should be avoided.  Originating in the U.S. Navy in 1960, the phrase has been associated with aircraft engineer Kelly Johnson.
-The principle is best exemplified by the story of Johnson handing a team of design engineers a handful of tools, with the challenge that the jet aircraft they were designing must be repairable by an average mechanic in the field under combat conditions with only these tools. Hence, the "stupid" refers to the relationship between the way things break and the sophistication of the tools available to repair them, not the capabilities of the engineers themselves. 
+The principle is best exemplified by the story of Johnson handing a team of design engineers a handful of tools, with the challenge that the jet aircraft they were designing must be repairable by an average mechanic in the field under combat conditions with only these tools. Hence, the "stupid" refers to the relationship between the way things break and the sophistication of the tools available to repair them, not the capabilities of the engineers themselves.
 See also:
@@ -823,7 +1073,6 @@ See also:
 [YAGNI on Wikipedia](https://en.wikipedia.org/wiki/You_ain%27t_gonna_need_it)
 This is an acronym for _**Y**ou **A**in't **G**onna **N**eed **I**t_.
 > Always implement things when you actually need them, never when you just foresee that you need them.
 >
@@ -854,7 +1103,7 @@ Also known as _Fallacies of Networked Computing_, the Fallacies are a list of co
 The first four items were listed by [Bill Joy](https://en.wikipedia.org/wiki/Bill_Joy) and [Tom Lyon](https://twitter.com/aka_pugs) around 1991 and first classified by [James Gosling](https://en.wikipedia.org/wiki/James_Gosling) as the "Fallacies of Networked Computing". [L. Peter Deutsch](https://en.wikipedia.org/wiki/L._Peter_Deutsch) added the 5th, 6th and 7th fallacies. In the late 90's Gosling added the 8th fallacy.
-The group were inspired by what was happening at the time inside [Sun Microsystems](https://en.wikipedia.org/wiki/Sun_Microsystems).
+The group was inspired by what was happening at the time inside [Sun Microsystems](https://en.wikipedia.org/wiki/Sun_Microsystems).
 These fallacies should be considered carefully when designing code which is resilient; assuming any of these fallacies can lead to flawed logic which fails to deal with the realities and complexities of distributed systems.
@@ -862,53 +1111,51 @@ See also:
 - [Foraging for the Fallacies of Distributed Computing (Part 1) - Vaidehi Joshi
 on Medium](https://medium.com/baseds/foraging-for-the-fallacies-of-distributed-computing-part-1-1b35c3b85b53)
- [Deutsch's Fallacies, 10 Years After](http://java.sys-con.com/node/38665)
+
 ### The Principle of Least Astonishment
 [The Principle of Least Astonishment on Wikipedia](https://en.wikipedia.org/wiki/Principle_of_least_astonishment)
 > People are part of the system. The design should match the user's experience, expectations, and mental models.
 >
 > Frans Kaashoek
 This principle proposes that systems and interfaces should be designed in a way that features and functionality is easily discovered and matches users expectations. Features that 'surprise' users should be discouraged in favour of features that can be intuitively reasoned about based on existing patterns and practices.
 Many examples are present in user interfaces, such as a 'pull down' gesture on a mobile appliation to refresh content. Another example would be command line tools, where many standards exist for how parameters are named, common parameters that should be available and so on.
 See also:
 - [Convention Over Configuration](#todo)
 ## Reading List
 If you have found these concepts interesting, you may enjoy the following books.
 - [Clean Code - Robert C. Martin](https://www.goodreads.com/book/show/3735293-clean-code) - One of the most well respected books on how to write clean, maintainable code.
 - [Extreme Programming Installed - Ron Jeffries, Ann Anderson, Chet Hendrikson](https://www.goodreads.com/en/book/show/67834) - Covers the core principles of Extreme Programming.
 - [The Mythical Man Month - Frederick P. Brooks Jr.](https://www.goodreads.com/book/show/13629.The_Mythical_Man_Month) - A classic volume on software engineering. [Brooks' Law](#brooks-law) is a central theme of the book.
 - [Gödel, Escher, Bach: An Eternal Golden Braid - Douglas R. Hofstadter.](https://www.goodreads.com/book/show/24113.G_del_Escher_Bach) - This book is difficult to classify. [Hofstadter's Law](#hofstadters-law) is from the book.
 - [Structure and Interpretation of Computer Programs - Harold Abelson, Gerald Jay Sussman, Julie Sussman](https://www.goodreads.com/book/show/43713) - If you were a comp sci or electical engineering student at MIT or Cambridge this was your intro to programming. Widely reported as being a turning point in people's lives.
 - [The Cathedral and the Bazaar - Eric S. Raymond](https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar) - a collection of essays on open source. This book was the source of [Linus's Law](#linuss-law).
 - [The Dilbert Principle - Scott Adams](https://www.goodreads.com/book/show/85574.The_Dilbert_Principle) - A comic look at corporate America, from the author who created the [Dilbert Principle](#the-dilbert-principle).
 - [The Mythical Man Month - Frederick P. Brooks Jr.](https://www.goodreads.com/book/show/13629.The_Mythical_Man_Month) - A classic volume on software engineering. [Brooks' Law](#brooks-law) is a central theme of the book.
 - [The Peter Principle - Lawrence J. Peter](https://www.goodreads.com/book/show/890728.The_Peter_Principle) - Another comic look at the challenges of larger organisations and people management, the source of [The Peter Principle](#the-peter-principle).
-## Translations
+## Online Resources
-Thanks to a number of wonderful contributors, Hacker Laws is available in a number of languages. Please consider sponsoring moderators!
+Some useful resources and reading.
-| Language | Moderator | Status |
+- [CB Insights: 8 Laws Driving Success In Tech: Amazon's 2-Pizza Rule, The 80/20 Principle, & More](https://www.cbinsights.com/research/report/tech-laws-success-failure) - an interesting write up of some laws which have been highly influential in technology.
 |----------|-----------|--------|
 | [🇮🇩 Bahasa Indonesia / Indonesian](./translations/pt-BR.md) | [arywidiantara](https://github.com/arywidiantara) | [![gitlocalized ](https://gitlocalize.com/repo/2513/id/badge.svg)](https://gitlocalize.com/repo/2513/id?utm_source=badge) |
 | [🇧🇷 Brasileiro / Brazilian](./translations/pt-BR.md) | [Eugênio Moreira](https://github.com/eugenioamn), [Leonardo Costa](https://github.com/leofc97) | [![gitlocalized ](https://gitlocalize.com/repo/2513/pt-BR/badge.svg)](https://gitlocalize.com/repo/2513/pt-BR?utm_source=badge) |
 | [🇨🇳 中文 / Chinese](https://github.com/nusr/hacker-laws-zh) | [Steve Xu](https://github.com/nusr) | Partially complete |
 | [🇩🇪 Deutsch / German](./translations/de.md) | [Vikto](https://github.com/viktodergunov) | [![gitlocalized ](https://gitlocalize.com/repo/2513/de/badge.svg)](https://gitlocalize.com/repo/2513/de?utm_source=badge) |
 | [🇫🇷 Français / French](./translations/fr.md) | [Kevin Bockelandt](https://github.com/KevinBockelandt) | [![gitlocalized ](https://gitlocalize.com/repo/2513/fr/badge.svg)](https://gitlocalize.com/repo/2513/fr?utm_source=badge) |
 | [🇬🇷 ελληνικά / Greek](./translations/el.md) | [Panagiotis Gourgaris](https://github.com/0gap) | [![gitlocalized ](https://gitlocalize.com/repo/2513/el/badge.svg)](https://gitlocalize.com/repo/2513/el?utm_source=badge) |
 | [🇮🇹 Italiano / Italian](https://github.com/csparpa/hacker-laws-it) | [Claudio Sparpaglione](https://github.com/csparpa) | Partially complete |
 | [🇯🇵 JP 日本語 / Japanese](./translations/jp.md) | [Fumikazu Fujiwara](https://github.com/freddiefujiwara)| [![gitlocalized ](https://gitlocalize.com/repo/2513/ja/badge.svg)](https://gitlocalize.com/repo/2513/ja?utm_source=badge) |
 | [🇰🇷 한국어 / Korean](https://github.com/codeanddonuts/hacker-laws-kr) | [Doughnut](https://github.com/codeanddonuts) | Partially complete |
 | [🇱🇻 Latviešu Valoda / Latvian](./translations/lv.md) | [Arturs Jansons](https://github.com/iegik) | [![gitlocalized ](https://gitlocalize.com/repo/2513/lv/badge.svg)](https://gitlocalize.com/repo/2513/lv?utm_source=badge) |
 | [🇷🇺 Русская версия / Russian](https://github.com/solarrust/hacker-laws) | [Alena Batitskaya](https://github.com/solarrust) | Partially complete |
 | [🇪🇸 Castellano / Spanish](./translations/es-ES.md) | [Manuel Rubio](https://github.com/manuel-rubio) ([Sponsor](https://github.com/sponsors/manuel-rubio)) | Partially complete |
 | [🇹🇷 Türkçe / Turkish](https://github.com/umutphp/hacker-laws-tr) | [Umut Işık](https://github.com/umutphp) | [![gitlocalized ](https://gitlocalize.com/repo/2513/tr/badge.svg)](https://gitlocalize.com/repo/2513/tr?utm_source=badge) |
-If you would like to update a translation, just [open a pull request](https://github.com/dwmkerr/hacker-laws/pulls). If you want to add a new language, log onto [GitLocalize](https://gitlocalize.com/) to create an account, then open an issue asking to administer the language and I will add you to the project! It would also be super helpful if you can open a pull request which updates the table above and link at the top of the file.
+## PDF eBook
-## Related Projects
+The project is available as a PDF eBook, [download the latest PDF eBook with this link](https://github.com/dwmkerr/hacker-laws/releases/latest/download/hacker-laws.pdf) or check the [release](https://github.com/dwmkerr/hacker-laws/releases) page for older versions.
- [Tip of the Day](https://tips.darekkay.com/html/hacker-laws-en.html) - Receive a daily hacker law/principle.
+A new version of the eBook is created automatically when a new version tag is pushed.
 - [Hacker Laws CLI](https://github.com/umutphp/hacker-laws-cli) - List, view and see random laws from the terminal!
-## Contributing
+## Podcast
-Please do contribute! [Raise an issue](https://github.com/dwmkerr/hacker-laws/issues/new) if you'd like to suggest an addition or change, or [Open a pull request](https://github.com/dwmkerr/hacker-laws/compare) to propose your own changes.
+Hacker Laws has been featured in [The Changelog](https://changelog.com/podcast/403), you can check out the Podcast episode with the link below:
-Please be sure to read the [Contributing Guidelines](./.github/contributing.md) for requirements on text, style and so on. Please be aware of the [Code of Conduct](./.github/CODE_OF_CONDUCT.md) when engaging in discussions on the project.
+<a href="https://changelog.com/podcast/403" target="_blank"><img src="./images/changelog-podcast.png" width="800px" alt="Changelog Podcast Image" /></a>
 ## TODO
 Hi! If you land here, you've clicked on a link to a topic I've not written up yet, sorry about this - this is work in progress!
 Feel free to [Raise an Issue](https://github.com/dwmkerr/hacker-laws/issues) requesting more details, or [Open a Pull Request](https://github.com/dwmkerr/hacker-laws/pulls) to submit your proposed definition of the topic.
--- a/assets/ebook.sh
+++ b/assets/ebook.sh
@@ -1,40 +0,0 @@
 #!/usr/bin/env bash
 #
 # Requirements:
 # - pandoc
 # - xelatex
 # brew install 
 # brew cask install basictex
 # Create the frontmatter.
 cat << EOF > frontmatter.md
 ---
 title: "Hacker Laws"
 author: "Dave Kerr, github.com/dwmkerr/hacker-laws"
 subtitle: "Laws, Theories, Principles and Patterns that developers will find useful."
 ---
 EOF
 # Combine the frontmatter and the laws.
 cat frontmatter.md README.md >> hacker-laws.md
 # Remove the title - we have it in the front-matter of the doc, so it will
 # automatically be added to the PDF.
 sed -i '' '/💻📖.*/d' hacker-laws.md
 # We can't have emojis in the final content with the PDF generator we're using.
 sed -i '' 's/❗/Warning/' hacker-laws.md
 # Now rip out the translations line.
 sed -i '' '/^\[Translations.*/d' hacker-laws.md
 # # Now rip out any table of contents items.
 sed -i '' '/\*.*/d' hacker-laws.md
 sed -i '' '/    \*.*/d' hacker-laws.md
 # Delete everything from 'Translations' onwards (we don't need the translations
 # lists, related projects, etc).
 sed -i ' ' '/## Translations/,$d' hacker-laws.md
 # Now build the e-book as a PDF.
 pandoc  -V toc-title:"Table Of Contents" --toc --pdf-engine=pdflatex -s -o hacker-laws.pdf hacker-laws.md
--- a/assets/sharing.md
+++ b/assets/sharing.md
@@ -1,20 +0,0 @@
 # Sharing
 Copy paste the below for sharing on social media. The channels are:
 - [Hacker News](https://news.ycombinator.com)
 - [`r/programming`](https://reddit.com/r/programming/)
 - LinkedIn
 - Twitter
 ## LinkedIn
 #hackerlaws - <Law Name> - <Short Quote>
 <Link>
 Hacker Laws is a set of theories, principles and patterns that developers will find useful.
 Thanks <person>
 #hacking #programming #coding #development #computerscience #logic
--- a/assets/site/index.html
+++ b/assets/site/index.html
@@ -0,0 +1,119 @@
 <!DOCTYPE html>
 <html lang="en">
 <head>
  <meta charset="UTF-8">
  <title>Interactive Hacker Laws Stack</title>
  <style>
    body {
      display: flex;
      justify-content: center;
      align-items: center;
      height: 100vh;
      background-color: #f5f5f5;
      margin: 0;
      font-family: Arial, sans-serif;
    }
    #stack {
      width: 400px;
      height: 500px;
      overflow-y: auto;
      position: relative;
      border: 1px solid #ddd;
      border-radius: 8px;
      background-color: #fff;
      box-shadow: 0 2px 10px rgba(0,0,0,0.1);
      padding: 10px;
    }
    .law-item {
      text-align: left;
      padding: 4px;
      transition: transform 0.2s ease, opacity 0.2s;
      transform-origin: left;
      font-size: 16px;
      color: #333;
      margin: 6px 0;
      position: relative;
      display: flex;
      align-items: center;
    }
    .law-item::before {
      content: '';
      display: block;
      width: 6px;
      height: 6px;
      border-radius: 50%;
      background-color: #aaa;
      margin-right: 8px;
      transition: height 0.2s, background-color 0.2s;
    }
  </style>
 </head>
 <body>
 <div id="stack" class="stack"></div>
 <script>
 const laws = [
  "90–9–1 Principle (1% Rule)", "90–90 Rule", "Amdahl's Law", "The Broken Windows Theory",
  "Brooks' Law", "CAP Theorem (Brewer's Theorem)", "Clarke's Three Laws", "Conway's Law",
  "Cunningham's Law", "Dunbar's Number", "The Dunning-Kruger Effect", "Fitts' Law",
  "Gall's Law", "Goodhart's Law", "Hanlon's Razor", "Hofstadter's Law", "Hutber's Law",
  "The Hype Cycle & Amara's Law", "Hyrum's Law (The Law of Implicit Interfaces)",
  "Metcalfe's Law", "Moore's Law", "Murphy's Law / Sod's Law", "Occam's Razor",
  "Parkinson's Law", "Premature Optimization Effect", "Putt's Law", "Reed's Law",
  "The Law of Conservation of Complexity (Tesler's Law)", "The Law of Leaky Abstractions",
  "The Law of Triviality", "The Unix Philosophy", "The Spotify Model", "Wadler's Law",
  "Wheaton's Law", "The Dilbert Principle", "The Pareto Principle (The 80/20 Rule)",
  "The Peter Principle", "The Robustness Principle (Postel's Law)", "SOLID",
  "The Single Responsibility Principle", "The Open/Closed Principle", "The Liskov Substitution Principle",
  "The Interface Segregation Principle", "The Dependency Inversion Principle", "The DRY Principle",
  "The KISS Principle", "YAGNI"
 ];
 const stack = document.getElementById('stack');
 const maxZoom = 1.5;
 const minZoom = 0.6;
 laws.forEach(title => {
  const div = document.createElement('div');
  div.className = 'law-item';
  div.innerText = title;
  stack.appendChild(div);
 });
 function updateScale(e) {
  const items = document.querySelectorAll('.law-item');
  items.forEach(item => {
    const itemRect = item.getBoundingClientRect();
    const itemCenter = (itemRect.top + itemRect.bottom) / 2;
    const distance = Math.abs(e.clientY - itemCenter);
    const scale = Math.max(maxZoom - distance / 150, minZoom);
    const opacity = Math.max(1 - distance / 300, 0.3);
    item.style.transform = `scale(${scale})`;
    item.style.opacity = opacity;
    const dot = item.querySelector('::before');
    const barHeight = Math.max(6, 30 - distance / 10);
    item.style.setProperty('--dot-height', barHeight + 'px');
    item.style.setProperty('--dot-color', distance < 50 ? '#333' : '#aaa');
    item.querySelector('::before');
    item.style.setProperty('--dot-height', barHeight + 'px');
  });
 }
 document.addEventListener('mousemove', updateScale);
 // Initial positioning
 updateScale({ clientY: window.innerHeight / 2 });
 </script>
 <style>
 .law-item::before {
  height: var(--dot-height, 6px);
  background-color: var(--dot-color, #aaa);
 }
 </style>
 </body>
 </html>
--- a/assets/site/index2.html
+++ b/assets/site/index2.html
@@ -0,0 +1,110 @@
 <!DOCTYPE html>
 <html lang="en">
 <head>
  <meta charset="UTF-8">
  <title>Interactive Hacker Laws Stack</title>
  <style>
    body {
      display: flex;
      justify-content: center;
      align-items: center;
      height: 100vh;
      background-color: #f5f5f5;
      margin: 0;
      font-family: Arial, sans-serif;
    }
    #stack {
      width: 400px;
      height: 500px;
      overflow-y: auto;
      position: relative;
      border: 1px solid #ddd;
      border-radius: 8px;
      background-color: #fff;
      box-shadow: 0 2px 10px rgba(0,0,0,0.1);
      padding: 10px;
    }
    .law-item {
      text-align: left;
      padding: 2px 4px;
      transition: transform 0.2s ease, opacity 0.2s;
      transform-origin: left;
      font-size: 15px;
      color: #333;
      margin: 4px 0;
      position: relative;
      display: flex;
      align-items: center;
    }
    .law-item::before {
      content: '';
      display: block;
      width: var(--bar-width, 6px);
      height: 6px;
      border-radius: 3px;
      background-color: var(--bar-color, #aaa);
      margin-right: 10px;
      transition: width 0.2s, background-color 0.2s;
    }
  </style>
 </head>
 <body>
 <div id="stack" class="stack"></div>
 <script>
 const laws = [
  "90–9–1 Principle (1% Rule)", "90–90 Rule", "Amdahl's Law", "The Broken Windows Theory",
  "Brooks' Law", "CAP Theorem (Brewer's Theorem)", "Clarke's Three Laws", "Conway's Law",
  "Cunningham's Law", "Dunbar's Number", "The Dunning-Kruger Effect", "Fitts' Law",
  "Gall's Law", "Goodhart's Law", "Hanlon's Razor", "Hofstadter's Law", "Hutber's Law",
  "The Hype Cycle & Amara's Law", "Hyrum's Law (The Law of Implicit Interfaces)",
  "Metcalfe's Law", "Moore's Law", "Murphy's Law / Sod's Law", "Occam's Razor",
  "Parkinson's Law", "Premature Optimization Effect", "Putt's Law", "Reed's Law",
  "The Law of Conservation of Complexity (Tesler's Law)", "The Law of Leaky Abstractions",
  "The Law of Triviality", "The Unix Philosophy", "The Spotify Model", "Wadler's Law",
  "Wheaton's Law", "The Dilbert Principle", "The Pareto Principle (The 80/20 Rule)",
  "The Peter Principle", "The Robustness Principle (Postel's Law)", "SOLID",
  "The Single Responsibility Principle", "The Open/Closed Principle", "The Liskov Substitution Principle",
  "The Interface Segregation Principle", "The Dependency Inversion Principle", "The DRY Principle",
  "The KISS Principle", "YAGNI"
 ];
 const stack = document.getElementById('stack');
 const maxZoom = 1.8;
 const minZoom = 0.5;
 laws.forEach(title => {
  const div = document.createElement('div');
  div.className = 'law-item';
  div.innerText = title;
  stack.appendChild(div);
 });
 function updateScale(e) {
  const items = document.querySelectorAll('.law-item');
  items.forEach(item => {
    const itemRect = item.getBoundingClientRect();
    const itemCenter = (itemRect.top + itemRect.bottom) / 2;
    const distance = Math.abs(e.clientY - itemCenter);
    const scale = Math.max(maxZoom - distance / 120, minZoom);
    const opacity = Math.max(1 - distance / 250, 0.2);
    const barWidth = Math.max(6, 60 - distance / 5);
    item.style.transform = `scale(${scale})`;
    item.style.opacity = opacity;
    item.style.setProperty('--bar-width', barWidth + 'px');
    item.style.setProperty('--bar-color', distance < 50 ? '#333' : '#aaa');
  });
 }
 document.addEventListener('mousemove', updateScale);
 // Initial positioning
 updateScale({ clientY: window.innerHeight / 2 });
 </script>
 </body>
 </html>
--- a/assets/site/index3.html
+++ b/assets/site/index3.html
@@ -0,0 +1,127 @@
 <!DOCTYPE html>
 <html lang="en">
 <head>
  <meta charset="UTF-8">
  <title>Interactive Hacker Laws Stack</title>
  <style>
    body {
      display: flex;
      justify-content: center;
      align-items: center;
      height: 100vh;
      background-color: #f5f5f5;
      margin: 0;
      font-family: Arial, sans-serif;
      overflow: hidden;
    }
    #stack-container {
      width: 400px;
      height: 500px;
      border: 1px solid #ddd;
      border-radius: 8px;
      background-color: #fff;
      box-shadow: 0 2px 10px rgba(0,0,0,0.1);
      padding: 10px;
      overflow: hidden;
      position: relative;
    }
    #stack {
      position: absolute;
      width: 100%;
    }
    .law-item {
      text-align: left;
      padding: 2px 4px;
      transition: transform 0.2s ease, opacity 0.2s;
      transform-origin: left;
      font-size: 15px;
      color: #333;
      margin: 4px 0;
      position: relative;
      display: flex;
      align-items: center;
    }
    .law-item::before {
      content: '';
      display: block;
      width: var(--bar-width, 6px);
      height: 6px;
      border-radius: 3px;
      background-color: var(--bar-color, #aaa);
      margin-right: 10px;
      transition: width 0.2s, background-color 0.2s;
    }
  </style>
 </head>
 <body>
 <div id="stack-container">
  <div id="stack"></div>
 </div>
 <script>
 const laws = [
  "90–9–1 Principle (1% Rule)", "90–90 Rule", "Amdahl's Law", "The Broken Windows Theory",
  "Brooks' Law", "CAP Theorem (Brewer's Theorem)", "Clarke's Three Laws", "Conway's Law",
  "Cunningham's Law", "Dunbar's Number", "The Dunning-Kruger Effect", "Fitts' Law",
  "Gall's Law", "Goodhart's Law", "Hanlon's Razor", "Hofstadter's Law", "Hutber's Law",
  "The Hype Cycle & Amara's Law", "Hyrum's Law (The Law of Implicit Interfaces)",
  "Metcalfe's Law", "Moore's Law", "Murphy's Law / Sod's Law", "Occam's Razor",
  "Parkinson's Law", "Premature Optimization Effect", "Putt's Law", "Reed's Law",
  "The Law of Conservation of Complexity (Tesler's Law)", "The Law of Leaky Abstractions",
  "The Law of Triviality", "The Unix Philosophy", "The Spotify Model", "Wadler's Law",
  "Wheaton's Law", "The Dilbert Principle", "The Pareto Principle (The 80/20 Rule)",
  "The Peter Principle", "The Robustness Principle (Postel's Law)", "SOLID",
  "The Single Responsibility Principle", "The Open/Closed Principle", "The Liskov Substitution Principle",
  "The Interface Segregation Principle", "The Dependency Inversion Principle", "The DRY Principle",
  "The KISS Principle", "YAGNI"
 ];
 const stack = document.getElementById('stack');
 const stackContainer = document.getElementById('stack-container');
 const maxZoom = 1.8;
 const minZoom = 0.5;
 let offsetY = 0;
 laws.forEach(title => {
  const div = document.createElement('div');
  div.className = 'law-item';
  div.innerText = title;
  stack.appendChild(div);
 });
 function updateScale() {
  const items = document.querySelectorAll('.law-item');
  items.forEach(item => {
    const itemRect = item.getBoundingClientRect();
    const containerRect = stackContainer.getBoundingClientRect();
    const itemCenter = (itemRect.top + itemRect.bottom) / 2;
    const containerCenter = (containerRect.top + containerRect.bottom) / 2;
    const distance = Math.abs(containerCenter - itemCenter);
    const scale = Math.max(maxZoom - distance / 120, minZoom);
    const opacity = Math.max(1 - distance / 300, 0.3);
    const barWidth = Math.max(6, 60 - distance / 3);
    item.style.transform = `scale(${scale})`;
    item.style.opacity = opacity;
    item.style.setProperty('--bar-width', barWidth + 'px');
    item.style.setProperty('--bar-color', distance < 50 ? '#333' : '#aaa');
  });
 }
 stackContainer.addEventListener('wheel', (e) => {
  e.preventDefault();
  offsetY = (offsetY + e.deltaY) % stack.scrollHeight;
  if (offsetY < 0) offsetY += stack.scrollHeight;
  stack.style.top = `${-offsetY}px`;
  updateScale();
 });
 document.addEventListener('mousemove', updateScale);
 updateScale();
 </script>
 </body>
 </html>
--- a/assets/site/index4.html
+++ b/assets/site/index4.html
@@ -0,0 +1,158 @@
 <!--
 Interactive Hacker Laws Stack - Specification:
 1. User Experience:
   - Display a vertically scrolling list of items ("laws") in a visually appealing, interactive format.
   - The list infinitely loops seamlessly; scrolling beyond the first or last item cycles continuously.
   - Mouse scrolling moves the entire list vertically within a fixed viewport (no internal scrollbar visible).
   - The item under the mouse cursor smoothly scales up (zooms) and becomes clearly highlighted.
   - Items further from the cursor scale down smoothly, fade out gradually, and become visually less prominent.
   - To the left of each text item, a horizontal bar visually represents the focus, forming a bell-curve-like effect. 
     The bar is smallest (circular) when far from the cursor, and smoothly expands (rectangular with rounded corners) when close.
 2. Sources:
   - Original Interaction Design Inspiration: https://press.stripe.com/
   - Data Source (list of "Hacker Laws"): https://github.com/dwmkerr/hacker-laws/
 3. Technical Details:
   - Implemented using plain HTML, CSS, and JavaScript without third-party libraries.
   - Clearly defined parameters for customization:
     - `maxZoom`: maximum scale factor for the item closest to the cursor.
     - `minZoom`: minimum scale factor for items furthest from the cursor.
   - Styling is clean, minimalist, and customizable via CSS variables.
 This specification allows easy adjustments, maintenance, and future enhancements of the interactive list.
 -->
 <!DOCTYPE html>
 <html lang="en">
 <head>
  <meta charset="UTF-8">
  <title>Interactive Hacker Laws Stack</title>
  <style>
    body {
      display: flex;
      justify-content: center;
      align-items: center;
      height: 100vh;
      background-color: #f5f5f5;
      margin: 0;
      font-family: Arial, sans-serif;
      overflow: hidden;
    }
    #stack-container {
      width: 400px;
      height: 500px;
      border: 1px solid #ddd;
      border-radius: 8px;
      background-color: #fff;
      box-shadow: 0 2px 10px rgba(0,0,0,0.1);
      padding: 10px;
      overflow: hidden;
      position: relative;
    }
    #stack {
      position: absolute;
      width: 100%;
    }
    .law-item {
      text-align: left;
      padding: 2px 4px;
      transition: transform 0.2s ease, opacity 0.2s;
      transform-origin: left;
      font-size: 15px;
      color: #333;
      margin: 4px 0;
      position: relative;
      display: flex;
      align-items: center;
    }
    .law-item::before {
      content: '';
      display: block;
      width: var(--bar-width, 6px);
      height: 6px;
      border-radius: 3px;
      background-color: var(--bar-color, #aaa);
      margin-right: 10px;
      transition: width 0.2s, background-color 0.2s;
    }
  </style>
 </head>
 <body>
 <div id="stack-container">
  <div id="stack"></div>
 </div>
 <script>
 const laws = [
  "90–9–1 Principle (1% Rule)", "90–90 Rule", "Amdahl's Law", "The Broken Windows Theory",
  "Brooks' Law", "CAP Theorem (Brewer's Theorem)", "Clarke's Three Laws", "Conway's Law",
  "Cunningham's Law", "Dunbar's Number", "The Dunning-Kruger Effect", "Fitts' Law",
  "Gall's Law", "Goodhart's Law", "Hanlon's Razor", "Hofstadter's Law", "Hutber's Law",
  "The Hype Cycle & Amara's Law", "Hyrum's Law (The Law of Implicit Interfaces)",
  "Metcalfe's Law", "Moore's Law", "Murphy's Law / Sod's Law", "Occam's Razor",
  "Parkinson's Law", "Premature Optimization Effect", "Putt's Law", "Reed's Law",
  "The Law of Conservation of Complexity (Tesler's Law)", "The Law of Leaky Abstractions",
  "The Law of Triviality", "The Unix Philosophy", "The Spotify Model", "Wadler's Law",
  "Wheaton's Law", "The Dilbert Principle", "The Pareto Principle (The 80/20 Rule)",
  "The Peter Principle", "The Robustness Principle (Postel's Law)", "SOLID",
  "The Single Responsibility Principle", "The Open/Closed Principle", "The Liskov Substitution Principle",
  "The Interface Segregation Principle", "The Dependency Inversion Principle", "The DRY Principle",
  "The KISS Principle", "YAGNI"
 ];
 const stack = document.getElementById('stack');
 const stackContainer = document.getElementById('stack-container');
 const maxZoom = 1.8;
 const minZoom = 0.5;
 let offsetY = 0;
 // Create seamless infinite scrolling
 const extendedLaws = [...laws, ...laws, ...laws];
 extendedLaws.forEach(title => {
  const div = document.createElement('div');
  div.className = 'law-item';
  div.innerText = title;
  stack.appendChild(div);
 });
 const totalHeight = stack.scrollHeight / 3;
 stack.style.top = `-${totalHeight}px`;
 offsetY = totalHeight;
 function updateScale(e) {
  const items = document.querySelectorAll('.law-item');
  items.forEach(item => {
    const itemRect = item.getBoundingClientRect();
    const distance = e.clientY ? Math.abs(e.clientY - (itemRect.top + itemRect.bottom) / 2) : 0;
    const scale = Math.max(maxZoom - distance / 120, minZoom);
    const opacity = Math.max(1 - distance / 300, 0.3);
    const barWidth = Math.max(6, 60 - distance / 3);
    item.style.transform = `scale(${scale})`;
    item.style.opacity = opacity;
    item.style.setProperty('--bar-width', barWidth + 'px');
    item.style.setProperty('--bar-color', distance < 50 ? '#333' : '#aaa');
  });
 }
 stackContainer.addEventListener('wheel', (e) => {
  e.preventDefault();
  offsetY += e.deltaY;
  if (offsetY >= totalHeight * 2) offsetY -= totalHeight;
  if (offsetY < totalHeight) offsetY += totalHeight;
  stack.style.top = `-${offsetY}px`;
  updateScale(e);
 });
 stackContainer.addEventListener('mousemove', updateScale);
 // Initial scale update
 updateScale({ clientY: window.innerHeight / 2 });
 </script>
 </body>
 </html>
--- a/images/Fitts_Law.svg
+++ b/images/Fitts_Law.svg
@@ -1,42 +1,363 @@
-<svg width="640" height="480" xmlns="http://www.w3.org/2000/svg" xmlns:svg="http://www.w3.org/2000/svg">
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
- <!-- Created with SVG-edit - http://svg-edit.googlecode.com/ -->
+<svg
-
+   width="640"
- <g>
+   height="480"
-  <title>Layer 1</title>
+   version="1.1"
-  <g id="svg_14" transform="rotate(38.2092, 97, 276.029)">
+   id="svg195"
-   <line stroke-linecap="round" id="svg_10" y2="276" x2="92" y1="301" x1="92.000002" stroke-width="4" stroke="#000000" fill="none"/>
+   sodipodi:docname="Fitts_Law.svg"
-   <line stroke-linecap="round" id="svg_7" y2="281" x2="112" y1="276" x1="102" stroke-width="4" stroke="#000000" fill="none"/>
+   inkscape:version="1.1 (c68e22c387, 2021-05-23)"
-   <line id="svg_8" stroke-linecap="round" y2="276" x2="102" y1="301.058297" x1="102" stroke-width="4" stroke="#000000" fill="none"/>
+   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
-   <line id="svg_11" stroke-linecap="round" y2="276" x2="92" y1="281" x1="82" stroke-width="4" stroke="#000000" fill="none"/>
+   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
-   <line id="svg_12" y2="251" x2="97" y1="281" x1="82" stroke-linecap="round" stroke-linejoin="null" stroke-dasharray="null" stroke-width="4" stroke="#000000" fill="none"/>
+   xmlns="http://www.w3.org/2000/svg"
-   <line id="svg_13" y2="251" x2="97" y1="281" x1="112" stroke-linecap="round" stroke-linejoin="null" stroke-dasharray="null" stroke-width="4" stroke="#000000" fill="none"/>
+   xmlns:svg="http://www.w3.org/2000/svg">
  <defs
     id="defs199" />
  <sodipodi:namedview
     id="namedview197"
     pagecolor="#ffffff"
     bordercolor="#666666"
     borderopacity="1.0"
     inkscape:pageshadow="2"
     inkscape:pageopacity="0.0"
     inkscape:pagecheckerboard="0"
     showgrid="false"
     inkscape:zoom="1.2197592"
     inkscape:cx="253.73861"
     inkscape:cy="240.21135"
     inkscape:window-width="1920"
     inkscape:window-height="1043"
     inkscape:window-x="0"
     inkscape:window-y="0"
     inkscape:window-maximized="1"
     inkscape:current-layer="layer2" />
  <g
     inkscape:groupmode="layer"
     id="layer2"
     inkscape:label="Layer 2"
     style="display:inline">
    <rect
       style="fill:#ffffff;stroke-width:0"
       id="rect557"
       width="100%"
       height="100%"
       x="0"
       y="0" />
  </g>
-  <g id="svg_16">
+  <!-- Created with SVG-edit - http://svg-edit.googlecode.com/ -->
-   <line fill="none" stroke="#7f7f7f" stroke-width="2" stroke-linejoin="round" stroke-linecap="round" x1="570" y1="135" x2="420" y2="135" id="svg_1" stroke-dasharray="5,5"/>
+  <g
-   <line fill="none" stroke="#7f7f7f" stroke-width="2" stroke-linejoin="round" stroke-linecap="round" x1="495" y1="210" x2="495" y2="60" id="svg_4" stroke-dasharray="5,5"/>
+     id="g193">
-   <rect fill="none" stroke="#000000" stroke-width="5" stroke-linejoin="round" stroke-linecap="round" x="445" y="85" width="100" height="100" id="svg_2"/>
+    <title
-   <text fill="#000000" stroke="#000000" stroke-width="0" stroke-dasharray="null" stroke-linejoin="round" stroke-linecap="round" x="495.91669" y="118.66669" id="svg_3" font-size="24" font-family="Sans-serif" text-anchor="middle" xml:space="preserve" font-weight="bold">Target</text>
+       id="title161">Layer 1</title>
    <g
       id="svg_14"
       transform="rotate(38.2092, 97, 276.029)">
      <line
         stroke-linecap="round"
         id="svg_10"
         y2="276"
         x2="92"
         y1="301"
         x1="92.000002"
         stroke-width="4"
         stroke="#000000"
         fill="none" />
      <line
         stroke-linecap="round"
         id="svg_7"
         y2="281"
         x2="112"
         y1="276"
         x1="102"
         stroke-width="4"
         stroke="#000000"
         fill="none" />
      <line
         id="svg_8"
         stroke-linecap="round"
         y2="276"
         x2="102"
         y1="301.058297"
         x1="102"
         stroke-width="4"
         stroke="#000000"
         fill="none" />
      <line
         id="svg_11"
         stroke-linecap="round"
         y2="276"
         x2="92"
         y1="281"
         x1="82"
         stroke-width="4"
         stroke="#000000"
         fill="none" />
      <line
         id="svg_12"
         y2="251"
         x2="97"
         y1="281"
         x1="82"
         stroke-linecap="round"
         stroke-linejoin="null"
         stroke-dasharray="null"
         stroke-width="4"
         stroke="#000000"
         fill="none" />
      <line
         id="svg_13"
         y2="251"
         x2="97"
         y1="281"
         x1="112"
         stroke-linecap="round"
         stroke-linejoin="null"
         stroke-dasharray="null"
         stroke-width="4"
         stroke="#000000"
         fill="none" />
    </g>
    <g
       id="svg_16">
      <line
         fill="none"
         stroke="#7f7f7f"
         stroke-width="2"
         stroke-linejoin="round"
         stroke-linecap="round"
         x1="570"
         y1="135"
         x2="420"
         y2="135"
         id="svg_1"
         stroke-dasharray="5,5" />
      <line
         fill="none"
         stroke="#7f7f7f"
         stroke-width="2"
         stroke-linejoin="round"
         stroke-linecap="round"
         x1="495"
         y1="210"
         x2="495"
         y2="60"
         id="svg_4"
         stroke-dasharray="5,5" />
      <rect
         fill="none"
         stroke="#000000"
         stroke-width="5"
         stroke-linejoin="round"
         stroke-linecap="round"
         x="445"
         y="85"
         width="100"
         height="100"
         id="svg_2" />
      <text
         fill="#000000"
         stroke="#000000"
         stroke-width="0"
         stroke-dasharray="null"
         stroke-linejoin="round"
         stroke-linecap="round"
         x="495.91669"
         y="118.66669"
         id="svg_3"
         font-size="24"
         font-family="Sans-serif"
         text-anchor="middle"
         xml:space="preserve"
         font-weight="bold">Target</text>
    </g>
    <text
       font-weight="bold"
       xml:space="preserve"
       text-anchor="middle"
       font-family="Sans-serif"
       font-size="24"
       id="svg_5"
       y="35"
       x="494"
       stroke-linecap="round"
       stroke-linejoin="null"
       stroke-dasharray="5,5"
       stroke-width="0"
       stroke="#7f7f7f"
       fill="#000000">W</text>
    <g
       id="svg_21">
      <line
         fill="none"
         stroke="#000000"
         stroke-width="3"
         stroke-linejoin="null"
         stroke-linecap="round"
         x1="445"
         y1="45"
         x2="545"
         y2="45"
         id="svg_9" />
      <line
         id="svg_17"
         y2="55"
         x2="455"
         y1="45"
         x1="445"
         stroke-linecap="round"
         stroke-linejoin="null"
         stroke-width="3"
         stroke="#000000"
         fill="none" />
      <line
         id="svg_18"
         y2="35"
         x2="455"
         y1="45"
         x1="445"
         stroke-linecap="round"
         stroke-linejoin="null"
         stroke-width="3"
         stroke="#000000"
         fill="none" />
      <line
         id="svg_19"
         y2="55"
         x2="535"
         y1="45"
         x1="545"
         stroke-linecap="round"
         stroke-linejoin="null"
         stroke-width="3"
         stroke="#000000"
         fill="none" />
      <line
         id="svg_20"
         y2="35"
         x2="535"
         y1="45"
         x1="545"
         stroke-linecap="round"
         stroke-linejoin="null"
         stroke-width="3"
         stroke="#000000"
         fill="none" />
    </g>
    <g
       id="svg_37"
       transform="rotate(-17.3352, 328.667, 273.333)">
      <line
         fill="none"
         stroke="#7f7f7f"
         stroke-width="2"
         stroke-dasharray="5,5"
         stroke-linejoin="null"
         stroke-linecap="round"
         x1="128.666668"
         y1="191.333333"
         x2="528.666668"
         y2="191.333333"
         id="svg_6" />
      <text
         id="svg_15"
         font-weight="bold"
         xml:space="preserve"
         text-anchor="middle"
         font-family="Sans-serif"
         font-size="24"
         y="349.333338"
         x="327.000016"
         stroke-linecap="round"
         stroke-linejoin="null"
         stroke-dasharray="5,5"
         stroke-width="0"
         stroke="#7f7f7f"
         fill="#000000">D</text>
      <g
         id="svg_34">
        <line
           fill="none"
           stroke="#000000"
           stroke-width="3"
           stroke-linejoin="null"
           stroke-linecap="round"
           x1="128.666668"
           y1="316.000005"
           x2="528.666668"
           y2="316.000005"
           id="svg_29" />
        <line
           y2="326.000005"
           x2="138.666668"
           y1="316.000005"
           x1="128.666668"
           stroke-linecap="round"
           stroke-linejoin="null"
           stroke-width="3"
           stroke="#000000"
           fill="none"
           id="svg_30" />
        <line
           y2="306.000005"
           x2="138.666668"
           y1="316.000005"
           x1="128.666668"
           stroke-linecap="round"
           stroke-linejoin="null"
           stroke-width="3"
           stroke="#000000"
           fill="none"
           id="svg_31" />
        <line
           y2="326.000005"
           x2="518.666668"
           y1="316.000005"
           x1="528.666668"
           stroke-linecap="round"
           stroke-linejoin="null"
           stroke-width="3"
           stroke="#000000"
           fill="none"
           id="svg_32" />
        <line
           y2="306.000005"
           x2="518.666668"
           y1="316.000005"
           x1="528.666668"
           stroke-linecap="round"
           stroke-linejoin="null"
           stroke-width="3"
           stroke="#000000"
           fill="none"
           id="svg_33" />
      </g>
      <line
         fill="none"
         stroke="#7f7f7f"
         stroke-width="2"
         stroke-dasharray="5,5"
         stroke-linejoin="null"
         stroke-linecap="round"
         x1="128.666668"
         y1="191.333333"
         x2="128.666668"
         y2="341.333333"
         id="svg_35" />
      <line
         fill="none"
         stroke="#7f7f7f"
         stroke-width="2"
         stroke-dasharray="5,5"
         stroke-linejoin="null"
         stroke-linecap="round"
         x1="528.666668"
         y1="191.333333"
         x2="528.666668"
         y2="341.333333"
         id="svg_36" />
    </g>
  </g>
-  <text font-weight="bold" xml:space="preserve" text-anchor="middle" font-family="Sans-serif" font-size="24" id="svg_5" y="35" x="494" stroke-linecap="round" stroke-linejoin="null" stroke-dasharray="5,5" stroke-width="0" stroke="#7f7f7f" fill="#000000">W</text>
+  <g
-  <g id="svg_21">
+     inkscape:groupmode="layer"
-   <line fill="none" stroke="#000000" stroke-width="3" stroke-linejoin="null" stroke-linecap="round" x1="445" y1="45" x2="545" y2="45" id="svg_9"/>
+     id="layer1"
-   <line id="svg_17" y2="55" x2="455" y1="45" x1="445" stroke-linecap="round" stroke-linejoin="null" stroke-width="3" stroke="#000000" fill="none"/>
+     inkscape:label="Layer 1" />
-   <line id="svg_18" y2="35" x2="455" y1="45" x1="445" stroke-linecap="round" stroke-linejoin="null" stroke-width="3" stroke="#000000" fill="none"/>
+</svg>
   <line id="svg_19" y2="55" x2="535" y1="45" x1="545" stroke-linecap="round" stroke-linejoin="null" stroke-width="3" stroke="#000000" fill="none"/>
   <line id="svg_20" y2="35" x2="535" y1="45" x1="545" stroke-linecap="round" stroke-linejoin="null" stroke-width="3" stroke="#000000" fill="none"/>
  </g>
  <g id="svg_37" transform="rotate(-17.3352, 328.667, 273.333)">
   <line fill="none" stroke="#7f7f7f" stroke-width="2" stroke-dasharray="5,5" stroke-linejoin="null" stroke-linecap="round" x1="128.666668" y1="191.333333" x2="528.666668" y2="191.333333" id="svg_6"/>
   <text id="svg_15" font-weight="bold" xml:space="preserve" text-anchor="middle" font-family="Sans-serif" font-size="24" y="349.333338" x="327.000016" stroke-linecap="round" stroke-linejoin="null" stroke-dasharray="5,5" stroke-width="0" stroke="#7f7f7f" fill="#000000">D</text>
   <g id="svg_34">
    <line fill="none" stroke="#000000" stroke-width="3" stroke-linejoin="null" stroke-linecap="round" x1="128.666668" y1="316.000005" x2="528.666668" y2="316.000005" id="svg_29"/>
    <line y2="326.000005" x2="138.666668" y1="316.000005" x1="128.666668" stroke-linecap="round" stroke-linejoin="null" stroke-width="3" stroke="#000000" fill="none" id="svg_30"/>
    <line y2="306.000005" x2="138.666668" y1="316.000005" x1="128.666668" stroke-linecap="round" stroke-linejoin="null" stroke-width="3" stroke="#000000" fill="none" id="svg_31"/>
    <line y2="326.000005" x2="518.666668" y1="316.000005" x1="528.666668" stroke-linecap="round" stroke-linejoin="null" stroke-width="3" stroke="#000000" fill="none" id="svg_32"/>
    <line y2="306.000005" x2="518.666668" y1="316.000005" x1="528.666668" stroke-linecap="round" stroke-linejoin="null" stroke-width="3" stroke="#000000" fill="none" id="svg_33"/>
   </g>
   <line fill="none" stroke="#7f7f7f" stroke-width="2" stroke-dasharray="5,5" stroke-linejoin="null" stroke-linecap="round" x1="128.666668" y1="191.333333" x2="128.666668" y2="341.333333" id="svg_35"/>
   <line fill="none" stroke="#7f7f7f" stroke-width="2" stroke-dasharray="5,5" stroke-linejoin="null" stroke-linecap="round" x1="528.666668" y1="191.333333" x2="528.666668" y2="341.333333" id="svg_36"/>
  </g>
 </g>
 </svg>
--- a/images/changelog-podcast.png
+++ b/images/changelog-podcast.png
--- a/images/complete_graph.png
+++ b/images/complete_graph.png
--- a/images/gartner_hype_cycle.png
+++ b/images/gartner_hype_cycle.png
--- a/images/hicks_law.svg
+++ b/images/hicks_law.svg
@@ -1,5 +1,6 @@
 <svg xmlns:xlink="http://www.w3.org/1999/xlink" width="18.644ex" height="2.843ex" style="vertical-align: -0.838ex;" viewBox="0 -863.1 8027.4 1223.9" role="img" focusable="false" xmlns="http://www.w3.org/2000/svg" aria-labelledby="MathJax-SVG-1-Title">
 <title id="MathJax-SVG-1-Title">{\displaystyle T=b\cdot \log _{2}(n+1)}</title>
 <rect style="fill:#ffffff" id="rect557" width="100%"  height="100%" x="0" y="-863.1" />
 <defs aria-hidden="true">
 <path stroke-width="1" id="E1-MJMATHI-54" d="M40 437Q21 437 21 445Q21 450 37 501T71 602L88 651Q93 669 101 677H569H659Q691 677 697 676T704 667Q704 661 687 553T668 444Q668 437 649 437Q640 437 637 437T631 442L629 445Q629 451 635 490T641 551Q641 586 628 604T573 629Q568 630 515 631Q469 631 457 630T439 622Q438 621 368 343T298 60Q298 48 386 46Q418 46 427 45T436 36Q436 31 433 22Q429 4 424 1L422 0Q419 0 415 0Q410 0 363 1T228 2Q99 2 64 0H49Q43 6 43 9T45 27Q49 40 55 46H83H94Q174 46 189 55Q190 56 191 56Q196 59 201 76T241 233Q258 301 269 344Q339 619 339 625Q339 630 310 630H279Q212 630 191 624Q146 614 121 583T67 467Q60 445 57 441T43 437H40Z"></path>
 <path stroke-width="1" id="E1-MJMAIN-3D" d="M56 347Q56 360 70 367H707Q722 359 722 347Q722 336 708 328L390 327H72Q56 332 56 347ZM56 153Q56 168 72 173H708Q722 163 722 153Q722 140 707 133H70Q56 140 56 153Z"></path>
--- a/scripts/prepare-markdown-for-ebook.sh
+++ b/scripts/prepare-markdown-for-ebook.sh
@@ -0,0 +1,44 @@
 #!/usr/bin/env bash
 # Fail on errors.
 set -e -o pipefail
 # Check if parameters are provided
 input="$1"
 output="$2"
 if [ -z "${input}" ] || [ -z "${output}" ]; then
    echo "usage: $(basename "$0") <input> <output>" >&2
    echo "  input: source markdown file (usually README.md)" >&2
    echo "  output: output markdown file (usually hacker-laws.md)" >&2
    exit 1
 fi
 # Grab env vars used to configure output, fail if required are missing.
 export date="${DATE:-$(date +%F)}"
 export version="${VERSION?error: VERSION must be set}"
 # Update the input file to an intermedate.
 intermediate="${input}.temp"
 cat <<EOF > "${intermediate}"
 ---
 title: "Hacker Laws"
 author: "Dave Kerr, github.com/dwmkerr/hacker-laws"
 subtitle: "Laws, Theories, Principles, and Patterns that developers will find useful. ${VERSION}, ${DATE}."
 version: ${VERSION}
 ---
 EOF
 cat "${input}" >> "${intermediate}"
 DATE="${date}" VERSION="${version}" envsubst < "${intermediate}" > "${output}"
 # Use a single `sed` command to clean up unwanted lines and emojis in one pass.
 sed      -e '/💻📖.*/d' \
         -e 's/❗/Warning/g' \
         -e '/^\[Translations.*/d' \
         -e '/\*.*/d' \
         -e '/    \*.*/d' \
         -e '/## Translations/,$d' "${output}" > "${intermediate}"
 mv "${intermediate}" "${output}"
 echo "${output} prepared successfully."
--- a/translations/fr.md
+++ b/translations/fr.md
@@ -193,7 +193,7 @@ Souvent aussi énoncée de cette manière :
 > Lorsqu'une mesure devient un objectif, elle cesse d'être une bonne mesure.
 > *Marilyn Strathern*
-Cette loi indique que les optimisations basées sur une mesure peuvent amener à une perte de valeur de la mesure elle même. Un ensemble de mesures ([KPIs](https://en.wikipedia.org/wiki/Performance_indicator)) trop restraint appliqué aveuglément à un process déforme le résultat. Les gens tendent à "tricher" localement pour satisfaire une mesure en particulier sans faire attention aux effect globaux de leurs actions sur le système.
+Cette loi indique que les optimisations basées sur une mesure peuvent amener à une perte de valeur de la mesure elle même. Un ensemble de mesures ([KPIs](https://en.wikipedia.org/wiki/Performance_indicator)) trop restraint appliqué aveuglément à un process déforme le résultat. Les gens tendent à "tricher" localement pour satisfaire une mesure en particulier sans faire attention aux effets globaux de leurs actions sur le système.
 Exemples concrets :
@@ -244,7 +244,7 @@ Par exemple, un abaissement de la latence de réponse sur une route (end-point)
 [Cycle du hype sur Wikipedia](https://fr.wikipedia.org/wiki/Cycle_du_hype)
-> On a tendance à surestimer l'effet d'une technologie sur le court terme et à le surestimer sur le long terme.
+> On a tendance à surestimer l'effet d'une technologie sur le court terme et à le sous-estimer sur le long terme.
 > (Roy Amara)
 Le cycle du hype est une représentation visuelle de l'attrait et du développement d'une technologie au fil du temps. Initialement réalisé par Gartner, le concept est plus clair avec un diagramme :
@@ -259,7 +259,7 @@ En clair, ce cycle montre qu'il y a généralement un pic d'excitation concernan
 [Loi d'Hyrum en ligne](http://www.hyrumslaw.com/)
-> > Passé un certain nombre d'utilisateur d'une API, peu importe ce qui est promis par l'interface, tous les comportements possibles du système seront utilisés.
+> Passé un certain nombre d'utilisateur d'une API, peu importe ce qui est promis par l'interface, tous les comportements possibles du système seront utilisés.
 > (Hyrum Wright)
 La loi d'Hyrum décris le fait que lorsqu'une API a un *nombre suffisamment élevé d'utilisateurs*, tous les comportements de l'API (y compris ceux qui ne sont pas définis publiquement) seront utilisés par quelqu'un. Un exemple trivial peut concerner les éléments non fonctionnels de l'API comme le temps de réponse. Un exemple plus subtil peut être l'utilisation d'une regex sur les messages d'erreurs pour en déterminer le *type*. Même si la spécification de l'API ne mentionne rien quant au contenu des messages, *certains* utilisateurs peuvent utiliser ces messages. Un changement au niveau de ces messages reviendrait à casser l'API pour ces utilisateurs.
@@ -486,7 +486,7 @@ Voir aussi :
 > Ne soyez pas un connard.
 > *Wil Wheaton*
-Inventée par Will Wheaton (Star Trek: The Next Generation, The Big Bang Theory), cette loi simple, concise et puissante vise à augmenter l'harmonie et le respect au sein d'un environnement professionnel. Elle peut être appliquée lorsqu'on parle à ses collègues, effectue une code review, argumente contre un autre point de vue, critique et de manière générale, lors de la plupart des interactions entre humains.
+Inventée par Will Wheaton (Star Trek: The Next Generation, The Big Bang Theory), cette loi simple, concise et puissante vise à augmenter l'harmonie et le respect au sein d'un environnement professionnel. Elle peut être appliquée lorsqu'on parle à ses collègues, effectue une revue de code (*code review*), argumente contre un autre point de vue, critique et de manière générale, lors de la plupart des interactions entre humains.
 ## Principes
@@ -499,7 +499,7 @@ Les principes sont généralement des lignes directrices liés à la conception.
 > Les entreprises tendent à promouvoir systématiquement les employés incompétents afin de les sortir du workflow.
 > *Scott Adams*
-Un concept de gestion inventé par Scott Adams (créateur du comic strip Dilbert) inspiré par le [principe de Peter](#principe-de-peter). Suivant le principe de Dilbert, les employés qui n'ont jamais montré de compétence dans leur travail sont promus à des postes de management afin de limité les dommages qu'ils peuvent causer. Adams expliqua initialement le principe dans un article du Wall Street Journal datant de 1995, et élabora le concept dans son livre de 1996: [The Dilbert Principle](#a-lire).
+Un concept de gestion inventé par Scott Adams (créateur du comic strip Dilbert) inspiré par le [principe de Peter](#principe-de-peter). Suivant le principe de Dilbert, les employés qui n'ont jamais montré de compétence dans leur travail sont promus à des postes de management afin de limiter les dommages qu'ils peuvent causer. Adams expliqua initialement le principe dans un article du Wall Street Journal datant de 1995, et élabora le concept dans son livre de 1996: [The Dilbert Principle](#a-lire).
 Voir aussi :
@@ -593,7 +593,7 @@ Voir aussi :
 > Les entités devraient être ouvertes à l'extension et fermées à la modification.
-Le deuxième des principes '[SOLID](#solid)'. Il énonce que le comportement des entités (classes, modules, fonctions, etc.) devraient pouvoir être *étendu*, mais que le comportement *existant* ne devrait pas pouvoir être modifié.
+Le deuxième des principes '[SOLID](#solid)'. Il énonce que le comportement des entités (classes, modules, fonctions, etc.) devrait être *étendu*, mais que le comportement *existant* ne devrait pas être modifié.
 Imaginons par exemple un module capable de changer un document rédigé en Markdown en HTML. Ce module peut être étendu en y ajoutant le support pour une nouvelle fonctionnalité Markdown sans modifier son fonctionnement interne. Le module est en revanche *fermé* à la modification dans le sens où un utilisateur *ne peut pas* changer la manière dont le code existant est rédigé.
@@ -679,7 +679,7 @@ Voir aussi :
 [KISS sur Wikipedia](https://fr.wikipedia.org/wiki/Principe_KISS)
-> > Keep it simple, stupid. (Ne complique pas les choses)
+> Keep it simple, stupid. (Ne complique pas les choses)
 Le principe KISS énonce que la plupart des systèmes fonctionnent mieux s'ils sont simples que compliqués. Par conséquent, la simplicité devrait être un but essentiel dans la conception et toute complexité inutile devrait être évité. Provenant de la marine Américaine en 1960, la phrase est attribuée à l'ingénieur Kelly Johnson.
@@ -700,7 +700,7 @@ Il s'agit d'un acronyme pour ***Y**ou **A**in't **G**onna **N**eed **I**t*. Que
 Ce principe *d'Extreme Programming* (XP) suggère que les développeurs ne devraient implémenter que les fonctionnalités qui sont nécessaires immédiatement et éviter de tenter de prédire l'avenir en implémentant des fonctionnalités qui pourraient être nécessaires plus tard.
-Adhérer à ce principe devrait réduire la quantité de code inutilisé dans la codebase et permettre d'éviter de passer du temps et des efforts sur des fonctionnalités qui n'apportent rien.
+Adhérer à ce principe devrait réduire la quantité de code inutilisé dans le codebase et permet d'éviter de passer du temps sur des fonctionnalités qui n'apportent rien.
 Voir aussi :
--- a/translations/it-IT.md
+++ b/translations/it-IT.md
@@ -310,7 +310,7 @@ La Legge afferma che i team di lavoro tendono a dedicare molto più tempo e atte
 Il tipico esempio fittizio usato per illustrare la Legge è quello di un comitato incaricato di approvare i piani per un impianto nucleare, che passa più tempo a discutere i dettagli del ripostiglio delle biciclette che a discutere il ben più importante design dell'impianto stesso. Può essere difficile a volte dare il giusto contributo quando si discute di argomenti grandi e complessi senza avere una preparazione o esperienza adeguata in merito. Tuttavia, le persone vogliono in genere mostrarsi attive nel collaborare fornendo input di valore. Da qui la tendenza a concentrarsi troppo sul dettaglio spiccio, che può essere discusso facilmente, ma non ha necessariamente rilevanza.
-L'esempio fittizio ha portato all'utilizzo del termine "ripostiglio delle biciclette" come metafora della perdita di tempo sui dettagli di poca rilevanza. 
+L'esempio fittizio ha portato all'utilizzo del termine "ripostiglio delle biciclette" come metafora della perdita di tempo sui dettagli di poca rilevanza.
 ### Filosofia Unix
--- a/translations/jp.md
+++ b/translations/jp.md
@@ -27,6 +27,7 @@
    - [ハイプサイクルとアマラの法則](#ハイプサイクルとアマラの法則)
    - [ハイラムの法則（暗黙のインターフェースの法則）](#ハイラムの法則暗黙のインターフェースの法則)
    - [カーニガンの法則](#カーニガンの法則)
    - [リーナスの法則](#リーナスの法則)
    - [メトカーフの法則](#メトカーフの法則)
    - [ムーアの法則](#ムーアの法則)
    - [マーフィーの法則/ソッドの法則](#マーフィーの法則ソッドの法則)
@@ -136,7 +137,7 @@
 > 遅延しているソフトウェア開発プロジェクトに人材を追加するとプロジェクトがさらに遅延する。
-この法則は、多くの場合、すでに遅れているプロジェクトを挽回させようとして、人的リソースを追加することで、プロジェクトが更に遅延することを示唆しています。ブルックスは、これが単純化しすぎであることを明らかにしていますが、一般的な推論としては、新しい人的リソースの立ち上げにかかる時間とコミュニケーションのオーバーヘッドを考えると、短期的には速度が低下するということです。また、多くのタスクは分割ないことがあり、リソース間で簡単にタスク分散されない可能性があり、期待するベロシティも得られなくなることを意味します。
+この法則は、多くの場合、すでに遅れているプロジェクトを挽回させようとして、人的リソースを追加することで、プロジェクトが更に遅延することを示唆しています。ブルックスは、これが単純化しすぎであることを明らかにしていますが、一般的な推論としては、新しい人的リソースの立ち上げにかかる時間とコミュニケーションのオーバーヘッドを考えると、短期的には速度が低下するということです。また、多くのタスクは分割出来ないことがあり、リソース間で簡単にタスク分散されない可能性があり、期待するベロシティも得られなくなることを意味します。
 出産でよく言われる「9人の女性は1ヶ月で子作りができない」という言葉は、ブルックスの法則、特にある種のタスクは分割や並列化できないという事実に関連しています。
@@ -301,6 +302,24 @@
 - [UNIX哲学](#unix哲学)
 - [オッカムのかみそり](#オッカムの剃刀)
 ### リーナスの法則
 [リーナスの法則-Wikipedia](https://ja.wikipedia.org/wiki/%E3%83%AA%E3%83%BC%E3%83%8A%E3%82%B9%E3%81%AE%E6%B3%95%E5%89%87)
 > 十分な目ん玉があれば、全てのバグは洗い出される。
 >
 > _エリック・S・レイモンド_
 この法則は簡単に言うと、あるプログラムを見る人が多ければ多いほど、誰かがその問題を以前に見て解決している可能性が高くなる、あるいはそれに非常に近い状況になる、というものです。
 元々はプロジェクトのオープンソースモデルの価値を説明するために使われましたが、どんなソフトウェアプロジェクトにも当てはまります。プロセスにも拡大して適用できます。より多くのコードレビューや静的解析、また多角的なテストプロセスによって、問題をより可視化されて識別しやすくなります。
 より格式ばって言うと以下のようになります。
 > ベータテスターと共同開発者が十分多くいれば、ほとんど全ての問題はすぐに明確になり、似た問題に以前遭遇したことのある人によって解決されるだろう。
 この法則は、エリック・S・レイモンドの著作『[伽藍とバザール](https://ja.wikipedia.org/wiki/%E4%BC%BD%E8%97%8D%E3%81%A8%E3%83%90%E3%82%B6%E3%83%BC%E3%83%AB)』の中で、[リーナス・トーバルズ](https://ja.wikipedia.org/wiki/%E3%83%AA%E3%83%BC%E3%83%8A%E3%82%B9%E3%83%BB%E3%83%88%E3%83%BC%E3%83%90%E3%83%AB%E3%82%BA)に敬意を表して名付けられました。
 ### メトカーフの法則
 [メトカーフの法則-Wikipedia](https://ja.wikipedia.org/wiki/%E3%83%A1%E3%83%88%E3%82%AB%E3%83%BC%E3%83%95%E3%81%AE%E6%B3%95%E5%89%87)
@@ -435,7 +454,7 @@ Donald Knuthの論文「 [Structured Programming With Go To Statements」で](ht
 この法則では、複雑なシステムでの作業を簡略化するためにコンピューティングで一般的に使用される抽象化は、特定の状況では、基礎となるシステムの要素を「漏らし」、抽象化が予期しない方法で動作することになると述べています。
-例としては、ファイルをロードしてその内容を読むことが挙げられます。ァイルシステム API は低レベルのカーネルシステムの *抽象化*であり、それ自体が磁気プラッター (または SSD のフラッシュメモリ) 上のデータの変更に関連する物理的なプロセスを抽象化したものです。ほとんどの場合、ファイルをバイナリデータのストリームのように扱うという抽象化が機能します。磁気ドライブの場合、データを連続的に読み込むと、ランダム・アクセスよりも（ページ・フォルトのオーバーヘッドが増加するため）*大幅に*速くなりますが、SSD ドライブの場合は、このオーバーヘッドは存在しません。この場合に対処するためには、基本的な詳細を理解する必要があります（例えば、データベースのインデックスファイルはランダムアクセスのオーバーヘッドを減らすために構造化されています）が、抽象化された実装の詳細は、開発者が注意する必要があるかもしれません。
+例としては、ファイルをロードしてその内容を読むことが挙げられます。ファイルシステム API は低レベルのカーネルシステムの *抽象化*であり、それ自体が磁気プラッター (または SSD のフラッシュメモリ) 上のデータの変更に関連する物理的なプロセスを抽象化したものです。ほとんどの場合、ファイルをバイナリデータのストリームのように扱うという抽象化が機能します。磁気ドライブの場合、データを連続的に読み込むと、ランダム・アクセスよりも（ページ・フォルトのオーバーヘッドが増加するため）*大幅に*速くなりますが、SSD ドライブの場合は、このオーバーヘッドは存在しません。この場合に対処するためには、基本的な詳細を理解する必要があります（例えば、データベースのインデックスファイルはランダムアクセスのオーバーヘッドを減らすために構造化されています）が、抽象化された実装の詳細は、開発者が注意する必要があるかもしれません。
 上記の例は、より多くの抽象化が導入されると、*より*複雑になる可能性があります。Linux オペレーティングシステムでは、ネットワーク経由でファイルにアクセスすることができますが、ローカルでは「通常の」ファイルとして表現されます。この抽象化は、ネットワーク障害が発生した場合に「漏れ」ます。開発者がこれらのファイルをネットワークの遅延や障害の影響を受ける可能性があることを考慮せずに「通常の」ファイルとして扱ってしまうと、解決策がバグだらけになってしまいます。
@@ -608,9 +627,9 @@ Spotifyモデルとは、「Spotify」によって普及したチームと組織
 > エンティティは拡張のために開かれ、修正のために閉じられるべきです。
-「 [SOLID](#solid) 」第二原則。この原則では、エンティティー（クラス、モジュール、関数など）は動作を*拡張*ることができなければならないが、 *既存*の振る舞いは修正することができないべきではないということを述べています。
+「 [SOLID](#solid) 」第二原則。この原則では、エンティティー（クラス、モジュール、関数など）は動作を*拡張*することができなければならないが、 *既存*の振る舞いは修正することができないべきではないということを述べています。
-仮定としてMarkdown文書をHTMLに変換することができるモジュールを想像してください。ジュールがモジュール内部を修正することなく、新しく提案されたMarkdown機能を処理するために拡張できた場合、拡張のためにオープンになります。既存のMarkdown機能が処理されるように、モジュールが利用者によって*修正されない*場合、修正のために*クローズド*になります。
+仮定としてMarkdown文書をHTMLに変換することができるモジュールを想像してください。モジュールがモジュール内部を修正することなく、新しく提案されたMarkdown機能を処理するために拡張できた場合、拡張のためにオープンになります。既存のMarkdown機能が処理されるように、モジュールが利用者によって*修正されない*場合、修正のために*クローズド*になります。
 この原則は、オブジェクト指向プログラミングに特に関連しています。簡単に拡張するオブジェクトを設計するかもしれませんが、予期しない方法で変更された既存の動作を持つことができるオブジェクトを設計することを避けます。
@@ -786,7 +805,7 @@ KISSの原則は、ほとんどのシステムは複雑にするのではなく
 ## 貢献方法
-貢献してください! 追加や変更を提案したい場合は  [Raise an issue](https://github.com/dwmkerr/hacker-laws/issues/new)、変更を提案したい場合は  [Open a pull request](https://github.com/dwmkerr/hacker-laws/compare)t をご利用ください。
+貢献してください! 追加や変更を提案したい場合は  [Raise an issue](https://github.com/dwmkerr/hacker-laws/issues/new)、変更を提案したい場合は  [Open a pull request](https://github.com/dwmkerr/hacker-laws/compare) をご利用ください。
 文章やスタイルなどの要件については、[Contributing Guidelines](./.github/contributing.md)  を必ずお読みください。プロジェクトの議論に参加する際には、[Code of Conduct](./.github/CODE_OF_CONDUCT.md)を意識してください。
@@ -794,4 +813,4 @@ KISSの原則は、ほとんどのシステムは複雑にするのではなく
 こんにちは！あなたがここに来たということは、私がまだ書き上げていないトピックへのリンクをクリックしたことにですね。
-リクエストしたい場合は  [Raise an Issue](https://github.com/dwmkerr/hacker-laws/issues) rをクリックするか、トピックの定義案を提出したい場合は [Open a Pull Request](https://github.com/dwmkerr/hacker-laws/pulls) をクリックしてください。
+リクエストしたい場合は  [Raise an Issue](https://github.com/dwmkerr/hacker-laws/issues) をクリックするか、トピックの定義案を提出したい場合は [Open a Pull Request](https://github.com/dwmkerr/hacker-laws/pulls) をクリックしてください。
--- a/translations/lv.md
+++ b/translations/lv.md
@@ -69,7 +69,7 @@ Kā šis projekts? Lūdzu, apsveriet iespēju [Sponsoring Me](https://github.com
 * [Lasīšanas saraksts](#lasīšanas-saraksts)
 * [Ieguldījums](#ieguldījums)
 * [Uzdevums](#TODO)
-    
+
 <!-- VIM-markdown-toc -->
 ## Ievads
--- a/translations/pl.md
+++ b/translations/pl.md
--- a/translations/pt-BR.md
+++ b/translations/pt-BR.md
@@ -93,9 +93,9 @@ Veja também:
 [Lei de Amdahl na Wikipédia](https://pt.wikipedia.org/wiki/Lei_de_Amdahl)
-> A lei de Amdahl, também conhecida como argumento de Amdahl, é usada para encontrar a máxima melhora esperada para um sistema em geral quando apenas uma única parte do mesmo é melhorada. Isto é frequentemente usado em computação paralela para prever o máximo speedup teórico usando múltiplos processadores. A lei possui o nome do Arquiteto computacional Gene Amdahl, e foi apresentada a AFIPS na Conferência Conjunta de Informática na primavera de 1967. 
+> A lei de Amdahl, também conhecida como argumento de Amdahl, é usada para encontrar a máxima melhora esperada para um sistema em geral quando apenas uma única parte do mesmo é melhorada. Isto é frequentemente usado em computação paralela para prever o máximo speedup teórico usando múltiplos processadores. A lei possui o nome do Arquiteto computacional Gene Amdahl, e foi apresentada a AFIPS na Conferência Conjunta de Informática na primavera de 1967.
-Fica mais fácil de entender com um exemplo prático. Se um programa é feito de duas partes, parte A, que é executada por um processador único, e parte B, que pode ser feito paralelamente com N processadores. Se adicionarmos mais processaores ao sistema, só vai ter aumento nas tarefas relacionadas à parte B do programa. A velocidade de A se mantém a mesma.
+Fica mais fácil de entender com um exemplo prático. Se um programa é feito de duas partes, parte A, que é executada por um processador único, e parte B, que pode ser feito paralelamente com N processadores. Se adicionarmos mais processadores ao sistema, só vai ter aumento nas tarefas relacionadas à parte B do programa. A velocidade de A se mantém a mesma.
 O diagrama abaixo mostra alguns exemplos de melhoria na velocidade:
@@ -125,15 +125,13 @@ Exemplos:
 ### Lei de Brook
-[Lei de Brooks na Wikipeia](https://en.wikipedia.org/wiki/Brooks%27s_law)
+[Lei de Brooks na Wikipedia](https://en.wikipedia.org/wiki/Brooks%27s_law)
 > Adicionar recursos humanos em um projeto, de desenvolvimento de software, atrasado, faz ficar ainda mais atrasado.
-> Adicionar recursos humanos em um projeto, de desenvolvimento de sotware, atrasado, faz ficar ainda mais atrasado. 
+Essa lei sugere que em muitos casos, na tentativa de acelerar uma entrega, que já está atrasada, adicionando mais pessoas atrasa ainda mais essa entrega. Brooks assume que essa afirmação é uma generalização excessiva, entretanto, o principal motivo para isso acontecer é dado pelo simples fato de adicionar pessoas requer um gasto com comunicação e construção de novos recursos para a equipe suportar novos membros. Logo, a curto prazo esse investimento não tem um retorno. Também existem tarefas que não podem ser dividias, portanto adicionar mais pessoas não vai fazer ela ser concluída mais rápido.
 Essa lei sugere que em muitos casos, na tentativa de acelerar uma entrega, que já está atrasada, adcionando mais pessoas atrasa ainda mais essa entrega. Brooke assume que essa afirmação é uma generalização excessiva, entretanto, o principal motivo para isso acontecer é dado pelo simples fato de adicionar pessoas requer um gasto com comunicação e construção de novos recursos para a equipe suportar novos membros. Logo, a curto prazo esse investimento não tem um retorno. Também existem tarefas que não podem ser dividias, portanto adicionar mais pessoas não vai fazer ela ser concluida mais rápido. 
 "Nove mulheres não podem parir uma criança em um mês" e "Dois pilotos não fazem o carro ir mais rápido" são frases relacionadas a Lei de Brooke, principalmente porque algumas tarefas nao podem ser divididas.
 "Nove mulheres não podem parir uma criança em um mês" e "Dois pilotos não fazem o carro ir mais rápido" são frases relacionadas a Lei de Brooks, principalmente porque algumas tarefas não podem ser divididas.
 Esse é um tema central do livro '[The Mythical Man Month](#lista-de-livros)'.
@@ -146,7 +144,7 @@ Veja também:
 [Lei de Conway na wikipedia](https://en.wikipedia.org/wiki/Conway%27s_law)
-Essa lei sugere que limites técnicos de um sistema refletirão na estrutura da organização. Se uma organização é estruturada em pequenos setores, desconexas unidades, o sofware que ela produz sera assim também. Se uma organização é construida de forma vertical, em torno de funcionalidades e serviços, terá reflexo disso dentro do sistema.
+Essa lei sugere que limites técnicos de um sistema refletirão na estrutura da organização. Se uma organização é estruturada em pequenos setores, desconexas unidades, o software que ela produz sera assim também. Se uma organização é construída de forma vertical, em torno de funcionalidades e serviços, terá reflexo disso dentro do sistema.
 Veja também:
@@ -168,11 +166,11 @@ Veja também:
 [Número de Dunbar na Wikipedia](https://en.wikipedia.org/wiki/Dunbar%27s_number)
-Dunbar propós que humanos só conseguem manter de forma confortável, 150 relacionamentos estáveis. Esse número está mais em um contexto social, "o número de pessoas que você não se sentiria sem graça para se juntar em uma bebiba se esbarrase com ela em um bar". Esse número geralmente está entra 100 e 250.
+Dunbar propôs que humanos só conseguem manter de forma confortável, 150 relacionamentos estáveis. Esse número está mais em um contexto social, "o número de pessoas que você não se sentiria sem graça para se juntar em uma bebida se esbarrasse com ela em um bar". Esse número geralmente está entra 100 e 250.
-Esse número é uma sugestão cognitiva limite para o número de pessoass para qual consegue-se manter uma relação social estável.
+Esse número é uma sugestão cognitiva limite para o número de pessoas para qual consegue-se manter uma relação social estável.
-Como uma relação entre pessoas, manter uma relação entre desenvolvedor e codigo requer esforço. É necessário usar politicas, padrões e procedimentos para encarar projetos complicados ou qualquer adversidade possível nesse tipo de relação. Número de Dunbar é importante em vários aspectos, não somente quando a empresa está em crescimento, mas também ao definir o escopo para os esforços da equipe ou decidir quando u msistema deve investir em ferramentas para axuliar na sobrecarga da logística. Colocando em contexto de engrenharia, é o número de projetos para os quais você se sentiria confiante para ingresssar em uma rotação de plantão de suporte.
+Como uma relação entre pessoas, manter uma relação entre desenvolvedor e código requer esforço. É necessário usar politicas, padrões e procedimentos para encarar projetos complicados ou qualquer adversidade possível nesse tipo de relação. Número de Dunbar é importante em vários aspectos, não somente quando a empresa está em crescimento, mas também ao definir o escopo para os esforços da equipe ou decidir quando um sistema deve investir em ferramentas para auxiliar na sobrecarga da logística. Colocando em contexto de engrenharia, é o número de projetos para os quais você se sentiria confiante para ingressar em uma rotação de plantão de suporte.
 Veja também:
@@ -207,7 +205,7 @@ Também referenciada como:
 >
 > _Marilyn Strathern_
-A lei diz que otimizações orientadas por medidas podem levar à uma desvalorização do próprio resultado da medição. O conjunto de medidas excessivamente seletivo ([KPIs](https://en.wikipedia.org/wiki/Performance_indicator)) aplicado cegamenta a um processo resulta em um efeito distorcido. As pessoas tentem a otimizar localmente "jogando com" o sistema para satisfazer métricas específicas ao invés de prestar atenção ao resultado holístico de suas ações.
+A lei diz que otimizações orientadas por medidas podem levar à uma desvalorização do próprio resultado da medição. O conjunto de medidas excessivamente seletivo ([KPIs](https://en.wikipedia.org/wiki/Performance_indicator)) aplicado cegamente a um processo resulta em um efeito distorcido. As pessoas tentem a otimizar localmente "jogando com" o sistema para satisfazer métricas específicas ao invés de prestar atenção ao resultado holístico de suas ações.
 Exemplos do mundo real:
 - Testes sem `assertions` atendem à cobertura de código esperada, apesar do objetivo da métrica era criar software bem testado
@@ -225,7 +223,7 @@ Veja também:
 >
 > Robert J. Hanlon
-Esse principio sugeste que ações negativas não são sempre resultado de má vontade. Em vez disso, é mais provável que o resultado negativo seja atribuido à ações que não foram totalmente entendidas.
+Esse principio sugere que ações negativas não são sempre resultado de má vontade. Em vez disso, é mais provável que o resultado negativo seja atribuído à ações que não foram totalmente entendidas.
 ### Lei de Hofstadter
@@ -248,7 +246,7 @@ This is from the book '[Gödel, Escher, Bach: An Eternal Golden Braid](#lista-de
 >
 > _([Patrick Hutber](https://en.wikipedia.org/wiki/Patrick_Hutber))_
-Essa lei sugere que melhorias em um sistema irão levar à deterioração em outras partes, ou ela ocultarão outras deteriorações, levando a uma degradação do estado atual do sistema.
+Essa lei sugere que melhorias em um sistema irão levar à deterioração em outras partes, ou elas ocultarão outras deteriorações, levando a uma degradação do estado atual do sistema.
 Por exemplo, a diminuição na latência da resposta para um `end-point` particular pode causar um aumento na taxa de transferência e na capacidade ao longo de um fluxo de solicitação, afetando um subsistema totalmente diferente.
@@ -266,7 +264,7 @@ O Ciclo Hype é uma representação visual da empolgação e desenvolvimento da
 *(Image Reference: By Jeremykemp at English Wikipedia, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=10547051)*
-Em curto prazo, o ciclo sugere que acontece uma explosão de empolgação a cerca de uma nova tecnologia e seu impacto em potencial. Equipes geralmente entram juntas nessas tecnlogias de forma rápida e em alguns casos ficam desapontados com os resutados. Uma das possíveis causas para isso é o fato da tecnologia em questão não ser madura o suficiente, ou aplicações do mundo real que não estão totalmente prontas. Depois de um certo tempo, a capacidade da tecnologia aumenta e oportunidades práticas para uso dela aumentam, as equipes finalmente podem ser produtivas. A citação de Amara resume isso de forma sucinta - "Nós tendemos a superestimar os efeitos da tecnologia em curto prazo e subestimar os efeitos a longo prazo".
+Em curto prazo, o ciclo sugere que acontece uma explosão de empolgação a cerca de uma nova tecnologia e seu impacto em potencial. Equipes geralmente entram juntas nessas tecnologias de forma rápida e em alguns casos ficam desapontadas com os resultados. Uma das possíveis causas para isso é o fato da tecnologia em questão não ser madura o suficiente, ou aplicações do mundo real que não estão totalmente prontas. Depois de um certo tempo, a capacidade da tecnologia aumenta e oportunidades práticas para uso dela aumentam, as equipes finalmente podem ser produtivas. A citação de Amara resume isso de forma sucinta - "Nós tendemos a superestimar os efeitos da tecnologia em curto prazo e subestimar os efeitos a longo prazo".
 ### Lei de Hyrum (Lei das Interfaces Implícitas)
@@ -280,7 +278,7 @@ Em curto prazo, o ciclo sugere que acontece uma explosão de empolgação a cerc
 >
 > Hyrum Wright
-A lei de Hyrum sugere que quando você tem um número muito grande de consumidores de uma API, todos os comportamentos dessa API (mesmo aqueles que não estão definidos como parte de um contrato público) eventualmente irão dependender de outra parte do sistema, ou outra API. Um exemplo trivial pode ser elementos não funcionais, como o tempo de resposta de uma API. Um exemplo mais sutil pode ser os consumidores que estão confiando em aplicar um regex a uma mensagem de erro para determinar o _tipo_ de erro de uma API. Mesmo que o contrato público da API não especifique nada sobre o conteúdo da mensagem, indicando que os usuários devem usar um código de erro associado, alguns usuários podem usar a mensagem e alterar a mensagem essencialmente interrompe a API para esses usuários.
+A lei de Hyrum sugere que quando você tem um número muito grande de consumidores de uma API, todos os comportamentos dessa API (mesmo aqueles que não estão definidos como parte de um contrato público) eventualmente irão depender de outra parte do sistema, ou outra API. Um exemplo trivial pode ser elementos não funcionais, como o tempo de resposta de uma API. Um exemplo mais sutil pode ser os consumidores que estão confiando em aplicar um regex a uma mensagem de erro para determinar o _tipo_ de erro de uma API. Mesmo que o contrato público da API não especifique nada sobre o conteúdo da mensagem, indicando que os usuários devem usar um código de erro associado, alguns usuários podem usar a mensagem e alterar a mensagem essencialmente interrompe a API para esses usuários.
 Veja Também:
@@ -289,11 +287,11 @@ Veja Também:
 ### Lei de Kernighan
-> A depuração é duplamente mais difícil do que escrever o código em primeiro lugar. Portanto, se você escrever o código da maneira mais inteligente possível, por definição, você não é inteligente o sufiencte para depurá-lo.
+> A depuração é duplamente mais difícil do que escrever o código em primeiro lugar. Portanto, se você escrever o código da maneira mais inteligente possível, por definição, você não é inteligente o suficiente para depurá-lo.
 >
 > Brian Kernighan
-A Lei de Kerningham é nomeada por [Brian Kernighan](https://en.wikipedia.org/wiki/Brian_Kernighan) e devivada de uma citação de Kerningham no livro [The Elements of Programming Style](https://en.wikipedia.org/wiki/The_Elements_of_Programming_Style):
+A Lei de Kerningham é nomeada por [Brian Kernighan](https://en.wikipedia.org/wiki/Brian_Kernighan) e derivada de uma citação de Kerningham no livro [The Elements of Programming Style](https://en.wikipedia.org/wiki/The_Elements_of_Programming_Style):
 > Todo mundo sabe que depurar é duplamente mais difícil do que programar em primeiro lugar. Então, se você é o mais inteligente possível quando escreve, como você conseguirá depurar o código?
@@ -320,7 +318,7 @@ Veja também:
 ### Lei de Moore
-[Lei de Moore na wikipedia](https://en.wikipedia.org/wiki/Moore%27s_law)
+[Lei de Moore na Wikipedia](https://en.wikipedia.org/wiki/Moore%27s_law)
 > O número de transistores dentro de um circuito integrado dobra a cada 2 anos, aproximadamente.
@@ -343,7 +341,7 @@ Isso é um ditado comum entre desenvolvedores. Muitas vezes o inesperado ocorre
 > Se algo pode dar errado, dará errado, no pior momento possível.
-Essas 'leis' são geralmente utilizadas em um sentido cômico. Contudo, fenômenos como [_Confirmation Bias_](#TODO) e [_Selection Bias_](#TODO) podem pevar as pessoas a enfatizarem demais essas leis (na maioria das vezes quando as coisas funcionam, elas passam desapercebidas, as falhas são mais perceptíveis e atraem mais discussões).
+Essas 'leis' são geralmente utilizadas em um sentido cômico. Contudo, fenômenos como [_Confirmation Bias_](#TODO) e [_Selection Bias_](#TODO) podem levar as pessoas a enfatizarem demais essas leis (na maioria das vezes quando as coisas funcionam, elas passam desapercebidas, as falhas são mais perceptíveis e atraem mais discussões).
 Veja também:
@@ -375,7 +373,7 @@ Exemplo:
 >O trabalho se expande de modo a preencher o tempo disponível para a sua realização.
-A lei de Parkinson foi publicada por Cyril Northcote Parkinson num artigo na revista The Economist em 1955, sendo depois reimpresso com outros artigos no livro Parkinson's Law: The Pursuit of Progress [A lei de Parkinson: a busca do progresso].Em seu contexto original, essa Lei foi baseada em estudos de burocracia. E pode ser pessimisticamente aplicado a desenvolvimento de software, a teoria diz que equipes serão ineficientes até os prazos finais, quando irão dar o máximo até o prazo final.
+A lei de Parkinson foi publicada por Cyril Northcote Parkinson num artigo na revista The Economist em 1955, sendo depois reimpresso com outros artigos no livro Parkinson's Law: The Pursuit of Progress [A lei de Parkinson: a busca do progresso]. Em seu contexto original, essa Lei foi baseada em estudos de burocracia. E pode ser pessimisticamente aplicado a desenvolvimento de software, a teoria diz que equipes serão ineficientes até os prazos finais, quando irão dar o máximo até o prazo final.
 ### Efeito de Otimização Prematura
@@ -385,7 +383,7 @@ A lei de Parkinson foi publicada por Cyril Northcote Parkinson num artigo na rev
 >
 > [(Donald Knuth)](https://twitter.com/realdonaldknuth?lang=en)
-No artigo de Donald Knuth, [Structured Programming With Go To Statements](http://wiki.c2.com/?StructuredProgrammingWithGoToStatements), ele escreve: "Programadores perdem grandes quantidades de tempo pensando ou se preocupando com a velocidade de partes não críticas de seus programas, e essas tentativas de eficiência possuem um forte impacto negativo quando depuração e manutenção são consideradas. Nós devemos esquecer essas pequenas eficiências, cerca de 97% das vezes: **otimização prematura é a raiz de todo o mal.** No entando, não devemos perder a oportunidade nesses 3% críticos".
+No artigo de Donald Knuth, [Structured Programming With Go To Statements](http://wiki.c2.com/?StructuredProgrammingWithGoToStatements), ele escreve: "Programadores perdem grandes quantidades de tempo pensando ou se preocupando com a velocidade de partes não críticas de seus programas, e essas tentativas de eficiência possuem um forte impacto negativo quando depuração e manutenção são consideradas. Nós devemos esquecer essas pequenas eficiências, cerca de 97% das vezes: **otimização prematura é a raiz de todo o mal.** No entanto, não devemos perder a oportunidade nesses 3% críticos".
 Contudo, _Otimização Prematura_ pode ser definida (em termos menos carregados) como otimizar antes de saber o que precisamos.
@@ -399,7 +397,9 @@ A Lei de Putt é frequentemente seguida pelo Corolário de Putt:
 > Cada hierarquia técnica, no tempo, desenvolve uma inversão de competência.
-Estas declarações sugerem que devido a vários critérios de seleção e tendências na forma como grupos se organizam, haverá um número de pessoas qualificadas nos níveis de trabalho de organizações técnicas, e um número de pessoas em funções gerenciais que não estão cientes das complexidades e desafios do trabalho que estão gerenciando. Isso pode ser devido a fenômenos como  (#em-progresso)
+Estas declarações sugerem que devido a vários critérios de seleção e tendências na forma como grupos se organizam, haverá um número de pessoas qualificadas nos níveis de trabalho de organizações técnicas, e um número de pessoas em funções gerenciais que não estão cientes das complexidades e desafios do trabalho que estão gerenciando. Isso pode ser devido a fenômenos como o [Princípio de Peter](#o-princípio-de-peter) ou o [Princípio Dilbert](#o-princípio-dilbert).
 No entanto, deve-se enfatizar que leis como essa são vastas generalizações e podem ser aplicáveis a alguns tipos de organizações, mas não a outras.
 Veja também:
@@ -422,7 +422,7 @@ Veja também:
 [A lei da Conservação de Complexidade na wikipedia](https://en.wikipedia.org/wiki/Law_of_conservation_of_complexity)
-Essa lei sugere que em todos sitemas sempre vai existir uma quantidade de complexidade que não pode ser reduzida.
+Essa lei sugere que em todos os sistemas sempre vai existir uma quantidade de complexidade que não pode ser reduzida.
 Alguma complexidade em um sistema é "inadvertida". É uma consequência da estrutura deficiente, erros ou apenas má modelagem de um problema a ser resolvido. A complexidade inadvertida pode ser reduzida (ou eliminada). No entanto, alguma complexidade é "intrínseca" como consequência da complexidade inerente ao problema a ser resolvido. Essa complexidade pode ser movida, mas não eliminada.
@@ -436,9 +436,9 @@ Um elemento interessante para essa lei é a sugestão de que, mesmo simplificand
 Essa lei afirma que abstrações, as quais são geralmente utilizadas na computação para simplificar um trabalho com sistemas complexos, em certas situações irão 'vazar' elementos do sistema subjacente, fazendo com que a abstração se comporte de maneira inesperada.
-Um exemplo disso pode ser carregar um arquivo e ler o seu conteúdo. As APIs do sistema de arquivo são abstrações do kernel de nível inferior, que são uma abstração dos processadores físicos relacionados à alteração de dados no disco rígido (ou na memória flash em SSD). Na maioria dos casos, a abstração de tratar um arquivo como um fluxo de dados binários funcionará. Contudo, para um disco rígido, a leitura sequencial dos dados será significamente mais rápida que o acesso aleatório (devido ao aumento da sobrecarga de falhas na página), mas para um disco SSD, essa sobrecarga não estará presente. Os detalhes subjacentes precisarão ser entendidos para lidar com esse caso (por exemplo, os arquivos índices de uma base de dados são estruturados para reduzir a sobrecarga do acesso aleatório), a abstração 'vaza' detalhes de implementação os quais o desenvolvedor precisa estar ciente.
+Um exemplo disso pode ser carregar um arquivo e ler o seu conteúdo. As APIs do sistema de arquivo são abstrações do kernel de nível inferior, que são uma abstração dos processadores físicos relacionados à alteração de dados no disco rígido (ou na memória flash em SSD). Na maioria dos casos, a abstração de tratar um arquivo como um fluxo de dados binários funcionará. Contudo, para um disco rígido, a leitura sequencial dos dados será significantemente mais rápida que o acesso aleatório (devido ao aumento da sobrecarga de falhas na página), mas para um disco SSD, essa sobrecarga não estará presente. Os detalhes subjacentes precisarão ser entendidos para lidar com esse caso (por exemplo, os arquivos índices de uma base de dados são estruturados para reduzir a sobrecarga do acesso aleatório), a abstração 'vaza' detalhes de implementação os quais o desenvolvedor precisa estar ciente.
-O exemplo acima pode se tormar mais complexo quando _mais_ abstrações são introduzidas. O sistema operacional Linux permite que os arquivos sejam acessados por rede mas representados localmente como arquivos 'normais'. Essa abstração será 'vazada' se houverem falhas de rede. Se um desenvolvedor tratar esses arquivos como 'normais', sem considerar o fato de que eles podem estar sujeitos à latência e falhas na rede, as soluções serão incorretas.
+O exemplo acima pode se tornar mais complexo quando _mais_ abstrações são introduzidas. O sistema operacional Linux permite que os arquivos sejam acessados por rede mas representados localmente como arquivos 'normais'. Essa abstração será 'vazada' se houverem falhas de rede. Se um desenvolvedor tratar esses arquivos como 'normais', sem considerar o fato de que eles podem estar sujeitos à latência e falhas na rede, as soluções serão incorretas.
 Veja também:
@@ -446,7 +446,7 @@ Veja também:
 Exemplos do mundo real:
- [Photoshop Slow Startup](https://forums.adobe.com/thread/376152) - um problema que eu encontrei no passado. O Photoshop demorava para abrir, às vezes levando alguns minutos. Parecia que o problema era que, ao iniciar, o programa lia algumas informações sobre a impressora padrão. No entando, se essa impressora fosse uma impressora de rede, isso demoraria tempo extremamente longo. A _abstração_ de uma impressora de rede ser mostrada ao sistema como uma impressora local causou um problema para usuários em situação de baixa conectividade. 
+- [Photoshop Slow Startup](https://forums.adobe.com/thread/376152) - um problema que eu encontrei no passado. O Photoshop demorava para abrir, às vezes levando alguns minutos. Parecia que o problema era que, ao iniciar, o programa lia algumas informações sobre a impressora padrão. No entanto, se essa impressora fosse uma impressora de rede, isso demoraria tempo extremamente longo. A _abstração_ de uma impressora de rede ser mostrada ao sistema como uma impressora local causou um problema para usuários em situação de baixa conectividade.
 ### A Lei da Trivialidade
@@ -454,7 +454,7 @@ Exemplos do mundo real:
 Essa lei sugere que grupos irão dar maior atenção para problemas triviais ou cosméticos, do que para os problemas sérios e substanciais.
-O exemplo fictício comum utilizado é o de um comitê aprovando planos para uma usina nuclear, que passam maior tempo discutindo a estrutura do bicicletário ao invés do design da própria usina que é muito mais importante. Pode ser difícil fornecer informações valiosas em discussões sobre tópicos muito grandes e complexos sem um alto grau de conhecimento ou preparação no assunto. No entando, as pessoas querem ser vistas contribuindo com informações importantes. Daí uma tendência de concentrar muito tempo em pequenos detalhes, que podem ser facilmente explicados, mas necessariamente não são de importância particular.
+O exemplo fictício comum utilizado é o de um comitê aprovando planos para uma usina nuclear, que passam maior tempo discutindo a estrutura do bicicletário ao invés do design da própria usina que é muito mais importante. Pode ser difícil fornecer informações valiosas em discussões sobre tópicos muito grandes e complexos sem um alto grau de conhecimento ou preparação no assunto. No entanto, as pessoas querem ser vistas contribuindo com informações importantes. Daí uma tendência de concentrar muito tempo em pequenos detalhes, que podem ser facilmente explicados, mas necessariamente não são de importância particular.
 O exemplo fictício acima levou ao uso do termo _'Bike Shedding'_ como uma expressão por gastar tempo em detalhes triviais.
@@ -473,14 +473,14 @@ Práticas modernas como a 'Arquitetura de Microsserviços' podem ser pensadas co
 O Modelo Spotify é uma abordagem para a organização de equipes que foi popularizado pelo 'Spotify'. Neste modelo, times são organizados por funcionalidades, não por tecnologias.
-O Modelo Spotify também popularizou o conteido de Tribos, Guildas, Capítulos, que são outros componentes de sua estrutura organizacional.
+O Modelo Spotify também popularizou o conceito de Tribos, Guildas, Capítulos, que são outros componentes de sua estrutura organizacional.
 ### Lei de Wadler
 [Wadler's Law on wiki.haskell.org](https://wiki.haskell.org/Wadler's_Law)
 > Em qualquer design de linguagem, o tempo total gasto discutindo a uma funcionalidade nessa lista é proporcional a dois elevados à potência de sua posição.
-> 
+>
 > 0. Semântica
 > 1. Sintaxe
 > 2. Sintaxe léxica
@@ -488,7 +488,7 @@ O Modelo Spotify também popularizou o conteido de Tribos, Guildas, Capítulos,
 >
 > (Em resumo, para cada hora gasta em semântica, 8 horas serão gastas na sintaxe de comentários)
-Semelhante à [Lei da Trivialidade](#a-lei-da-trivialidade), a Lei de Wadler afirma que quando projetamos uma linguagem, o tempo gasto em estruturas é desproporcionalmente maior do que a imporância dessas funcionalidades.
+Semelhante à [Lei da Trivialidade](#a-lei-da-trivialidade), a Lei de Wadler afirma que quando projetamos uma linguagem, o tempo gasto em estruturas é desproporcionalmente maior do que a importância dessas funcionalidades.
 Veja também:
@@ -504,7 +504,7 @@ Veja também:
 >
 > _Wil Wheaton_
-Cunhada por Wil Wheaton (Star Trek: The Next Generation, The Big Bang Theory), esta lei simples, concisa e poderosa visa aumentar a harmonia e o respeito dentro de uma organização profissional. Ela pode ser aplicada ao conversar com colegas de trabalho, ao efetuar code reviews, contrariar outros ponto de vista, criticar, e, em linhas gerais, na maioria das interações que os humanos mantém entre si.
+Cunhada por Wil Wheaton (Star Trek: The Next Generation, The Big Bang Theory), esta lei simples, concisa e poderosa visa aumentar a harmonia e o respeito dentro de uma organização profissional. Ela pode ser aplicada ao conversar com colegas de trabalho, ao efetuar code reviews, contrariar outros pontos de vista, criticar, e, em linhas gerais, na maioria das interações que os humanos mantém entre si.
 ## Princípios
@@ -539,7 +539,7 @@ O Princípio de Pareto sugere que em alguns casos, a maioria dos resultados vem
 - 20% dos bugs causam 80% das quebras
 - 20% das funcionalidades causam 80% da utilização
-Nos anos 40 o engenheiro americano-romeno Dr. Joseph Juran, reconhecido como pai do controle de qualidade, [começou a aplicar o Princípio de Pareto a questões de qualidade]((https://en.wikipedia.org/wiki/Joseph_M._Juran)).
+Nos anos 40 o engenheiro americano-romeno Dr. Joseph Juran, reconhecido como pai do controle de qualidade, [começou a aplicar o Princípio de Pareto a questões de qualidade](https://en.wikipedia.org/wiki/Joseph_M._Juran).
 Este princípio é também conhecido como: A Regra do 80/20, A Lei dos Poucos Vitais e O Princípio de Escassez do Fator.
@@ -555,7 +555,7 @@ Exemplos do mundo real:
 >
 > _Laurence J. Peter_
-Um conceito de gerenciamento desenvolvido por Laurence J. Peter, o Princípio de Peter observa que as pessoas que são boas em seu emprego são promovidas até um nível onde elas não são mais bem-sucedidas (o "nível de incompetência"). Neste ponto, à medida em que são mais seniores, é menos provável que elas sejam removidas da organização (a não ser que elas performem de maneira horrível) e irão continuar a permanecer em uma função na qual possuem poucas habilidades intrínsecas, pois as habilidades originais que as fizeram bem-sucedidas não são necessariamente as mesmas que o novo cargo exige.  
+Um conceito de gerenciamento desenvolvido por Laurence J. Peter, o Princípio de Peter observa que as pessoas que são boas em seu emprego são promovidas até um nível onde elas não são mais bem-sucedidas (o "nível de incompetência"). Neste ponto, à medida em que são mais seniores, é menos provável que elas sejam removidas da organização (a não ser que elas performem de maneira horrível) e irão continuar a permanecer em uma função na qual possuem poucas habilidades intrínsecas, pois as habilidades originais que as fizeram bem-sucedidas não são necessariamente as mesmas que o novo cargo exige.
 Isso é de interesse particular para engenheiros - que inicialmente começam em funções técnicas mas tem uma carreira que leva ao _gerenciamento_ de outros engenheiros - o que requer um conjunto de habilidades fundamentalmente diferente.
@@ -594,7 +594,7 @@ Esses são os princípios-chave da [Programação Orientada a Objetos](#todo). O
 O primeiro dos princípios '[SOLID](#solid)'. Esse princípio sugere que módulos ou classes devem fazer apenas uma única coisa. Em termos mais práticos, isso significa que uma mudança simples a uma funcionalidade de um programa deve exigir uma mudança em apenas um componente. Por exemplo, mudar como uma senha é validada por complexidade deve exigir uma mudança em apenas uma parte do programa.
-Teoricamente, isso deve tornar o código mais robusto, e fácil de ser mudado. Sabendo que um componente que está sendo alterado possui apenas uma responsabilidade siginfica que o _teste_ deverá ser mais fácil. Usando o exemplo anterior, trocar a complexidade do componente de senha deve afetar apenas as funcionalidades que são relacionadas com a complexidade de senha. Pode ser muito mais difícil argumentar sobre o impacto de uma alteração em um componente que tem muitas responsabilidades.
+Teoricamente, isso deve tornar o código mais robusto, e fácil de ser mudado. Sabendo que um componente que está sendo alterado possui apenas uma responsabilidade significa que o _teste_ deverá ser mais fácil. Usando o exemplo anterior, trocar a complexidade do componente de senha deve afetar apenas as funcionalidades que são relacionadas com a complexidade de senha. Pode ser muito mais difícil argumentar sobre o impacto de uma alteração em um componente que tem muitas responsabilidades.
 Veja também:
@@ -607,11 +607,11 @@ Veja também:
 > Entidades devem estar aberta para extensão e fechadas para modificação
-O segundo princípio do '[SOLID](#solid)'. Esse princípio afirma que entidades (que podem ser classes, módulos, funções e afins) poderão ter seu comportamento _extendido_, mas que o comportamento já existente não poderá ser alterado.
+O segundo princípio do '[SOLID](#solid)'. Esse princípio afirma que entidades (que podem ser classes, módulos, funções e afins) poderão ter seu comportamento _estendido_, mas que o comportamento já existente não poderá ser alterado.
-Em um exemplo hipotético, imagine um módulo que converte um documento Markdown para HTML. Se o módulo pode ser extendido para aceitar uma nova funcionalidade do markdown, sem modificar a parte interna desse módulo, quer dizer que ele está aberto para extensões. Se o módulo _não_ pode ser modificado por um consumidor, de modo que as funcionalidades existentes do markdown sejam tratadas, então ele estará _fechado_ para modificações.
+Em um exemplo hipotético, imagine um módulo que converte um documento Markdown para HTML. Se o módulo pode ser estendido para aceitar uma nova funcionalidade do markdown, sem modificar a parte interna desse módulo, quer dizer que ele está aberto para extensões. Se o módulo _não_ pode ser modificado por um consumidor, de modo que as funcionalidades existentes do markdown sejam tratadas, então ele estará _fechado_ para modificações.
-Esse princípio tem uma relevância particular na orientação a objetos, onde nós projetamos objetos para serem facilmente extendidos, mas evitamos projetar objetos onde o comportamento existente pode ser alterado de maneiras inesperadas.
+Esse princípio tem uma relevância particular na orientação a objetos, onde nós projetamos objetos para serem facilmente estendidos, mas evitamos projetar objetos onde o comportamento existente pode ser alterado de maneiras inesperadas.
 Veja também:
@@ -628,7 +628,7 @@ O terceiro princípio '[SOLID](#solid)'. O princípio afirma que se um component
 Como um exemplo, imagine que temos um método que lê um documento XML de uma estrutura que representa um arquivo. Se o método utiliza a base de um tipo 'arquivo', então qualquer coisa que seja derivada de 'arquivo' poderá ser utilizada na função. Se 'arquivo' suporta busca recursiva, e o interpretador de XML utiliza essa função, mas o tipo derivado 'arquivo de rede' falha quando tenta uma busca recursiva, então o tipo 'arquivo de rede' estaria violando o princípio.
-Esse princípio tem uma relevância particular na orientação a objetos, onde as hierarquias de tipos precisam ser modeladas com cautela para envitar confusão entre usuaríos do sistema.
+Esse princípio tem uma relevância particular na orientação a objetos, onde as hierarquias de tipos precisam ser modeladas com cautela para evitar confusão entre usuários do sistema.
 Veja também:
@@ -643,9 +643,9 @@ Veja também:
 O quarto princípio do '[SOLID](#solid)'. Esse princípio afirma que os consumidores de um componente não devem depender de funções daquele componente, as quais eles atualmente não usem.
-Como um exemplo, imagine que um método lê um documento XML de uma estutura que representa um arquivo. O método apenas precisa ler os bytes, ir para frente ou para trás no arquivo. Se esse método precisar ser atualizado porque um recurso não relacionado da estrutura do arquivo é alterado (como uma atualização no modelo de permissões utilizado para representar a segurança do arquivo), o princípio foi invalidado. 
+Como um exemplo, imagine que um método lê um documento XML de uma estrutura que representa um arquivo. O método apenas precisa ler os bytes, ir para frente ou para trás no arquivo. Se esse método precisar ser atualizado porque um recurso não relacionado da estrutura do arquivo é alterado (como uma atualização no modelo de permissões utilizado para representar a segurança do arquivo), o princípio foi invalidado.
-Esse princípio tem uma relevância particular na orientação a objetos, onde interfaces, hierarquias e tipos abstratos são utilizados para [minimizar o acomplamento](#todo) entre componentes diferentes. [Duck typing]() é uma metodologia que enforça esse princípio, eliminando interfaces explícitas.
+Esse princípio tem uma relevância particular na orientação a objetos, onde interfaces, hierarquias e tipos abstratos são utilizados para [minimizar o acoplamento](#todo) entre componentes diferentes. [Duck typing]() é uma metodologia que impõe esse princípio, eliminando interfaces explícitas.
 Veja também:
@@ -660,7 +660,7 @@ Veja também:
 > Módulos de alto nível não devem ser dependentes de implementações de baixo nível.
-O quinto conceito do '[SOLID](#solid)'. Esse princípio afirma que componentes 
+O quinto conceito do '[SOLID](#solid)'. Esse princípio afirma que componentes
 Como um exemplo, imagine que temos um programa que lê os metadados de um website. Nós devemos assumir que o componente principal precisa conhecer um componente que irá baixar a página, depois um outro componente que irá ler os metadados. Se fôssemos levar a inversão de dependências em conta, o componente principal deveria depender apenas de um componente abstrato que pode buscar pelos bytes, e depois outro componente abstrato que irá ler os metadados de um fluxo de bytes. O componente principal não sabe nada sobre TCP/IP, HTTP, HTML, etc.
@@ -679,7 +679,7 @@ Veja também:
 > Cada pedaço de código deve possuir uma representação única, inequívoca e autoritária dentro de um sistema.
-DRY é um acrônimo para _**D**on't **R**epeat **Y**ourself_ (Não repita você mesmo). Esse princípio ajuda os desenvolvedores a reduzir a repetição de código e manter a informação em um único lugar. Foi citado em 1999 por Andrew Hunt e Dave Thomas no livro [The Pragmatic Developer](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer).
+DRY é um acrônimo para _**D**on't **R**epeat **Y**ourself_ (Não repita você mesmo). Esse princípio ajuda os desenvolvedores a reduzir a repetição de código e manter a informação em um único lugar. Foi citado em 1999 por Andrew Hunt e Dave Thomas no livro [The Pragmatic Programmer](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer).
 > O oposto de DRY seria WET (Write Everything Twice or We Enjoy Typing) - (Escreva tudo duas vezes ou Nós gostamos de digitar).
@@ -687,7 +687,7 @@ Na prática, se você tem o mesmo pedaço de informação em dois (ou mais) luga
 Veja também:
- [The Pragmatic Developer](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer)
+- [The Pragmatic Programmer](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer)
 ### O Princípio KISS
@@ -715,7 +715,7 @@ Veja também:
 Este princípio da _Extreme Programming_ (XP) sugere que os desenvolvedores apenas devem implementar funcionalidades quando elas forem necessárias, e evitar tentativas de prever o futuro e implementar uma funcionalidade que talvez seja necessária.
-Aderir a esse princípio deve reduzir a quantidade de código não utilizado em um projeto, e evitar tempo e esforço sendo disperdiçados em funcionalidades que não agregam valor.
+Aderir a esse princípio deve reduzir a quantidade de código não utilizado em um projeto, e evitar tempo e esforço sendo desperdiçados em funcionalidades que não agregam valor.
 Veja também:
@@ -783,7 +783,7 @@ Se você quer atualizar uma tradução, [abra uma pull request](https://github.c
 ## Projetos relacionados
- [Tip of the Day](https://tips.darekkay.com/html/hacker-laws-en.html) - Receba diaramente uma lei ou princípio hacker.
+- [Tip of the Day](https://tips.darekkay.com/html/hacker-laws-en.html) - Receba diariamente uma lei ou princípio hacker.
 - [Hacker Laws CLI](https://github.com/umutphp/hacker-laws-cli) - Liste e visualize as leis de maneira aleatória no seu terminal!
 ## Contribuindo
--- a/translations/vi.md
+++ b/translations/vi.md
Author	SHA1	Message	Date
Dave Kerr	1225053274	Merge pull request #445 from dwmkerr/release-please--branches--main chore(main): release 0.3.0	2025-03-31 09:40:38 +01:00
github-actions[bot]	f65bb28e58	chore(main): release 0.3.0	2025-03-31 08:40:21 +00:00
Dave Kerr	dcdcfdfc25	feat: add Koomey's Law Adds Koomey's Law, including its definition, history, and relationship to Moore's Law and Dennard Scaling.	2025-03-31 09:39:34 +01:00
Dave Kerr	7cd48102cb	Merge pull request #443 from dwmkerr/release-please--branches--main chore(main): release 0.2.1	2025-03-31 08:30:31 +01:00
github-actions[bot]	46148724e2	chore(main): release 0.2.1	2025-03-31 07:28:31 +00:00
Dave Kerr	2140429b95	fix: remove frontmatter	2025-03-31 08:27:42 +01:00
Dave Kerr	32d95692c6	Merge pull request #442 from dwmkerr/release-please--branches--main chore(main): release 0.2.0	2025-03-31 08:15:19 +01:00
github-actions[bot]	a337004e69	chore(main): release 0.2.0	2025-03-31 07:14:33 +00:00
Dave Kerr	a6ae7d8189	Merge branch 'main' of github.com:dwmkerr/hacker-laws	2025-03-31 08:13:36 +01:00
Dave Kerr	59465379dd	Merge branch 'main' of github.com:dwmkerr/hacker-laws	2025-03-31 08:13:28 +01:00
Dave Kerr	f5cf372f03	Merge branch 'main' of github.com:dwmkerr/hacker-laws	2025-03-31 08:10:38 +01:00
Dave Kerr	c1c7f013e7	build: testing new build	2025-03-31 08:10:24 +01:00
Dave Kerr	5690da764c	Update README.md	2025-03-30 21:04:35 +01:00
Dave Kerr	d6a7d4eac3	Merge pull request #439 from dwmkerr/staging docs: the bitter lesson	2025-03-28 10:56:28 +00:00
Dave Kerr	8e99eb1643	docs: cleanup 'the bitter lesson'	2025-03-28 10:29:47 +00:00
Dave Kerr	c535f12797	Merge pull request #418 from Ghost---Shadow/the-bitter-lesson The Bitter Lesson	2025-03-28 10:04:26 +00:00
Dave Kerr	0ed571cae0	Merge branch 'staging' into the-bitter-lesson	2025-03-28 10:03:58 +00:00
Dave Kerr	d83d439df8	fix: correct formatting around quote	2025-03-17 15:35:53 +00:00
Dave Kerr	6f9b1e3334	fix: correct facebook link on website	2025-03-17 10:53:23 +00:00
Dave Kerr	a35ebb9c2e	Merge branch 'main' of github.com:caretak3r/hacker-laws into caretak3r-main	2025-03-17 10:39:49 +00:00
Dave Kerr	bbb716064f	chore: delete stale file	2025-03-17 10:29:15 +00:00
Dave Kerr	39506a03e6	docs: fix link	2025-03-14 15:50:27 +00:00
Dave Kerr	0de2035d52	docs: cleanup heading	2025-03-14 11:02:11 +00:00
Dave Kerr	3075d4c9b6	Merge pull request #437 from dwmkerr/chore/cleanup chore: cleanup	2025-03-11 11:01:15 +00:00
Dave Kerr	3f730a8538	fix	2025-03-11 11:00:46 +00:00
Dave Kerr	4d795efb0c	fix	2025-03-11 10:56:01 +00:00
Dave Kerr	b8cac9c4af	fix	2025-03-11 10:51:56 +00:00
Dave Kerr	558f24ad63	fix	2025-03-11 10:47:35 +00:00
Dave Kerr	63adb0a350	test	2025-03-11 10:33:48 +00:00
Dave Kerr	dd36c58ef4	fix button	2025-03-11 10:32:48 +00:00
Dave Kerr	711327b632	fix build	2025-03-11 10:29:42 +00:00
Dave Kerr	0a56479bd9	chore: more fixes	2025-03-10 15:08:18 +00:00
Dave Kerr	692b7cca1a	fix: image paths	2025-03-10 12:34:12 +00:00
Dave Kerr	0d001f14e1	wip: looking better, almost ready for final cleanup	2025-03-10 12:28:45 +00:00
Dave Kerr	67c135701f	chore: slightly better markdown	2025-03-10 08:42:48 +00:00
Dave Kerr	8bac32a000	chore: build a little better...	2025-03-09 07:43:56 +00:00
Dave Kerr	8142ce0a9f	chore: interim	2025-03-09 07:41:31 +00:00
Dave Kerr	5e1cfb7608	chore: wip on site build	2025-03-09 07:20:19 +00:00
Dave Kerr	f810c81da2	chore: working on template	2025-03-09 06:52:35 +00:00
Dave Kerr	280ad8d45c	refactor: single heading / laws + principles	2025-03-08 21:29:27 +00:00
Dave Kerr	beb3d57a6a	feat(pages): update index.html and pages.yaml for deployment Updated the index.html to include a full HTML structure with Bootstrap and Google tag. Modified pages.yaml to deploy from 'build/pages' branch instead of the default branch.	2025-03-08 21:22:41 +00:00
Dave Kerr	decfccdfbc	Merge pull request #435 from dwmkerr/build/test-pages build: test github pages	2025-03-08 20:47:59 +00:00
Dave Kerr	6d904cd9d7	build: test github pages	2025-03-08 20:46:45 +00:00
Dave Kerr	44779074ca	feat: 90-90 rule	2025-02-26 14:17:26 +00:00
Dave Kerr	593fbcbba4	Merge pull request #391 from gurjeet/patch-1 Added Ninety–Ninety Rule	2025-02-26 12:05:25 +00:00
Dave Kerr	85112d267f	Merge branch 'staging' into patch-1	2025-02-26 12:05:00 +00:00
Dave Kerr	9ff8039a43	Merge branch 'marcosValle-patch-1'	2025-02-17 16:46:26 +00:00
Dave Kerr	b9ad4c6f99	feat: twyman's law Merge branch 'patch-1' of github.com:marcosValle/hacker-laws into marcosValle-patch-1	2025-02-17 16:45:35 +00:00
Dave Kerr	4adcc2a090	docs: fix casing	2025-02-11 12:10:19 +00:00
Dave Kerr	eb34ea9a67	docs: minor tweaks to The Ringelmann Effect	2025-02-11 12:07:48 +00:00
Dave Kerr	ae17de2b67	Merge pull request #369 from hliyan/main Added Ringelmann effect	2025-02-11 12:04:01 +00:00
Dave Kerr	31d14b7deb	Merge branch 'main' into main	2025-02-11 12:03:53 +00:00
Dave Kerr	dfc978df13	docs: clean up IPO title	2025-02-04 15:05:26 +00:00
Dave Kerr	8dc1baa919	Merge pull request #432 from dwmkerr/staging staging	2025-02-04 15:03:45 +00:00
Dave Kerr	d66d8afae4	docs: input process output	2025-02-04 15:02:21 +00:00
Dave Kerr	82af717edd	Merge pull request #304 from guettli/patch-1 Added input-processing-output	2025-02-04 14:50:31 +00:00
Dave Kerr	5fd0a88927	Merge pull request #427 from MEgooneh/patch-1 Adding Persian to Translation section	2025-01-02 07:23:41 +00:00
MEGAGON	34a7131aef	Fixing order of local and global languages	2025-01-02 02:30:40 +03:30
MEGAGON	3ce9be6081	Adding Persian to Translation section	2025-01-02 02:25:01 +03:30
Dave Kerr	01402ca31d	Merge pull request #425 from JohnbelMDev/patch-1 Update prepare-markdown-for-ebook.sh	2024-11-14 20:01:29 +11:00
Johnbel Mahautiere	69856f7ab2	Update prepare-markdown-for-ebook.sh Occurrences updata	2024-11-12 10:20:01 -05:00
Souradeep Nanda	a97981e735	Add twitter handle of author	2024-06-12 10:29:07 -05:00
Souradeep Nanda	2ce26c0576	The Bitter Lesson	2024-06-12 10:25:47 -05:00
Dave Kerr	274c008a0a	Merge pull request #415 from emmanuelbernard/patch-1 Minor French typo	2024-01-31 13:08:25 +01:00
Emmanuel Bernard	96bf4635e5	Minor French typo	2024-01-30 16:05:54 +01:00
Dave Kerr	1d0a24e547	Merge pull request #412 from akbarali1/main-1 Fix WikiWiki web	2023-08-08 20:54:35 -07:00
Akbarali	8c3de66940	Update README.md	2023-08-06 17:15:58 +05:00
Dave Kerr	5412cfbde3	Merge pull request #408 from GGuinea/navigation_polish_translation Fix navigation for polish translation.	2023-05-28 08:00:11 -07:00
Gguinea	3adb816f30	Fix navigation for polish translation.	2023-05-27 22:58:21 +02:00
Dave Kerr	2116b5cbd6	Merge pull request #407 from GGuinea/solidny_acrocym_doesn_not_exists	2023-05-26 11:09:02 -07:00
Gguinea	560ff0d9f1	SOLID acronym cannot be translated	2023-05-26 18:17:34 +02:00
Dave Kerr	c03384f370	Merge pull request #406 from tobiasbueschel/patch-1 Update small spelling mistake in .github/workflows	2023-04-05 11:31:08 -04:00
Tobias Büschel	c0ec1b5fdb	Update small spelling mistake in .github/workflows	2023-04-05 22:10:46 +08:00
Dave Kerr	4be482731b	Merge pull request #404 from dwmkerr/feat/principle-of-least-astonishment feat: principle of least astonishment	2023-03-10 11:10:41 +08:00
Dave Kerr	9bd03d8345	Update README.md	2023-03-10 16:10:24 +13:00
Dave Kerr	e4662cbc27	feat: principle of least astonishment	2023-03-10 11:06:50 +08:00
Dave Kerr	80bea4040f	Merge pull request #402 from a0m0rajab/patch-1 Add language contributor - Arabic	2023-01-09 16:19:15 +13:00
Abdurrahman Rajab	87ec516a23	Add language contributor - Arabic	2023-01-01 13:09:15 +03:00
Dave Kerr	6f177f4b46	Merge pull request #399 from gustavothecoder/fix-the-pragmatic-programmer-typo Fix typo: "The Pragmatic Developer" to "The Pragmatic Programmer"	2022-12-05 17:19:42 +13:00
Gustavo Ribeiro	97adc7dbb1	Fix typo: The Pragmatic Developer to The Pragmatic Programmer	2022-12-03 14:47:07 -03:00
Dave Kerr	80e8ccff15	Merge pull request #398 from duongductrong/patch-1 Fix misspelling from "sẫn" to "sẵn"	2022-11-21 14:38:32 +13:00
Dương Đức Trọng	7c92a91988	Fix misspelling from "sẫn" to "sẵn" The word misspelling "sẫn", The correct word is "sẵn"	2022-11-20 23:40:50 +07:00
caretak3r	5f74607c63	feat: add section for Kerckhoff's principle	2022-09-28 16:43:05 -04:00
Dave Kerr	bf758f436a	Merge pull request #376 from thomasmerz/main Added Clarke's three laws for issues/375	2022-08-12 22:14:10 +08:00
Gurjeet Singh	722d79619c	Added Ninety–Ninety Rule	2022-05-01 08:59:35 -07:00
thomasmerz	6b4572f590	Merge branch 'dwmkerr:main' into main	2022-03-14 23:02:25 +01:00
Dave Kerr	e8acd18321	Merge pull request #387 from AmaiSaeta/patch-1 Fix a typo in Japanese translation	2022-03-07 15:54:57 +08:00
Dave Kerr	10937886b7	Merge pull request #388 from hituzi-no-sippo/fix-typo-in-JP Fix typo in JP	2022-03-07 15:54:30 +08:00
hituzi no sippo	6ec4ecf503	Fix typo in JP	2022-03-05 05:02:06 +09:00
天井冴太	c42fa2179e	Fix a typo in Japanese translation	2022-03-05 01:00:47 +09:00
Marcos Valle	f9ff7d844d	Add Twyman's rule for data analysis	2022-02-13 17:39:00 +01:00
Dave Kerr	73010181d9	Merge pull request #381 from gmw/main Minor grammar and punctuation fixes	2022-02-03 12:24:58 +08:00
Magnus Wissler	e24acac797	Minor grammar and punctuation fixes	2022-02-02 15:44:22 +01:00
Dave Kerr	adc57da407	Merge pull request #377 from ohno418/translate-linus-law-in-jp Translate Linus's Law in JP	2022-01-31 06:47:22 -07:00
ohno418	743595fee3	Translate Linus's Law in JP	2022-01-31 19:08:19 +09:00
Thomas Merz	36492867d3	Added Clarke's three laws for issues/375	2022-01-20 13:35:50 +01:00
Dave Kerr	f15e6fdb0c	Merge pull request #373 from truonghoangnguyen/vietnamese add Vietnamese language	2022-01-17 22:33:14 -07:00
guen	a45f5ba757	add Vietnamese language	2022-01-17 15:37:13 +07:00
Dave Kerr	8b280bee13	Merge pull request #372 from wppoland/patch-1 update url	2022-01-16 17:53:17 -07:00
Mariusz Szatkowski	58c08b093b	update url	2022-01-15 14:06:19 +01:00
Dave Kerr	70b03354a8	docs: update table of contents	2022-01-13 13:58:16 +08:00
Dave Kerr	847757c98d	Merge pull request #348 from puremana/law-of-the-instrument Add The Law of the Instrument	2022-01-12 22:56:50 -07:00
Dave Kerr	4b6d9b969c	Merge pull request #370 from k0gen/main pl.md	2022-01-11 21:06:36 -07:00
Mariusz Kogen	db065cf9a9	images link fix	2022-01-09 00:41:55 +01:00
Mariusz Kogen	0a412ff6ae	Merge pull request #1 from k0gen/gitlocalize-17834 initial translation	2022-01-09 00:29:15 +01:00
mt-gitlocalize	c6a173755e	Translate pl.md via GitLocalize	2022-01-08 23:28:12 +00:00
Mariusz Kogen	1ca5cb9345	Translate pl.md via GitLocalize	2022-01-08 23:28:12 +00:00
Hasitha N. Liyanage	ff00ccc5c3	Update README.md	2022-01-08 20:10:16 +05:30
Hasitha N. Liyanage	269991a7cf	Update README.md	2022-01-08 19:54:27 +05:30
Hasitha N. Liyanage	0baacdbdcc	Update README.md	2022-01-08 19:52:15 +05:30
Dave Kerr	e42035062e	Merge pull request #368 from k0gen/patch-1 Polish translation 🇵🇱	2022-01-07 23:59:41 -07:00
Mariusz Kogen	26e001b5b9	Polish translation 🇵🇱	2022-01-07 15:20:33 +01:00
Dave Kerr	70970880d4	docs: update link to translator guide	2022-01-07 13:33:06 +08:00
Dave Kerr	9d2ea60824	docs: update contributing guides for translators	2022-01-07 13:31:12 +08:00
Dave Kerr	896c87f24b	Merge pull request #367 from kelvins/fix-pt-br-typos Fix typos related to the pt-BR translation	2022-01-06 01:50:11 -07:00
Kelvin S. do Prado	016c849a0f	Fix typos related to the pt-BR translation	2022-01-05 19:02:57 -03:00
Dave Kerr	ff2732697f	docs: update license year	2022-01-03 22:02:06 -07:00
Dave Kerr	e3a242e974	Merge pull request #360 from underq/patch-1 FR typo and markdown fix	2022-01-03 19:40:16 -07:00
Delangue Benjamin	813582f8a5	Update fr.md	2022-01-03 21:00:34 +01:00
Dave Kerr	fa8016129e	Merge pull request #359 from ferrarienz0/patch-1 Fix typo on "Efeito de Otimização Prematura"	2022-01-03 06:26:24 -07:00
Enzo Ferrari	31e92a434c	Fix typo on "Efeito de Otimização Prematura" No entando => No entanto	2022-01-03 09:02:24 -03:00
Dave Kerr	6635e8da51	Merge pull request #356 from maekawatoshiki/fix Fix jp typo	2022-01-03 03:29:03 -07:00
Dave Kerr	3b78ae65f0	Merge pull request #358 from pusewicz/patch-1 fix: remove superfluous 'is'	2022-01-03 03:20:03 -07:00
Piotr Usewicz	9ebebefa0e	Remove is	2022-01-03 10:14:00 +01:00
maekawatoshiki	d6cb586e80	Fix jp typo	2022-01-02 18:01:09 +09:00
Dave Kerr	0ace74c8c2	Update contributing.md	2021-11-10 09:03:43 +08:00
Dave Kerr	193118ff2d	Merge pull request #350 from Joshua-rose/feat/Darkmode-image-support Added white background to transparent images	2021-11-10 09:00:38 +08:00
Joshua-Rose	7ed9f3d6ba	Added white background to transparent images	2021-11-04 20:45:20 -05:00
puremana	619eabc9d2	Add references for quotes	2021-10-05 12:59:16 +13:00
puremana	9baa224340	Add The Law of the Instrument	2021-10-05 12:56:00 +13:00
Dave Kerr	f4e0acf525	chore: fix spelling of Chesterton	2021-04-19 14:34:54 +08:00
Dave Kerr	716aef807e	Merge pull request #342 from dwmkerr/feat/scout-rule feat: the scout rule	2021-04-19 14:25:24 +08:00
Dave Kerr	c6fccf4978	feat: the scout rule Closes #144	2021-04-19 14:24:32 +08:00
Dave Kerr	8152d6ffbb	Merge pull request #340 from Leyka/french-fix Add few corrections to French translation	2021-03-29 11:37:51 +08:00
Skander	15bc98a2fc	Add few corrections to French translation	2021-03-28 19:49:18 -04:00
Dave Kerr	96aade10ff	chore: update contributor guidelines Closes #209.	2021-02-23 17:58:46 +08:00
Dave Kerr	ddfa99d017	Merge pull request #328 from franciscogaluppo/minor-change Change in "The Two Pizza Rule"	2020-12-10 13:01:27 +08:00
Francisco Galuppo Azevedo	9bf87e4d37	Change in "The Two Pizza Rule" In "The Two Pizza Rule" there is the following statement: > This is supported by the fact that as the team size increases linearly, the links between people increases exponentially; thus the cost of coordinating and communicating also grows exponentially. But clearly the links growth is _quadratic_. The author even acknowledge that: > The number of links between people can be expressed as n(n-1)/2 where n = number of people.	2020-12-09 11:01:32 -03:00
Dave Kerr	887b9d3f20	refactor: refine the content on the dunning-kruger effect	2020-12-03 17:37:04 +08:00
Dave Kerr	34c38d87ed	feat: Dunning-Kruger Effect (#318 )	2020-12-03 16:11:39 +08:00
Akash Chandwani	7da3edd242	Added blockquote for the text from wikipedia	2020-11-19 12:05:14 +05:30
Redowan Delowar	bc041dbf62	Updated the link concerning software entropy (#322 )	2020-11-12 21:56:07 +08:00
Dave Kerr	015d25197f	feat: add ukranian language to README (#320 ) Fixes #236	2020-10-27 00:44:02 +08:00
Nicu Borta	a07ab62114	chore: Remove whitespace (#319 )	2020-10-21 09:56:43 +08:00
Akash Chandwani	2cd30d0845	Add explaination and real world example	2020-10-18 11:22:47 +05:30
Akash Chandwani	3dbc237c1f	feat: Dunning Kruger Effect	2020-10-17 23:57:42 +05:30
leocaraballo	7b341fc0d2	fix: Fix section's links (#317 ) Corrected wrong self-links for the following sections: * The Fallacies of Distributed Computing * The Pareto Principle (The 80/20 Rule)	2020-10-13 09:17:38 +08:00
Dave Kerr	d8df4603ca	docs: note on ebook creation	2020-10-01 18:16:08 +08:00
Dave Kerr	0c35525fca	chore: add ebook link	2020-10-01 18:14:58 +08:00
Dave Kerr	0bf80bf8b5	build: version number and date in e-book	2020-10-01 18:06:58 +08:00
Dave Kerr	50e2f2e6ce	build: release ebook when version tag is pushed	2020-09-30 14:32:55 +08:00
Dave Kerr	3ef9a5435e	docs: add the 'hacker laws' github action to the 'related projects'	2020-09-28 15:02:11 +08:00
Dave Kerr	c18795765f	Merge pull request #311 from i3anaan/patch-1 Remove a link that leads to some advertisement	2020-09-23 22:40:49 +08:00
Dave Kerr	93dec16bc9	feat: all models are wrong Closes #263	2020-09-23 22:02:28 +08:00
i3anaan	4dd35e129e	Remove a link that leads to some advertisement	2020-09-21 21:31:23 +02:00
Dave Kerr	b6bd7b15d0	chore: slight rewording of the shirky principle	2020-09-09 19:24:39 +08:00
Dave Kerr	46a017ac55	Merge pull request #201 from BoltzmannBrain/patch-1 Add Shirky Principle	2020-09-09 19:18:05 +08:00
Dave Kerr	abaca319be	chore: add 'the' to two pizza rule	2020-08-26 17:20:50 +08:00
Dave Kerr	5a11b27c60	chore: tweak wording on the two pizza rule	2020-08-26 17:19:22 +08:00
Dave Kerr	30008f11d5	Merge pull request #292 from puremana/two-pizza-rule Two pizza rule and adding complete graph illustration	2020-08-26 17:14:25 +08:00
Thomas Güttler	e96ae13977	Added input-processing-output	2020-08-05 17:25:13 +02:00
Dave Kerr	442a63aab5	docs: fix typo	2020-08-04 14:46:53 +08:00
Dave Kerr	c6c5d6d376	Merge pull request #299 from adambricelis/master Fixed grammar in Fitts' Law and TFoDC	2020-08-04 14:44:56 +08:00
Adam Lis	41289460fa	Fixed grammar in Fitts' Law and TFoDC	2020-07-27 21:17:50 -04:00
Dave Kerr	e10a96dc31	docs: add link to the Changelog Podcast	2020-07-20 11:38:19 +08:00
Dave Kerr	a5236c0917	Merge pull request #297 from rafedramzi/patch-1 Fix bahasa indonesia link	2020-07-18 22:12:20 +08:00
Rafed Ramzi	ea84113520	Fix bahasa indonesia link	2020-07-18 20:58:21 +07:00
puremana	2c29ebe1b6	Two pizza rule and adding complete graph illustration	2020-07-07 22:05:45 +12:00
Dave Kerr	f03d9a502e	Merge branch 'aetiusflavius-master'	2020-06-30 13:00:21 +08:00
Dave Kerr	cbbfdbb41c	Merge branch 'master' of https://github.com/aetiusflavius/hacker-laws into aetiusflavius-master	2020-06-30 12:59:47 +08:00
Dave Kerr	c21a06765b	feat: add an 'online resources' section	2020-06-30 12:51:46 +08:00
Dave Kerr	700e57f03d	chore: remove unneeded file	2020-06-24 10:41:36 +08:00
Dave Kerr	a387e3fc7e	docs: update wording for linus' law	2020-06-22 16:56:22 +08:00
Dave Kerr	491ace1341	Merge pull request #167 from WOSPM/master Linus's Law	2020-06-22 16:38:08 +08:00
Dave Kerr	639465c7d8	Merge pull request #287 from rogermarlow/book/scip Book/scip	2020-06-21 23:05:24 +08:00
Roger Marlow	5e57095aa6	Typo	2020-06-20 23:58:42 +01:00
Roger Marlow	f06b64ac38	Reading list - SICP	2020-06-20 23:56:27 +01:00
Dave Kerr	7af3c2dde8	Merge pull request #285 from dwmkerr/gitlocalize-12048 Add Hick's Law (Hick-Hyman Law) To Turkish Translation	2020-06-11 10:44:58 +08:00
Alexander Lavin	d3c4a9a3f2	Add Shirky Principle	2020-01-24 06:06:46 -08:00
Umut Isik	97d358a3d3	Update the definition of Linus law after the feedback of @dvmkerr	2019-12-11 11:45:01 +03:00
aetiusflavius	d812cd79a5	Clean up wording	2019-11-23 00:29:34 -08:00
aetiusflavius	933e7aa485	Add Chesterson's Fence	2019-11-23 00:26:29 -08:00
Umut Isik	5f4fb690c3	Leave the ToC link	2019-11-13 10:54:43 +03:00
Umut Isik	f67e1dde05	Minor update	2019-11-13 10:48:49 +03:00
Umut Isik	98fa2e4a2d	Add Linus's Law	2019-11-13 10:44:43 +03:00
`@@ -1,4 +1,4 @@`
	`Copyright (c) Dave Kerr 2020`	`Copyright (c) Dave Kerr 2021`

	`# Attribution-ShareAlike 4.0 International`	`# Attribution-ShareAlike 4.0 International`