Essays 6 min read

Why Thirty-Three Repositories Needed a Census

I had thirty-three git repositories and treated all thirty-three as if they were on fire. The fix was not more discipline or a better tool. It was a census: an inventory, an edge, and a rule for what counts as alive. Domain cartography applied to my own sprawl.

Why Thirty-Three Repositories Needed a Census

I have thirty-three git repositories under one organization, and for a long time I treated all thirty-three as if they were on fire.

Every one of them sat in the same folder, at the same brightness, with the same silent claim on my attention. Opening the directory felt like walking into a room where thirty-three people all start talking at once. Some of those projects were genuinely active. Some had not been touched in months and were fine that way. A few were finished. One or two were probably dead and just had not been told. But nothing in the way I had them arranged said which was which, so my brain did the only thing it could with an undifferentiated pile: it treated the whole pile as urgent, and I paid an anxiety tax every single time I looked at it.

The reflex, when this happens, is to assume the problem is you. You need more discipline. You need to finally learn the tool that will organize everything. You need a monorepo, or a better dashboard, or a weekend of cleanup. I tried versions of all of that, and none of it touched the actual problem, because the actual problem was not effort and it was not tooling. It was that I had never made the domain legible to myself. My bottleneck was never knowledge. It was governance.

Sprawl is a symptom, not the disease

Here is the thing I had backwards. I thought the sprawl was the problem. The sprawl was a symptom. The disease was that there was no map, and with no map, every repository defaulted to the same status: equally alive, equally my responsibility, equally on fire. A collection only becomes a burden when you have no way to say that some of it is at rest.

That reframing is the whole move, and it comes straight out of the practice I have been writing about, domain cartography, the craft of making a complex domain legible enough to navigate. My repositories were a domain. A real one, with parts and forces and edges, and I had simply never charted it. I had been living inside it by memory, and memory is exactly the thing that fails at this scale. So I stopped trying to remember my way through thirty-three repos and started trying to map them. The map has a name. It is a census.

What a census actually is

A census is not a cleanup. Cleanup is where most people start, and it is a trap, because you cannot clean a domain you have not yet described. You end up making a hundred small irreversible decisions in a fog. A census comes first. It is just the first three layers of the method run on a real domain, and it goes in order.

First, the inventory. I wrote down all thirty-three, fast, flat, no sorting. This is the primitives layer, and it did the thing it always does: the moment the pile became a numbered list, it stopped being infinite. Thirty-three is a lot. It is also a specific, finite, countable amount, and a specific finite amount is something a person can actually govern. The fog was never the repos. The fog was that I had never once made them hold still long enough to be counted.

Then, the edge. I decided what this map was and was not. This census covers code repositories under the organization. It does not cover my notes, my writing pipeline, or the private life systems that live elsewhere. Those are real, and they are other maps. Drawing that boundary is what kept the census from ballooning into a map of my entire working life, which would have been as useless as no map at all. An edge is what makes a map finishable.

Then, the lanes. This is the part that changed everything. I gave every repository one of three statuses, and the three are the heart of it: active, maintenance, archive.

  • Active means it is being worked on now. It is allowed to ask for my attention. There are not many of these, and that is the point.
  • Maintenance means it works, it ships, it gets a security bump or a small fix when it needs one, and it is otherwise allowed to be quiet. It is not on fire. It is not supposed to be on fire.
  • Archive means it is done, or it is dead, and either way it is preserved and closed. It does not get feature work. It is allowed to be finished.

That is the governance layer, and writing those three definitions down, once, in calm, did more for my actual workload than any tool ever has. Because the lanes are decisions made in advance. "Archived repos do not get feature work" is a rule I set once and never have to relitigate at midnight when some old project whispers that maybe I should go fix it. The lane already answered. The governor already spoke.

What the census captures

If you do this yourself, capture more than the name and the lane. The fields that earned their place on mine: what the repository is in one honest sentence, its lane, when it was last actually touched, what depends on it, and what would have to be true for it to change lanes. That last field is quietly the most important one, because it is what keeps the census from going stale. A map that cannot tell you when to redraw it is already decaying. "This moves from active to maintenance when version one ships" means the census knows its own future, and updating it becomes a small honest act instead of another overwhelming project.

The tax it removed

The repositories did not change. I did not delete a single one or write a line of code. All that changed is that the domain became legible, and the change in how it felt to stand in front of it was total. The directory stopped being thirty-three people shouting. It became three active projects with my name on them, a quiet shelf of things that work, and a closed archive of things that are done. The same territory, finally charted, and the anxiety tax that I had been paying on every glance just stopped being collected.

This is the smallest, most concrete version of the only thing I really believe about complexity. You do not survive a sprawling domain by working harder inside the fog, and you do not survive it by pretending it is smaller than it is. You survive it by making it legible. Inventory what is there. Draw the edge. Decide, once and in advance, what counts as alive. That is a census, and a census is just a map, and a map is the difference between owning thirty-three things and being owned by them.

If you want the general method behind this, it is the six layers. If you want the field it belongs to, it is domain cartography. This was just the day I pointed it at my own mess and watched the fog turn back into ground.