Code as Communication

Here's a number that should change how you think about code: 10:1.

For every minute you spend writing code, someone will spend 10 minutes reading it. That someone is usually future you.

This isn't a guess. Studies of developer behavior consistently show that we spend the vast majority of our time reading, navigating, and understanding code—not writing it.

The Fundamental Insight

The Art of Readable Code puts it simply: Your goal should be to minimize the time it takes someone else to understand your code.

Not to minimize lines. Not to minimize characters. Not to look clever. To minimize understanding time.

This is a profound shift. Instead of asking "How do I make this work?" you ask "How do I make this obvious?"

Writing for Your Future Self

In 6 months, you won't remember why you wrote that code. You won't remember what processData was supposed to process. You won't remember why you checked for status === 3.

I've spent entire afternoons reverse-engineering code I wrote myself. It's humbling. And it's avoidable.

The developer who will maintain your code most often is you. Write code that helps that person.

Machines vs. Humans

Here's code optimized for the machine:

for (let i = 0; i < a.length; i++) {
  if (a[i].s === 1 && a[i].t > n) r.push(a[i]);
}

The computer doesn't care. It will execute this perfectly. But you—trying to understand what this does at 3pm on a Friday—will struggle.

Now the same logic, optimized for the human:

const activeUsers = users.filter(user => 
  user.status === ACTIVE && user.lastLoginAt > cutoffDate
);

Same result. Radically different experience reading it.

Notice what changed:

• a became users — the data has meaning
• s === 1 became status === ACTIVE — the magic number has context
• t > n became lastLoginAt > cutoffDate — the comparison is self-explanatory
• The loop became filter — the intent is declarative

The "Newspaper Article" Principle

Good code reads like a newspaper article:

1. Headline first — The function name tells you what happens
2. Lead paragraph — The first few lines give you the gist
3. Details follow — Dive deeper only if you need to

If someone has to read your entire function to understand what it does, you've failed. They should be able to stop at the function name and know enough.

Code Review Through This Lens

When reviewing code, ask:

• Could a new team member understand this in under 5 minutes?
• Would I understand this if I saw it 6 months from now?
• Are there any lines where I had to pause and re-read?

Every pause is a signal. Every re-read is a cost. Every moment of confusion is a bug waiting to happen.

The Trade-off

Clean, communicative code can be more verbose. That's okay.

Compare:

const x = a ? b : c ? d : e;

vs.

let result;
if (isPremiumUser) {
  result = premiumPrice;
} else if (hasDiscount) {
  result = discountedPrice;
} else {
  result = standardPrice;
}

The second version is longer. It's also immediately clear. The first version is a puzzle you have to solve every time you read it.

Clarity wins. Every time.

What to Do

1. Name things for the reader — Would someone unfamiliar with the codebase understand this name?
2. Prefer explicit over clever — Clever code is fun to write and painful to debug
3. Read your own code cold — Come back to code you wrote last week. Can you understand it instantly?
4. Optimize for skimming — Most readers will skim your code. Make the important parts visible.

Key insight: Code is read 10x more than it's written. Optimize for the reader, not the writer. Your future self will thank you.