The Discipline of Reuse — Designing by Not Writing

The conventional industry assumption is that the best programmers write the most code. Productivity is measured in commits per day, lines of code per week, features shipped per quarter. In 1999, Eric S. Raymond proposed exactly the opposite. In The Cathedral and the Bazaar, he formulated what is now widely cited as Lesson 5²:

Good programmers know what to write. Great programmers know what to rewrite (and reuse).

The proposition sits in plain sight, but its full weight is easy to miss. Greatness in programming is not measured by what one chooses to write. It is measured by what one chooses not to write ── what is recognised as already extant, already maintained, already proven, and therefore appropriately consumed rather than rebuilt. This article traces how the same proposition runs from the deepest substrate of the UNIX tradition through the OSS ecosystem to contemporary AI-tool design.

“Do One Thing Well” ── Reuse Built Into the Substrate

Twenty-one years before Raymond’s declaration, Doug McIlroy at Bell Labs articulated the design philosophy that would carry the UNIX system through five decades of evolution³:

Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new “features”.

This was the philosophy that supported the pipe. grep searches; sort sorts; uniq deduplicates. Each is small, individually reusable, freely composable ── and the composition is what becomes the user’s creative space.

At this point the value of not writing is already embedded in the substrate. Read McIlroy’s claim from the inverse direction: when new functionality is needed, look first for a way to achieve it through existing programs in combination. Avoiding writing new code in favour of new compositions is not a clever optimisation: it is the original UNIX move, expressed in 1978 before “open source” was a phrase.

The Other Side ── Knuth’s Responsibility to Be Read

If McIlroy articulated the philosophy of the side that composes, Donald Knuth in 1984 articulated the philosophy of the side that gets composed ── Literate Programming⁴:

Let us change our traditional attitude to the construction of programs: instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to humans what we want a computer to do.

Read against the reuse principle, this paradigm shift carries a deep implication. For code to be reusable by others, the others must be able to read it. The gap between code that works and code that someone else can read is profound, and bridging that gap is the responsibility a literate programmer accepts.

The TeX system Knuth wrote single-handedly remains in active service across global academic typesetting today. Roughly 25,000 lines of code, written by one person, reused by millions of hands across multiple decades ── this is what it looks like when a writer takes the responsibility to be reusable seriously, to its limit. The discipline of not writing requires that someone, on the other side of the equation, has taken the responsibility of writing well. Knuth represents that side.

The Composition Philosophy ── Porcelain and Plumbing

The division of labour between the side that writes and the side that composes is articulated most cleanly in Git’s design vocabulary: porcelain and plumbing⁶.

• Porcelain: high-level commands polished for the user (git commit, git push)
• Plumbing: low-level commands that the porcelain calls beneath the surface (git update-ref, git hash-object)

Porcelain does not rewrite plumbing; it composes it. The author of plumbing takes on the obligation to provide a stable interface that porcelain can rely on. The two layers are interdependent through trust.

Brian Kernighan and Rob Pike, in The Practice of Programming (1999)⁵, translated this division into everyday practice ── use libraries and idioms aggressively. Before writing anything, check whether it already exists. Minimise what needs to be written. Their proposition is not minimalism for its own sake but a direct application of the reuse principle to the level of the working programmer.

McIlroy (1978) → Knuth (1984) → Raymond (1999) → Kernighan & Pike (1999) → Git (2005). The philosophy of not-writing has been independently rediscovered, in slightly different vocabularies, every step from the UNIX substrate through the OSS golden era to the modern composition stack.

OSS as Trust Infrastructure

For not writing to be a viable strategy, one further condition must hold: the code being reused must be trustworthy. Operational reliability, API stability, maintenance continuity, security transparency ── absent any of these, reuse becomes the act of importing risk.

The OSS ecosystem solves this through visibility. When code is publicly available, anyone can read it, verify it, fork it, improve it. Linus Torvalds’s well-known formulation, articulated in Raymond’s writing as Linus’s Law², captures the epistemological consequence directly:

