Reading Room

Outside your usual reading: this is a story about a reward check from a legendary computer scientist, and underneath it is a real lesson about being careful before you claim you caught a mistake.

Donald Knuth, author of the foundational multi-volume series The Art of Computer Programming, has run a famous standing offer for decades: he personally signs a check for anyone who finds a genuine error in one of his books, typos included. Knuth and his reward are what the writer of this piece, Thomas Huehn, calls "computer science folklore." Thousands of readers, many of them, in Huehn's words, smarter and more patient than he is, have combed through Knuth's books looking for exactly this kind of mistake. Huehn says he thought it was "preposterous" to imagine he could ever earn one himself.

Then he found something. But Huehn did not report it the moment he spotted it. He waited and rechecked it for months, worried about looking foolish. He even raised it with someone he calls "our local genius" at his university, who dismissed it and did not seem to care. Only after that long, deliberate recheck did he send the finding to Knuth.

The error itself sits somewhere almost nobody would expect to find Knuth slipping. It is not in one of his heavily studied books like The TeXbook or The Art of Computer Programming. It is in a far less-read volume called Computer Modern Typefaces, Volume E in his Computers and Typesetting series. And it is not hidden on some obscure page deep inside: it is on page one, in the first paragraph, in the very first word. Nearly everyone who ever opened that book had already read straight past it.

Knuth confirmed the error and sent a reward, though not a real bank check. Huehn notes that Knuth stopped issuing real checks years ago and now sends what he calls a "fantasy certificate" from a made-up bank, the Bank of San Serriffe, a play on serif, the small decorative strokes on certain letterforms. The amount on Huehn's check reads "0x$1.20," hexadecimal notation (base 16, not base 10) that works out to $2.88 in ordinary decimal, and the memo field reads "E1," Knuth's own shorthand for Volume E, page 1, tying the reward directly back to exactly where the error lived.

Huehn tried again a few years later with a second proposed error. This time he was wrong, and Knuth wrote back several paragraphs explaining exactly why. But Knuth decided one throwaway sentence buried inside Huehn's bug report counted as a genuinely useful suggestion anyway, and sent a second check, this one for $0.32.

The real lesson here has nothing to do with typefaces. Huehn found something, assumed he was probably wrong given how many sharper, more patient people had already read the same page, and sat on it for months verifying before he claimed credit. That is the same habit worth borrowing for code review, a data discrepancy, or any moment you think you caught something others missed: check quietly first, stay ready to be wrong, and only speak once you have genuinely tried to rule yourself out.

Outside your usual reading: a software engineer's post about joining, then nearly losing, his family's small business, worth keeping in mind given your own interest in buying and running one.

A 26-year-old poster on the r/smallbusiness forum describes quitting a software engineering job to join his family's tourism business. He had three and a half years of professional experience (five counting internships), had just been promoted to mid-level, and says he was reasonably happy where he was. His younger brother, 24, had been running and developing the family business and was already earning more than he was.

The brother offered him about a 30 percent pay increase plus co-ownership, rather than hiring him as a regular employee. He was not initially interested. What changed his mind was his brother's pitch: that he needed the poster's help, and that the plan was to use the business's own cash to fund new, more interesting ventures together. The poster says he has always been drawn to entrepreneurship, so he quit his software job and joined.

After a short time inside the business, he says he can see real cash flow and real potential. But his brother has now told him he is fed up working with their mother and wants to leave the business entirely. The poster says he feels betrayed: he made a major career decision based on the shared future his brother described, and he may now end up running a tourism business on his own, one he says he is not particularly passionate about.

He is explicit that the money is still good and the business still has potential. His real reason for taking the risk was the idea of building something together with his brother and eventually branching into other ventures, not the tourism business itself. He lays out three options in his own post: go back to software engineering while he still can, stay and try to build the business himself, or give it a chance even without his brother there.

For anyone thinking about buying into or running a small business with family, the post is a clean case study in a specific risk: the deal you actually agree to is often not the business on paper, it is the partner and the plan they describe. The business's cash flow was real and is still real. What broke was the second half of the pitch, the joint, multi-venture future that made the pay cut and the risk worth it in the first place. That gap between a sound asset and a shifting human agreement is exactly what a term sheet or a valuation number will not catch.

