├── .all-contributorsrc
├── .github
├── CHANGELOG.md
├── CODE_OF_CONDUCT.md
├── FUNDING.yml
├── contributing.md
├── makefile
├── pull_request_template.md
├── release-please-config.json
├── release-please-manifest.json
├── website
│ ├── backup
│ │ ├── ideas.md
│ │ ├── index2.html
│ │ ├── index3.html
│ │ └── index4.html
│ ├── build
│ │ └── .gitignore
│ ├── generate.py
│ ├── makefile
│ ├── requirements.txt
│ └── src
│ │ ├── favicon.svg
│ │ ├── index.html.jinja
│ │ ├── script.js
│ │ └── styles.css
└── workflows
│ └── cicd.yaml
├── .gitignore
├── LICENSE
├── README.md
├── assets
├── banner.png
├── banner.psd
├── diagrams.bmpr
├── repository-open-graph-template.png
└── site
│ ├── index.html
│ ├── index2.html
│ ├── index3.html
│ └── index4.html
├── images
├── Fitts_Law.svg
├── amdahls_law.png
├── changelog-podcast.png
├── complete_graph.png
├── gartner_hype_cycle.png
├── gitlocalize.png
└── hicks_law.svg
├── scripts
└── prepare-markdown-for-ebook.sh
└── translations
├── es-ES.md
├── fr.md
├── id.md
├── it-IT.md
├── jp.md
├── lv.md
├── pl.md
├── pt-BR.md
├── tr.md
└── vi.md
/.all-contributorsrc:
--------------------------------------------------------------------------------
1 | {
2 | "files": [
3 | "README.md"
4 | ],
5 | "imageSize": 100,
6 | "commit": false,
7 | "commitType": "docs",
8 | "commitConvention": "angular",
9 | "contributors": [
10 | {
11 | "login": "hemmatt",
12 | "name": "Amir Hemmati",
13 | "avatar_url": "https://avatars.githubusercontent.com/u/22114089?v=4",
14 | "profile": "https://github.com/hemmatt",
15 | "contributions": [
16 | "doc"
17 | ]
18 | }
19 | ],
20 | "contributorsPerLine": 7,
21 | "skipCi": true,
22 | "repoType": "github",
23 | "repoHost": "https://github.com",
24 | "projectName": "hacker-laws",
25 | "projectOwner": "dwmkerr"
26 | }
27 |
--------------------------------------------------------------------------------
/.github/CHANGELOG.md:
--------------------------------------------------------------------------------
1 | # Changelog
2 |
3 | ## [0.3.2](https://github.com/dwmkerr/hacker-laws/compare/v0.3.1...v0.3.2) (2025-03-31)
4 |
5 |
6 | ### Bug Fixes
7 |
8 | * update ebook download link ([4546562](https://github.com/dwmkerr/hacker-laws/commit/454656237d9508c8fadafffbc1c1286fc134f8cf))
9 |
10 | ## [0.3.1](https://github.com/dwmkerr/hacker-laws/compare/v0.3.0...v0.3.1) (2025-03-31)
11 |
12 |
13 | ### Bug Fixes
14 |
15 | * effective shell links ([6353fe4](https://github.com/dwmkerr/hacker-laws/commit/6353fe4b8f044456d66dac0af950e41989c56c5a))
16 |
17 | ## [0.3.0](https://github.com/dwmkerr/hacker-laws/compare/v0.2.1...v0.3.0) (2025-03-31)
18 |
19 |
20 | ### Features
21 |
22 | * add Koomey's Law ([dcdcfdf](https://github.com/dwmkerr/hacker-laws/commit/dcdcfdfc25ee121b6bcb931a71e185fa7ffeedcd))
23 |
24 | ## [0.2.1](https://github.com/dwmkerr/hacker-laws/compare/v0.2.0...v0.2.1) (2025-03-31)
25 |
26 |
27 | ### Bug Fixes
28 |
29 | * remove frontmatter ([2140429](https://github.com/dwmkerr/hacker-laws/commit/2140429b959a8284b452c3fa05e1c9fd03e5ebab))
30 |
31 | ## [0.2.0](https://github.com/dwmkerr/hacker-laws/compare/v0.1.0...v0.2.0) (2025-03-31)
32 |
33 |
34 | ### Features
35 |
36 | * 90-90 rule ([4477907](https://github.com/dwmkerr/hacker-laws/commit/44779074caa6495198214100e5bd0a886cc1e680))
37 | * add section for Kerckhoff's principle ([5f74607](https://github.com/dwmkerr/hacker-laws/commit/5f74607c63d3a76009ec0546ba515f8f7c1d3864))
38 | * add ukranian language to README ([#320](https://github.com/dwmkerr/hacker-laws/issues/320)) ([015d251](https://github.com/dwmkerr/hacker-laws/commit/015d25197f808d66c4dfebcdd0b54675af6a3eae)), closes [#236](https://github.com/dwmkerr/hacker-laws/issues/236)
39 | * Dunning Kruger Effect ([3dbc237](https://github.com/dwmkerr/hacker-laws/commit/3dbc237c1f1c59e809969320cc0ae4347a4b45c3))
40 | * Dunning-Kruger Effect ([#318](https://github.com/dwmkerr/hacker-laws/issues/318)) ([34c38d8](https://github.com/dwmkerr/hacker-laws/commit/34c38d87edba4b0e36d2ad9488b97d0c77f9b550))
41 | * **pages:** update index.html and pages.yaml for deployment ([beb3d57](https://github.com/dwmkerr/hacker-laws/commit/beb3d57a6a5a3a38aa9e692ed13eb01060b85ded))
42 | * principle of least astonishment ([4be4827](https://github.com/dwmkerr/hacker-laws/commit/4be482731b6a6009453af7d303d3cd2470a2e73e))
43 | * principle of least astonishment ([e4662cb](https://github.com/dwmkerr/hacker-laws/commit/e4662cbc27d04fb968220837633034420b7fb11a))
44 | * the scout rule ([716aef8](https://github.com/dwmkerr/hacker-laws/commit/716aef807e758bd8df976f323089db525da9f708))
45 | * the scout rule ([c6fccf4](https://github.com/dwmkerr/hacker-laws/commit/c6fccf4978d9483637fba8c7887127abad3de581)), closes [#144](https://github.com/dwmkerr/hacker-laws/issues/144)
46 | * twyman's law ([b9ad4c6](https://github.com/dwmkerr/hacker-laws/commit/b9ad4c6f99f991a1bda9a2cfdddef62787e6ae82))
47 |
48 |
49 | ### Bug Fixes
50 |
51 | * correct facebook link on website ([6f9b1e3](https://github.com/dwmkerr/hacker-laws/commit/6f9b1e33345bc1332428f0fba8c7aa2900147500))
52 | * correct formatting around quote ([d83d439](https://github.com/dwmkerr/hacker-laws/commit/d83d439df89e8af50ae53bafa3a791f8d92a6991))
53 | * Fix section's links ([#317](https://github.com/dwmkerr/hacker-laws/issues/317)) ([7b341fc](https://github.com/dwmkerr/hacker-laws/commit/7b341fc0d205f076e25ff8fedb972e652201c3c6))
54 | * image paths ([692b7cc](https://github.com/dwmkerr/hacker-laws/commit/692b7cca1a97eb62384db170297b504f51ea408e))
55 | * remove superfluous 'is' ([3b78ae6](https://github.com/dwmkerr/hacker-laws/commit/3b78ae65f02fca457bb8adbf113135e1ed042a46))
56 |
--------------------------------------------------------------------------------
/.github/CODE_OF_CONDUCT.md:
--------------------------------------------------------------------------------
1 | # Contributor Covenant Code of Conduct
2 |
3 | ## Our Pledge
4 |
5 | In the interest of fostering an open and welcoming environment, we as
6 | contributors and maintainers pledge to making participation in our project and
7 | our community a harassment-free experience for everyone, regardless of age, body
8 | size, disability, ethnicity, sex characteristics, gender identity and expression,
9 | level of experience, education, socio-economic status, nationality, personal
10 | appearance, race, religion, or sexual identity and orientation.
11 |
12 | ## Our Standards
13 |
14 | Examples of behavior that contributes to creating a positive environment
15 | include:
16 |
17 | * Using welcoming and inclusive language
18 | * Being respectful of differing viewpoints and experiences
19 | * Gracefully accepting constructive criticism
20 | * Focusing on what is best for the community
21 | * Showing empathy towards other community members
22 |
23 | Examples of unacceptable behavior by participants include:
24 |
25 | * The use of sexualized language or imagery and unwelcome sexual attention or
26 | advances
27 | * Trolling, insulting/derogatory comments, and personal or political attacks
28 | * Public or private harassment
29 | * Publishing others' private information, such as a physical or electronic
30 | address, without explicit permission
31 | * Other conduct which could reasonably be considered inappropriate in a
32 | professional setting
33 |
34 | ## Our Responsibilities
35 |
36 | Project maintainers are responsible for clarifying the standards of acceptable
37 | behavior and are expected to take appropriate and fair corrective action in
38 | response to any instances of unacceptable behavior.
39 |
40 | Project maintainers have the right and responsibility to remove, edit, or
41 | reject comments, commits, code, wiki edits, issues, and other contributions
42 | that are not aligned to this Code of Conduct, or to ban temporarily or
43 | permanently any contributor for other behaviors that they deem inappropriate,
44 | threatening, offensive, or harmful.
45 |
46 | ## Scope
47 |
48 | This Code of Conduct applies both within project spaces and in public spaces
49 | when an individual is representing the project or its community. Examples of
50 | representing a project or community include using an official project e-mail
51 | address, posting via an official social media account, or acting as an appointed
52 | representative at an online or offline event. Representation of a project may be
53 | further defined and clarified by project maintainers.
54 |
55 | ## Enforcement
56 |
57 | Instances of abusive, harassing, or otherwise unacceptable behavior may be
58 | reported by contacting the project team at dwmkerr@gmail.com. All
59 | complaints will be reviewed and investigated and will result in a response that
60 | is deemed necessary and appropriate to the circumstances. The project team is
61 | obligated to maintain confidentiality with regard to the reporter of an incident.
62 | Further details of specific enforcement policies may be posted separately.
63 |
64 | Project maintainers who do not follow or enforce the Code of Conduct in good
65 | faith may face temporary or permanent repercussions as determined by other
66 | members of the project's leadership.
67 |
68 | ## Attribution
69 |
70 | This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
71 | available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
72 |
73 | [homepage]: https://www.contributor-covenant.org
74 |
75 | For answers to common questions about this code of conduct, see
76 | https://www.contributor-covenant.org/faq
77 |
--------------------------------------------------------------------------------
/.github/FUNDING.yml:
--------------------------------------------------------------------------------
1 | # Support 'GitHub Sponsors' funding.
2 | github: dwmkerr
3 |
--------------------------------------------------------------------------------
/.github/contributing.md:
--------------------------------------------------------------------------------
1 | # Contributing Guidelines
2 |
3 |
4 |
5 | - [Goal of the Project](#goal-of-the-project)
6 | - [Example Law: The Law of Leaky Abstractions](#example-law-the-law-of-leaky-abstractions)
7 | - [Translations](#translations)
8 | - [How do I know if a law is relevant?](#how-do-i-know-if-a-law-is-relevant)
9 | - [How do I know if a law is 'well known' enough?](#how-do-i-know-if-a-law-is-well-known-enough)
10 | - [Use of Images](#use-of-images)
11 | - [Developer Guide](#developer-guide)
12 |
13 |
14 |
15 | ## Goal of the Project
16 |
17 | 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:
18 |
19 | 1. Short - one or two paragraphs.
20 | 2. Include the original source.
21 | 3. Quote the law if possible, with the author's name.
22 | 4. Link to related laws in the 'See also' section.
23 | 5. Include real-world examples if possible in the 'Real-world examples' section.
24 |
25 | Some other tips:
26 |
27 | - It is fine to include laws which are humorous or not serious.
28 | - If a law does not obviously apply to development or coding, include a paragraph explaining the relevance to technologists.
29 | - Don't worry about managing the table of contents, I can generate it.
30 | - Feel free to include images, but aim to keep it down to one image per law.
31 | - Be careful not to copy-and-paste content (unless it is explicitly quoted), as it might violate copyright.
32 | - Include hyperlinks to referenced material.
33 | - Do not advocate for the law, or aim to be opinionated on the correctness or incorrectness of the law, as this repository is simply the descriptions and links.
34 | - Avoid 'you' when writing. For example, prefer "This law suggests refactoring should be avoided when..." rather than "you should avoid refactoring when...". This keeps the style slightly more formal and avoids seeming like advocation of a law.
35 |
36 | An example law is shown below, which covers most of the key points:
37 |
38 | ---
39 |
40 | ## Example Law: The Law of Leaky Abstractions
41 |
42 | [The Law of Leaky Abstractions on Joel on Software](https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/)
43 |
44 | > All non-trivial abstractions, to some degree, are leaky.
45 | >
46 | > (Joel Spolsky)
47 |
48 | This law states that abstractions, which are generally used in computing to simplify working with complicated systems, will in certain situations 'leak' elements of the underlying system, this making the abstraction behave in an unexpected way.
49 |
50 | An example might be loading a file and reading its contents. The file system APIs are an _abstraction_ of the lower level kernel systems, which are themselves an abstraction over the physical processes relating to changing data on a magnetic platter (or flash memory for an SSD). In most cases, the abstraction of treating a file like a stream of binary data will work. However, for a magnetic drive, reading data sequentially will be *significantly* faster than random access (due to increased overhead of page faults), but for an SSD drive, this overhead will not be present. Underlying details will need to be understood to deal with this case (for example, database index files are structured to reduce the overhead of random access), the abstraction 'leaks' implementation details the developer may need to be aware of.
51 |
52 | The example above can become more complex when _more_ abstractions are introduced. The Linux operating system allows files to be accessed over a network, but represented locally as 'normal' files. This abstraction will 'leak' if there are network failures. If a developer treats these files as 'normal' files, without considering the fact that they may be subject to network latency and failures, the solutions will be buggy.
53 |
54 | The article describing the law suggests that an over-reliance on abstractions, combined with a poor understanding of the underlying processes, actually makes dealing with the problem at hand _more_ complex in some cases.
55 |
56 | See also:
57 |
58 | - [Hyrum's Law](#hyrums-law-the-law-of-implicit-interfaces)
59 |
60 | Real-world examples:
61 |
62 | - [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.
63 |
64 | ## Translations
65 |
66 | 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:
67 |
68 | 
69 |
70 | If you would like to moderate a language, please follow the steps below:
71 |
72 | 1. Log in to [Git Localize](https://gitlocalize.com) with your GitHub account, this will create a GitLocalize account for you.
73 | 0. [Open an Issue](https://github.com/dwmkerr/hacker-laws/issues/new) with the name of the language you would like to moderate/translate.
74 | 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.
75 | 3. I will then make you a moderator of the language and ensure the language is listed properly.
76 |
77 | Thanks!
78 |
79 |
80 | ## How do I know if a law is relevant?
81 |
82 | In general, it should be reasonably applicable to the world of computer sciences, IT or coding in general.
83 |
84 | ## How do I know if a law is 'well known' enough?
85 |
86 | A good test is 'If I search for it on Google, will I find it in the first few results?'.
87 |
88 | ## Use of Images
89 |
90 | 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.
91 |
92 | ## Developer Guide
93 |
94 | Where possible, anything which is not the core `README.md` file is kept in the `.github/` folder to keep the landing page for the repository as clean as possible.
95 |
96 | To use the makefile, pass its path explicitly, e.g:
97 |
98 | ```bash
99 | make -f .github/makefile
100 | ```
101 |
102 | Or create an alias:
103 |
104 | ```bash
105 | alias hlmake="make -f .github/makefile"
106 |
--------------------------------------------------------------------------------
/.github/makefile:
--------------------------------------------------------------------------------
1 | default: help
2 |
3 | .PHONY: help
4 | help: # Show help for each of the Makefile recipes.
5 | @grep -E '^[a-zA-Z0-9 -]+:.*#' Makefile | sort | while read -r l; do printf "\033[1;32m$$(echo $$l | cut -f 1 -d':')\033[00m:$$(echo $$l | cut -f 2- -d'#')\n"; done
6 |
7 | .PHONY: prepare-markdown
8 | prepare-markdown: # Prepare the markdown for PDF output.
9 | ./scripts/prepare-markdown-for-ebook.sh "README.md" "hacker-laws.md"
10 |
11 | .PHONY: create-pdf
12 | create-pdf: # Create the PDF.
13 | docker run --rm \
14 | --platform linux/amd64 \
15 | -v ${PWD}:/data \
16 | pandoc/latex:3.6 \
17 | -V toc-title:"Table Of Contents" \
18 | --toc \
19 | --pdf-engine=lualatex \
20 | --standalone \
21 | --output hacker-laws.pdf \
22 | hacker-laws.md
23 |
--------------------------------------------------------------------------------
/.github/pull_request_template.md:
--------------------------------------------------------------------------------
1 | **Pull Request Checklist**
2 |
3 | Please double check the items below!
4 |
5 | - [ ] I have read the [Contributor Guidelines](https://github.com/dwmkerr/hacker-laws/blob/master/.github/contributing.md).
6 | - [ ] I have not directly copied text from another location (unless explicitly indicated as a quote) or violated copyright.
7 | - [ ] I have linked to the original Law.
8 | - [ ] I have quote the law (if possible) and the author's name (if possible).
9 | - [ ] I am happy to have my changes merged, so that I appear as a contributor, but also the text altered if required to keep the language consistent in the project.
10 |
11 | And don't forget:
12 |
13 | - I can handle the table of contents, feel free to leave it out.
14 | - Check to see if other laws should link back to the law you have added.
15 | - Include your **Twitter Handle** if you want me to include you when tweeting this update!
16 |
--------------------------------------------------------------------------------
/.github/release-please-config.json:
--------------------------------------------------------------------------------
1 | {
2 | "release-type": "simple",
3 | "bump-minor-pre-major": true,
4 | "packages": {
5 | ".": {
6 | "release-type": "simple",
7 | "extra-files": [
8 | {
9 | "type": "generic",
10 | "path": "README.md"
11 | }
12 | ],
13 | "changelog-path": ".github/CHANGELOG.md"
14 | }
15 | }
16 | }
17 |
18 |
19 |
--------------------------------------------------------------------------------
/.github/release-please-manifest.json:
--------------------------------------------------------------------------------
1 | {
2 | ".": "0.3.2"
3 | }
4 |
--------------------------------------------------------------------------------
/.github/website/backup/ideas.md:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/dwmkerr/hacker-laws/6f4ff0d3b2adf543e6d32040c81e53ca54f03252/.github/website/backup/ideas.md
--------------------------------------------------------------------------------
/.github/website/backup/index2.html:
--------------------------------------------------------------------------------
1 |
2 |
3 |
Laws, Theories, Principles and Patterns that developers will find useful.
94 |
95 |
96 |
97 |
98 |
99 |
100 |
Introduction
101 |
There are lots of laws which people discuss when talking about development. This repository is a reference and overview of some of the most common ones. Please share and submit PRs!
102 |
Note: This repo contains an explanation of some laws, principles and patterns, but does not advocate for any of them. Whether they should be applied will always be a matter of debate, and greatly dependent on what you are working on.
The 90-9-1 principle suggests that within an internet community such as a wiki, 90% of participants only consume content, 9% edit or modify content and 1% of participants add content.
127 |
Real-world examples:
128 |
129 |
A 2014 study of four digital health social networks found the top 1% created 73% of posts, the next 9% accounted for an average of ~25% and the remaining 90% accounted for an average of 2%.
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.
150 |
This is a wry reinterpretation of the Pareto Principle (or 80-20 rule) that highlights the real-world challenges of completing engineering work. This sentiment is also echoed in Hofstadter's Law.
Laws, Theories, Principles and Patterns that developers will find useful.
107 |
108 |
109 |
110 |
111 |
112 |
113 |
Introduction
114 |
There are lots of laws which people discuss when talking about development. This repository is a reference and overview of some of the most common ones. Please share and submit PRs!
115 |
Note: This repo contains an explanation of some laws, principles and patterns, but does not advocate for any of them. Whether they should be applied will always be a matter of debate, and greatly dependent on what you are working on.
The 90-9-1 principle suggests that within an internet community such as a wiki, 90% of participants only consume content, 9% edit or modify content and 1% of participants add content.
134 |
Real-world examples:
135 |
136 |
A 2014 study of four digital health social networks found the top 1% created 73% of posts, the next 9% accounted for an average of ~25% and the remaining 90% accounted for an average of 2%.
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.
157 |
This is a wry reinterpretation of the Pareto Principle (or 80-20 rule) that highlights the real-world challenges of completing engineering work. This sentiment is also echoed in Hofstadter's Law.