feat(pages): update index.html and pages.yaml for deployment

Updated the index.html to include a full HTML structure with Bootstrap and Google tag. Modified pages.yaml to deploy from 'build/pages' branch instead of the default branch.
Merge pull request #435 from dwmkerr/build/test-pages
2025-12-17 12:45:20 +01:00 · 2025-03-08 21:22:41 +00:00 · 2025-03-08 20:47:59 +00:00 · 2025-03-08 20:46:45 +00:00 · 2025-02-26 14:17:26 +00:00 · 2025-02-26 12:05:25 +00:00
18 changed files with 2927 additions and 229 deletions
--- a/.github/contributing.md
+++ b/.github/contributing.md
@@ -2,11 +2,17 @@

 <!-- vim-markdown-toc GFM -->

+* [Goal of the Project](#goal-of-the-project)
 * [Example Law: The Law of Leaky Abstractions](#example-law-the-law-of-leaky-abstractions)
-* [Localisation](#localisation)
+* [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)

 <!-- 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 +36,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 +60,30 @@ 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.
--- a/.github/pages/index.html
+++ b/.github/pages/index.html
@@ -0,0 +1,28 @@
+<!doctype html>
+<html lang="en">
+  <head>
+    <meta charset="utf-8">
+    <meta name="viewport" content="width=device-width, initial-scale=1">
+
+    <!-- Bootstrap CSS -->
+    <link href="https://cdn.jsdelivr.net/npm/bootstrap@5.0.2/dist/css/bootstrap.min.css" rel="stylesheet" integrity="sha384-EVSTQN3/azprG1Anm3QDgpJLIm9Nao0Yz1ztcQTwFspd3yD65VohhpuuCOmLASjC" crossorigin="anonymous">
+
+    <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>
+  </head>
+  <body>
+    <h1>Hacker Laws</h1>
+
+    <!-- Bootstrap JS -->
+    <script src="https://cdn.jsdelivr.net/npm/bootstrap@5.0.2/dist/js/bootstrap.min.js" integrity="sha384-cVKIPhGWiC2Al4u+LWgxfKTRIcfu0JTxR+EQDz/bgldoEyl4H0zUF0QKbrJ0EcQF" crossorigin="anonymous"></script>
+  </body>
+</html>
--- a/.github/workflows/build-on-pull-request.yaml
+++ b/.github/workflows/build-on-pull-request.yaml
@@ -36,7 +36,7 @@ jobs:
          name: hacker-laws.pdf
          path: hacker-laws.pdf

-      - name: Publish Intermiediate Markdown Artifact
+      - name: Publish Intermediate Markdown Artifact
        uses: actions/upload-artifact@master
        with:
          name: hacker-laws.md
--- a/.github/workflows/pages.yaml
+++ b/.github/workflows/pages.yaml
@@ -0,0 +1,40 @@
+name: Deploy to Pages
+
+on:
+  # Runs on pushes targeting the default branch (or runs manually).
+  push:
+    # branches: [$default-branch]
+    branches: ['build/pages'] # we're deploying from a build branch for now.
+  workflow_dispatch:
+
+# Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages
+permissions:
+  contents: read
+  pages: write
+  id-token: write
+
+# Allow only one concurrent deployment, skipping runs queued between the run in-progress and latest queued.
+# However, do NOT cancel in-progress runs as we want to allow these production deployments to complete.
+concurrency:
+  group: "pages"
+  cancel-in-progress: false
+
+jobs:
+  # Single deploy job since we're just deploying
+  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: Upload artifact
+        uses: actions/upload-pages-artifact@v3
+        with:
+          path: './.github/pages'
+      - name: Deploy to GitHub Pages
+        id: deployment
+        uses: actions/deploy-pages@v4
--- a/2
+++ b/2
@@ -1,4 +1,4 @@
-Copyright (c) Dave Kerr 2020
+Copyright (c) Dave Kerr 2021

 # Attribution-ShareAlike 4.0 International

--- a/README.md
+++ b/README.md
@@ -2,79 +2,88 @@

 Laws, Theories, Principles and Patterns that developers will find useful.

-[Translations](#translations): [🇮🇩](./translations/id.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)
+[Translations](#translations): [🇮🇩](./translations/id.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) [🇵🇱](./translations/pl.md) [🇷🇺](https://github.com/solarrust/hacker-laws) [🇪🇸](./translations/es-ES.md) [🇹🇷](https://github.com/umutphp/hacker-laws-tr) [🇯🇵](./translations/jp.md) [🇺🇦](./translations/uk.md) [🇻🇳](./translations/vi.md)

-Like this project? Please considering [sponsoring me](https://github.com/sponsors/dwmkerr) and the [translators](#translations). Also check out this podcast on [The Changelog - Laws for Hackers to Live By](https://changelog.com/podcast/403) to learn more about the project! You can also [download the latest PDF eBook](https://github.com/dwmkerr/hacker-laws/releases/latest/download/hacker-laws.pdf).
+Like this project? Please considering [sponsoring me](https://github.com/sponsors/dwmkerr) and the [translators](#translations). Also check out this podcast on [The Changelog - Laws for Hackers to Live By](https://changelog.com/podcast/403) to learn more about the project! You can also [download the latest PDF eBook](https://github.com/dwmkerr/hacker-laws/releases/latest/download/hacker-laws.pdf). Check the [Contributor Guide](./.github/contributing.md) if you are keen to contribute!

 ---

 <!-- 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)
-    * [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 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)
-    * [The Two Pizza Rule](#the-two-pizza-rule)
-    * [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)
-    * [Chesterson's Fence](#chestersons-fence)
-    * [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)
-* [Reading List](#reading-list)
-* [Online Resources](#online-resources)
-* [PDF eBook](#pdf-ebook)
-* [Podcast](#podcast)
-* [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)
+    - [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 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)
+    - [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)
+- [Translations](#translations)
+- [Related Projects](#related-projects)
+- [Contributing](#contributing)
+- [TODO](#todo)

 <!-- vim-markdown-toc -->

@@ -88,6 +97,7 @@ There are lots of laws which people discuss when talking about development. This

 And here we go!

+
 ### 90–9–1 Principle (1% Rule)

 [1% Rule on Wikipedia](https://en.wikipedia.org/wiki/1%25_rule_(Internet_culture))
@@ -102,6 +112,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)
@@ -139,7 +162,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/)

@@ -149,7 +172,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.

@@ -168,7 +191,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).

@@ -181,14 +204,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:

@@ -212,12 +247,31 @@ 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:
+
+* [Apple vs. FBI: Why This Anti-Terror Hawk Switched Sides](https://fortune.com/2016/03/10/apple-fbi-lindsay-graham/) - In 2016 Senator Lindsey Graham changed his stance on Apple creating a 'backdoor' in their encryption of devices. Initially Graham had been critical of Apple challenging a request to create a 'backdoor', which he saw as necessary to investigate potential terrorist plots. However, by Graham's own admission, as he learned more about the technical complexity of the domain, he realised that he had assumed it to be far more simple than he had realised, and that such a backdoor could have serious negative consequences. This could potentially be considered an example of the Dunning-Kruger effect - a cyber-security expert would likely understand immediately how such a backdoor could be exploited, as they have deep understanding of the domain, a layperson might assume that phone security is more similar to _physical security_ where the practice of having a 'master key' for law enforcement is possible, but this analogy does not apply sufficiently well to describe modern encryption in cyber-security. 
+
 ### Fitts' Law

 [Fitts' Law on Wikipedia](https://en.wikipedia.org/wiki/Fitts%27s_law)
@@ -371,6 +425,24 @@ 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.
@@ -399,7 +471,7 @@ See also:

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

@@ -481,7 +553,7 @@ 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.
 >
@@ -522,6 +594,15 @@ See also:
 - [Metcalfe's Law](#metcalfes-law)
 - [Dunbar's Number](#dunbars-number)

+### 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)
@@ -568,6 +649,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)
@@ -586,6 +686,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/)
@@ -602,12 +722,24 @@ Members of the organisation have described that the actual meaning of these grou
 >
 > (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 is 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 exponentially; thus the cost of coordinating and communicating also grows exponentially. If this cost of coordination is essentially overhead, then smaller teams should be preferred.
+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)
@@ -659,15 +791,15 @@ See also:

 - [The Law of Leaky Abstractions](#the-law-of-leaky-abstractions)

-### Chesterson's Fence
+### Chesterton's Fence

-[Chesterson's Fence on Wikipedia](https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_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. Chesterson'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.
+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. Chesterson](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."
+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."

 ### The Dead Sea Effect

@@ -723,7 +855,7 @@ Real-world examples:
 [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).
@@ -735,7 +867,7 @@ Related to:

 See also:

- [Pareto Principle](#the-pareto-principle)
+- [Pareto Principle](#the-pareto-principle-the-8020-rule)

 ### The Peter Principle

@@ -747,7 +879,7 @@ See also:

 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:

@@ -770,7 +902,6 @@ See Also:

 - [Hyrum's Law](#hyrums-law-the-law-of-implicit-interfaces)

-
 ### SOLID

 This is an acronym, which refers to:
@@ -791,7 +922,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:

@@ -823,7 +954,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.

@@ -857,7 +988,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.

@@ -876,7 +1007,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).

@@ -884,7 +1015,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

@@ -894,7 +1025,7 @@ See also:

 The KISS principle states that most systems work best if they are kept simple rather than made complicated; therefore, simplicity should be a key goal in design, and unnecessary complexity should be avoided.  Originating in the U.S. Navy in 1960, the phrase has been associated with aircraft engineer Kelly Johnson.

-The principle is best exemplified by the story of Johnson handing a team of design engineers a handful of tools, with the challenge that the jet aircraft they were designing must be repairable by an average mechanic in the field under combat conditions with only these tools. Hence, the "stupid" refers to the relationship between the way things break and the sophistication of the tools available to repair them, not the capabilities of the engineers themselves. 
+The principle is best exemplified by the story of Johnson handing a team of design engineers a handful of tools, with the challenge that the jet aircraft they were designing must be repairable by an average mechanic in the field under combat conditions with only these tools. Hence, the "stupid" refers to the relationship between the way things break and the sophistication of the tools available to repair them, not the capabilities of the engineers themselves.

 See also:

@@ -944,17 +1075,34 @@ 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)

+### 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).
- [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.

 ## Online Resources

@@ -966,6 +1114,8 @@ Some useful resources and reading.

 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.

+A new version of the eBook is created automatically when a new version tag is pushed.
+
 ## Podcast

 Hacker Laws has been featured in [The Changelog](https://changelog.com/podcast/403), you can check out the Podcast episode with the link below:
@@ -978,6 +1128,7 @@ Thanks to a number of wonderful contributors, Hacker Laws is available in a numb

 | Language | Moderator | Status |
 |----------|-----------|--------|
+| [AR Arabic / Arabic](./translations/ar-AR.md) | [Abdurrahman Rajab - a0m0rajab](https://github.com/a0m0rajab) | . |
 | [🇮🇩 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 |
@@ -988,11 +1139,15 @@ Thanks to a number of wonderful contributors, Hacker Laws is available in a numb
 | [🇯🇵 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) |
+| [🇮🇷 فارسی / Persian](./translations/fa.md) | [MohammadErfan Gooneh](https://github.com/MEgooneh) | . |
+| [🇵🇱 Polski / Polish](./translations/pl.md) | [Mariusz Kogen](https://github.com/k0gen) | [![gitlocalized ](https://gitlocalize.com/repo/2513/pl/badge.svg)](https://gitlocalize.com/repo/2513/pl?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) |
+| [🇺🇦 українська мова / Ukrainian](./translations/uk.md) | [Nazar](https://github.com/troyane), [Helga Lastivka](https://github.com/HelgaLastivka) | [![gitlocalized ](https://gitlocalize.com/repo/2513/uk/badge.svg)](https://gitlocalize.com/repo/2513/uk?utm_source=badge) |
+| [🇻🇳 Tiếng Việt / Vietnamese](./translations/vu.md)                      | [Nguyên](https://github.com/truonghoangnguyen), [Trương Hoàng](https://github.com/truonghoangnguyen) | [![gitlocalized ](https://gitlocalize.com/repo/2513/vi/badge.svg)](https://gitlocalize.com/repo/2513/vi?utm_source=badge) |

-If you would like to update a translation, just [open a pull request](https://github.com/dwmkerr/hacker-laws/pulls). If you want to add a new language, log onto [GitLocalize](https://gitlocalize.com/) to create an account, then open an issue asking to administer the language and I will add you to the project! It would also be super helpful if you can open a pull request which updates the table above and link at the top of the file.
+If you would like to update a translation, follow the [Translators Contributor Guide](https://github.com/dwmkerr/hacker-laws/blob/main/.github/contributing.md#translations).

 ## Related Projects

--- a/images/Fitts_Law.svg
+++ b/images/Fitts_Law.svg
@@ -1,42 +1,363 @@
-<svg width="640" height="480" xmlns="http://www.w3.org/2000/svg" xmlns:svg="http://www.w3.org/2000/svg">
- <!-- 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"/>
+<?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>
-  <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>
+  <!-- Created with SVG-edit - http://svg-edit.googlecode.com/ -->
+  <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>
+    <text
+       font-weight="bold"
+       xml:space="preserve"
+       text-anchor="middle"
+       font-family="Sans-serif"
+       font-size="24"
+       id="svg_5"
+       y="35"
+       x="494"
+       stroke-linecap="round"
+       stroke-linejoin="null"
+       stroke-dasharray="5,5"
+       stroke-width="0"
+       stroke="#7f7f7f"
+       fill="#000000">W</text>
+    <g
+       id="svg_21">
+      <line
+         fill="none"
+         stroke="#000000"
+         stroke-width="3"
+         stroke-linejoin="null"
+         stroke-linecap="round"
+         x1="445"
+         y1="45"
+         x2="545"
+         y2="45"
+         id="svg_9" />
+      <line
+         id="svg_17"
+         y2="55"
+         x2="455"
+         y1="45"
+         x1="445"
+         stroke-linecap="round"
+         stroke-linejoin="null"
+         stroke-width="3"
+         stroke="#000000"
+         fill="none" />
+      <line
+         id="svg_18"
+         y2="35"
+         x2="455"
+         y1="45"
+         x1="445"
+         stroke-linecap="round"
+         stroke-linejoin="null"
+         stroke-width="3"
+         stroke="#000000"
+         fill="none" />
+      <line
+         id="svg_19"
+         y2="55"
+         x2="535"
+         y1="45"
+         x1="545"
+         stroke-linecap="round"
+         stroke-linejoin="null"
+         stroke-width="3"
+         stroke="#000000"
+         fill="none" />
+      <line
+         id="svg_20"
+         y2="35"
+         x2="535"
+         y1="45"
+         x1="545"
+         stroke-linecap="round"
+         stroke-linejoin="null"
+         stroke-width="3"
+         stroke="#000000"
+         fill="none" />
+    </g>
+    <g
+       id="svg_37"
+       transform="rotate(-17.3352, 328.667, 273.333)">
+      <line
+         fill="none"
+         stroke="#7f7f7f"
+         stroke-width="2"
+         stroke-dasharray="5,5"
+         stroke-linejoin="null"
+         stroke-linecap="round"
+         x1="128.666668"
+         y1="191.333333"
+         x2="528.666668"
+         y2="191.333333"
+         id="svg_6" />
+      <text
+         id="svg_15"
+         font-weight="bold"
+         xml:space="preserve"
+         text-anchor="middle"
+         font-family="Sans-serif"
+         font-size="24"
+         y="349.333338"
+         x="327.000016"
+         stroke-linecap="round"
+         stroke-linejoin="null"
+         stroke-dasharray="5,5"
+         stroke-width="0"
+         stroke="#7f7f7f"
+         fill="#000000">D</text>
+      <g
+         id="svg_34">
+        <line
+           fill="none"
+           stroke="#000000"
+           stroke-width="3"
+           stroke-linejoin="null"
+           stroke-linecap="round"
+           x1="128.666668"
+           y1="316.000005"
+           x2="528.666668"
+           y2="316.000005"
+           id="svg_29" />
+        <line
+           y2="326.000005"
+           x2="138.666668"
+           y1="316.000005"
+           x1="128.666668"
+           stroke-linecap="round"
+           stroke-linejoin="null"
+           stroke-width="3"
+           stroke="#000000"
+           fill="none"
+           id="svg_30" />
+        <line
+           y2="306.000005"
+           x2="138.666668"
+           y1="316.000005"
+           x1="128.666668"
+           stroke-linecap="round"
+           stroke-linejoin="null"
+           stroke-width="3"
+           stroke="#000000"
+           fill="none"
+           id="svg_31" />
+        <line
+           y2="326.000005"
+           x2="518.666668"
+           y1="316.000005"
+           x1="528.666668"
+           stroke-linecap="round"
+           stroke-linejoin="null"
+           stroke-width="3"
+           stroke="#000000"
+           fill="none"
+           id="svg_32" />
+        <line
+           y2="306.000005"
+           x2="518.666668"
+           y1="316.000005"
+           x1="528.666668"
+           stroke-linecap="round"
+           stroke-linejoin="null"
+           stroke-width="3"
+           stroke="#000000"
+           fill="none"
+           id="svg_33" />
+      </g>
+      <line
+         fill="none"
+         stroke="#7f7f7f"
+         stroke-width="2"
+         stroke-dasharray="5,5"
+         stroke-linejoin="null"
+         stroke-linecap="round"
+         x1="128.666668"
+         y1="191.333333"
+         x2="128.666668"
+         y2="341.333333"
+         id="svg_35" />
+      <line
+         fill="none"
+         stroke="#7f7f7f"
+         stroke-width="2"
+         stroke-dasharray="5,5"
+         stroke-linejoin="null"
+         stroke-linecap="round"
+         x1="528.666668"
+         y1="191.333333"
+         x2="528.666668"
+         y2="341.333333"
+         id="svg_36" />
+    </g>
  </g>
-  <text font-weight="bold" xml:space="preserve" text-anchor="middle" font-family="Sans-serif" font-size="24" id="svg_5" y="35" x="494" stroke-linecap="round" stroke-linejoin="null" stroke-dasharray="5,5" stroke-width="0" stroke="#7f7f7f" fill="#000000">W</text>
-  <g id="svg_21">
-   <line fill="none" stroke="#000000" stroke-width="3" stroke-linejoin="null" stroke-linecap="round" x1="445" y1="45" x2="545" y2="45" id="svg_9"/>
-   <line id="svg_17" y2="55" x2="455" y1="45" x1="445" stroke-linecap="round" stroke-linejoin="null" stroke-width="3" stroke="#000000" fill="none"/>
-   <line id="svg_18" y2="35" x2="455" y1="45" x1="445" stroke-linecap="round" stroke-linejoin="null" stroke-width="3" stroke="#000000" fill="none"/>
-   <line id="svg_19" y2="55" x2="535" y1="45" x1="545" stroke-linecap="round" stroke-linejoin="null" stroke-width="3" stroke="#000000" fill="none"/>
-   <line id="svg_20" y2="35" x2="535" y1="45" x1="545" stroke-linecap="round" stroke-linejoin="null" stroke-width="3" stroke="#000000" fill="none"/>
-  </g>
-  <g id="svg_37" transform="rotate(-17.3352, 328.667, 273.333)">
-   <line fill="none" stroke="#7f7f7f" stroke-width="2" stroke-dasharray="5,5" stroke-linejoin="null" stroke-linecap="round" x1="128.666668" y1="191.333333" x2="528.666668" y2="191.333333" id="svg_6"/>
-   <text id="svg_15" font-weight="bold" xml:space="preserve" text-anchor="middle" font-family="Sans-serif" font-size="24" y="349.333338" x="327.000016" stroke-linecap="round" stroke-linejoin="null" stroke-dasharray="5,5" stroke-width="0" stroke="#7f7f7f" fill="#000000">D</text>
-   <g id="svg_34">
-    <line fill="none" stroke="#000000" stroke-width="3" stroke-linejoin="null" stroke-linecap="round" x1="128.666668" y1="316.000005" x2="528.666668" y2="316.000005" id="svg_29"/>
-    <line y2="326.000005" x2="138.666668" y1="316.000005" x1="128.666668" stroke-linecap="round" stroke-linejoin="null" stroke-width="3" stroke="#000000" fill="none" id="svg_30"/>
-    <line y2="306.000005" x2="138.666668" y1="316.000005" x1="128.666668" stroke-linecap="round" stroke-linejoin="null" stroke-width="3" stroke="#000000" fill="none" id="svg_31"/>
-    <line y2="326.000005" x2="518.666668" y1="316.000005" x1="528.666668" stroke-linecap="round" stroke-linejoin="null" stroke-width="3" stroke="#000000" fill="none" id="svg_32"/>
-    <line y2="306.000005" x2="518.666668" y1="316.000005" x1="528.666668" stroke-linecap="round" stroke-linejoin="null" stroke-width="3" stroke="#000000" fill="none" id="svg_33"/>
-   </g>
-   <line fill="none" stroke="#7f7f7f" stroke-width="2" stroke-dasharray="5,5" stroke-linejoin="null" stroke-linecap="round" x1="128.666668" y1="191.333333" x2="128.666668" y2="341.333333" id="svg_35"/>
-   <line fill="none" stroke="#7f7f7f" stroke-width="2" stroke-dasharray="5,5" stroke-linejoin="null" stroke-linecap="round" x1="528.666668" y1="191.333333" x2="528.666668" y2="341.333333" id="svg_36"/>
-  </g>
- </g>
-</svg>
+  <g
+     inkscape:groupmode="layer"
+     id="layer1"
+     inkscape:label="Layer 1" />
+</svg>
--- a/images/complete_graph.png
+++ b/images/complete_graph.png
--- a/images/gartner_hype_cycle.png
+++ b/images/gartner_hype_cycle.png
--- a/images/hicks_law.svg
+++ b/images/hicks_law.svg
@@ -1,5 +1,6 @@
 <svg xmlns:xlink="http://www.w3.org/1999/xlink" width="18.644ex" height="2.843ex" style="vertical-align: -0.838ex;" viewBox="0 -863.1 8027.4 1223.9" role="img" focusable="false" xmlns="http://www.w3.org/2000/svg" aria-labelledby="MathJax-SVG-1-Title">
 <title id="MathJax-SVG-1-Title">{\displaystyle T=b\cdot \log _{2}(n+1)}</title>
+<rect style="fill:#ffffff" id="rect557" width="100%"  height="100%" x="0" y="-863.1" />
 <defs aria-hidden="true">
 <path stroke-width="1" id="E1-MJMATHI-54" d="M40 437Q21 437 21 445Q21 450 37 501T71 602L88 651Q93 669 101 677H569H659Q691 677 697 676T704 667Q704 661 687 553T668 444Q668 437 649 437Q640 437 637 437T631 442L629 445Q629 451 635 490T641 551Q641 586 628 604T573 629Q568 630 515 631Q469 631 457 630T439 622Q438 621 368 343T298 60Q298 48 386 46Q418 46 427 45T436 36Q436 31 433 22Q429 4 424 1L422 0Q419 0 415 0Q410 0 363 1T228 2Q99 2 64 0H49Q43 6 43 9T45 27Q49 40 55 46H83H94Q174 46 189 55Q190 56 191 56Q196 59 201 76T241 233Q258 301 269 344Q339 619 339 625Q339 630 310 630H279Q212 630 191 624Q146 614 121 583T67 467Q60 445 57 441T43 437H40Z"></path>
 <path stroke-width="1" id="E1-MJMAIN-3D" d="M56 347Q56 360 70 367H707Q722 359 722 347Q722 336 708 328L390 327H72Q56 332 56 347ZM56 153Q56 168 72 173H708Q722 163 722 153Q722 140 707 133H70Q56 140 56 153Z"></path>
--- a/scripts/prepare-markdown-for-ebook.sh
+++ b/scripts/prepare-markdown-for-ebook.sh
@@ -1,42 +1,32 @@
 #!/usr/bin/env bash
-# This script prepares a `hacker-laws.md` file which is in a format ready to be
-# exported to PDF or other formats for an e-book.
+# This script prepares a `hacker-laws.md` file for export to PDF or e-book format.

-# Require that we provide the version number and get a date.
+# Require a version number and get the current date.
 version=$1
 date=$(date "+%Y-%m-%d")

-if [ -z $version ]; then
-    echo "version must be specified: ./prepare-markdown-for-ebook.sh <version>"
+if [ -z "$version" ]; then
+    echo "Usage: $0 <version>"
    exit 1
 fi

-# Create the frontmatter.
-cat << EOF > frontmatter.md
+# Create `hacker-laws.md` with frontmatter and README content in one step.
+cat << EOF > hacker-laws.md
 ---
 title: "Hacker Laws"
 author: "Dave Kerr, github.com/dwmkerr/hacker-laws"
-subtitle: "Laws, Theories, Principles and Patterns that developers will find useful. ${version}, ${date}."
+subtitle: "Laws, Theories, Principles, and Patterns that developers will find useful. ${version}, ${date}."
 ---
+
 EOF
+cat README.md >> hacker-laws.md

-# Combine the frontmatter and the laws.
-cat frontmatter.md README.md >> hacker-laws.md
+# Use a single `sed` command to clean up unwanted lines and emojis in one pass.
+sed -i'' -e '/💻📖.*/d' \
+         -e 's/❗/Warning/g' \
+         -e '/^\[Translations.*/d' \
+         -e '/\*.*/d' \
+         -e '/    \*.*/d' \
+         -e '/## Translations/,$d' 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
+echo "hacker-laws.md prepared successfully."
--- a/translations/fr.md
+++ b/translations/fr.md
@@ -193,7 +193,7 @@ Souvent aussi énoncée de cette manière :
 > Lorsqu'une mesure devient un objectif, elle cesse d'être une bonne mesure.
 > *Marilyn Strathern*

-Cette loi indique que les optimisations basées sur une mesure peuvent amener à une perte de valeur de la mesure elle même. Un ensemble de mesures ([KPIs](https://en.wikipedia.org/wiki/Performance_indicator)) trop restraint appliqué aveuglément à un process déforme le résultat. Les gens tendent à "tricher" localement pour satisfaire une mesure en particulier sans faire attention aux effect globaux de leurs actions sur le système.
+Cette loi indique que les optimisations basées sur une mesure peuvent amener à une perte de valeur de la mesure elle même. Un ensemble de mesures ([KPIs](https://en.wikipedia.org/wiki/Performance_indicator)) trop restraint appliqué aveuglément à un process déforme le résultat. Les gens tendent à "tricher" localement pour satisfaire une mesure en particulier sans faire attention aux effets globaux de leurs actions sur le système.

 Exemples concrets :

@@ -244,7 +244,7 @@ Par exemple, un abaissement de la latence de réponse sur une route (end-point)

 [Cycle du hype sur Wikipedia](https://fr.wikipedia.org/wiki/Cycle_du_hype)

-> On a tendance à surestimer l'effet d'une technologie sur le court terme et à le surestimer sur le long terme.
+> On a tendance à surestimer l'effet d'une technologie sur le court terme et à le sous-estimer sur le long terme.
 > (Roy Amara)

 Le cycle du hype est une représentation visuelle de l'attrait et du développement d'une technologie au fil du temps. Initialement réalisé par Gartner, le concept est plus clair avec un diagramme :
@@ -259,7 +259,7 @@ En clair, ce cycle montre qu'il y a généralement un pic d'excitation concernan

 [Loi d'Hyrum en ligne](http://www.hyrumslaw.com/)

-> > Passé un certain nombre d'utilisateur d'une API, peu importe ce qui est promis par l'interface, tous les comportements possibles du système seront utilisés.
+> Passé un certain nombre d'utilisateur d'une API, peu importe ce qui est promis par l'interface, tous les comportements possibles du système seront utilisés.
 > (Hyrum Wright)

 La loi d'Hyrum décris le fait que lorsqu'une API a un *nombre suffisamment élevé d'utilisateurs*, tous les comportements de l'API (y compris ceux qui ne sont pas définis publiquement) seront utilisés par quelqu'un. Un exemple trivial peut concerner les éléments non fonctionnels de l'API comme le temps de réponse. Un exemple plus subtil peut être l'utilisation d'une regex sur les messages d'erreurs pour en déterminer le *type*. Même si la spécification de l'API ne mentionne rien quant au contenu des messages, *certains* utilisateurs peuvent utiliser ces messages. Un changement au niveau de ces messages reviendrait à casser l'API pour ces utilisateurs.
@@ -486,7 +486,7 @@ Voir aussi :
 > Ne soyez pas un connard.
 > *Wil Wheaton*

-Inventée par Will Wheaton (Star Trek: The Next Generation, The Big Bang Theory), cette loi simple, concise et puissante vise à augmenter l'harmonie et le respect au sein d'un environnement professionnel. Elle peut être appliquée lorsqu'on parle à ses collègues, effectue une code review, argumente contre un autre point de vue, critique et de manière générale, lors de la plupart des interactions entre humains.
+Inventée par Will Wheaton (Star Trek: The Next Generation, The Big Bang Theory), cette loi simple, concise et puissante vise à augmenter l'harmonie et le respect au sein d'un environnement professionnel. Elle peut être appliquée lorsqu'on parle à ses collègues, effectue une revue de code (*code review*), argumente contre un autre point de vue, critique et de manière générale, lors de la plupart des interactions entre humains.

 ## Principes

@@ -499,7 +499,7 @@ Les principes sont généralement des lignes directrices liés à la conception.
 > Les entreprises tendent à promouvoir systématiquement les employés incompétents afin de les sortir du workflow.
 > *Scott Adams*

-Un concept de gestion inventé par Scott Adams (créateur du comic strip Dilbert) inspiré par le [principe de Peter](#principe-de-peter). Suivant le principe de Dilbert, les employés qui n'ont jamais montré de compétence dans leur travail sont promus à des postes de management afin de limité les dommages qu'ils peuvent causer. Adams expliqua initialement le principe dans un article du Wall Street Journal datant de 1995, et élabora le concept dans son livre de 1996: [The Dilbert Principle](#a-lire).
+Un concept de gestion inventé par Scott Adams (créateur du comic strip Dilbert) inspiré par le [principe de Peter](#principe-de-peter). Suivant le principe de Dilbert, les employés qui n'ont jamais montré de compétence dans leur travail sont promus à des postes de management afin de limiter les dommages qu'ils peuvent causer. Adams expliqua initialement le principe dans un article du Wall Street Journal datant de 1995, et élabora le concept dans son livre de 1996: [The Dilbert Principle](#a-lire).

 Voir aussi :

@@ -593,7 +593,7 @@ Voir aussi :

 > Les entités devraient être ouvertes à l'extension et fermées à la modification.

-Le deuxième des principes '[SOLID](#solid)'. Il énonce que le comportement des entités (classes, modules, fonctions, etc.) devraient pouvoir être *étendu*, mais que le comportement *existant* ne devrait pas pouvoir être modifié.
+Le deuxième des principes '[SOLID](#solid)'. Il énonce que le comportement des entités (classes, modules, fonctions, etc.) devrait être *étendu*, mais que le comportement *existant* ne devrait pas être modifié.

 Imaginons par exemple un module capable de changer un document rédigé en Markdown en HTML. Ce module peut être étendu en y ajoutant le support pour une nouvelle fonctionnalité Markdown sans modifier son fonctionnement interne. Le module est en revanche *fermé* à la modification dans le sens où un utilisateur *ne peut pas* changer la manière dont le code existant est rédigé.

@@ -679,7 +679,7 @@ Voir aussi :

 [KISS sur Wikipedia](https://fr.wikipedia.org/wiki/Principe_KISS)

-> > Keep it simple, stupid. (Ne complique pas les choses)
+> Keep it simple, stupid. (Ne complique pas les choses)

 Le principe KISS énonce que la plupart des systèmes fonctionnent mieux s'ils sont simples que compliqués. Par conséquent, la simplicité devrait être un but essentiel dans la conception et toute complexité inutile devrait être évité. Provenant de la marine Américaine en 1960, la phrase est attribuée à l'ingénieur Kelly Johnson.

@@ -700,7 +700,7 @@ Il s'agit d'un acronyme pour ***Y**ou **A**in't **G**onna **N**eed **I**t*. Que

 Ce principe *d'Extreme Programming* (XP) suggère que les développeurs ne devraient implémenter que les fonctionnalités qui sont nécessaires immédiatement et éviter de tenter de prédire l'avenir en implémentant des fonctionnalités qui pourraient être nécessaires plus tard.

-Adhérer à ce principe devrait réduire la quantité de code inutilisé dans la codebase et permettre d'éviter de passer du temps et des efforts sur des fonctionnalités qui n'apportent rien.
+Adhérer à ce principe devrait réduire la quantité de code inutilisé dans le codebase et permet d'éviter de passer du temps sur des fonctionnalités qui n'apportent rien.

 Voir aussi :

--- a/translations/it-IT.md
+++ b/translations/it-IT.md
@@ -310,7 +310,7 @@ La Legge afferma che i team di lavoro tendono a dedicare molto più tempo e atte

 Il tipico esempio fittizio usato per illustrare la Legge è quello di un comitato incaricato di approvare i piani per un impianto nucleare, che passa più tempo a discutere i dettagli del ripostiglio delle biciclette che a discutere il ben più importante design dell'impianto stesso. Può essere difficile a volte dare il giusto contributo quando si discute di argomenti grandi e complessi senza avere una preparazione o esperienza adeguata in merito. Tuttavia, le persone vogliono in genere mostrarsi attive nel collaborare fornendo input di valore. Da qui la tendenza a concentrarsi troppo sul dettaglio spiccio, che può essere discusso facilmente, ma non ha necessariamente rilevanza.

-L'esempio fittizio ha portato all'utilizzo del termine "ripostiglio delle biciclette" come metafora della perdita di tempo sui dettagli di poca rilevanza. 
+L'esempio fittizio ha portato all'utilizzo del termine "ripostiglio delle biciclette" come metafora della perdita di tempo sui dettagli di poca rilevanza.

 ### Filosofia Unix

--- a/translations/jp.md
+++ b/translations/jp.md
@@ -27,6 +27,7 @@
    - [ハイプサイクルとアマラの法則](#ハイプサイクルとアマラの法則)
    - [ハイラムの法則（暗黙のインターフェースの法則）](#ハイラムの法則暗黙のインターフェースの法則)
    - [カーニガンの法則](#カーニガンの法則)
+    - [リーナスの法則](#リーナスの法則)
    - [メトカーフの法則](#メトカーフの法則)
    - [ムーアの法則](#ムーアの法則)
    - [マーフィーの法則/ソッドの法則](#マーフィーの法則ソッドの法則)
@@ -136,7 +137,7 @@

 > 遅延しているソフトウェア開発プロジェクトに人材を追加するとプロジェクトがさらに遅延する。

-この法則は、多くの場合、すでに遅れているプロジェクトを挽回させようとして、人的リソースを追加することで、プロジェクトが更に遅延することを示唆しています。ブルックスは、これが単純化しすぎであることを明らかにしていますが、一般的な推論としては、新しい人的リソースの立ち上げにかかる時間とコミュニケーションのオーバーヘッドを考えると、短期的には速度が低下するということです。また、多くのタスクは分割ないことがあり、リソース間で簡単にタスク分散されない可能性があり、期待するベロシティも得られなくなることを意味します。
+この法則は、多くの場合、すでに遅れているプロジェクトを挽回させようとして、人的リソースを追加することで、プロジェクトが更に遅延することを示唆しています。ブルックスは、これが単純化しすぎであることを明らかにしていますが、一般的な推論としては、新しい人的リソースの立ち上げにかかる時間とコミュニケーションのオーバーヘッドを考えると、短期的には速度が低下するということです。また、多くのタスクは分割出来ないことがあり、リソース間で簡単にタスク分散されない可能性があり、期待するベロシティも得られなくなることを意味します。

 出産でよく言われる「9人の女性は1ヶ月で子作りができない」という言葉は、ブルックスの法則、特にある種のタスクは分割や並列化できないという事実に関連しています。

@@ -301,6 +302,24 @@
 - [UNIX哲学](#unix哲学)
 - [オッカムのかみそり](#オッカムの剃刀)

+### リーナスの法則
+
+[リーナスの法則-Wikipedia](https://ja.wikipedia.org/wiki/%E3%83%AA%E3%83%BC%E3%83%8A%E3%82%B9%E3%81%AE%E6%B3%95%E5%89%87)
+
+> 十分な目ん玉があれば、全てのバグは洗い出される。
+>
+> _エリック・S・レイモンド_
+
+この法則は簡単に言うと、あるプログラムを見る人が多ければ多いほど、誰かがその問題を以前に見て解決している可能性が高くなる、あるいはそれに非常に近い状況になる、というものです。
+
+元々はプロジェクトのオープンソースモデルの価値を説明するために使われましたが、どんなソフトウェアプロジェクトにも当てはまります。プロセスにも拡大して適用できます。より多くのコードレビューや静的解析、また多角的なテストプロセスによって、問題をより可視化されて識別しやすくなります。
+
+より格式ばって言うと以下のようになります。
+
+> ベータテスターと共同開発者が十分多くいれば、ほとんど全ての問題はすぐに明確になり、似た問題に以前遭遇したことのある人によって解決されるだろう。
+
+この法則は、エリック・S・レイモンドの著作『[伽藍とバザール](https://ja.wikipedia.org/wiki/%E4%BC%BD%E8%97%8D%E3%81%A8%E3%83%90%E3%82%B6%E3%83%BC%E3%83%AB)』の中で、[リーナス・トーバルズ](https://ja.wikipedia.org/wiki/%E3%83%AA%E3%83%BC%E3%83%8A%E3%82%B9%E3%83%BB%E3%83%88%E3%83%BC%E3%83%90%E3%83%AB%E3%82%BA)に敬意を表して名付けられました。
+
 ### メトカーフの法則

 [メトカーフの法則-Wikipedia](https://ja.wikipedia.org/wiki/%E3%83%A1%E3%83%88%E3%82%AB%E3%83%BC%E3%83%95%E3%81%AE%E6%B3%95%E5%89%87)
@@ -435,7 +454,7 @@ Donald Knuthの論文「 [Structured Programming With Go To Statements」で](ht

 この法則では、複雑なシステムでの作業を簡略化するためにコンピューティングで一般的に使用される抽象化は、特定の状況では、基礎となるシステムの要素を「漏らし」、抽象化が予期しない方法で動作することになると述べています。

-例としては、ファイルをロードしてその内容を読むことが挙げられます。ァイルシステム API は低レベルのカーネルシステムの *抽象化*であり、それ自体が磁気プラッター (または SSD のフラッシュメモリ) 上のデータの変更に関連する物理的なプロセスを抽象化したものです。ほとんどの場合、ファイルをバイナリデータのストリームのように扱うという抽象化が機能します。磁気ドライブの場合、データを連続的に読み込むと、ランダム・アクセスよりも（ページ・フォルトのオーバーヘッドが増加するため）*大幅に*速くなりますが、SSD ドライブの場合は、このオーバーヘッドは存在しません。この場合に対処するためには、基本的な詳細を理解する必要があります（例えば、データベースのインデックスファイルはランダムアクセスのオーバーヘッドを減らすために構造化されています）が、抽象化された実装の詳細は、開発者が注意する必要があるかもしれません。
+例としては、ファイルをロードしてその内容を読むことが挙げられます。ファイルシステム API は低レベルのカーネルシステムの *抽象化*であり、それ自体が磁気プラッター (または SSD のフラッシュメモリ) 上のデータの変更に関連する物理的なプロセスを抽象化したものです。ほとんどの場合、ファイルをバイナリデータのストリームのように扱うという抽象化が機能します。磁気ドライブの場合、データを連続的に読み込むと、ランダム・アクセスよりも（ページ・フォルトのオーバーヘッドが増加するため）*大幅に*速くなりますが、SSD ドライブの場合は、このオーバーヘッドは存在しません。この場合に対処するためには、基本的な詳細を理解する必要があります（例えば、データベースのインデックスファイルはランダムアクセスのオーバーヘッドを減らすために構造化されています）が、抽象化された実装の詳細は、開発者が注意する必要があるかもしれません。

 上記の例は、より多くの抽象化が導入されると、*より*複雑になる可能性があります。Linux オペレーティングシステムでは、ネットワーク経由でファイルにアクセスすることができますが、ローカルでは「通常の」ファイルとして表現されます。この抽象化は、ネットワーク障害が発生した場合に「漏れ」ます。開発者がこれらのファイルをネットワークの遅延や障害の影響を受ける可能性があることを考慮せずに「通常の」ファイルとして扱ってしまうと、解決策がバグだらけになってしまいます。

@@ -608,9 +627,9 @@ Spotifyモデルとは、「Spotify」によって普及したチームと組織

 > エンティティは拡張のために開かれ、修正のために閉じられるべきです。

-「 [SOLID](#solid) 」第二原則。この原則では、エンティティー（クラス、モジュール、関数など）は動作を*拡張*ることができなければならないが、 *既存*の振る舞いは修正することができないべきではないということを述べています。
+「 [SOLID](#solid) 」第二原則。この原則では、エンティティー（クラス、モジュール、関数など）は動作を*拡張*することができなければならないが、 *既存*の振る舞いは修正することができないべきではないということを述べています。

-仮定としてMarkdown文書をHTMLに変換することができるモジュールを想像してください。ジュールがモジュール内部を修正することなく、新しく提案されたMarkdown機能を処理するために拡張できた場合、拡張のためにオープンになります。既存のMarkdown機能が処理されるように、モジュールが利用者によって*修正されない*場合、修正のために*クローズド*になります。
+仮定としてMarkdown文書をHTMLに変換することができるモジュールを想像してください。モジュールがモジュール内部を修正することなく、新しく提案されたMarkdown機能を処理するために拡張できた場合、拡張のためにオープンになります。既存のMarkdown機能が処理されるように、モジュールが利用者によって*修正されない*場合、修正のために*クローズド*になります。

 この原則は、オブジェクト指向プログラミングに特に関連しています。簡単に拡張するオブジェクトを設計するかもしれませんが、予期しない方法で変更された既存の動作を持つことができるオブジェクトを設計することを避けます。

@@ -786,7 +805,7 @@ KISSの原則は、ほとんどのシステムは複雑にするのではなく

 ## 貢献方法

-貢献してください! 追加や変更を提案したい場合は  [Raise an issue](https://github.com/dwmkerr/hacker-laws/issues/new)、変更を提案したい場合は  [Open a pull request](https://github.com/dwmkerr/hacker-laws/compare)t をご利用ください。
+貢献してください! 追加や変更を提案したい場合は  [Raise an issue](https://github.com/dwmkerr/hacker-laws/issues/new)、変更を提案したい場合は  [Open a pull request](https://github.com/dwmkerr/hacker-laws/compare) をご利用ください。

 文章やスタイルなどの要件については、[Contributing Guidelines](./.github/contributing.md)  を必ずお読みください。プロジェクトの議論に参加する際には、[Code of Conduct](./.github/CODE_OF_CONDUCT.md)を意識してください。

@@ -794,4 +813,4 @@ KISSの原則は、ほとんどのシステムは複雑にするのではなく

 こんにちは！あなたがここに来たということは、私がまだ書き上げていないトピックへのリンクをクリックしたことにですね。

-リクエストしたい場合は  [Raise an Issue](https://github.com/dwmkerr/hacker-laws/issues) rをクリックするか、トピックの定義案を提出したい場合は [Open a Pull Request](https://github.com/dwmkerr/hacker-laws/pulls) をクリックしてください。
+リクエストしたい場合は  [Raise an Issue](https://github.com/dwmkerr/hacker-laws/issues) をクリックするか、トピックの定義案を提出したい場合は [Open a Pull Request](https://github.com/dwmkerr/hacker-laws/pulls) をクリックしてください。
--- a/translations/lv.md
+++ b/translations/lv.md
@@ -69,7 +69,7 @@ Kā šis projekts? Lūdzu, apsveriet iespēju [Sponsoring Me](https://github.com
 * [Lasīšanas saraksts](#lasīšanas-saraksts)
 * [Ieguldījums](#ieguldījums)
 * [Uzdevums](#TODO)
-    
+
 <!-- VIM-markdown-toc -->

 ## Ievads
--- a/translations/pl.md
+++ b/translations/pl.md
--- a/translations/pt-BR.md
+++ b/translations/pt-BR.md
@@ -93,9 +93,9 @@ Veja também:

 [Lei de Amdahl na Wikipédia](https://pt.wikipedia.org/wiki/Lei_de_Amdahl)

-> A lei de Amdahl, também conhecida como argumento de Amdahl, é usada para encontrar a máxima melhora esperada para um sistema em geral quando apenas uma única parte do mesmo é melhorada. Isto é frequentemente usado em computação paralela para prever o máximo speedup teórico usando múltiplos processadores. A lei possui o nome do Arquiteto computacional Gene Amdahl, e foi apresentada a AFIPS na Conferência Conjunta de Informática na primavera de 1967. 
+> A lei de Amdahl, também conhecida como argumento de Amdahl, é usada para encontrar a máxima melhora esperada para um sistema em geral quando apenas uma única parte do mesmo é melhorada. Isto é frequentemente usado em computação paralela para prever o máximo speedup teórico usando múltiplos processadores. A lei possui o nome do Arquiteto computacional Gene Amdahl, e foi apresentada a AFIPS na Conferência Conjunta de Informática na primavera de 1967.

-Fica mais fácil de entender com um exemplo prático. Se um programa é feito de duas partes, parte A, que é executada por um processador único, e parte B, que pode ser feito paralelamente com N processadores. Se adicionarmos mais processaores ao sistema, só vai ter aumento nas tarefas relacionadas à parte B do programa. A velocidade de A se mantém a mesma.
+Fica mais fácil de entender com um exemplo prático. Se um programa é feito de duas partes, parte A, que é executada por um processador único, e parte B, que pode ser feito paralelamente com N processadores. Se adicionarmos mais processadores ao sistema, só vai ter aumento nas tarefas relacionadas à parte B do programa. A velocidade de A se mantém a mesma.

 O diagrama abaixo mostra alguns exemplos de melhoria na velocidade:

@@ -125,15 +125,13 @@ Exemplos:

 ### Lei de Brook

-[Lei de Brooks na Wikipeia](https://en.wikipedia.org/wiki/Brooks%27s_law)
+[Lei de Brooks na Wikipedia](https://en.wikipedia.org/wiki/Brooks%27s_law)

+> Adicionar recursos humanos em um projeto, de desenvolvimento de software, atrasado, faz ficar ainda mais atrasado.

-> Adicionar recursos humanos em um projeto, de desenvolvimento de sotware, atrasado, faz ficar ainda mais atrasado. 
-
-Essa lei sugere que em muitos casos, na tentativa de acelerar uma entrega, que já está atrasada, 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:

@@ -375,7 +373,7 @@ Exemplo:

 >O trabalho se expande de modo a preencher o tempo disponível para a sua realização.

-A lei de Parkinson foi publicada por Cyril Northcote Parkinson num artigo na revista The Economist em 1955, sendo depois reimpresso com outros artigos no livro Parkinson's Law: The Pursuit of Progress [A lei de Parkinson: a busca do progresso].Em seu contexto original, essa Lei foi baseada em estudos de burocracia. E pode ser pessimisticamente aplicado a desenvolvimento de software, a teoria diz que equipes serão ineficientes até os prazos finais, quando irão dar o máximo até o prazo final.
+A lei de Parkinson foi publicada por Cyril Northcote Parkinson num artigo na revista The Economist em 1955, sendo depois reimpresso com outros artigos no livro Parkinson's Law: The Pursuit of Progress [A lei de Parkinson: a busca do progresso]. Em seu contexto original, essa Lei foi baseada em estudos de burocracia. E pode ser pessimisticamente aplicado a desenvolvimento de software, a teoria diz que equipes serão ineficientes até os prazos finais, quando irão dar o máximo até o prazo final.

 ### Efeito de Otimização Prematura

@@ -385,7 +383,7 @@ A lei de Parkinson foi publicada por Cyril Northcote Parkinson num artigo na rev
 >
 > [(Donald Knuth)](https://twitter.com/realdonaldknuth?lang=en)

-No artigo de Donald Knuth, [Structured Programming With Go To Statements](http://wiki.c2.com/?StructuredProgrammingWithGoToStatements), ele escreve: "Programadores perdem grandes quantidades de tempo pensando ou se preocupando com a velocidade de partes não críticas de seus programas, e essas tentativas de eficiência possuem um forte impacto negativo quando depuração e manutenção são consideradas. Nós devemos esquecer essas pequenas eficiências, cerca de 97% das vezes: **otimização prematura é a raiz de todo o mal.** No entando, não devemos perder a oportunidade nesses 3% críticos".
+No artigo de Donald Knuth, [Structured Programming With Go To Statements](http://wiki.c2.com/?StructuredProgrammingWithGoToStatements), ele escreve: "Programadores perdem grandes quantidades de tempo pensando ou se preocupando com a velocidade de partes não críticas de seus programas, e essas tentativas de eficiência possuem um forte impacto negativo quando depuração e manutenção são consideradas. Nós devemos esquecer essas pequenas eficiências, cerca de 97% das vezes: **otimização prematura é a raiz de todo o mal.** No entanto, não devemos perder a oportunidade nesses 3% críticos".

 Contudo, _Otimização Prematura_ pode ser definida (em termos menos carregados) como otimizar antes de saber o que precisamos.

@@ -399,7 +397,9 @@ A Lei de Putt é frequentemente seguida pelo Corolário de Putt:

 > Cada hierarquia técnica, no tempo, desenvolve uma inversão de competência.

-Estas declarações sugerem que devido a vários critérios de seleção e tendências na forma como grupos se organizam, haverá um número de pessoas qualificadas nos níveis de trabalho de organizações técnicas, e um número de pessoas em funções gerenciais que não estão cientes das complexidades e desafios do trabalho que estão gerenciando. Isso pode ser devido a fenômenos como  (#em-progresso)
+Estas declarações sugerem que devido a vários critérios de seleção e tendências na forma como grupos se organizam, haverá um número de pessoas qualificadas nos níveis de trabalho de organizações técnicas, e um número de pessoas em funções gerenciais que não estão cientes das complexidades e desafios do trabalho que estão gerenciando. Isso pode ser devido a fenômenos como o [Princípio de Peter](#o-princípio-de-peter) ou o [Princípio Dilbert](#o-princípio-dilbert).
+
+No entanto, deve-se enfatizar que leis como essa são vastas generalizações e podem ser aplicáveis a alguns tipos de organizações, mas não a outras.

 Veja também:

@@ -422,7 +422,7 @@ Veja também:

 [A lei da Conservação de Complexidade na wikipedia](https://en.wikipedia.org/wiki/Law_of_conservation_of_complexity)

-Essa lei sugere que em todos sitemas sempre vai existir uma quantidade de complexidade que não pode ser reduzida.
+Essa lei sugere que em todos os sistemas sempre vai existir uma quantidade de complexidade que não pode ser reduzida.

 Alguma complexidade em um sistema é "inadvertida". É uma consequência da estrutura deficiente, erros ou apenas má modelagem de um problema a ser resolvido. A complexidade inadvertida pode ser reduzida (ou eliminada). No entanto, alguma complexidade é "intrínseca" como consequência da complexidade inerente ao problema a ser resolvido. Essa complexidade pode ser movida, mas não eliminada.

@@ -436,9 +436,9 @@ Um elemento interessante para essa lei é a sugestão de que, mesmo simplificand

 Essa lei afirma que abstrações, as quais são geralmente utilizadas na computação para simplificar um trabalho com sistemas complexos, em certas situações irão 'vazar' elementos do sistema subjacente, fazendo com que a abstração se comporte de maneira inesperada.

-Um exemplo disso pode ser carregar um arquivo e ler o seu conteúdo. As APIs do sistema de arquivo são abstrações do kernel de nível inferior, que são uma abstração dos processadores físicos relacionados à alteração de dados no disco rígido (ou na memória flash em SSD). Na maioria dos casos, a abstração de tratar um arquivo como um fluxo de dados binários funcionará. Contudo, para um disco rígido, a leitura sequencial dos dados será significamente mais rápida que o acesso aleatório (devido ao aumento da sobrecarga de falhas na página), mas para um disco SSD, essa sobrecarga não estará presente. Os detalhes subjacentes precisarão ser entendidos para lidar com esse caso (por exemplo, os arquivos índices de uma base de dados são estruturados para reduzir a sobrecarga do acesso aleatório), a abstração 'vaza' detalhes de implementação os quais o desenvolvedor precisa estar ciente.
+Um exemplo disso pode ser carregar um arquivo e ler o seu conteúdo. As APIs do sistema de arquivo são abstrações do kernel de nível inferior, que são uma abstração dos processadores físicos relacionados à alteração de dados no disco rígido (ou na memória flash em SSD). Na maioria dos casos, a abstração de tratar um arquivo como um fluxo de dados binários funcionará. Contudo, para um disco rígido, a leitura sequencial dos dados será significantemente mais rápida que o acesso aleatório (devido ao aumento da sobrecarga de falhas na página), mas para um disco SSD, essa sobrecarga não estará presente. Os detalhes subjacentes precisarão ser entendidos para lidar com esse caso (por exemplo, os arquivos índices de uma base de dados são estruturados para reduzir a sobrecarga do acesso aleatório), a abstração 'vaza' detalhes de implementação os quais o desenvolvedor precisa estar ciente.

-O exemplo acima pode se tormar mais complexo quando _mais_ abstrações são introduzidas. O sistema operacional Linux permite que os arquivos sejam acessados por rede mas representados localmente como arquivos 'normais'. Essa abstração será 'vazada' se houverem falhas de rede. Se um desenvolvedor tratar esses arquivos como 'normais', sem considerar o fato de que eles podem estar sujeitos à latência e falhas na rede, as soluções serão incorretas.
+O exemplo acima pode se tornar mais complexo quando _mais_ abstrações são introduzidas. O sistema operacional Linux permite que os arquivos sejam acessados por rede mas representados localmente como arquivos 'normais'. Essa abstração será 'vazada' se houverem falhas de rede. Se um desenvolvedor tratar esses arquivos como 'normais', sem considerar o fato de que eles podem estar sujeitos à latência e falhas na rede, as soluções serão incorretas.

 Veja também:

@@ -446,7 +446,7 @@ Veja também:

 Exemplos do mundo real:

- [Photoshop Slow Startup](https://forums.adobe.com/thread/376152) - um problema que eu encontrei no passado. O Photoshop demorava para abrir, às vezes levando alguns minutos. Parecia que o problema era que, ao iniciar, o programa lia algumas informações sobre a impressora padrão. No entando, se essa impressora fosse uma impressora de rede, isso demoraria tempo extremamente longo. A _abstração_ de uma impressora de rede ser mostrada ao sistema como uma impressora local causou um problema para usuários em situação de baixa conectividade. 
+- [Photoshop Slow Startup](https://forums.adobe.com/thread/376152) - um problema que eu encontrei no passado. O Photoshop demorava para abrir, às vezes levando alguns minutos. Parecia que o problema era que, ao iniciar, o programa lia algumas informações sobre a impressora padrão. No entanto, se essa impressora fosse uma impressora de rede, isso demoraria tempo extremamente longo. A _abstração_ de uma impressora de rede ser mostrada ao sistema como uma impressora local causou um problema para usuários em situação de baixa conectividade.

 ### A Lei da Trivialidade

@@ -454,7 +454,7 @@ Exemplos do mundo real:

 Essa lei sugere que grupos irão dar maior atenção para problemas triviais ou cosméticos, do que para os problemas sérios e substanciais.

-O exemplo fictício comum utilizado é o de um comitê aprovando planos para uma usina nuclear, que passam maior tempo discutindo a estrutura do bicicletário ao invés do design da própria usina que é muito mais importante. Pode ser difícil fornecer informações valiosas em discussões sobre tópicos muito grandes e complexos sem um alto grau de conhecimento ou preparação no assunto. No entando, as pessoas querem ser vistas contribuindo com informações importantes. Daí uma tendência de concentrar muito tempo em pequenos detalhes, que podem ser facilmente explicados, mas necessariamente não são de importância particular.
+O exemplo fictício comum utilizado é o de um comitê aprovando planos para uma usina nuclear, que passam maior tempo discutindo a estrutura do bicicletário ao invés do design da própria usina que é muito mais importante. Pode ser difícil fornecer informações valiosas em discussões sobre tópicos muito grandes e complexos sem um alto grau de conhecimento ou preparação no assunto. No entanto, as pessoas querem ser vistas contribuindo com informações importantes. Daí uma tendência de concentrar muito tempo em pequenos detalhes, que podem ser facilmente explicados, mas necessariamente não são de importância particular.

 O exemplo fictício acima levou ao uso do termo _'Bike Shedding'_ como uma expressão por gastar tempo em detalhes triviais.

@@ -473,14 +473,14 @@ Práticas modernas como a 'Arquitetura de Microsserviços' podem ser pensadas co

 O Modelo Spotify é uma abordagem para a organização de equipes que foi popularizado pelo 'Spotify'. Neste modelo, times são organizados por funcionalidades, não por tecnologias.

-O Modelo Spotify também popularizou o conteido de Tribos, Guildas, Capítulos, que são outros componentes de sua estrutura organizacional.
+O Modelo Spotify também popularizou o conceito de Tribos, Guildas, Capítulos, que são outros componentes de sua estrutura organizacional.

 ### Lei de Wadler

 [Wadler's Law on wiki.haskell.org](https://wiki.haskell.org/Wadler's_Law)

 > Em qualquer design de linguagem, o tempo total gasto discutindo a uma funcionalidade nessa lista é proporcional a dois elevados à potência de sua posição.
-> 
+>
 > 0. Semântica
 > 1. Sintaxe
 > 2. Sintaxe léxica
@@ -488,7 +488,7 @@ O Modelo Spotify também popularizou o conteido de Tribos, Guildas, Capítulos,
 >
 > (Em resumo, para cada hora gasta em semântica, 8 horas serão gastas na sintaxe de comentários)

-Semelhante à [Lei da Trivialidade](#a-lei-da-trivialidade), a Lei de Wadler afirma que quando projetamos uma linguagem, o tempo gasto em estruturas é desproporcionalmente maior do que a imporância dessas funcionalidades.
+Semelhante à [Lei da Trivialidade](#a-lei-da-trivialidade), a Lei de Wadler afirma que quando projetamos uma linguagem, o tempo gasto em estruturas é desproporcionalmente maior do que a importância dessas funcionalidades.

 Veja também:

@@ -504,7 +504,7 @@ Veja também:
 >
 > _Wil Wheaton_

-Cunhada por Wil Wheaton (Star Trek: The Next Generation, The Big Bang Theory), esta lei simples, concisa e poderosa visa aumentar a harmonia e o respeito dentro de uma organização profissional. Ela pode ser aplicada ao conversar com colegas de trabalho, ao efetuar code reviews, contrariar outros ponto de vista, criticar, e, em linhas gerais, na maioria das interações que os humanos mantém entre si.
+Cunhada por Wil Wheaton (Star Trek: The Next Generation, The Big Bang Theory), esta lei simples, concisa e poderosa visa aumentar a harmonia e o respeito dentro de uma organização profissional. Ela pode ser aplicada ao conversar com colegas de trabalho, ao efetuar code reviews, contrariar outros pontos de vista, criticar, e, em linhas gerais, na maioria das interações que os humanos mantém entre si.

 ## Princípios

@@ -539,7 +539,7 @@ O Princípio de Pareto sugere que em alguns casos, a maioria dos resultados vem
 - 20% dos bugs causam 80% das quebras
 - 20% das funcionalidades causam 80% da utilização

-Nos anos 40 o engenheiro americano-romeno Dr. Joseph Juran, reconhecido como pai do controle de qualidade, [começou a aplicar o Princípio de Pareto a questões de qualidade]((https://en.wikipedia.org/wiki/Joseph_M._Juran)).
+Nos anos 40 o engenheiro americano-romeno Dr. Joseph Juran, reconhecido como pai do controle de qualidade, [começou a aplicar o Princípio de Pareto a questões de qualidade](https://en.wikipedia.org/wiki/Joseph_M._Juran).

 Este princípio é também conhecido como: A Regra do 80/20, A Lei dos Poucos Vitais e O Princípio de Escassez do Fator.

@@ -555,7 +555,7 @@ Exemplos do mundo real:
 >
 > _Laurence J. Peter_

-Um conceito de gerenciamento desenvolvido por Laurence J. Peter, o Princípio de Peter observa que as pessoas que são boas em seu emprego são promovidas até um nível onde elas não são mais bem-sucedidas (o "nível de incompetência"). Neste ponto, à medida em que são mais seniores, é menos provável que elas sejam removidas da organização (a não ser que elas performem de maneira horrível) e irão continuar a permanecer em uma função na qual possuem poucas habilidades intrínsecas, pois as habilidades originais que as fizeram bem-sucedidas não são necessariamente as mesmas que o novo cargo exige.  
+Um conceito de gerenciamento desenvolvido por Laurence J. Peter, o Princípio de Peter observa que as pessoas que são boas em seu emprego são promovidas até um nível onde elas não são mais bem-sucedidas (o "nível de incompetência"). Neste ponto, à medida em que são mais seniores, é menos provável que elas sejam removidas da organização (a não ser que elas performem de maneira horrível) e irão continuar a permanecer em uma função na qual possuem poucas habilidades intrínsecas, pois as habilidades originais que as fizeram bem-sucedidas não são necessariamente as mesmas que o novo cargo exige.

 Isso é de interesse particular para engenheiros - que inicialmente começam em funções técnicas mas tem uma carreira que leva ao _gerenciamento_ de outros engenheiros - o que requer um conjunto de habilidades fundamentalmente diferente.

@@ -594,7 +594,7 @@ Esses são os princípios-chave da [Programação Orientada a Objetos](#todo). O

 O primeiro dos princípios '[SOLID](#solid)'. Esse princípio sugere que módulos ou classes devem fazer apenas uma única coisa. Em termos mais práticos, isso significa que uma mudança simples a uma funcionalidade de um programa deve exigir uma mudança em apenas um componente. Por exemplo, mudar como uma senha é validada por complexidade deve exigir uma mudança em apenas uma parte do programa.

-Teoricamente, isso deve tornar o código mais robusto, e fácil de ser mudado. Sabendo que um componente que está sendo alterado possui apenas uma responsabilidade siginfica que o _teste_ deverá ser mais fácil. Usando o exemplo anterior, trocar a complexidade do componente de senha deve afetar apenas as funcionalidades que são relacionadas com a complexidade de senha. Pode ser muito mais difícil argumentar sobre o impacto de uma alteração em um componente que tem muitas responsabilidades.
+Teoricamente, isso deve tornar o código mais robusto, e fácil de ser mudado. Sabendo que um componente que está sendo alterado possui apenas uma responsabilidade significa que o _teste_ deverá ser mais fácil. Usando o exemplo anterior, trocar a complexidade do componente de senha deve afetar apenas as funcionalidades que são relacionadas com a complexidade de senha. Pode ser muito mais difícil argumentar sobre o impacto de uma alteração em um componente que tem muitas responsabilidades.

 Veja também:

@@ -607,11 +607,11 @@ Veja também:

 > Entidades devem estar aberta para extensão e fechadas para modificação

-O segundo princípio do '[SOLID](#solid)'. Esse princípio afirma que entidades (que podem ser classes, módulos, funções e afins) poderão ter seu comportamento _extendido_, mas que o comportamento já existente não poderá ser alterado.
+O segundo princípio do '[SOLID](#solid)'. Esse princípio afirma que entidades (que podem ser classes, módulos, funções e afins) poderão ter seu comportamento _estendido_, mas que o comportamento já existente não poderá ser alterado.

-Em um exemplo hipotético, imagine um módulo que converte um documento Markdown para HTML. Se o módulo pode ser extendido para aceitar uma nova funcionalidade do markdown, sem modificar a parte interna desse módulo, quer dizer que ele está aberto para extensões. Se o módulo _não_ pode ser modificado por um consumidor, de modo que as funcionalidades existentes do markdown sejam tratadas, então ele estará _fechado_ para modificações.
+Em um exemplo hipotético, imagine um módulo que converte um documento Markdown para HTML. Se o módulo pode ser estendido para aceitar uma nova funcionalidade do markdown, sem modificar a parte interna desse módulo, quer dizer que ele está aberto para extensões. Se o módulo _não_ pode ser modificado por um consumidor, de modo que as funcionalidades existentes do markdown sejam tratadas, então ele estará _fechado_ para modificações.

-Esse princípio tem uma relevância particular na orientação a objetos, onde nós projetamos objetos para serem facilmente extendidos, mas evitamos projetar objetos onde o comportamento existente pode ser alterado de maneiras inesperadas.
+Esse princípio tem uma relevância particular na orientação a objetos, onde nós projetamos objetos para serem facilmente estendidos, mas evitamos projetar objetos onde o comportamento existente pode ser alterado de maneiras inesperadas.

 Veja também:

@@ -628,7 +628,7 @@ O terceiro princípio '[SOLID](#solid)'. O princípio afirma que se um component

 Como um exemplo, imagine que temos um método que lê um documento XML de uma estrutura que representa um arquivo. Se o método utiliza a base de um tipo 'arquivo', então qualquer coisa que seja derivada de 'arquivo' poderá ser utilizada na função. Se 'arquivo' suporta busca recursiva, e o interpretador de XML utiliza essa função, mas o tipo derivado 'arquivo de rede' falha quando tenta uma busca recursiva, então o tipo 'arquivo de rede' estaria violando o princípio.

-Esse princípio tem uma relevância particular na orientação a objetos, onde as hierarquias de tipos precisam ser modeladas com cautela para envitar confusão entre usuaríos do sistema.
+Esse princípio tem uma relevância particular na orientação a objetos, onde as hierarquias de tipos precisam ser modeladas com cautela para evitar confusão entre usuários do sistema.

 Veja também:

@@ -643,9 +643,9 @@ Veja também:

 O quarto princípio do '[SOLID](#solid)'. Esse princípio afirma que os consumidores de um componente não devem depender de funções daquele componente, as quais eles atualmente não usem.

-Como um exemplo, imagine que um método lê um documento XML de uma estutura que representa um arquivo. O método apenas precisa ler os bytes, ir para frente ou para trás no arquivo. Se esse método precisar ser atualizado porque um recurso não relacionado da estrutura do arquivo é alterado (como uma atualização no modelo de permissões utilizado para representar a segurança do arquivo), o princípio foi invalidado. 
+Como um exemplo, imagine que um método lê um documento XML de uma estrutura que representa um arquivo. O método apenas precisa ler os bytes, ir para frente ou para trás no arquivo. Se esse método precisar ser atualizado porque um recurso não relacionado da estrutura do arquivo é alterado (como uma atualização no modelo de permissões utilizado para representar a segurança do arquivo), o princípio foi invalidado.

-Esse princípio tem uma relevância particular na orientação a objetos, onde interfaces, hierarquias e tipos abstratos são utilizados para [minimizar o acomplamento](#todo) entre componentes diferentes. [Duck typing]() é uma metodologia que enforça esse princípio, eliminando interfaces explícitas.
+Esse princípio tem uma relevância particular na orientação a objetos, onde interfaces, hierarquias e tipos abstratos são utilizados para [minimizar o acoplamento](#todo) entre componentes diferentes. [Duck typing]() é uma metodologia que impõe esse princípio, eliminando interfaces explícitas.

 Veja também:

@@ -660,7 +660,7 @@ Veja também:

 > Módulos de alto nível não devem ser dependentes de implementações de baixo nível.

-O quinto conceito do '[SOLID](#solid)'. Esse princípio afirma que componentes 
+O quinto conceito do '[SOLID](#solid)'. Esse princípio afirma que componentes

 Como um exemplo, imagine que temos um programa que lê os metadados de um website. Nós devemos assumir que o componente principal precisa conhecer um componente que irá baixar a página, depois um outro componente que irá ler os metadados. Se fôssemos levar a inversão de dependências em conta, o componente principal deveria depender apenas de um componente abstrato que pode buscar pelos bytes, e depois outro componente abstrato que irá ler os metadados de um fluxo de bytes. O componente principal não sabe nada sobre TCP/IP, HTTP, HTML, etc.

@@ -679,7 +679,7 @@ Veja também:

 > Cada pedaço de código deve possuir uma representação única, inequívoca e autoritária dentro de um sistema.

-DRY é um acrônimo para _**D**on't **R**epeat **Y**ourself_ (Não repita você mesmo). Esse princípio ajuda os desenvolvedores a reduzir a repetição de código e manter a informação em um único lugar. Foi citado em 1999 por Andrew Hunt e Dave Thomas no livro [The Pragmatic Developer](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer).
+DRY é um acrônimo para _**D**on't **R**epeat **Y**ourself_ (Não repita você mesmo). Esse princípio ajuda os desenvolvedores a reduzir a repetição de código e manter a informação em um único lugar. Foi citado em 1999 por Andrew Hunt e Dave Thomas no livro [The Pragmatic Programmer](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer).

 > O oposto de DRY seria WET (Write Everything Twice or We Enjoy Typing) - (Escreva tudo duas vezes ou Nós gostamos de digitar).

@@ -687,7 +687,7 @@ Na prática, se você tem o mesmo pedaço de informação em dois (ou mais) luga

 Veja também:

- [The Pragmatic Developer](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer)
+- [The Pragmatic Programmer](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer)

 ### O Princípio KISS

@@ -715,7 +715,7 @@ Veja também:

 Este princípio da _Extreme Programming_ (XP) sugere que os desenvolvedores apenas devem implementar funcionalidades quando elas forem necessárias, e evitar tentativas de prever o futuro e implementar uma funcionalidade que talvez seja necessária.

-Aderir a esse princípio deve reduzir a quantidade de código não utilizado em um projeto, e evitar tempo e esforço sendo disperdiçados em funcionalidades que não agregam valor.
+Aderir a esse princípio deve reduzir a quantidade de código não utilizado em um projeto, e evitar tempo e esforço sendo desperdiçados em funcionalidades que não agregam valor.

 Veja também:

@@ -783,7 +783,7 @@ Se você quer atualizar uma tradução, [abra uma pull request](https://github.c

 ## Projetos relacionados

- [Tip of the Day](https://tips.darekkay.com/html/hacker-laws-en.html) - Receba diaramente uma lei ou princípio hacker.
+- [Tip of the Day](https://tips.darekkay.com/html/hacker-laws-en.html) - Receba diariamente uma lei ou princípio hacker.
 - [Hacker Laws CLI](https://github.com/umutphp/hacker-laws-cli) - Liste e visualize as leis de maneira aleatória no seu terminal!

 ## Contribuindo
--- a/translations/vi.md
+++ b/translations/vi.md
Author	SHA1	Message	Date
Dave Kerr	beb3d57a6a	feat(pages): update index.html and pages.yaml for deployment Updated the index.html to include a full HTML structure with Bootstrap and Google tag. Modified pages.yaml to deploy from 'build/pages' branch instead of the default branch.	2025-03-08 21:22:41 +00:00
Dave Kerr	decfccdfbc	Merge pull request #435 from dwmkerr/build/test-pages build: test github pages	2025-03-08 20:47:59 +00:00
Dave Kerr	6d904cd9d7	build: test github pages	2025-03-08 20:46:45 +00:00
Dave Kerr	44779074ca	feat: 90-90 rule	2025-02-26 14:17:26 +00:00
Dave Kerr	593fbcbba4	Merge pull request #391 from gurjeet/patch-1 Added Ninety–Ninety Rule	2025-02-26 12:05:25 +00:00
Dave Kerr	85112d267f	Merge branch 'staging' into patch-1	2025-02-26 12:05:00 +00:00
Dave Kerr	9ff8039a43	Merge branch 'marcosValle-patch-1'	2025-02-17 16:46:26 +00:00
Dave Kerr	b9ad4c6f99	feat: twyman's law Merge branch 'patch-1' of github.com:marcosValle/hacker-laws into marcosValle-patch-1	2025-02-17 16:45:35 +00:00
Dave Kerr	4adcc2a090	docs: fix casing	2025-02-11 12:10:19 +00:00
Dave Kerr	eb34ea9a67	docs: minor tweaks to The Ringelmann Effect	2025-02-11 12:07:48 +00:00
Dave Kerr	ae17de2b67	Merge pull request #369 from hliyan/main Added Ringelmann effect	2025-02-11 12:04:01 +00:00
Dave Kerr	31d14b7deb	Merge branch 'main' into main	2025-02-11 12:03:53 +00:00
Dave Kerr	dfc978df13	docs: clean up IPO title	2025-02-04 15:05:26 +00:00
Dave Kerr	8dc1baa919	Merge pull request #432 from dwmkerr/staging staging	2025-02-04 15:03:45 +00:00
Dave Kerr	d66d8afae4	docs: input process output	2025-02-04 15:02:21 +00:00
Dave Kerr	82af717edd	Merge pull request #304 from guettli/patch-1 Added input-processing-output	2025-02-04 14:50:31 +00:00
Dave Kerr	5fd0a88927	Merge pull request #427 from MEgooneh/patch-1 Adding Persian to Translation section	2025-01-02 07:23:41 +00:00
MEGAGON	34a7131aef	Fixing order of local and global languages	2025-01-02 02:30:40 +03:30
MEGAGON	3ce9be6081	Adding Persian to Translation section	2025-01-02 02:25:01 +03:30
Dave Kerr	01402ca31d	Merge pull request #425 from JohnbelMDev/patch-1 Update prepare-markdown-for-ebook.sh	2024-11-14 20:01:29 +11:00
Johnbel Mahautiere	69856f7ab2	Update prepare-markdown-for-ebook.sh Occurrences updata	2024-11-12 10:20:01 -05:00
Dave Kerr	274c008a0a	Merge pull request #415 from emmanuelbernard/patch-1 Minor French typo	2024-01-31 13:08:25 +01:00
Emmanuel Bernard	96bf4635e5	Minor French typo	2024-01-30 16:05:54 +01:00
Dave Kerr	1d0a24e547	Merge pull request #412 from akbarali1/main-1 Fix WikiWiki web	2023-08-08 20:54:35 -07:00
Akbarali	8c3de66940	Update README.md	2023-08-06 17:15:58 +05:00
Dave Kerr	5412cfbde3	Merge pull request #408 from GGuinea/navigation_polish_translation Fix navigation for polish translation.	2023-05-28 08:00:11 -07:00
Gguinea	3adb816f30	Fix navigation for polish translation.	2023-05-27 22:58:21 +02:00
Dave Kerr	2116b5cbd6	Merge pull request #407 from GGuinea/solidny_acrocym_doesn_not_exists	2023-05-26 11:09:02 -07:00
Gguinea	560ff0d9f1	SOLID acronym cannot be translated	2023-05-26 18:17:34 +02:00
Dave Kerr	c03384f370	Merge pull request #406 from tobiasbueschel/patch-1 Update small spelling mistake in .github/workflows	2023-04-05 11:31:08 -04:00
Tobias Büschel	c0ec1b5fdb	Update small spelling mistake in .github/workflows	2023-04-05 22:10:46 +08:00
Dave Kerr	4be482731b	Merge pull request #404 from dwmkerr/feat/principle-of-least-astonishment feat: principle of least astonishment	2023-03-10 11:10:41 +08:00
Dave Kerr	9bd03d8345	Update README.md	2023-03-10 16:10:24 +13:00
Dave Kerr	e4662cbc27	feat: principle of least astonishment	2023-03-10 11:06:50 +08:00
Dave Kerr	80bea4040f	Merge pull request #402 from a0m0rajab/patch-1 Add language contributor - Arabic	2023-01-09 16:19:15 +13:00
Abdurrahman Rajab	87ec516a23	Add language contributor - Arabic	2023-01-01 13:09:15 +03:00
Dave Kerr	6f177f4b46	Merge pull request #399 from gustavothecoder/fix-the-pragmatic-programmer-typo Fix typo: "The Pragmatic Developer" to "The Pragmatic Programmer"	2022-12-05 17:19:42 +13:00
Gustavo Ribeiro	97adc7dbb1	Fix typo: The Pragmatic Developer to The Pragmatic Programmer	2022-12-03 14:47:07 -03:00
Dave Kerr	80e8ccff15	Merge pull request #398 from duongductrong/patch-1 Fix misspelling from "sẫn" to "sẵn"	2022-11-21 14:38:32 +13:00
Dương Đức Trọng	7c92a91988	Fix misspelling from "sẫn" to "sẵn" The word misspelling "sẫn", The correct word is "sẵn"	2022-11-20 23:40:50 +07:00
Dave Kerr	bf758f436a	Merge pull request #376 from thomasmerz/main Added Clarke's three laws for issues/375	2022-08-12 22:14:10 +08:00
Gurjeet Singh	722d79619c	Added Ninety–Ninety Rule	2022-05-01 08:59:35 -07:00
thomasmerz	6b4572f590	Merge branch 'dwmkerr:main' into main	2022-03-14 23:02:25 +01:00
Dave Kerr	e8acd18321	Merge pull request #387 from AmaiSaeta/patch-1 Fix a typo in Japanese translation	2022-03-07 15:54:57 +08:00
Dave Kerr	10937886b7	Merge pull request #388 from hituzi-no-sippo/fix-typo-in-JP Fix typo in JP	2022-03-07 15:54:30 +08:00
hituzi no sippo	6ec4ecf503	Fix typo in JP	2022-03-05 05:02:06 +09:00
天井冴太	c42fa2179e	Fix a typo in Japanese translation	2022-03-05 01:00:47 +09:00
Marcos Valle	f9ff7d844d	Add Twyman's rule for data analysis	2022-02-13 17:39:00 +01:00
Dave Kerr	73010181d9	Merge pull request #381 from gmw/main Minor grammar and punctuation fixes	2022-02-03 12:24:58 +08:00
Magnus Wissler	e24acac797	Minor grammar and punctuation fixes	2022-02-02 15:44:22 +01:00
Dave Kerr	adc57da407	Merge pull request #377 from ohno418/translate-linus-law-in-jp Translate Linus's Law in JP	2022-01-31 06:47:22 -07:00
ohno418	743595fee3	Translate Linus's Law in JP	2022-01-31 19:08:19 +09:00
Thomas Merz	36492867d3	Added Clarke's three laws for issues/375	2022-01-20 13:35:50 +01:00
Dave Kerr	f15e6fdb0c	Merge pull request #373 from truonghoangnguyen/vietnamese add Vietnamese language	2022-01-17 22:33:14 -07:00
guen	a45f5ba757	add Vietnamese language	2022-01-17 15:37:13 +07:00
Dave Kerr	8b280bee13	Merge pull request #372 from wppoland/patch-1 update url	2022-01-16 17:53:17 -07:00
Mariusz Szatkowski	58c08b093b	update url	2022-01-15 14:06:19 +01:00
Dave Kerr	70b03354a8	docs: update table of contents	2022-01-13 13:58:16 +08:00
Dave Kerr	847757c98d	Merge pull request #348 from puremana/law-of-the-instrument Add The Law of the Instrument	2022-01-12 22:56:50 -07:00
Dave Kerr	4b6d9b969c	Merge pull request #370 from k0gen/main pl.md	2022-01-11 21:06:36 -07:00
Mariusz Kogen	db065cf9a9	images link fix	2022-01-09 00:41:55 +01:00
Mariusz Kogen	0a412ff6ae	Merge pull request #1 from k0gen/gitlocalize-17834 initial translation	2022-01-09 00:29:15 +01:00
mt-gitlocalize	c6a173755e	Translate pl.md via GitLocalize	2022-01-08 23:28:12 +00:00
Mariusz Kogen	1ca5cb9345	Translate pl.md via GitLocalize	2022-01-08 23:28:12 +00:00
Hasitha N. Liyanage	ff00ccc5c3	Update README.md	2022-01-08 20:10:16 +05:30
Hasitha N. Liyanage	269991a7cf	Update README.md	2022-01-08 19:54:27 +05:30
Hasitha N. Liyanage	0baacdbdcc	Update README.md	2022-01-08 19:52:15 +05:30
Dave Kerr	e42035062e	Merge pull request #368 from k0gen/patch-1 Polish translation 🇵🇱	2022-01-07 23:59:41 -07:00
Mariusz Kogen	26e001b5b9	Polish translation 🇵🇱	2022-01-07 15:20:33 +01:00
Dave Kerr	70970880d4	docs: update link to translator guide	2022-01-07 13:33:06 +08:00
Dave Kerr	9d2ea60824	docs: update contributing guides for translators	2022-01-07 13:31:12 +08:00
Dave Kerr	896c87f24b	Merge pull request #367 from kelvins/fix-pt-br-typos Fix typos related to the pt-BR translation	2022-01-06 01:50:11 -07:00
Kelvin S. do Prado	016c849a0f	Fix typos related to the pt-BR translation	2022-01-05 19:02:57 -03:00
Dave Kerr	ff2732697f	docs: update license year	2022-01-03 22:02:06 -07:00
Dave Kerr	e3a242e974	Merge pull request #360 from underq/patch-1 FR typo and markdown fix	2022-01-03 19:40:16 -07:00
Delangue Benjamin	813582f8a5	Update fr.md	2022-01-03 21:00:34 +01:00
Dave Kerr	fa8016129e	Merge pull request #359 from ferrarienz0/patch-1 Fix typo on "Efeito de Otimização Prematura"	2022-01-03 06:26:24 -07:00
Enzo Ferrari	31e92a434c	Fix typo on "Efeito de Otimização Prematura" No entando => No entanto	2022-01-03 09:02:24 -03:00
Dave Kerr	6635e8da51	Merge pull request #356 from maekawatoshiki/fix Fix jp typo	2022-01-03 03:29:03 -07:00
Dave Kerr	3b78ae65f0	Merge pull request #358 from pusewicz/patch-1 fix: remove superfluous 'is'	2022-01-03 03:20:03 -07:00
Piotr Usewicz	9ebebefa0e	Remove is	2022-01-03 10:14:00 +01:00
maekawatoshiki	d6cb586e80	Fix jp typo	2022-01-02 18:01:09 +09:00
Dave Kerr	0ace74c8c2	Update contributing.md	2021-11-10 09:03:43 +08:00
Dave Kerr	193118ff2d	Merge pull request #350 from Joshua-rose/feat/Darkmode-image-support Added white background to transparent images	2021-11-10 09:00:38 +08:00
Joshua-Rose	7ed9f3d6ba	Added white background to transparent images	2021-11-04 20:45:20 -05:00
puremana	619eabc9d2	Add references for quotes	2021-10-05 12:59:16 +13:00
puremana	9baa224340	Add The Law of the Instrument	2021-10-05 12:56:00 +13:00
Dave Kerr	f4e0acf525	chore: fix spelling of Chesterton	2021-04-19 14:34:54 +08:00
Dave Kerr	716aef807e	Merge pull request #342 from dwmkerr/feat/scout-rule feat: the scout rule	2021-04-19 14:25:24 +08:00
Dave Kerr	c6fccf4978	feat: the scout rule Closes #144	2021-04-19 14:24:32 +08:00
Dave Kerr	8152d6ffbb	Merge pull request #340 from Leyka/french-fix Add few corrections to French translation	2021-03-29 11:37:51 +08:00
Skander	15bc98a2fc	Add few corrections to French translation	2021-03-28 19:49:18 -04:00
Dave Kerr	96aade10ff	chore: update contributor guidelines Closes #209.	2021-02-23 17:58:46 +08:00
Dave Kerr	ddfa99d017	Merge pull request #328 from franciscogaluppo/minor-change Change in "The Two Pizza Rule"	2020-12-10 13:01:27 +08:00
Francisco Galuppo Azevedo	9bf87e4d37	Change in "The Two Pizza Rule" In "The Two Pizza Rule" there is the following statement: > This is supported by the fact that as the team size increases linearly, the links between people increases exponentially; thus the cost of coordinating and communicating also grows exponentially. But clearly the links growth is _quadratic_. The author even acknowledge that: > The number of links between people can be expressed as n(n-1)/2 where n = number of people.	2020-12-09 11:01:32 -03:00
Dave Kerr	887b9d3f20	refactor: refine the content on the dunning-kruger effect	2020-12-03 17:37:04 +08:00
Dave Kerr	34c38d87ed	feat: Dunning-Kruger Effect (#318 )	2020-12-03 16:11:39 +08:00
Akash Chandwani	7da3edd242	Added blockquote for the text from wikipedia	2020-11-19 12:05:14 +05:30
Redowan Delowar	bc041dbf62	Updated the link concerning software entropy (#322 )	2020-11-12 21:56:07 +08:00
Dave Kerr	015d25197f	feat: add ukranian language to README (#320 ) Fixes #236	2020-10-27 00:44:02 +08:00
Nicu Borta	a07ab62114	chore: Remove whitespace (#319 )	2020-10-21 09:56:43 +08:00
Akash Chandwani	2cd30d0845	Add explaination and real world example	2020-10-18 11:22:47 +05:30
Akash Chandwani	3dbc237c1f	feat: Dunning Kruger Effect	2020-10-17 23:57:42 +05:30
leocaraballo	7b341fc0d2	fix: Fix section's links (#317 ) Corrected wrong self-links for the following sections: * The Fallacies of Distributed Computing * The Pareto Principle (The 80/20 Rule)	2020-10-13 09:17:38 +08:00
Dave Kerr	d8df4603ca	docs: note on ebook creation	2020-10-01 18:16:08 +08:00
Thomas Güttler	e96ae13977	Added input-processing-output	2020-08-05 17:25:13 +02:00