If any of your projects touch data pipelines, this explains exactly which habits to change to get a real speed increase for free. DuckDB is a small database engine many data tools build on, and the open alpha of DuckDB 2.0, due out this fall, is genuinely faster, not just a version bump. The person who wrote this ran the new release on their own laptop and against Amazon's cloud storage service, S3, to see what changes for people who build data tables and pipelines, not people who build database engines. Two changes explain most of the gain: how DuckDB reads files stored on S3, and how it walks data shaped like a family tree, such as an org chart or a project's commit history.

The S3 improvement needs no changes to your own queries. The test reads one column out of four from a 2.2 gigabyte file, a Stack Overflow voting dataset with 228 million rows split into 2,268 chunks of about 122,000 rows each (called row groups), stored as a compressed table format called Parquet. The author also turned off DuckDB's file cache for the test, so every run really has to hit S3 instead of reusing a cached copy. Old version, 1.5.5: 18.8 seconds. New version, the 2.0 alpha: 7.7 seconds, on the same laptop and the same home internet connection, which the author notes slows both versions about equally. The old version had each of 18 worker threads both download and decode data in turn, so a thread's chip sat idle while it waited on the network, and at most 18 downloads could ever be in flight; the new version changes that by reading ahead of the workers rather than downloading strictly in lockstep with decoding. Three more tests from the same post: 23 large Parquet files totaling 13.6 gigabytes went from 11.8 to 3.9 seconds; one 1.7 gigabyte plain text file went from 116 to 55 seconds; but 30 tiny, roughly 1 megabyte Parquet files barely moved, 3.7 to 3.3 seconds, because that time is mostly a network round trip per file, which reading ahead cannot remove. Storing a data lake as thousands of tiny files is a bad habit no matter which version you run.

The second change speeds up a common type of lookup: following a parent-to-child chain, like an org chart, a folder tree, a reply thread, or a project's commit history, where each row just points to its parent, using what the post calls a recursive CTE. Walking the history of a 20,000 commit code repository back to its first commit, one round per commit, took 1.8 to 16 seconds across different runs on the old version; on the 2.0 alpha it took 0.10 seconds, every time.

These numbers come from one person's laptop and home internet connection to a single AWS region, a caveat the post itself makes. The practical read for you: if any pipeline reads Parquet files from S3, or walks a parent-child structure such as commit history or a reply thread, upgrading to DuckDB 2.0 could cut that work by half to two-thirds with no code changes, because the faster behavior is on by default. The one thing it will not fix is a bad storage layout: thousands of tiny files still cost you a round trip each, version or no version.

Spotted on LinkedIn: a post built around one number, that GitHub now holds 450 million repositories (the stores of code the whole industry builds from), followed by a hand-picked list of 20 AI-related projects on GitHub, ranked by how many people starred them. Stars are GitHub's version of a like button, a rough measure of how many developers noticed and bookmarked a project, not proof it works well. The post sorts the 20 into five groups: AI coding agents, tools for building and running agents, AI infrastructure, learning material, and one curated list.

The first group, AI coding agents, tools that write and run code largely on their own, is topped by OpenClaw at 278,000 stars, ahead of Opencode at 118,000, Claude Code (the tool this very session runs on) at 75,000, Superpowers at 73,000, and Codex at 63,000. The second group, agent engineering and tools, covers the pieces builders wire agents together with: Firecrawl at 89,000 stars, Context7 at 48,000, Scrapling at 25,000, Agent Browser at 19,000, and Symphony at 8,900.

The third group, AI infrastructure, the plumbing that runs models once they are built, lists Open WebUI at 126,000 stars, llama.cpp (code for running AI models directly on a laptop or phone) at 97,000, Daytona at 63,000, and Zeroclaw at 24,000. The fourth group, learning material, runs from Hermes Agent at 200,000 stars and Awesome LLM Apps at 100,000, down to AI Agents for Beginners at 53,000, Prompt Engineering at 32,000, and Hello Agents at 25,000. The fifth and last entry stands alone as a curated list: System Prompts of AI Tools, at 129,000 stars.

None of the five groups come with a description beyond the name and the star count, so treat this as a shortlist to go look at rather than a verdict on what each tool does. The one entry you already have a verdict on is Claude Code itself; everything above and below it on the list is worth a glance the next time you are shopping for a new agent tool or a faster way to pull data off the web.