What Write Only Code Means and What It Doesn’t

“Write only code� means source code that is written without any intention of being read, reviewed, or maintained by another human—its only purpose is to be executed by a machine. It does not mean code that is merely hard to read or poorly formatted; it refers to a deliberate or accidental state where the code’s readability and maintainability are completely sacrificed, often making it impossible for anyone (including the original author) to understand it later.

Formula

The calculator above provides a rough, subjective “readability score� for a piece of code, based on how many lines you can read and understand per minute. The formula is:

Score = max(0, 100 – (lines / minutes) * 2)

• lines – the number of lines of code you are evaluating (unit: lines)
• minutes – the time you took to read and understand those lines (unit: minutes)
• Score – a score from 0 to 100, where higher means more readable (unit: score)

This is not a scientific metric—it’s a heuristic to illustrate that when you read code very slowly (low lines per minute), the score drops, and when you fly through it, the score rises. A score near 0 suggests the code is effectively “write only� for you.

Worked Example

Using the default values: you have 100 lines of code and you take 10 minutes to read them.

1. Lines per minute = 100 / 10 = 10
2. Multiply by 2: 10 * 2 = 20
3. Subtract from 100: 100 – 20 = 80
4. Max with 0: 80

The calculator returns a readability score of 80, which is fairly readable.

Background: Where the Term Comes From

The phrase “write-only code� has been around in programming culture for decades, often used humorously to describe code that is so convoluted that it can only be written, never read. It’s a play on “read-only memory� (ROM) and “write-only memory� (WOM), a joke term for hardware that you can write to but never read from—which is useless. In software, write-only code is similarly useless because code that cannot be read cannot be debugged, extended, or reused.

The term gained traction in the 1980s and 1990s with the rise of code reviews and maintainability as professional practices. It is often associated with “spaghetti code,� “code golf� (writing the shortest possible code, often at the expense of clarity), and “legacy code� that nobody wants to touch.

What Write Only Code Actually Looks Like

Write-only code isn’t just ugly—it has specific, recognizable traits:

• No comments or documentation – even when the logic is non-obvious.
• Cryptic variable names – like a, b, x1, or temp.
• Deeply nested control structures – five levels of if/else inside loops.
• Copy-pasted blocks – instead of functions, the same code appears dozens of times.
• Global state everywhere – functions that depend on and modify global variables, making order of execution critical.
• Magic numbers – unexplained constants like 86400 or 3.14159.
• Overly clever one-liners – using obscure language features to save a few characters.

But note: write-only code is not the same as code written by a beginner. Beginners write unclear code because they don’t know better. Write-only code is often written by experienced developers who are either in a rush, trying to be clever, or simply don’t care about the future.

Why People Write It (and Why It’s a Problem)

There are several reasons why write-only code gets created:

• Deadlines – “We’ll fix it laterâ€� is a famous last words. Later never comes.
• Job security – a toxic mindset that if you make your code unreadable, you can’t be replaced.
• Lack of code reviews – if no one else ever looks at the code, there’s no external pressure to make it readable.
• Prototyping gone wrong – a quick hack that accidentally ends up in production.
• Ego – writing “cleverâ€� code that impresses peers but confuses everyone else.

The cost of write-only code is enormous. When a bug appears, the developer who wrote it may have moved on, and the new developer has to spend hours or days just figuring out what the code does. This is why the software industry has developed practices like code reviews, pair programming, and linting—all to prevent write-only code from entering the codebase.

What Write Only Code Does NOT Mean

It’s important to clear up common misconceptions:

• It’s not just “bad codeâ€� – bad code can still be readable; write-only code is unreadable by design or neglect.
• It’s not the same as “code golfâ€� – code golf is a recreational challenge to write the shortest code; it’s often write-only, but it’s a deliberate game, not a production practice.
• It’s not “legacy codeâ€� – legacy code is old code that still works; it may be hard to maintain, but it often has documentation and structure. Write-only code is a quality issue, not an age issue.
• It’s not “code that only the author can readâ€� – in practice, even the author often can’t read it after a few months.

How to Avoid Write Only Code

Preventing write-only code is a matter of discipline and process:

1. Write comments – explain why, not what. The code says what; comments say why.
2. Use meaningful names – customerAge is better than ca.
3. Keep functions small – a function should do one thing.
4. Refactor ruthlessly – when you see duplication, extract it.
5. Do code reviews – have peers read your code before it merges.
6. Follow a style guide – consistent formatting makes code easier to scan.
7. Use static analysis tools – linters can catch overly complex code.

Frequently Asked Questions

Is write-only code ever acceptable?

In rare cases, such as a throwaway script that will run once and be deleted, it might be acceptable. But even then, you might need to reuse it later. As a rule, assume your code will be read by someone else (including future you) and write accordingly.

Can write-only code be fixed?

Yes, but it often requires rewriting rather than incremental fixes. The first step is to understand what the code does (which may require running it with debug output), then refactor it into smaller, named functions with clear logic.

What’s the difference between write-only and obfuscated code?

Obfuscated code is intentionally made hard to read, often for security or intellectual property protection. Write-only code is usually not intentionally obfuscated—it’s just a byproduct of poor practices. Obfuscation is a deliberate technique; write-only is a failure.

Does write-only code mean the programmer is bad?

Not necessarily. Even great programmers can write write-only code under extreme deadline pressure or when they’re new to a codebase. What matters is whether they recognize it and correct it.

Is there a tool that can measure write-only code?

There are complexity metrics like cyclomatic complexity and maintainability index that can flag problematic code, but no tool can truly measure “write-only-ness.� Human review is still the best detector.

Related

• Indigenous Smartphone Design: Local Parts & Meaning
• Steam Not Enough Disk Space? Fixes That Work
• Best Fuel Efficient Cars to Cut Monthly Fuel Costs

in t | Time to read (minutes) | min | 10 | 0 | 1440
in l | Lines of code | lines | 100 | 1 | 100000
out pace | Readability score | score | max(0, 100 - (l / t) * 2) | 0