machu

Posted on Mar 14

Git Archaeology #10 — Dark Matter: The Invisible Gravity

#opensource #productivity #git #career

Most of the universe's mass cannot be observed. The same is true in code universes.

Previously

In Chapter 9, I wrote about Origin — the Big Bang and the first commit of code universes.

This time, I write about another force that exists in the universe.

An invisible force.

Dark Matter

Most of the universe's mass is said to be dark matter.

Yet it cannot be observed.

Telescopes can't see it. There's no means of direct detection.

Still, we're certain dark matter exists. Because — it manifests only as gravity, but gravity is undeniably there.

When you calculate a galaxy's rotation speed, visible matter alone can't explain it. Invisible mass is holding the galaxy together.

Dark Matter in Code Universes

Code universes have dark matter too.

It's the work that doesn't appear in commits.

Code review. Design discussions. Pair programming. Dependency cleanup. Small refactors. Documentation fixes.

These are small as commits — or don't even become commits at all.

Yet they support the stability of the universe.

Anchors Are Dark Matter

Remember the Anchor role defined in Chapter 3.

Anchors don't stand out. Neither their Production nor Design scores are exceptional.

But without them, the universe would quickly crumble.

Anchors are the dark matter of code universes.

Just as galaxies can't rotate without dark matter, teams can't stay stable without Anchors.

EIS can detect Anchors. But what EIS shows is dark matter's "gravitational effect" — not dark matter itself. The real work of an Anchor lies in the parts that don't appear in code.

Examples of Invisible Work

Code Review

Reviews don't produce commits.

Yet a codebase without reviews loses its structure.

Review is observation. Just like the Observer Effect in physics, observed code always changes.

It might be deleted. It might be improved. New dependencies might emerge.

Observation changes the universe.

Design Discussion

Thirty minutes in front of a whiteboard, and the design is decided.

Those thirty minutes aren't recorded in commits. But they determine the structure of thousands of lines of code that follow.

Invisible forces determine visible structure.

Small Refactors

A 3-line rename. A 5-line method extraction.

In the commit log, they look like "noise."

But this is the act of fighting the universe's entropy. The accumulation of small refactors prevents structural decay.

The Limits of EIS

Here's something I must be honest about.

EIS cannot see dark matter.

EIS is a commit-based tool. It can't measure work that doesn't appear in commits.

The quality of reviews. The depth of design discussions. The effect of mentoring. A team's psychological safety.

These are all dark matter.

What EIS shows us is only the "visible part" of the universe — stars and galaxies.

But knowing that dark matter exists lets you interpret EIS numbers correctly.

An Anchor's score looks low because most of their work is dark matter.

Judging "this engineer has low productivity" by looking only at numbers is the same mistake as calculating a galaxy's mass from visible matter alone.

Being Aware of Dark Matter

When using EIS, always be aware of dark matter's existence.

Dark matter doesn't only exist within engineers. It exists in every layer of the organization and business.

Engineer Dark Matter

An engineer with a low score might actually be supporting the team's stability
Design decisions that don't appear in commits might be the core of the structure
The quality of reviews might be lifting the entire team's Quality scores

Planning Dark Matter

A planner pouring their soul into the business, producing precise specifications — this doesn't appear in a single line of commits.

But without that precision, code gets rewritten over and over. Survival drops. Quality crumbles.

A team's high Robust score isn't just engineering skill. It's because the specs are stable. And the one creating that stability is a planner — dark matter fighting invisible battles with the business.

Cultural Dark Matter

In organizations without a tech-company culture, business decisions rain down that ignore the state of the code.

Sudden pivots. Schedules that don't account for technical constraints. Pressure to "just make it work."

The result: gravitational fields get torn apart. Architects disappear. If engineers are still moving forward despite this — those engineers are dark matter itself, holding together a universe on the verge of collapse.

Conversely, in organizations with good culture — where failure is tolerated, where time for Debt Cleanup is secured, where design discussions are valued — Growing engineers develop, Cleaners function, and Architects are reproduced.

Culture is the largest dark matter of all. It never appears in commits, but it determines the entire structure of the universe.

Hiring Dark Matter

Having strong engineers on the team is no accident.

Someone identified them, persuaded them, built the right environment. That work is never recorded in commits. But it determines the team's initial conditions — the Big Bang from Chapter 9.

The one who sets the universe's initial conditions is also dark matter.

When you look at EIS numbers, never forget that layers upon layers of dark matter exist behind them.

Trying to see the invisible. That too is an act of observing the universe.