Part of my job description is getting stuck with things.

Programming, businesses, research, you name it. Getting stuck is an integral part of everything I do.

Getting stuck is unavoidable, and sometimes even fun. Yet it hinders progress. Getting unstuck feels more like escaping quicksands rather than steadily moving forward.

In my work, I've noticed one particular kind of being stuck that is always captivating but rarely rewarding. It makes me slow and indecisive, all while making me feel that I'm doing the most important work.

I'm talking about "organizing things ™️."

(Dis)organizing data

I write things down and then create a structure for them:

• Code gets put into files, functions, modules, classes, etc.
• Research notes get put into all different kinds of note files and lists, connected with all sorts of links.
• Tasks and plans get assigned to quarters, weeks, days, projects, colors of the sky, and Moon phases.

Sometimes it's trivial: there's already the best place possible for this new thing I need to organize.

However, other times it's less obvious:

• Which level of abstraction works best for this new code? Do I add it to an existing abstraction or create a new one? How does it connect to other things? What would be the API surface?
• Where do I put this insight I've just gained from reading a book? Should I keep a "list of insights"? "Notes on Existentialism"? Do I only leave it in the "notes on book X"? Do I organize those notes per chapter or per topic?
• Do I organize my tasks by status? Do I package them into weekly sprints? How do I maintain my backlog?

After many years of being a premature optimizer of everything in life, I've realized one thing: Most of the time I spent "organizing" didn't lead to any pragmatic benefit.

On the contrary, every time I prematurely organized my code, notes, or tasks, it led to individual items spilling all over the place, adding more and more indirection. And it made harder, not easier, to navigate and use them.

I faced this pattern so much in programming that I wrote a whole essay dedicated to it: No architecture is better than bad architecture

Don't get me wrong: One cannot magically avoid organizing data beyond a certain point, nor should they oppose the idea of organization.

The problem rises when you either do it unnecessarily or prematurely.

The problem is creating a poor structure when no structure is necessary.

Ultimately, the problem is getting stuck when you shouldn't.

Start with one

I also found a solution.

Unless it's obvious where to put The Thing, start with one: list, function, file, etc.

Start with one and stick with it for as long as it's convenient in practice. Often it would mean forever.

Keep it intentionally disorganized until it begs for structure for reasons that are rather pragmatic than intellectual.

There's a reason why a single index.php or (my favorite) Untitled.txt work for many people. And it's the same reason why some people get fatigued by overuse of design patterns in programming, or by using advanced note-taking tools like Roam or Obsidian.

The tools are not the problem. The problem is thinking that any data is worthless unless perfectly organized.

Resist. Start with one.

The Trial of usefulness

There may come a day when you look at your 3000-line code file or an endless list of "all my tasks in life" and a fresh thought occurs to you:

"Ugh, this sucks!"

Congratulations! Now you know it's time to do something about it.

This moment signifies the most important fact about that mess of a thing: you are still using it!

Don't take it for granted. Most code you wrote will mostly remain in its "v0" version. Most notes you took, you will never really read again. Most tasks you defined, you will never even start.

Most of the letters you enter into your computer are not that important. But some are. Let those surface first.

Heuristic not a rule

Before wrapping up, I want to go back to an important caveat I touched on earlier.

Sometimes I do know, most often from having done it before, the proper way of organizing something from the get go.

In such cases, if it worked before, it would probably work again, so I go for it.

Similarly, with time I learn which code, notes, tasks, and so on are more likely to end up being important.

This is why I treat this principle as a catch-all rule for cases when my experience doesn't give me a reliable answer.

Letting the Things pile up might not be the most optimal way. However, you don't store those Things just for the sake of doing it (hopefully).

You do all that to accomplish something down the line. And if you value getting things done more than being the world's best collector, you will find this trade off acceptable.