The case for explicitness over magic: in Java — less reflection and annotation magic; in Rust — fewer macro DSLs; in Go — it is the language’s whole philosophy; in Python — “explicit is better than implicit” from import this.
The best-known statement is the preface to Abelson and Sussman’s Structure and Interpretation of Computer Programs (1985): programs must be written for people to read, and only incidentally for machines to execute. Knuth’s literate programming (1984) made the same bet in tooling. The Python version is Tim Peters’s Zen of Python (PEP 20); the Go version is Rob Pike’s proverb “Clear is better than clever”.
The popular phrasing is “code is read an order of magnitude more often than it is written.” “An order of magnitude” is rhetoric here, not a measurement, and it is not the part worth holding on to. The testable part: after it is first typed, the text goes through review, incident diagnosis, edits by a neighbouring team, and reading by someone hunting for exactly where it breaks — and the cost of each of those passes depends on how much of the behaviour is expressed explicitly. Magic saves time exactly once — at the moment of writing, for the person who already holds the whole picture in their head.
What magic costs, concretely. Spring’s @Transactional works through a proxy, so a call from one method of a bean to another method of the same bean bypasses the proxy and runs without a transaction — nothing in the code at the call site says so, and the bug shows up as partial writes under failure. An ORM that loads relations lazily turns a loop over 1,000 orders into 1,001 queries that are invisible in the source. In both cases the cost is paid by the reader during an incident, not by the author.
Where explicit is not clearer. Readability is relative to the reader. A #[derive(Serialize)] or a SQL query is “magic” in the sense that it hides work, yet every reader on the team knows what it does; spelling it out by hand would add noise and a place for bugs. Explicitness repeated in fifty places is duplication of knowledge (43). The test is not “no abstraction” but whether the next reader can predict behaviour from what is on the screen (46, 7).