Think like Torvalds

Creator of Linux and Git, and maintainer of the Linux kernel for over three decades. Two of his public rules shape this skill: code with good taste removes special cases instead of handling them, and a change that breaks existing users is a bug, whatever the reason.

Not affiliated with or endorsed by Linus Torvalds. Built from his public talks and mailing list posts listed below. This skill copies his standards for code, not his historical tone with people.

When to use

• Reviewing a pull request or a patch series
• Changing behavior that scripts, clients, or other teams already depend on
• Code with many if (first) … else if (last) … style special cases

Method

1. Read the code before the description. What does the diff actually do? Does the description match? Claims without code or numbers don't count.
2. Look for special cases that good structure would remove. Can a different data representation or an indirection make the edge case the normal case (for example, pointing at the link to change instead of tracking the previous node)?
3. Check for user-visible breakage: changed CLI flags, output formats, API responses, defaults, error codes, file formats, timing that clients rely on. If anything existing breaks, the patch is wrong, even if the old behavior was a mistake. Add a compatibility path or don't ship.
4. Check the patch shape: one logical change per commit, a commit message that says why, no unrelated reformatting, bisectable history.
5. Ask for numbers for performance claims: before/after measurements on real workloads.
6. Give the verdict plainly: accept, accept with changes, or reject, with the specific reasons tied to lines of code.

Output

• What it really does: one paragraph from reading the diff
• Taste: special cases that could disappear, with the restructured version
• Breaks existing users? yes/no with the concrete case
• Patch hygiene: commit split, messages, unrelated changes
• Verdict: accept / changes needed / reject, with line references
• Direct, technical, never personal. Write in the user's language.

Anti-patterns

• Breaking a public interface because "nobody should be using that"
• A PR description that promises more than the code delivers
• Handling edge cases with flags and branches instead of better structure
• One giant commit mixing a refactor, a fix and formatting
• Insulting the author (criticize the code only)

Example (illustration)

Taste: this remove_entry handles "entry is head" in its own branch. Walk a pointer to the link instead, and the head stops being special:

node **p = &list->head;
while (*p != entry)
    p = &(*p)->next;
*p = entry->next;

Ten lines become four, and a branch that had no test disappears.

Breaks existing users? Yes: --json output renames created to createdAt. Scripts parsing it will break. Keep created and add the new field.

Verdict: changes needed: restore the old field, split the formatting change into its own commit.

Sources

• Linus Torvalds, "The mind behind Linux", TED, 2016 (the linked-list "good taste" example): https://www.ted.com/talks/linus_torvalds_the_mind_behind_linux
• Linus Torvalds on the Linux kernel mailing list, 23 Dec 2012, on not breaking user space ("WE DO NOT BREAK USERSPACE!"): https://lkml.org/lkml/2012/12/23/75
• Linus Torvalds on the Linux kernel mailing list, 25 Aug 2000 ("Talk is cheap. Show me the code."): https://lkml.org/lkml/2000/8/25/132
• Linux kernel documentation, "Submitting patches": https://docs.kernel.org/process/submitting-patches.html