Reading code instead of writing code: The underestimated senior discipline | heise online

heise+ entdecken

SuchenAbo

Suchen

Alle Magazine im Browser lesen<br>Newsletter<br>heise-Bot<br>Push-Nachrichten

${lead}

${lead}

${content}

${content}

${content}

${content}

Advertisement

Advertisement

In April 2000, Stack Overflow founder Joel Spolsky published an essay titled “Things You Should Never Do, Part I”. The occasion was Netscape's decision to rewrite the code of its then-browser from scratch instead of further developing the existing one.

Continue after ad

Golo Roden is the founder and CTO of the native web GmbH. He works on the design and development of web and cloud applications and APIs, with a focus on event-driven and service-based distributed architectures. His guiding principle is that software development is not an end in itself, but must always follow an underlying technical expertise.

Spolsky's thesis: This decision was the worst strategic mistake a software company could make. It was based on a fundamental misunderstanding of what programming work actually is. Programmers prefer to rewrite because reading foreign code is tedious and writing feels productive. But this impression is deceptive. The temptation to start over is one of the most expensive temptations in the industry.

More than 25 years later, this text has lost none of its relevance. On the contrary. With the advent of Large Language Models (LLM), the asymmetry between writing and reading has shifted to such an extent that the question becomes acute whether we are systematically underestimating the true senior discipline of software development. Typing is not what will keep teams breathless in the coming years. Reading is. In this article, I want to show why this is the case, where the asymmetry comes from, how it is exacerbated by generative AI, and how a casual accompanying skill must become an independent discipline.

Your own code becomes foreign code after three weeks

When writing, you have everything in your head at once: the requirement, the data model, the planned architecture, the part you are currently working on, the assumptions you are making, the trade-offs you are entering into. This overall mental view makes writing fast. It is also what is missing when reading.

If you look at the same code again three weeks later without bringing the context, you have to reconstruct this overall view. Variable names provide clues, tests say more, a pull request comment provides the technical reason in the best case, a commit message with luck the last justification. The actual intention, the thought model, the discarded alternatives, all of that is lost. Reconstruction costs time and concentration, and both are pricier than writing.

Videos by heise

mehr Videos

c't 3003

heise & ct

Peertube

Spolsky's anecdote is so vivid because it shows this asymmetry at the organizational level. At Netscape, they were faced with an old codebase that no one wanted to decipher anymore. The temptation to simply rewrite the whole thing was strong. The result is known: three years of stagnation, a lost browser market, a company declining. The seemingly easier path was the most expensive.

Continue after ad

At the individual level, the same pattern repeats daily. It appears in Stack Overflow answers that suggest an alternative instead of answering the question. It appears in colleagues who suggest refactorings without really understanding the existing code. Furthermore, it appears in the temptation to replace a module rather than improve it. Reading is and remains inconvenient.

LLMs tip the balance definitively

A modern LLM generates several hundred lines of code in the time it takes a person to skim those lines once. Generating has become cheap. Tokens are cheap, waiting times are short, and the mental model for the task has shrunk to formulating a prompt. The effort on the writing side has effectively collapsed.

On the reading side, nothing has changed. Understanding still costs what it always has: focused attention, time, patience. The human processing speed for code is roughly a few lines per minute, significantly less depending on complexity. This magnitude cannot be accelerated by tools because it depends on human cognition itself.

The result is a grotesque shift. Where a day's work used to produce about a hundred lines of code that a reviewer could go through in half an hour, an hour of prompt work can now generate thousands of lines. The amount to be understood grows dramatically, while the speed of understanding remains constant. What used to be a bottleneck in writing now becomes a bottleneck in understanding.

This shift is ignored in many discussions. Productivity on the generation side is celebrated, while the balance on the reading side is silenced. What is not read is not understood. What is not understood is not reliably operated. The debt merely shifts to the future; it does not disappear.

This becomes visible at the...