professional-programming: 101 topics, a generated table of contents, and no releases

The table of contents is generated, and the file tells you not to edit it by hand

The single largest structure in this repository is machine written. The contents sit between a START doctoc generated TOC marker and an END marker, with an instruction between them not to edit that section and instead re-run doctoc to update it. That is the whole maintenance model of a list this size: a tool reads the headings, and the headings are the taxonomy. It has a concrete effect on contributing. Drop a link into an existing heading and the contents are already correct, but add a new category or rename one and the table is stale until doctoc runs again, which means a pull request that looks finished can be visibly out of sync. The top level also carries a .pre-commit-config.yaml, so formatting and whatever else the hooks cover are checked before a commit lands, and a CONTRIBUTING.md describes the process. The categories are the real content here, and they are the part a tool maintains for you. That is worth knowing before you decide the list is a static document.

Four AI headings and two reliability headings overlap, with no cross references

The taxonomy was grown rather than designed, and the seams show. Machine learning and AI, Large Language Model (LLM), Generative AI, and Agentic coding are four separate top level headings for closely related material, and Reliability, with subtopics Integration patterns (dependency management) and Resiliency, sits beside a separate Site Reliability Engineering (SRE) heading. The data area is split the same way across Data analysis and data science, Data science/data engineering, Data semantics, and Data formats. Nothing in the structure cross-references these, so a reader looking for retrieval or evaluation material has no way to know which of the four AI headings holds it, and an author has to guess. Duplicate suppression in a link list is a matter of judgement about titles, and overlapping headings make two plausible homes for the same resource. The practical effect is that the table of contents cannot be trusted as a partition of the subject, so search inside the page beats browsing it for anything topical.

Chess, Fonts, Humor and Procrastination sit next to Kubernetes and Compilers

Some headings are engineering domains with depth, such as Databases, which splits into Internals, NoSQL, and Postgres, or Design (OO modeling, architecture, patterns, anti-patterns, etc.), which splits into Design: database schema, Design: patterns, and Design: simplicity, and Observability, which splits into Logging, Error and exception handling, Metrics, and Monitoring. Others are hobbies, habits, or subjects adjacent to software: Chess, Fonts, Characters sets, Humor, Biases, Accounting, Marketing, Email, Math, Hardware, and Procrastination, which is a subtopic under Attitude, habits, mindset. Career growth has its own pair, Choosing your next/first opportunity and Getting to Staff Eng. That mixture is the project's character rather than a mistake, and it is also the reason the list cannot be consumed as a sequence. Nobody progresses from Compilers to Chess, and a reader who wants depth on a topic has to ignore most of the headings, which is exactly what a search box is for.

antipatterns/, cheatsheets/, training/ and three loose files make this more than a link list

The top level holds a list-of-links/ directory, an antipatterns/ directory, a cheatsheets/ directory, a training/ directory, an images/ directory, and three standalone Markdown files, feature-flags.md, glossary.md, and CONTRIBUTING.md, alongside the readme and a pre-commit configuration. The distinction matters for expectations. A pure awesome list is links with curation, and everything rots independently of the maintainers. The material in antipatterns/, cheatsheets/, and glossary.md is authored, and authored material does not rot the way a link does, so it is the part of this repository with a longer useful life. At the same time, the sections at the top of the file are where the curated side lives, with Must-read books, Must-read articles, Other general material and list of resources covering other lists, books, articles, axioms, and courses, and further sections for Resources and inspiration for presentations, Keeping up-to-date, Concepts, and My other lists. Two different kinds of artefact in one repository means two different maintenance expectations.

list-of-links/ is the directory the page never explains

Everything the reader is meant to navigate lives in the readme, and the directory that presumably holds the actual link data is never described. Nothing in the contents explains what list-of-links/ contains, how many files it has, how they map to the 101 headings, or whether a category lives in a file or inline in the readme itself. The same is true of cheatsheets/, training/, and antipatterns/, where the readme gives a link and no schema. The consequences are practical for anyone who wants to do more than read. A team mirroring the list into an internal wiki has to open the tree and infer the convention rather than follow a documented one. A script that wants the links as data has no documented structure to parse and no promise that the headings and the files stay in sync. And a contributor adding a category has to copy whatever pattern the existing files use without being told what the pattern is, which is the kind of gap that produces a pull request adding a link where a file was expected.

The repository is labelled Python while the top level holds no Python at all

The metadata and the tree disagree in a way that only shows up if you read both. The primary language is recorded as Python, and the top level entries are a pre-commit configuration, a contributing file, a license, the readme, a list-of-links directory, an antipatterns directory, a cheatsheets directory, a training directory, an images directory, and three Markdown files. Nothing at the top level is Python, and the project's description is a collection of learning resources for curious software engineers, not a library. The practical effect is on tooling rather than on content. Language based filters, repository classifiers, and dependency bots will describe this as a Python project and draw conclusions from that which the tree does not support, while anyone expecting a Python package with an install step will find nothing to install. Reading the contents rather than the language badge is the only way to know what is here, and for a curated list that is the right default anyway.

No releases and no homepage mean a category can change with no snapshot to diff

There is no GitHub release history for this project and no homepage of its own, so the only addressable version is the master branch, which was last pushed on 2026-09-21. For a library that would be a warning. For a curated list it is a quieter problem, because the things people come back for are the category structure and a handful of specific links, and both change without ceremony. A link is removed in a commit, a heading is renamed, a whole category can be pruned, and there is no tag to return to and no changelog to read, because the updating mechanism the project does have is a section named Keeping up-to-date rather than a release feed. Anyone who wants to track the list over time has to record commit identifiers themselves. Anyone who wants to be notified has to watch the branch or find that section, and anyone who depends on a link surviving has no signal when it does not.

Editorial conclusion

Treat professional-programming as a map of where a topic lives rather than a curriculum, because 101 headings covering chess, fonts, and procrastination alongside database internals will not be read end to end by anyone, and the overlapping AI, data, and reliability buckets mean a good resource can be filed in more than one place or in none. It is worth your time for the structure and for the original material in antipatterns/, cheatsheets/, training/, glossary.md, and feature-flags.md, which is not subject to link rot. Before mirroring it internally, copy links you care about rather than the list, because the repository has no GitHub releases and no homepage, so a category can shrink on master with no snapshot to diff against and no changelog to read. And if you contribute, add your link under the right heading and re-run doctoc, since the table of contents is generated and the header tells you not to edit it by hand.

Frequently asked questions

Official sources

1. Official README
2. Project repository