Why Writing More Code Doesn’t Mean Better Engineers – Lessons from Apple’s Bill Atkinson

In many developers' daily work, the number of lines of code written per day or week is often treated as a KPI, a measure of efficiency, or even a gauge of a developer's value.

But does writing more code really mean greater ability or contribution?

A classic story resurfaced on Hacker News: early Apple engineer Bill Atkinson rewrote an algorithm, boosting software performance by nearly six times while eliminating about 2,000 lines of code.

When asked to report his weekly code count, he boldly wrote "-2000" as a protest against using line count as a productivity metric.

Atkinson, the creator of the QuickDraw graphics engine and a key UI designer for the Lisa and Macintosh projects, believed that code lines were a terrible measure of efficiency. He aimed to make programs as small and fast as possible, and the line‑count metric encouraged bloated, low‑quality code.

By completely rewriting QuickDraw’s region‑calculation engine with a simpler, more generic algorithm, he achieved almost a six‑fold performance increase and simultaneously removed roughly 2,000 lines of code.

His act discouraged management from demanding such reports from him again.

Other developers shared similar “code‑deletion triumphs.” One user, bironran, described deleting about 60,000 lines of code after replacing a complex, memory‑intensive server component with a concise 5,000‑line solution, dramatically improving performance and maintainability.

Another anecdote from a university intern described deleting three‑quarters of a Turbo Pascal codebase—thousands of lines—while working on a project for the U.S. Department of Energy that managed nuclear material inventories.

Not everyone dismisses code‑change volume. A team manager noted that, after analyzing two years of commit data, the most productive members indeed had significantly larger code‑change amounts, including both additions and deletions, suggesting that change frequency can reflect participation when the context is clear.

Ultimately, the consensus is that a programmer’s value should not be defined by the sheer number of lines written. Instead, engineers should strive for cleaner, clearer, and more stable code, often achieving greater impact by removing code rather than adding it.

Code is valuable not only when written but also when deleted.