The Complete Developer Cheat Sheet Collection: 20 References Worth Saving

The Complete Developer Cheat Sheet Collection

A programming cheat sheet is a single-page reference holding the commands, syntax, and decision rules you use often enough to need fast but not often enough to have memorised. It is not a tutorial and it is not documentation — it is the middle layer between the two, and it is the layer most developers never deliberately build.

This page collects twenty of them, organised by when you actually reach for each one.

The honest framing first: you do not need twenty cheat sheets. You need the three or four that match your daily work, printed and within arm's reach, plus a bookmark folder for the rest. A wall of unread reference cards is decoration. The value is in the small number you consult so often that the paper wears out.

Updated for 2026. Every linked sheet is reviewed on a six-month cycle.

Why Cheat Sheets Still Beat Asking an AI

A junior developer once asked why anyone would keep a Git reference card when ChatGPT answers any Git question in seconds. It is a fair question with a specific answer.

Consider a mechanic. Every workshop has a laptop with the full manufacturer service database on it. Every workshop also has a laminated torque-spec card stuck to the wall. The database is more complete, more current, and more authoritative. The card is on the wall because when your hands are dirty and the engine is open, walking to a computer and typing a query costs you the thread of what you were doing.

The same economics apply to your editor.

There is a second advantage that matters more over a career. An AI assistant answers the question you knew to ask. A cheat sheet shows you the whole surface area of a tool — including the parts you did not know existed. Most developers discover git bisect by seeing it on a reference card, not by thinking to ask for it.

Use all four layers. Just know which one you are reaching for and why.

The Memorise / Look Up / Ignore Framework

Before the list, a framework that makes the list useful. Every entry on every cheat sheet sits in one of three columns.

Memorise — you use it more than five times a day. Looking it up costs more than learning it. This should be about twenty items per technology, no more. For Git that is status, add, commit, push, pull, checkout, branch, merge, log, diff. That is it. Everything else is column two.

Look up — you use it weekly or monthly, and it has a precise form you will get wrong from memory. Regex patterns, tar flags, useEffect dependency rules, JOIN semantics. This is what a cheat sheet is for, and it should be the largest column.

Ignore — it exists, you have never needed it, and you will look it up properly with documentation on the day you do. Most of any tool's surface area lives here, and pretending otherwise is how people waste a weekend memorising awk and never use it.

The mistake beginners make is trying to move everything into column one. The mistake experienced developers make is leaving things in column two for years that should have been promoted. Both are fixed by noticing which entries you keep returning to.

How to Actually Use This Collection

Three rules make the difference between a useful reference habit and a folder of dead bookmarks.

Print the interrupt-driven ones, bookmark the deliberate ones. If you consult it in the middle of typing, it belongs on paper beside your monitor. If you consult it while planning, a browser tab is fine.

Cap yourself at four printed sheets. Beyond that you spend longer finding the right sheet than the sheet saves you. Four is roughly what fits in peripheral vision beside a monitor, which is not a coincidence.

Promote repeated lookups into memory. The third or fourth time you look up the same entry, stop and read the real documentation for it. Repeated lookups are a signal, not a habit to protect.

The Daily-Use Cheat Sheets

These four are the ones most developers touch every single working day, regardless of stack or seniority. If you print nothing else, print these.

1. Git Commands

Git is the tool developers use most and understand least. The daily surface is about ten commands; the rescue surface — undoing things, recovering branches, fixing a bad rebase — is another ten that you need rarely and urgently, which is the exact profile of something that belongs on paper rather than in memory.

The single most valuable section on any Git card is the undo section, because those are the commands you need while mildly panicking:

git reflog                    # every HEAD position, including "lost" commits
git reset --soft HEAD~1       # undo last commit, keep changes staged
git reset --hard origin/main  # discard everything local — destructive
git revert <commit>           # undo a pushed commit safely
git restore --staged <file>   # unstage without losing work

git reflog has saved more work than any other command in this list. It shows every position HEAD has occupied for roughly the last 90 days, which means a commit you think you destroyed is almost always still recoverable.

What people get wrong: confusing reset with revert. reset rewrites history and is unsafe on a shared branch; revert creates a new commit that undoes an old one and is always safe. If the commit is pushed, use revert.

Best for: everyone, from day one. → Git Commands Cheat Sheet for Daily Use

2. Linux and Shell Commands

