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

chore(main): release 0.3.0

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

.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)
-* [Localisation](#localisation)
+- [Goal of the Project](#goal-of-the-project)
+- [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"

.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

.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"
+    }
+  }
+}
+
+

.github/release-please-manifest.json

@@ -0,0 +1,3 @@
+{
+  ".": "0.3.0"
+}

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

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

.github/website/build/.gitignore

@@ -0,0 +1 @@
+*

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

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

.github/website/requirements.txt

@@ -0,0 +1,4 @@
+markdown
+jinja2
+watchdog
+beautifulsoup4

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

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

.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');
+});

.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;
+}

.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

LICENSE

@@ -1,4 +1,4 @@
-Copyright (c) Dave Kerr 2020
+Copyright (c) Dave Kerr 2021
 
 # Attribution-ShareAlike 4.0 International
 

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)
-
-Like this project? Please considering [sponsoring me](https://github.com/sponsors/dwmkerr) and the [translators](#translations).
+- 📖 My new book [Effective Shell](https://effective-shell) on [Amazon](https://amzn.to/4ho0F91)
+- 🌍 Try [hacker-laws.com](https://hacker-laws.com)
+- 🧠 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)
-* [Laws](#laws)
-    * [90–9–1 Principle (1% Rule)](#9091-principle-1-rule)
-    * [Amdahl's Law](#amdahls-law)
-    * [The Broken Windows Theory](#the-broken-windows-theory)
-    * [Brooks' Law](#brooks-law)
-    * [CAP Theorem (Brewer's Theorem)](#cap-theorem-brewers-theorem)
-    * [Conway's Law](#conways-law)
-    * [Cunningham's Law](#cunninghams-law)
-    * [Dunbar's Number](#dunbars-number)
-    * [Fitts' Law](#fitts-law)
-    * [Gall's Law](#galls-law)
-    * [Goodhart's Law](#goodharts-law)
-    * [Hanlon's Razor](#hanlons-razor)
-    * [Hick's Law (Hick-Hyman Law)](#hicks-law-hick-hyman-law)
-    * [Hofstadter's Law](#hofstadters-law)
-    * [Hutber's Law](#hutbers-law)
-    * [The Hype Cycle & Amara's Law](#the-hype-cycle--amaras-law)
-    * [Hyrum's Law (The Law of Implicit Interfaces)](#hyrums-law-the-law-of-implicit-interfaces)
-    * [Kernighan's Law](#kernighans-law)
-    * [Metcalfe's Law](#metcalfes-law)
-    * [Moore's Law](#moores-law)
-    * [Murphy's Law / Sod's Law](#murphys-law--sods-law)
-    * [Occam's Razor](#occams-razor)
-    * [Parkinson's Law](#parkinsons-law)
-    * [Premature Optimization Effect](#premature-optimization-effect)
-    * [Putt's Law](#putts-law)
-    * [Reed's Law](#reeds-law)
-    * [The Law of Conservation of Complexity (Tesler's Law)](#the-law-of-conservation-of-complexity-teslers-law)
-    * [The Law of Demeter](#the-law-of-demeter)
-    * [The Law of Leaky Abstractions](#the-law-of-leaky-abstractions)
-    * [The Law of Triviality](#the-law-of-triviality)
-    * [The Unix Philosophy](#the-unix-philosophy)
-    * [The Spotify Model](#the-spotify-model)
-    * [Wadler's Law](#wadlers-law)
-    * [Wheaton's Law](#wheatons-law)
-* [Principles](#principles)
-    * [The Dead Sea Effect](#the-dead-sea-effect)
-    * [The Dilbert Principle](#the-dilbert-principle)
-    * [The Pareto Principle (The 80/20 Rule)](#the-pareto-principle-the-8020-rule)
-    * [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)
-* [Reading List](#reading-list)
-* [Translations](#translations)
-* [Related Projects](#related-projects)
-* [Contributing](#contributing)
-* [TODO](#todo)
+- [Introduction](#introduction)
+- [Laws](#laws)
+    - [90–9–1 Principle (1% Rule)](#9091-principle-1-rule)
+    - [90–90 Rule](#9090-rule)
+    - [Amdahl's Law](#amdahls-law)
+    - [The Broken Windows Theory](#the-broken-windows-theory)
+    - [Brooks' Law](#brooks-law)
+    - [CAP Theorem (Brewer's Theorem)](#cap-theorem-brewers-theorem)
+    - [Clarke's three laws](#clarkes-three-laws)
+    - [Conway's Law](#conways-law)
+    - [Cunningham's Law](#cunninghams-law)
+    - [Dunbar's Number](#dunbars-number)
+    - [The Dunning-Kruger Effect](#the-dunning-kruger-effect)
+    - [Fitts' Law](#fitts-law)
+    - [Gall's Law](#galls-law)
+    - [Goodhart's Law](#goodharts-law)
+    - [Hanlon's Razor](#hanlons-razor)
+    - [Hick's Law (Hick-Hyman Law)](#hicks-law-hick-hyman-law)
+    - [Hofstadter's Law](#hofstadters-law)
+    - [Hutber's Law](#hutbers-law)
+    - [The Hype Cycle & Amara's Law](#the-hype-cycle--amaras-law)
+    - [Hyrum's Law (The Law of Implicit Interfaces)](#hyrums-law-the-law-of-implicit-interfaces)
+    - [Input-Process-Output (IPO)](#input-process-output-ipo)
+    - [Kernighan's Law](#kernighans-law)
+    - [Koomey's Law](#koomeys-law)
+    - [Linus's Law](#linuss-law)
+    - [Metcalfe's Law](#metcalfes-law)
+    - [Moore's Law](#moores-law)
+    - [Murphy's Law / Sod's Law](#murphys-law--sods-law)
+    - [Occam's Razor](#occams-razor)
+    - [Parkinson's Law](#parkinsons-law)
+    - [Premature Optimization Effect](#premature-optimization-effect)
+    - [Putt's Law](#putts-law)
+    - [Reed's Law](#reeds-law)
+    - [The Bitter Lesson](#the-bitter-lesson)
+    - [The Ringelmann Effect](#the-ringelmann-effect)
+    - [The Law of Conservation of Complexity (Tesler's Law)](#the-law-of-conservation-of-complexity-teslers-law)
+    - [The Law of Demeter](#the-law-of-demeter)
+    - [The Law of Leaky Abstractions](#the-law-of-leaky-abstractions)
+    - [The Law of the Instrument](#the-law-of-the-instrument)
+    - [The Law of Triviality](#the-law-of-triviality)
+    - [The Unix Philosophy](#the-unix-philosophy)
+    - [The Scout Rule](#the-scout-rule)
+    - [The Spotify Model](#the-spotify-model)
+    - [The Two Pizza Rule](#the-two-pizza-rule)
+    - [Twyman's law](#twymans-law)
+    - [Wadler's Law](#wadlers-law)
+    - [Wheaton's Law](#wheatons-law)
+- [Principles](#principles)
+    - [All Models Are Wrong (George Box's Law)](#all-models-are-wrong-george-boxs-law)
+    - [Chesterton's Fence](#chestertons-fence)
+    - [Kerckhoffs's principle](#kerckhoffss-principle)
+    - [The Dead Sea Effect](#the-dead-sea-effect)
+    - [The Dilbert Principle](#the-dilbert-principle)
+    - [The Pareto Principle (The 80/20 Rule)](#the-pareto-principle-the-8020-rule)
+    - [The Shirky Principle](#the-shirky-principle)
+    - [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
 
@@ -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 |
-|----------|-----------|--------|
-| [🇮🇩 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) |
+- [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.
 
-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.
-- [Hacker Laws CLI](https://github.com/umutphp/hacker-laws-cli) - List, view and see random laws from the terminal!
+A new version of the eBook is created automatically when a new version tag is pushed.
 
-## 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.

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

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

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>
+

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>
+

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>
+

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>
+

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"?>
+<svg
+   width="640"
+   height="480"
+   version="1.1"
+   id="svg195"
+   sodipodi:docname="Fitts_Law.svg"
+   inkscape:version="1.1 (c68e22c387, 2021-05-23)"
+   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+   xmlns="http://www.w3.org/2000/svg"
+   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>
   <!-- Created with SVG-edit - http://svg-edit.googlecode.com/ -->
-
- <g>
-  <title>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
+     id="g193">
+    <title
+       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
+       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"/>
+    <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
+       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"/>
+      <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>
+  <g
+     inkscape:groupmode="layer"
+     id="layer1"
+     inkscape:label="Layer 1" />
 </svg>

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>

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

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 :
 

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) をクリックしてください。

translations/pt-BR.md

@@ -95,7 +95,7 @@ Veja também:
 
 > 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, 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.
+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.
 
+"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:
 
@@ -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,7 +473,7 @@ 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
 
@@ -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.
 
@@ -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:
 
@@ -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