Skip to main content

About

You probably consume a lot of information too. Books, podcasts, articles, videos. So here’s my question: how do you remember any of it when you actually need it?


I’ve been reading about a book a week for five years, and I follow more podcasts than I can keep track of. My Readwise holds over 17,000 highlights, and I’ve reviewed them every day for more than 2,100 days without breaking the streak.


Capture, in other words, was never my problem. Discipline wasn’t either. The problem was subtler: 17,000 highlights are still someone else’s sentences, and recognizing an idea when it resurfaces is not the same as being able to reach for it when a decision is in front of you.


So I rebuilt the back half of the process. Ideas worth keeping now get compressed into a single note in my own words, drawing on every source that converged on the same idea. Those become flashcards I review daily — retrieval practice rather than re-reading. And the ones I want permanently go into memory palaces; I ended up writing my own app for that.


This blog publishes one visible slice of that system: one idea per post, synthesized from whatever sources arrived at it, with the flashcards included so you can test yourself rather than just nod along. Not book summaries — what survives them.


The subjects are whatever I’m reading: technology, leadership, personal growth, health and longevity. Sources are always linked. The Anki decks are public. Take them.


And tell me how you do it. Your system is probably better than mine in ways I haven’t thought of — the comments are open, and that exchange is the part I’m most interested in.

— Mihai Giurgiu

Comments

Popular posts from this blog

You cannot out-architect your org chart

In 1968 Melvin Conway published an observation that has since outlived most of the technology it was written about: organizations that design systems are constrained to produce designs that copy their own communication structures. It sounds like a curiosity. It is closer to a law of physics. Siloed departments produce siloed systems. Departmental budgets produce departmental technology choices. Teams measured locally produce locally optimized architectures. None of this requires anyone to make a bad decision — every actor can behave sensibly within their scope and the result is still fragmentation, because no one is accountable for the whole. This leads to the uncomfortable conclusion for anyone who owns an architecture function: governance cannot win this fight indefinitely. You can publish principles, run review boards, and maintain a target-state model, and the organization will still quietly re-fragment your systems — faster than governance can integrate them — as long as repor...

The model is the commodity. The map is the moat.

Most organizations approaching AI agents ask which model to use. It is the wrong first question, and the answer keeps changing anyway. Here is the more useful framing, which I picked up from Eran Yahav of Tabnine and have not been able to unsee since. An enterprise agent stack has three parts, not one: The LLM — powerful, general, and completely ignorant of your organization. It has never seen your systems, your history, your incidents, or the reason that one service is named after someone's dog. The agent — orchestration, tool use, interaction with humans. The context engine — a persistent, continuously maintained map of the organization itself. Almost everyone invests in the first two and improvises the third. That is why agents fail most complex enterprise tasks — and the failures are usually not reasoning failures. They are onboarding failures. The agent lacks the knowledge a human engineer accumulates in their first few months and then never thinks about again. The bl...