Linux commands are the highest-return thing a beginner can memorise, for one reason: they do not change. The grep flags you learn this year will still be correct in a decade, they work identically on macOS, and they work on Windows through WSL. Almost nothing else in software has that shelf life.

Roughly thirty commands cover the overwhelming majority of real usage — navigation, file operations, permissions, process inspection, and text search:

grep -rn "searchTerm" .        # recursive search with line numbers
find . -name "*.log" -mtime +7 # files matching a pattern, older than 7 days
lsof -i :3000                  # what is using port 3000
du -sh * | sort -h             # what is eating disk space, sorted
chmod 755 script.sh            # owner: rwx, everyone else: r-x

What people get wrong: file permission numbers. 755 is not arbitrary — it is three octal digits for owner, group, and others, where read is 4, write is 2, and execute is 1. So 7 is 4+2+1 (everything) and 5 is 4+1 (read and execute). Once you see the arithmetic, you never need to look it up again, which makes it a perfect candidate for promotion out of column two.

Best for: absolute beginners, and anyone who deploys anything. → Linux Commands Cheat Sheet for Beginners

3. VS Code Shortcuts

This is the cheat sheet with the fastest measurable payback in the collection. Multi-cursor editing, jump-to-symbol, and the command palette each save small amounts of time hundreds of times a day, which is exactly the shape of a compounding return.

The reason most developers never learn these is that each individual shortcut saves about two seconds, so learning it never feels urgent. Twenty shortcuts, at two seconds each, across two hundred uses a day, is the actual number — and it is more than an hour.

The highest-value five, if you learn nothing else: command palette, go-to-file, go-to-symbol, multi-cursor on selection, and rename-symbol. Rename-symbol in particular is the one people replace with find-and-replace, which is how you rename a variable and silently break a string literal that happened to match.

Best for: anyone who has used the same editor for more than a month without customising it. → VS Code Shortcuts and Settings Cheat Sheet

4. Regular Expressions

Regex is the clearest case in programming of a skill nobody retains between uses. You solve a problem with a beautiful pattern, feel briefly competent, and then cannot read your own expression six weeks later.

A regex card should be pattern-first rather than syntax-first, because you almost never need to invent a pattern from nothing — you need to adapt one:

^\S+@\S+\.\S+$           # pragmatic email check
^\d{4}-\d{2}-\d{2}$      # ISO date
(?<=\$)\d+(?:\.\d{2})?   # price after a dollar sign, lookbehind
\s+$                     # trailing whitespace

What people get wrong: greedy versus lazy quantifiers. <.*> on <a><b> matches the entire string, not <a>, because * is greedy. <.*?> matches just <a>. This single distinction accounts for a large share of regex bugs, and it is exactly the kind of thing that belongs on a card rather than in your head.

Best for: anyone doing text processing, validation, or log analysis. → Regex Cheat Sheet With Copy-Paste Patterns

The Language Cheat Sheets

Pick the ones matching your stack. Ignore the rest — a Python card is worthless to someone writing Go, and collecting them "for later" is how bookmark folders die.

5. Python

The Python card earns its place through the standard library and the idioms, not the syntax. List comprehensions, dictionary methods, f-strings, enumerate, zip, and the collections module are what separate Python that works from Python that reads like Python.

{k: v for k, v in items if v}       # dict comprehension with a filter
for i, item in enumerate(items, 1):  # index without a counter variable
from collections import defaultdict, Counter
Counter(words).most_common(3)        # top 3 in one line

What people get wrong: mutable default arguments. def f(items=[]) creates the list once, at function definition, and every call shares it. Use def f(items=None) and assign inside. This bug is invisible until it is not.

→ Python Cheat Sheet Every Developer Should Save

6. JavaScript

JavaScript's array methods alone justify a reference card. map, filter, reduce, find, some, every, flatMap — knowing which one fits the problem is most of writing clean JavaScript, and the naming is just similar enough to be confusing under pressure.

What people get wrong: using map when they mean forEach. map builds and returns a new array; if you are not using the return value, you are allocating an array for nothing and signalling the wrong intent to the next reader.

→ JavaScript Cheat Sheet You'll Use Every Day

7. TypeScript

TypeScript's utility types are the section people actually need. Partial, Pick, Omit, Record, and ReturnType solve most real typing problems, and almost nobody remembers all five without looking.

