How to Write Code Without Having to Read It

Summary

The article argues that developers can minimize code reading when fixing bugs or changing features by focusing on information not already checked by tools. It recommends locating a user-visible entrypoint, then making a deliberately breaking edit and climbing the callstack through build errors rather than reading each caller. Strict types, tagged unions, exhaustive switches, linters, and unit tests expose incompatible inputs, missing cases, deprecated patterns, and affected consumers; pure functions separated from side-effect code keep tests simple and informative. After the tooling-driven passes, developers manually confirm behavior, revisiting the design when runtime issues remain and making future changes more "unread"-able.

Context

Extra reading is described as wasteful because it complicates the developer's mental model and increases the chance of losing track of critical information. The goal is to skip areas checked by the computer and focus human attention on areas susceptible to human error.

Approach / What changed

Locate the relevant entrypoint using user-visible strings, accessibility labels, UI position, component properties, or git bisect for regressions. Make a breaking change, follow build errors up the callstack, then use linters, additional type errors, exhaustive checks, and unit-test failures to guide the return pass. Separate pure decision logic from side-effect code and manually confirm the final behavior.

Takeaways

• User-visible strings, accessibility labels, screen position, component type, and distinctive style parameters can help locate a UI component without relying on naming conventions.
• Tagged unions and strict type changes can make invalid argument combinations impossible or expose affected callers through build errors.
• Separating business decisions from side effects enables simpler unit tests with less setup, mocking, and contextual reading.

Related reading