Every Programmer Should Know — User Guide (mtdvio/every-programmer-should-know): guide library

A reader's guide to the curated list at 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.

Open the list at github.com/mtdvio/every-programmer-should-know.
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).
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), 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 — 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 and 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 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, 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, and Regex Crossword.

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, PortSwigger Academy, 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, 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 — 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, Mostly Adequate Guide to Functional Programming, SICP, Programming Paradigms for Dummies, Learn X in Y Minutes, Hyperpolyglot, 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, 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.

Open Source

Pointer to a Git + GitHub tutorial (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 — 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 — one link, but it is to an 8,000-entry index maintained by the EbookFoundation.

Services

Abstract API, Free For Dev, Public APIs, The Noun Project, Without Coding collection, Simple Icons, Learn Anything, and 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, 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, Elevator Saga, Untrusted, CSS Diner, and CodinGame.

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

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

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

Download the README only

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

  % 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 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:

Solution:

Search the Wayback Machine for the dead URL.
File a GitHub issue titled Broken link: <resource name>, following the existing naming pattern.
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, #123 Network, #60 Data Structures 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 (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 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 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 and Hyperpolyglot as jumping-off points, but the list itself is language-agnostic. For language-specific material, use 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`
Default branch	`master`
Canonical URL	`https://github.com/mtdvio/every-programmer-should-know`
License	See `LICENSE` (MIT)
Maintainer	Dmitri Grabov (@mtdvio)
Primary file	`README.md`
Supporting files	`CONTRIBUTING.md`, `LICENSE`

9.2 Repository layout

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

Awesome — the meta-list of curated "awesome" lists. Broader, less opinionated.
Free Programming Books — broader, language-indexed, non-opinionated.
Papers We Love — the paper-focused counterpart; referenced from the Papers section.