What people get wrong: reaching for any when the correct answer is unknown. any disables checking entirely and silently spreads; unknown forces you to narrow before use, which is the whole point of having types.

→ TypeScript Cheat Sheet: Types, Generics, and Utility Types

8. React

A React card should be hooks-first. The useEffect dependency rules in particular are the single most common source of subtle bugs in React codebases, and they are rules — which means they belong on a card rather than in intuition.

What people get wrong: treating useEffect as a lifecycle hook rather than a synchronisation tool. Most effects that fetch data on mount are better expressed as a query library call, and most effects that derive state from props should not be effects at all.

→ React Developer Cheat Sheet (Must Save)

9. CSS and Tailwind

Flexbox and Grid are the two things people look up forever, because the mental model is spatial and the syntax is not. A good CSS card is visual — it shows you the layout each property produces rather than describing it.

What people get wrong: reaching for Flexbox for two-dimensional layouts. Flexbox is one-dimensional — a row or a column. The moment you need rows and columns to align with each other, you want Grid, and fighting Flexbox into that shape is how you end up with nested wrapper divs.

→ CSS and Tailwind Cheat Sheet: Flexbox, Grid, and Utilities

10. Bash Scripting

Bash has a first line that belongs on every script and that most scripts are missing:

#!/usr/bin/env bash
set -euo pipefail

-e exits on any error, -u errors on undefined variables, and -o pipefail makes a pipeline fail if any stage fails rather than only the last one. That one line converts silent failure into loud failure, which is the difference between a script you can trust and one you cannot.

What people get wrong: unquoted variables. rm -rf $DIR where DIR is empty becomes rm -rf, and where DIR contains a space becomes two arguments. Always "$DIR".

→ Bash and Shell Scripting Cheat Sheet

The Data and Backend Cheat Sheets

11. SQL

SQL appears in more job interviews than most candidates expect, including for frontend and product roles. It is also the rare skill that transfers completely — SQL learned on PostgreSQL works on MySQL, SQLite, and BigQuery with minor dialect adjustments.

The section worth memorising rather than looking up is the JOIN types, because choosing the wrong one produces a result that looks plausible and is wrong.

What people get wrong: filtering a LEFT JOIN in the WHERE clause instead of the ON clause. A condition on the right table in WHERE silently converts your LEFT JOIN into an INNER JOIN, because null rows fail the filter. Put it in ON.

→ SQL Cheat Sheet for Interviews and Real Projects

12. HTTP Status Codes and REST

Every developer knows 200, 404, and 500. Far fewer can say confidently whether a failed login should return 401 or 403, or which code a validation error belongs under. Those are the ones that make an API feel professional or amateur.

The short answer: 401 means "I do not know who you are" — authenticate and try again. 403 means "I know exactly who you are and you are not allowed" — retrying will not help. Validation errors are 422 if you want precision, 400 if you want universal client compatibility.

→ HTTP Status Codes and REST API Cheat Sheet

13. Docker

Docker's daily command surface is small and its debugging surface is where people get stuck. The commands for inspecting a container that will not start — logs, exec, inspect — are the ones you need at the worst possible moment:

docker logs -f --tail 100 <container>   # follow recent output
docker exec -it <container> sh          # shell inside a running container
docker inspect <container>              # full config as JSON
docker system prune -a                  # reclaim disk — destructive

What people get wrong: ordering Dockerfile layers badly. Copying your whole source tree before installing dependencies invalidates the dependency cache on every code change, turning a five-second rebuild into a five-minute one. Copy the lockfile, install, then copy source.

→ Docker Cheat Sheet for Developers

14. Kubernetes

Kubernetes needs a different kind of card than the others in this list. The commands are the easy part; the hard part is the object model — how a Pod relates to a Deployment relates to a Service. A Kubernetes card should be a map before it is a command list.

What people get wrong: debugging a failing Pod with logs when the Pod never started. If the container has not run, there are no logs — you want kubectl describe pod and its Events section, which is where image-pull failures and scheduling problems actually appear.

→ Kubernetes Cheat Sheet: Beyond kubectl Commands

15. Pandas and NumPy

Roughly twenty Pandas operations cover the large majority of real data work. The genuinely confusing area is merge versus join versus concat, which is exactly the kind of three-way distinction a table resolves in five seconds and prose never resolves at all.

