Thread by @tottinge

You know what I don't do as a developer?
Memorize a big codebase.
I used to try, but then found I couldn't do it.
As a result, I have to make it scannable, discoverable, readable.

This has an unexpected benefit.

As it turns out, human memory is not a shared resource. There is an advantage to the person who knows how it all works, provided nothing changes (much).

But nobody else owns your memory, and it leaves with you.

I later found out that my "inability" to memorize a big code base is the reason people appreciated my code and found it useful and maintainable.

I didn't really do it for them at first, but as a survival tactic in a world where a lot of people had better memories than me.

Later as people move from company to company and team to team, memorizing the whole codebase became a rarity. There are still some people who have been in the same codebase for 8+ years, but it's hella uncommon.

And most of them have had to tolerate code being reformatted, refactored, reworked, "cleaned" etc.

They lamented that they *used* to know where function X was -- it was line N of file F. Now they have to hunt for it b/c it's changing so fast.

Memorization used to make them great at their work, and still knowing how it all works is a big advantage. But now the rate of change is high, and that's a good thing.

Sometimes old advantages evaporate as context changes.

The question then becomes whether the changes that discomfit us actually serve our community better than the context that was advantageous to us personally.

That is where it gets hard to embrace change.
But let's not reject good change.

And while memorization isn't the advantage it used to be, I still admire the people who can and have done it.