# Every Programmer Should Know — User Guide

A reader's guide to the curated list at [github.com/mtdvio/every-programmer-should-know](https://github.com/mtdvio/every-programmer-should-know): what it is, what it contains, and how to get real value from it without drowning in links.

> [!NOTE]
> This project is **not software**. There is nothing to install, run, or configure. It is a single, opinionated `README.md` that links to books, articles, papers, talks, and practice sites organized into topics every working programmer benefits from studying.

---

## 1. Quick Start

If you have five minutes right now, do these three things.

1. Open the list at [github.com/mtdvio/every-programmer-should-know](https://github.com/mtdvio/every-programmer-should-know).
2. Scan the section headings on the right-hand table of contents (Introduction, Falsehoods, Algorithms, Data Structures, Numbers, Strings, Latency, Time, Memory, Distributed Systems, Machine Learning, RegExp, Security, UX/Usability, SEO, Architecture, Code Design, Engineering Philosophy, Practices, Career, Open Source, Remote Work, Problem Solving, Soft Skills, Mental Health, Papers on Programming, Free Books on Programming, Services, Licenses, Where To Look For Further Info, Coding Practice Sites, Learning through entertainment, Platform Engineering).
3. Pick **one** section that matches either a current gap in your knowledge or a topic you touched this week. Open one resource from it. Close everything else.

> [!TIP]
> The list is long on purpose, but the value comes from reading *one resource at a time*, not from bookmarking the whole page. Treat it like a bookshelf, not a checklist.

---

## 2. What This Project Is

A hand-curated collection of (mostly) technical resources the maintainer, Dmitri Grabov ([@mtdvio](https://github.com/mtdvio)), recommends to every programmer "regardless of their skill level or tech stack".

Key framing, taken directly from the project:

- **Highly opinionated.** One curator's picks, not a consensus document.
- **Not backed by science.** No study ranked these resources. They are recommended because the curator found them valuable.
- **In no particular order.** Sections are thematic; items inside a section are not ranked best-to-worst.
- **You do not need to know all of this.** The project's own preamble quotes [xkcd 1050](https://xkcd.com/1050/) — nobody has mastered everything on the list, and that is fine.

> [!IMPORTANT]
> The value of this list is *curation*, not comprehensiveness. If a topic has three entries and a bigger list elsewhere has thirty, the three here are the ones the curator vouches for personally. Use that signal.

### What is **not** here

- Package downloads, binaries, or runnable code.
- Language-specific tutorials. The list is tech-stack agnostic.
- Endless newsletters, forums, or blogs. The curator explicitly excludes "endless stream resources" as noise.
- Anything the curator has not personally evaluated (per the contribution rules — see Admin Guide).

---

## 3. How To Read The List

### 3.1 The resource-type emojis

Every entry is prefixed with an emoji that tells you, at a glance, what kind of resource it is. The emoji vocabulary is defined in `CONTRIBUTING.md`:

| Emoji | Meaning |
|-------|---------|
| `:movie_camera:` 🎥 | Video or talk |
| `:book:` 📖 | Book |
| `:page_facing_up:` 📄 | Online article |
| `:scroll:` 📜 | Academic paper or long-form document |
| `:white_check_mark:` ✅ | Checklist |

Other emojis appear in practice (`:link:` for practice-site links, `:newspaper:` for journal-style sources, `:school:` for courses, `:moneybag:` for salary/compensation references, `:globe_with_meridians:` for remote-work references, `:hammer:` for tools, `:zap:` / `:fire:` / `:heart:` as curator emphasis) but the five above are the officially documented vocabulary.

> [!TIP]
> When you have 20 minutes, look for 📄. When you have two hours, look for 🎥. When you have two weeks, look for 📖. When you have a flight, download a 📜.

### 3.2 Section structure

Each section is a plain Markdown `###` heading followed by a bulleted list. Most bullets are one line: emoji + link + (optional) short note. A few sections (Platform Engineering, for example) use nested bullets with expanded annotations. There is no ranking inside a section.

### 3.3 How to work through a topic

A proven reading loop for any topic on the list:

- [ ] Pick one section you care about this month.
- [ ] Read the section top-to-bottom in under two minutes to get the shape of it.
- [ ] Open **one** resource. Ignore the rest.
- [ ] Read/watch it end-to-end before returning to the list.
- [ ] Write a 3-sentence note to yourself: what did you learn, what surprised you, what will you do differently.
- [ ] Only then pick the next resource.

> [!WARNING]
> The single biggest failure mode is opening 15 tabs and closing them all a week later unread. The list is optimized for depth, not tab count.

---

## 4. What Each Section Covers

This is an overview of every top-level section in the list as of the current version, so you can jump straight to what you need. See the live list for the exact current entries.

### Introduction
Starting points for orienting yourself in computer science as a field. Videos, articles, and community-driven roadmaps like [roadmap.sh/computer-science](https://roadmap.sh/computer-science) and [kamranahmedse/developer-roadmap](https://github.com/kamranahmedse/developer-roadmap).

**Read this section when:** you are early in your career, switching fields, or want a wall-sized mental map of CS.

### Falsehoods
Pointers to the "Awesome Falsehoods" collection — curated lists of beliefs programmers hold that are wrong (about names, addresses, time zones, email, numbers, strings, etc.).

**Read this section when:** you are about to design a schema, a form, a parser, or anything that touches user data.

### Algorithms
Big-O cheat sheet, *Computer Science Distilled*, *Grokking Algorithms*, *Introduction to Algorithms* (CLRS), algorithm visualizations, and the [cp-algorithms.com](https://cp-algorithms.com/) reference.

**Read this section when:** you are preparing for an interview, hitting performance ceilings, or writing your first serious data-processing pipeline.

### Data Structures
*Hello Algo*, UC Berkeley's data structures course, EDX, Coursera, and Eric Lehman's *Mathematics for Computer Science*.

**Read this section when:** you can solve problems but your first instinct for "how to store this" is always the same hash map.

### Numbers
*How to Count*, [floating-point-gui.de](http://floating-point-gui.de/), Goldberg's classic *What Every Computer Scientist Should Know About Floating-Point Arithmetic*, and CodeChef's number-theory primer.

**Read this section when:** you have ever been surprised by `0.1 + 0.2 != 0.3`, or you work on anything involving money, physics, or IDs.

### Strings
Joel Spolsky's *Unicode and Character Sets*, the homoglyph project, the Unicode CLDR, and explanatory videos on ASCII and UTF-8.

**Read this section when:** you have ever had a production incident involving `?`, mojibake, emoji, or user input from outside the ASCII range.

### Latency
Peter Norvig / Jeff Dean's *Latency Numbers Every Programmer Should Know* and the Berkeley interactive infographic.

**Read this section when:** you are designing anything whose performance matters. Memorize the orders of magnitude; they make you a better engineer immediately.

### Time
Notes on time and *The Problem with Timezones*.

**Read this section when:** you schedule, bill, log, synchronize, audit, or display anything to humans.

### Memory
Ulrich Drepper's *What Every Programmer Should Know About Memory* (the paper — the list references it twice, which tells you how important the curator thinks it is).

**Read this section when:** you work close to the metal: systems programming, databases, game engines, performance-sensitive services.

### Distributed Systems
*Understanding Distributed Systems*, *Designing Data-Intensive Applications* (Kleppmann), Jeff Dean's *Designs, Lessons and Advice*, Lamport's *Time, Clocks and the Ordering of Events*, *There is No Now*, Kyle Kingsbury's Jepsen series, and the *Fallacies of Distributed Computing*.

**Read this section when:** your system runs on more than one machine. Which is almost always.

### Machine Learning
Andrew Ng's Coursera Machine Learning Specialization.

**Read this section when:** you want a solid first pass on the ML fundamentals. The curator deliberately keeps this short — quality over quantity.

### RegExp
RegexHQ, [learn-regex](https://github.com/ziishaned/learn-regex), and [Regex Crossword](https://regexcrossword.com/).

**Read this section when:** you want to stop copy-pasting regexes from Stack Overflow and start writing them.

### Security
*Security Programming*, *Rolling Your Own Crypto*, *Cryptographic Right Answers*, *Foundations of Security*, [OWASP Top 10](https://owasp.org/www-project-top-ten), [PortSwigger Academy](https://portswigger.net), *Web Application Exploits and Defenses* (Google Gruyere), and *Hashing, Encryption and Encoding*.

**Read this section when:** you touch user accounts, money, PII, or anything internet-facing. PortSwigger Academy and the OWASP Top 10 are the practical starting points.

> [!IMPORTANT]
> *Cryptographic Right Answers* is specifically calibrated for application developers who should **not** be inventing crypto. Read it before you reach for `crypto.createCipher()`.

### UX/Usability
*Don't Make Me Think* and Bret Victor's *Inventing on Principle*.

**Read this section when:** you ship anything that a human — other than you — is expected to use.

### SEO
*What Every Programmer Should Know About SEO*.

**Read this section when:** you are responsible for a site whose reach matters.

### Architecture
*A Field Guide to Boxology*, *Out of the Tar Pit*, *No Silver Bullet* (Brooks), Guy Steele's *Growing a Language*, CQRS & Event Sourcing talks, *Practical Object-Oriented Design in Ruby*, *Evolutionary Software Architectures*, [System Design Primer](https://github.com/donnemartin/system-design-primer), a multi-part series on how JavaScript works internally, and an intro to the Entity-Component-System pattern.

**Read this section when:** you are about to make a structural decision (choosing a pattern, splitting a service, introducing an abstraction) that will be hard to reverse.

### Code Design
The [Programming Principles Wiki](http://www.principles-wiki.net/) — a compact reference to named design principles.

**Read this section when:** you want vocabulary for what you already sense is wrong with a codebase.

### Engineering Philosophy
Rich Hickey's *Simple Made Easy*, *Category Theory in Life*, *#NoEstimates*, *The Myth of the Genius Programmer*, *Making Badass Developers*, *The Debugging Mindset*, Norvig's *Teach Yourself Programming in Ten Years*, and others.

**Read this section when:** you are mid-career and starting to notice that the hardest problems are not technical.

### Practices
*Working Effectively with Legacy Code* (Feathers), *The Art of Readable Code*, *Code Complete*, *Clean Code*, *Test-Driven Development: By Example* (Beck), *Release It!* (Nygard), [going-to-production checklist](https://github.com/mr-mig/going-to-production), *Mostly Adequate Guide to Functional Programming*, *SICP*, *Programming Paradigms for Dummies*, [Learn X in Y Minutes](https://learnxinyminutes.com/), [Hyperpolyglot](http://hyperpolyglot.org/), *Pomodoro for Programmers*, and Google's free *Site Reliability Engineering* book.

**Read this section when:** you want to level up as a day-to-day practitioner. This is the thickest section for a reason.

### Career
[Levels.fyi](https://www.levels.fyi), *The Passionate Programmer*, *Soft Skills*, *The Complete Software Developer's Career Guide*, *Programming Beyond Practices*, *Ten Rules for Negotiating a Job Offer*, *How To Be A STAR Engineer*, *TL;DR Stock Options*, *The Open Guide to Equity Compensation*, *Equity 101*, *Cracking the Coding Interview*, *Tech Interview Handbook*, *97 things every programmer should know*, *A Philosophy of Software Design*, and more.

**Read this section when:** you are job-hunting, negotiating, evaluating an offer, or thinking about the arc of a 20-year career.

### Fine-tune Your Resume
Pointer to [CV Compiler](https://cvcompiler.com/).

### Open Source
Pointer to a Git + GitHub tutorial ([deployhq.com/git](https://www.deployhq.com/git)).

### Remote Work
Remotive.io, the Remote Work List for Developers, NomadList, Zapier's *Ultimate Guide to Remote Work*, and Awesome Remote Job.

**Read this section when:** you are considering going remote, hiring remotely, or designing an async-first team.

### Problem Solving
*The Art and Craft of Problem Solving* and Polya's *How to Solve It*.

**Read this section when:** you want a framework for approaching novel, ambiguous problems, not just LeetCode.

### Soft Skills
*Difficult Conversations*, *Crucial Conversations*, and *How to Win Friends and Influence People*.

**Read this section when:** the technical problem is solved but the rollout keeps failing for reasons that look a lot like humans.

### Mental Health
[Awesome Mental Health](https://github.com/dreamingechoes/awesome-mental-health) — curated articles and resources on mental health in the software industry.

> [!IMPORTANT]
> Burnout is an engineering risk. Treat this section like the Security section.

### Papers on Programming
*Papers We Love*, Adrian Colyer's *The Morning Paper*, *What Every Programmer Should Know About Memory* (again — Drepper), Dijkstra's *Go To Statement Considered Harmful*, Arxiv, and Sci-Hub.

**Read this section when:** you are ready to stop reading *about* papers and start reading papers.

### Free Books on Programming
[Free Programming Books](https://github.com/EbookFoundation/free-programming-books) — one link, but it is to an 8,000-entry index maintained by the EbookFoundation.

### Services
Abstract API, [Free For Dev](https://github.com/ripienaar/free-for-dev/blob/master/README.md), Public APIs, The Noun Project, *Without Coding* collection, Simple Icons, [Learn Anything](https://learn-anything.xyz/), and [repl.it](https://repl.it/).

**Read this section when:** you need a free/cheap utility, icon, dataset, or sandbox to get moving.

### Licenses
[Choose An Open Source License](https://choosealicense.com/), [tldrlegal.com](https://tldrlegal.com/), and a FreeCodeCamp explainer.

**Read this section when:** you are publishing anything public for the first time, or reviewing a dependency's license for compliance.

### Where To Look For Further Info
freeCodeCamp Guide, GeeksForGeeks, Dev.To, Stack Overflow, and DZone.

### Coding Practice Sites
Over 25 sites including CodeForces, CodeChef, HackerRank, LeetCode, Exercism, CodeSignal, Project Euler, AtCoder, Codility, Codewars, CodinGame, InterviewBit, InterviewCake, and more.

> [!TIP]
> The list does not rank these. Pick one, stick with it for a month, then evaluate. Jumping between sites is procrastination in disguise.

### Learning through entertainment
[Robocode](https://robocode.sourceforge.io/), [Elevator Saga](https://play.elevatorsaga.com/), [Untrusted](https://alexnisnevich.github.io/untrusted/), [CSS Diner](https://flukeout.github.io/), and [CodinGame](https://www.codingame.com/).

**Read this section when:** you want to learn a concept by playing a game instead of reading about it.

### Platform Engineering
The newest section, with nested structure. Covers:

- **What is Platform Engineering** — Microsoft Learn overview, Atlassian's roles/responsibilities explainer.
- **Internal Developer Platform (IDP)** — [internaldeveloperplatform.org](https://internaldeveloperplatform.org/), Atlassian's IDP guide.
- **Golden Paths (Paved Roads)** — Spotify's original Golden Paths writeup and Red Hat's explainer.

**Read this section when:** you work in or with a platform team, or you are standing one up.

---

## 5. Using The List Offline

The list is a single `README.md` file. You can keep a copy anywhere:

=== "Clone the repo"

    ```bash
    git clone https://github.com/mtdvio/every-programmer-should-know.git
    cd every-programmer-should-know
    ```

    ```text
    Cloning into 'every-programmer-should-know'...
    remote: Enumerating objects: ...
    Receiving objects: 100% (.../...)
    ```

=== "Download the README only"

    ```bash
    curl -L -o every-programmer-should-know.md \
      https://raw.githubusercontent.com/mtdvio/every-programmer-should-know/master/README.md
    ```

    ```text
      % Total    % Received % Xferd  Average Speed   Time ...
    100 22241  100 22241    0     0  ...
    ```

=== "Save as PDF"

    Open the repo on GitHub, press **Ctrl+P** / **Cmd+P** in your browser, and save as PDF. GitHub's rendered view prints cleanly.

> [!NOTE]
> Pulling the repo periodically (`git pull`) is the easiest way to stay current. The list is updated via accepted pull requests, not on a release schedule.

---

## 6. Common Tasks

### 6.1 "I joined a team working on X. What should I skim first?"

| X is about... | Jump to section(s) |
|---------------|--------------------|
| Databases, replication, consensus | Distributed Systems, Latency, Time |
| Auth, payments, anything internet-facing | Security, Falsehoods, Strings |
| A new programming language | Practices (Learn X in Y Minutes, Hyperpolyglot) |
| A high-traffic website | Architecture, Latency, SEO, Distributed Systems |
| A rewrite of a legacy system | Practices (*Working Effectively with Legacy Code*), Architecture |
| An ML feature | Machine Learning, Numbers, Papers on Programming |
| Infrastructure / developer tooling | Platform Engineering, Practices (SRE book) |
| A game or graphics engine | Memory, Architecture (ECS), Numbers |
| A parser, compiler, or DSL | Strings, Architecture (*Growing a Language*), Papers |

### 6.2 "I have an interview in two weeks."

- [ ] Algorithms — skim Big-O cheat sheet, work through *Grokking Algorithms* if time allows.
- [ ] Data Structures — drill on the standard set (arrays, hash maps, trees, graphs, heaps).
- [ ] Career → *Cracking the Coding Interview* or *Tech Interview Handbook*.
- [ ] Career → *Ten Rules for Negotiating a Job Offer* (for after the offer).
- [ ] Coding Practice Sites — pick **one** and drill daily.

### 6.3 "My team ships bugs that could have been caught in review."

- [ ] Practices → *The Art of Readable Code* and *Clean Code* (pick one; do not read both cover to cover).
- [ ] Practices → *Code Complete* chapters on defensive programming.
- [ ] Practices → *Release It!* for resilience patterns in production.
- [ ] Falsehoods → whichever list matches the bug domain (names, time zones, etc.).

### 6.4 "I want to contribute a resource."

See the [Admin Guide](mtdvio__every-programmer-should-know__AdminGuide.md#contribution-workflow) for the full contribution workflow. Quick version:

- One resource per PR.
- You must have personally evaluated the resource.
- Use one of the five standard emojis.
- PRs that don't fit the curator's values will be discussed, not silently dropped — the project's explicit rule is *"No PR will be discarded without explanations!"*.

---

## 7. Troubleshooting

### Problem: "A link is broken."

The maintainers track broken links as GitHub issues. Reported examples from the issue tracker include:

- [#731 — SEO Link (OPEN)](https://github.com/mtdvio/every-programmer-should-know/issues/731)
- [#187 — Inventing on Principle (CLOSED)](https://github.com/mtdvio/every-programmer-should-know/issues/187)
- [#186 — Professor Frisby's Mostly Adequate Guide (CLOSED)](https://github.com/mtdvio/every-programmer-should-know/issues/186)
- [#214 — TL;DR Stock Options (CLOSED)](https://github.com/mtdvio/every-programmer-should-know/issues/214)

**Solution:**

1. Search the [Wayback Machine](https://web.archive.org/) for the dead URL.
2. File a GitHub issue titled `Broken link: <resource name>`, following the existing naming pattern.
3. Better: open a pull request that replaces the dead link with a working one (Wayback, the new canonical URL, or a fitting replacement).

### Problem: "I want a resource on topic X, but X is not a section."

**Cause:** the curator has not added that topic yet, or has decided it does not fit the project's values.

**Solution:** open a GitHub issue to discuss first (see open issues like [#42 Problem Solving](https://github.com/mtdvio/every-programmer-should-know/issues/42), [#123 Network](https://github.com/mtdvio/every-programmer-should-know/issues/123), [#60 Data Structures](https://github.com/mtdvio/every-programmer-should-know/issues/60) for the style). If a new section is justified, you will be asked to open a PR with one concrete resource.

### Problem: "The list feels overwhelming."

**Cause:** the list is designed to cover a full career's worth of topics. It is not meant to be read top-to-bottom.

**Solution:** pick one section per month, one resource per week. Delete every other browser tab. See §3.3 above.

### Problem: "I see emojis I don't recognize on some entries."

**Cause:** contributors occasionally use emojis outside the five documented in `CONTRIBUTING.md` (🎥, 📖, 📄, 📜, ✅). The additional ones (`:link:`, `:school:`, `:moneybag:`, `:zap:`, etc.) are curator emphasis rather than resource-type signals.

**Solution:** treat unknown emojis as decorative. The five-emoji vocabulary in `CONTRIBUTING.md` is the only one you need to navigate the list efficiently.

### Problem: "I want to suggest a resource but don't know if it fits."

**Cause:** the project is highly opinionated and the bar for inclusion is the maintainer's personal evaluation.

**Solution:** before opening a PR, ask yourself the four questions from `CONTRIBUTING.md`:

- Will it make every programmer a better human being?
- Will it change the quality of a programmer's work?
- Will it change the quality of a programmer's life?
- Would you personally recommend this resource to a friend starting a software-development career?

If you cannot answer "yes" to at least two of these, don't open the PR.

### Problem: "The translated versions I've seen are outdated."

**Cause:** there have been feature requests like [#219 for Brazilian Portuguese](https://github.com/mtdvio/every-programmer-should-know/issues/219) (closed), but the canonical list is English-only. Third-party translations are not maintained by `mtdvio`.

**Solution:** rely on the English `README.md` for currency. Use translated copies only if language is a blocker.

---

## 8. FAQ

**Q: Is this a tutorial or a course?**

No. It is a list of pointers to other people's work. Each linked resource is the tutorial, course, book, or paper. The list's job is curation, not instruction.

**Q: How long will it take to "finish" this list?**

You are not meant to finish it. The curator's own preamble links [xkcd 1050](https://xkcd.com/1050/) to make that explicit. Use it as a lifelong reference.

**Q: Which single resource should I read first?**

If you forced an answer: in the Practices section, *The Art of Readable Code*; in the Engineering Philosophy section, Rich Hickey's *Simple Made Easy*; in the Latency section, the *Latency Numbers* gist. But this question is against the spirit of the list — pick the section that matches what you are working on *this week*.

**Q: Are book entries free?**

Mostly not. Books link to Goodreads so you can evaluate them; you buy/borrow them elsewhere. Papers (`:scroll:`) and articles (`:page_facing_up:`) are usually free. The `Free Books on Programming` section points to the [Free Programming Books](https://github.com/EbookFoundation/free-programming-books) project for free titles.

**Q: Why are some sections (Machine Learning, Code Design, SEO) tiny?**

By design. The curator prefers one excellent resource per topic over ten mediocre ones. See the "Less is more" value in `CONTRIBUTING.md`.

**Q: Can I fork this list and customize it for my team/company/tech stack?**

Yes — the repository is MIT-licensed. Fork, prune sections you don't need, add a company-specific section, and share the fork internally. See the Admin Guide for details on maintaining a fork.

**Q: Is the list kept up to date?**

Yes, but slowly. Updates happen when contributors open PRs and the curator accepts them. The source commit for this guide is listed in the footer. New sections (Platform Engineering is the most recent significant addition) appear when the topic matures.

**Q: Does the list cover specific languages like Python, JavaScript, Rust, Go?**

Intentionally no. The *Practices* section includes [Learn X in Y Minutes](https://learnxinyminutes.com/) and [Hyperpolyglot](http://hyperpolyglot.org/) as jumping-off points, but the list itself is language-agnostic. For language-specific material, use [Free Programming Books](https://github.com/EbookFoundation/free-programming-books).

**Q: What does "highly opinionated" actually mean in practice?**

It means the curator rejects well-regarded resources if they don't match the project's values — specifically, resources that add to hype or stress, endless-stream resources (newsletters, forums), and resources the curator has not personally evaluated. See the Admin Guide's "Curation Philosophy" section for the full picture.

**Q: How do I cite an entry in a blog post or book?**

Link to the project's GitHub URL (`https://github.com/mtdvio/every-programmer-should-know`) and quote the section heading. There are no stable anchor IDs beyond what GitHub auto-generates from headings.

**Q: Is there a maintained RSS or update feed?**

No. The best proxy is the repository's commit feed: `https://github.com/mtdvio/every-programmer-should-know/commits/master.atom`.

**Q: Is there a Discord/Slack/forum for discussing the list?**

No. The project is deliberately minimal. Discussion happens in GitHub issues and pull requests.

**Q: The repo has a promotional banner for `mylevel.dev`. Is that trustworthy?**

The sponsorship banner at the top of the `README.md` is disclosed as "Created by this repo author" — i.e. by the curator (`@mtdvio`). It is a self-promotion for a developer-level quiz, not a third-party ad. Treat it the same way you'd treat any author-run project; it is out of scope for the curated list itself.

---

## 9. Reference

### 9.1 Repository metadata

| Field | Value |
|-------|-------|
| Repository | [`mtdvio/every-programmer-should-know`](https://github.com/mtdvio/every-programmer-should-know) |
| Default branch | `master` |
| Canonical URL | `https://github.com/mtdvio/every-programmer-should-know` |
| License | See `LICENSE` (MIT) |
| Maintainer | Dmitri Grabov ([@mtdvio](https://github.com/mtdvio)) |
| Primary file | `README.md` |
| Supporting files | `CONTRIBUTING.md`, `LICENSE` |

### 9.2 Repository layout

```text
every-programmer-should-know/
├── CONTRIBUTING.md    ← Contribution rules, core values, emoji vocabulary
├── LICENSE            ← MIT license
├── README.md          ← The list itself (≈22 KB, ~30 sections)
└── .github/           ← Community health files
```

That is the entire repository. No build system, no dependencies, no CI beyond GitHub's default Markdown rendering.

### 9.3 Resource-type emoji vocabulary

| Emoji | Markdown shortcode | Meaning |
|-------|--------------------|---------|
| 🎥 | `:movie_camera:` | Video or talk |
| 📖 | `:book:` | Book |
| 📄 | `:page_facing_up:` | Online article |
| 📜 | `:scroll:` | Paper or long-form document |
| ✅ | `:white_check_mark:` | Checklist |

### 9.4 All sections at a glance

Introduction · Falsehoods · Algorithms · Data Structures · Numbers · Strings · Latency · Time · Memory · Distributed Systems · Machine Learning · RegExp · Security · UX/Usability · SEO · Architecture · Code Design · Engineering Philosophy · Practices · Career · Fine-tune Your Resume · Open Source · Remote Work · Problem Solving · Soft Skills · Mental Health · Papers on Programming · Free Books on Programming · Services · Licenses · Where To Look For Further Info · Coding Practice Sites · Learning through entertainment · Platform Engineering

### 9.5 Related further reading

- [Awesome](https://github.com/sindresorhus/awesome) — the meta-list of curated "awesome" lists. Broader, less opinionated.
- [Free Programming Books](https://github.com/EbookFoundation/free-programming-books) — broader, language-indexed, non-opinionated.
- [Papers We Love](https://github.com/papers-we-love/papers-we-love) — the paper-focused counterpart; referenced from the Papers section.

---

_Generated May 2026 from mtdvio/every-programmer-should-know at e47b7c4. AI-generated documentation. The library is checked by sampling (three repositories so far); this guide was not individually reviewed. Verify against the project before relying on it. Unofficial; not affiliated with or reviewed by the project._