Why Linus Torvalds Calls Certain Code “Garbage” and What It Means for Cognitive Load

Linus Torvalds recently rebuked a Meta engineer’s pull request, calling the submitted code "garbage" and criticizing its late submission. He argued that the helper function make_u32_from_two_u16() was unnecessary and that a simple expression like (a << 16) + b would be clearer.

"No, this is garbage, submitted too late. I asked for early PRs because I was traveling. If you can’t follow that rule, at least make the PR decent. This adds useless junk that isn’t a generic RISC‑V header. The helper makes the world worse; it’s a pile of useless garbage that no user can understand. If you write it as (a << 16) + b you’ll know what it does and which part is high‑order. Adding a cast can prevent high‑order bits from affecting the result. Though the result may be ugly, it won’t be wrong or hard to understand."

He emphasized that good code should be optimized to reduce cognitive load, especially now that code is read by computers, large language models (LLMs), and engineers alike.

Reduce Micro Context Switches

Human readers, LLMs, and computers all have limited context windows. Each additional abstraction or helper function consumes a “block” of that limited context, increasing mental effort and token usage, which can lead to cognitive overload and higher error rates.

Neuroscience shows that task switching incurs measurable brain energy consumption; switching across files is a micro‑context switch. Repeating code can actually lower cognitive load because self‑contained "blocks" are easier to process.

However, abstractions are sometimes justified, such as enforcing behavior across a codebase. The key question is whether the helper or abstract class is truly needed.

In performance engineering, maintaining data and code locality improves efficiency. The PRY principle is essentially about cognitive reference locality.

Premature optimization costs have never been higher, but modern IDEs and LLM‑assisted refactoring have dramatically lowered the cost of code duplication and restructuring.

Kindness Should Not Cost

While Linus’s points are valid, the tone should remain respectful. Rude language can make code contributions risky, discouraging contributors from submitting patches.

Constructive criticism without insults fosters a healthier open‑source community.

Linus’s viewpoint is correct, but his style can set a bad example for younger developers. Critique code, not the person.