# Eagleson's law

> Code you wrote six months ago might as well be someone else's, so write it for a reader who has none of your context.

Concept · Laws of software engineering · https://levelcode.org/concepts/eaglesons-law

**Eagleson's law** says: any code of your own that you haven't looked at for six or more months might as well have been written by someone else. It circulates in collections of programming laws; who Eagleson was is unclear. The idea is familiar to anyone who has run `git blame` on a confusing line and found their own name.

## How it works

While you're writing code, your head holds most of the context: the bug you were avoiding, the option you tried and dropped, why the odd special case exists. None of that is in the code. After a few months the context is gone, and you're left with only what you wrote down: names, structure, comments, tests and commit messages. If those don't explain it, you have to reverse-engineer your own reasoning.

It follows that the reader you should write for is not a colleague who already knows the system. It's a capable stranger, and in six months that includes you.

> [!NOTE]
> **How AI changes it.** Two shifts weaken the law as stated. First, coding assistants can read an unfamiliar module and explain what it does in seconds, so returning to "someone else's" code is far cheaper than it was. Second, a growing share of code is generated rather than typed, so it was never in your head in the first place: the six months is now zero. Both shifts move the problem rather than solve it. An assistant can tell you *what* the code does. It cannot tell you *why* this approach was chosen over the obvious one, which constraint the special case protects, or which behavior callers [depend on](https://levelcode.org/concepts/hyrums-law). That was never in the code, so it has to be written down.

## What to do about it

- **Write the why, not the what.** Comments and commit messages should record intent and rejected alternatives; the code already shows what it does.
- **Use history.** `git log -p` and `git blame` lead from a line to the change and message that introduced it, so the message is worth writing well. [Exploring history](https://levelcode.org/roadmaps/git/first-repository) covers `git log`, and [git bisect](https://levelcode.org/concepts/git-bisect) finds the commit that changed a behavior.
- **Let tests document behavior.** A test named for the case it protects explains a special case better than a comment, and fails when the explanation stops being true.
- **Prefer boring code.** A clever trick saves a minute now and costs an hour every time someone, including you, reads it later.