Given enough eyeballs, all bugs are shallow.

Open source is not merely a licensing posture: it is the trust infrastructure without which a discipline of large-scale reuse would be unworkable.

The discipline of not writing is thus not only a technique-level efficiency principle. It is simultaneously a declaration of dependence on, and participation in, the OSS commons. To reuse is also to file bug reports, to write missing documentation, to fork-and-improve when warranted, and to contribute upstream where possible. The ethics close only when the participating side returns its share to the commons.

A Concrete Example ── Not Writing in an AI Toolchain

The discipline of not writing has entered a new register in the AI era. Consider media-scribe-workflow⁷, an open-source toolkit the author of this article maintains for converting recorded talks into typeset proceedings. Most of the substantial functionality is not written by the toolkit’s author:

Capability	Borrowed from	Written by
Speech recognition	Whisper	OpenAI team
Contextual analysis / structuring	Claude API	Anthropic team
Typesetting	LuaTeX (Lua + TeX)	Knuth and successors
Video encoding	ffmpeg	Bellard et al.
GUI framework	PySide6 / Qt	Qt Company + The Qt Project
Image processing	OpenCV	OpenCV.org community
Subtitle format	SRT	SubRip developers

What remains to be written by the toolkit’s author is how these pieces connect. Each underlying layer has been verified by millions of users, hardened by years of maintenance, and stabilised behind a documented interface. In Raymond’s terms, choosing to write only the connective tissue is what greatness reduces to in this domain.

The same shape applies to luatex-docker-remote⁸: the entire TeX Live distribution, the Japanese font ecosystem, Docker, SSH, rsync ── nothing is written from scratch. What was written is a thin layer of shell scripts that compose these components into the workflow “compile remotely, sync the source files, fetch the PDF, leave the local environment clean”. When not writing is maximised, the unique capability that emerges sits at the level of orchestration ── and orchestration is what the writer’s contribution actually consists of.

---

Re-read in the broader context, the discipline of not writing carries an ethical dimension that goes beyond programmer productivity. Reuse is, in the end, standing on the accumulated labour of others ── a socialised face of what the foundational essay Relative, Not Deterministic calls mediation: a tool or medium, as the thing standing in between, prescribes what can be seen, what can be done, what becomes easy to think. What Clark and Chalmers (1998) framed as the extended mind from the cognitive-science side, and what this site calls mediation, are the same situation through different entrances¹. Not writing is the version where that mediation is delegated to other people’s excellent implementations ── and the borrowed mediation is not neutral: it bends my thought toward “thinking in grep” or “thinking in TeX”. So “what to borrow” is at once an efficiency question and a “shape of thought” question. The companion essay Writing as Thinking — Where Tools and Thought Meet (currently in Japanese) traces that lineage.

For this relationship to operate fairly, two symmetrical responsibilities are required.

First, the borrowing side must remain conscious of borrowing. License compliance, attribution, monetary contribution where appropriate (FOSS sponsorship, paid commercial OSS support) are not optional decorations but the substantive form of not free-riding on the commons.

Second, the writing side must write as if reuse is the default. Knuth’s literate programming ethic, comprehensive testing, maintained documentation, API stability commitments, backward-compatibility discipline ── these are the obligations that the writer of reusable code accepts in exchange for the privilege of being reused.

Designing by not writing presupposes a symmetric ecosystem where both responsibilities are honoured. As large language models enter the field as a new kind of writing side ── generating code that may then be reused by humans ── this symmetry is being tested in unprecedented ways. When LLMs write the code we reuse, what exactly are we borrowing, and what is the appropriate return? This is one of the genuinely open questions of contemporary intellectual labour, and the discipline of not writing, articulated in 1999, is a starting framework for posing it precisely rather than dissolving it into hype.

To not write is, technically, an efficiency choice; ecologically, a commitment to trust infrastructure; ethically, an acceptance of mutual responsibility. Raymond’s 1999 declaration carries all three weights at once ── and, in the LLM era, those weights have only grown.

References