The Fine Line Between Experience and Repeating Yourself

If You Don’t Write It Down, It Didn’t Happen

When a senior dev runs into a bug, they don’t start from scratch.

They draw on years of pattern recognition. Symptoms remind them of past edge cases.

Logs feel familiar. Their brain quietly starts pattern-matching against a messy, lived-in archive of past problems, fixes, and “never doing that again” moments.

Same thing happens with engineering leaders. We deal with ambiguity, misalignment, missed bets, surprise attrition, reorg whiplash, and sudden reprioritizations. Over time, you get better at spotting patterns here too.

But that only works if we’ve been diligent about capturing those experiences.

The wins and the misses. When we didn’t see it coming. When we overcorrected.

When we nailed it but never stopped to ask why it worked.

For me, that reflection workflow has lived in Logseq since 2022.

Just a bunch of simple Markdown files that live in my work OneDrive (yeah, this is Microsoft work stuff, compliance matters).

When I’m in the middle of something and an idea pops up, I offload it as soon as I can.

A quick note, a screenshot, a TODO.. whatever’s fastest. What matters is not losing it.

It’s not clean. It’s not pretty. But it works. And those little moments compound value over time. They let me link ideas, trace decisions, and spot patterns I’d long forgotten.

There’s probably more to share on how I use this system day to day, but I’ll save that for another time.

In any case, it doesn’t have to be fancy. Just consistent. Whatever works for you, as long as it is searchable. Revisit it now and then. That’s it. None of this is rocket science.

But I’ve still had to relearn the same damm lesson more times than I’d like to admit.