100 Things You Should Know

How to Actually Make a 100-Item List That Doesn't Read Like Spam

I've spent years watching people attempt what they call the 100 Things You Should Know format. Most fail. Not because the concept is bad, but because nobody explains the logistics of actually producing one without it devolving into filler. I built my first proper one back in 2019 for an internal documentation system at a mid-size tech company. Took me eleven days. The second one took six. The difference was learning how to structure the work before writing a single item. A 100-item list is not a collection of random facts. It's a structured knowledge map. When done right, it functions as both a reference document and a teaching tool. When done wrong, it's just a blog post padded to hit page count.

Why People Search for 100 Things You Should Know

The search volume for this format is real. People want comprehensive yet digestible content. They want to feel like they're getting depth without committing to a textbook. A well-executed 100 Things You Should Know article or guide satisfies both instincts. But the barrier to quality is high because most writers don't have a system for generating 100 distinct, non-repetitive, accurate entries under deadline pressure. Before you write anything, you need a taxonomy. This is the step everyone skips and then wonders why their list has twelve entries about basics and forty-three about the same intermediate topic. Divide your subject into five to seven categories, then distribute your 100 items across them with intentional balance. Not equal distribution—some categories naturally carry more weight—but intentional. You should be able to look at your outline and immediately see where the gaps are. Here's a practical example from my own work. I was building a 100 Things You Should Know guide on prompt engineering for LLMs. My categories were: fundamentals, structure patterns, advanced techniques, common failure modes, tooling and APIs, workflow integration, and ethics plus limitations. I allocated twelve, eighteen, sixteen, fourteen, twelve, sixteen, and twelve items respectively. That left exactly one slot open, which I used for a cross-cutting meta-item. The result was a document where no category dominated and every section had a clear purpose.

Writing this way also solves a problem most people encounter around item 60: the list starts sounding repetitive because you've exhausted the obvious angles. If your taxonomy is solid, you can always go deeper into a category that still has inventory. If it isn't, you're stuck padding.

The Writing Process

Don't write items 1 through 100 in order. Write the ones you know cold first. These become your anchor points—the entries that define the quality bar for everything else. In my prompt engineering guide, I wrote the items on temperature control, token limits, and few-shot examples early. They set the tone. Everything that followed had to match their precision. Each item should follow a consistent internal structure without being rigid. My formula was: one sentence of plain definition, two to four sentences of practical context, and one concrete example or edge case when relevant. That's it. No intros. No conclusions. No "here's why this matters." The item itself is the value. Readers don't need you to announce the value. They clicked the list because they want the content. I learned this the hard way. My first draft had items averaging 120 words each because I kept adding setup language. A reviewer cut every piece of it down to an average of 55 words. The resulting document was actually easier to scan and more useful in practice. Longer isn't deeper. Dense and direct is.

Verification and Error Handling

This is where most 100-item lists die quietly. Someone publishes a massive guide, half the entries contain minor inaccuracies, and nobody notices until months later when a reader points out that a specific claim is wrong. By then the damage is done to credibility. My workaround for this is brutal and simple: after drafting all 100 items, I spend a full day going through every single one and fact-checking it against primary sources. Not secondary articles. Primary documentation, official specs, peer-reviewed papers, or firsthand experience. For the prompt engineering guide, this meant cross-referencing OpenAI's documentation, Hugging Face's papers, and actual API behavior logs I'd kept from production deployments. Three items came back as wrong. One was a subtle misunderstanding about how max tokens interacts with stop sequences. I fixed it and added a note about the nuance. If you're writing about a technical subject and you haven't personally tested or verified the claims, you should say so. Readers can tell the difference between someone who has operated in the space and someone who summarized three blog posts about it.

The Hidden Problem: Cognitive Load

A 100-item list creates a specific reading problem that almost nobody accounts for. By item 40, attention drops significantly. By item 70, most readers are skimming. This isn't a flaw in the audience. It's a structural reality of long-form list content. The mitigation is grouping with clear visual separation. Use subheadings within each category. Don't just number items 1 through 100 linearly. Break them into visible sections with descriptive headers so readers can jump to the part they need without wading through unrelated content. In practice this also improves SEO because search engines can index the subsections independently. I also learned to front-load the highest-value items within each section. Put the things people are most likely to search for or need immediately at the top of each category. The less critical but still useful items go toward the bottom. This way even a partial reader gets the important material.

When a 100-Item List Is the Wrong Format

Sometimes people reach for this format when a different structure would serve better. If your subject matter is highly narrative or requires extended explanation, a list compresses the content too much and loses essential context. If there are only genuinely twenty to thirty distinct things worth knowing, padding to one hundred creates the exact quality problem you're trying to avoid. A checklist or a decision tree might be more appropriate for procedural knowledge. A flowing essay works better for conceptual arguments. The 100 Things You Should Know format sits best for reference material, foundational knowledge, and topics where discrete factual entries add real value. Know the difference. Using it for the wrong purpose is the fastest way to produce something mediocre.

The Final Step Nobody Talks About

After the list is complete and verified, publish a dated version identifier. Version 1.0, release date, subject area. This seems trivial but it matters enormously for a document of this size. People will quote individual items. They will cite them in other work. They will update their own knowledge based on your entries. Without a version marker, you lose track of what changed when, and accuracy degrades silently over time. I maintain a public changelog for every major list I publish. It's usually three paragraphs long. Last month I revised twelve items in my prompt engineering guide after a major platform update changed how certain parameters behave. The changelog noted which items changed, what the old wording was, and what the new wording is. Readers who had downloaded or referenced the old version can see exactly what shifted. This builds trust faster than any marketing language ever could. The format itself is straightforward. The execution is what separates useful reference documents from content filler. Most people never learn that distinction. If you're going to put a hundred things out there, make sure each one earns its place.