What people get wrong: chained indexing — df[df.a > 1]['b'] = 0. This assigns to a temporary copy and silently does nothing to your actual DataFrame. Use .loc[df.a > 1, 'b'] = 0.

→ Pandas and NumPy Cheat Sheet for Data Work

The Interview and Architecture Cheat Sheets

These five are consulted while thinking rather than while typing. Bookmark them; do not print them.

16. Coding Interview Patterns

This is the highest-leverage sheet in the entire collection, and it is the one most candidates skip in favour of grinding problems.

Around fifteen patterns — sliding window, two pointers, fast and slow pointers, binary search on the answer, backtracking, topological sort, and a handful more — cover the overwhelming majority of interview problems. Recognising the pattern in the first two minutes is worth more than having previously solved the specific problem, because you will not get a problem you have seen.

A candidate who has solved 400 problems without organising them by pattern is often outperformed by one who has solved 120 and can name the family of every new problem within a minute.

→ The Coding Interview Cheat Sheet: Patterns, Not Problems

17. Data Structures and Big-O

You will be asked to state the time complexity of your own solution. Getting it wrong after writing correct code reads worse than writing slightly slower code and knowing exactly why it is slower.

The other half of this card is the selection question: which structure for which problem. Hash map for lookup, heap for "top k", stack for matching pairs, queue for level-order traversal. That mapping is more useful in practice than the complexity table beside it.

What people get wrong: quoting average-case complexity as if it were guaranteed. A hash map is O(1) average and O(n) worst case, and the worst case is what an interviewer is probing when they ask what happens with adversarial keys.

→ Data Structures and Big-O Cheat Sheet for Interviews

18. System Design

From mid-level upward, system design becomes the round that decides the offer. A one-page card cannot teach system design, but it can give you the checklist — load balancing, caching layers, database replication, sharding, message queues, the CAP theorem — so that you never freeze on a blank whiteboard.

The card's real job is sequencing. Requirements, then scale estimates, then the high-level diagram, then the data model, then the bottleneck discussion. Candidates who jump straight to drawing boxes lose points they never recover.

→ System Design Cheat Sheet on One Page

19. Networking

Networking is the most common knowledge gap among self-taught developers, because it is the one area you can avoid entirely while building applications and then cannot avoid at all the first time something breaks in production.

The OSI model, the common ports, how DNS resolution actually proceeds, and the difference between TCP and UDP are the four things that come up repeatedly — in interviews, and at 3am when a service cannot reach another service.

→ Networking Cheat Sheet for CS Students and Developers

20. Machine Learning

The useful machine learning card is an algorithm-selection map, not a formula sheet. Given a labelled dataset of a certain size and shape, which family of model do you reach for first, and which evaluation metric is appropriate?

What people get wrong: accuracy on imbalanced data. A model that predicts "not fraud" for every transaction in a dataset with 0.2% fraud is 99.8% accurate and completely useless. Precision, recall, and the F1 score exist for exactly this reason, and knowing when to abandon accuracy is more valuable than knowing any single algorithm.

→ Machine Learning Cheat Sheet for Beginners

Which Ones You Actually Need

Pick by role rather than collecting the full set.

Build Your Own Sheet — The One Nobody Else Can Write

The twenty sheets above are general. The most valuable reference card you will ever own is the one you write yourself, because it holds the things that are specific to your codebase and your mistakes.

Keep a single plain text file. Every time you look something up for the second time, paste it in with a one-line note about what it does. Do not organise it. Do not format it. Organisation is what kills these files — the moment it becomes a project, you stop maintaining it.

After three months you will have thirty to fifty entries, and they will be a startlingly accurate portrait of your actual gaps. That file is worth more than any of the twenty above, and it takes about four seconds a week to maintain.

The One Rule That Makes This Work

Every entry on a cheat sheet exists in one of three states: something you have memorised, something you look up, or something you have never used. The whole purpose of keeping the sheet is to move entries leftward over time.

If an entry has been in the "look up" column for a year and you have consulted it twenty times, it was never a lookup — it was a gap in your knowledge wearing a lookup costume. Read the real documentation for that one thing, properly, once. Then it stops costing you two seconds a day forever.

🔗 Start with the cheat sheet matching whatever you are working on today: Git Commands Cheat Sheet for Daily Use if you are writing code this week, or Linux Commands Cheat Sheet for Beginners if you are still finding the terminal uncomfortable.