Git Archaeology #8 — Engineering Relativity: Why the Same Engineer Gets Different Scores

Source: Dev.to

Engineering Relativity

The same object is lighter on the Moon and heavier on Jupiter. The same thing happens in codebases.

In Chapter 7 I talked about the universe‑like structure of codebases — gravity, four forces, and “seasoned, good gravity.” This chapter is about another fundamental property of that gravity.

Gravity Depends on Its Universe

Looking at EIS results across different codebases, I noticed something:

Gravity changes depending on the universe.

EIS measures how much gravity you created in a codebase, but gravity has one critical property: it depends on the space it exists in.

• In physics, Earth, the Moon, and Jupiter each have different gravitational fields. The same object becomes lighter or heavier depending on where it is.
• In codebases, the same engineer gets different EIS scores in different codebases.

Mature vs. Weak Codebases

• In a mature environment, creating new gravity is hard. The stronger the existing structure, the more energy it takes to shift the center, so EIS scores are harder to raise.
• In a weak environment, the first person to introduce decent design becomes an Architect overnight, and EIS scores are easier to raise.

Result: EIS is not an absolute value. It is determined by the interaction between the engineer and the codebase’s gravitational field.
This is, in a sense, Engineering Relativity – the same engineer, in a different universe, produces different gravity.

Implications for Engineering Evaluation

Imagine an engineer whose scores look like this:

Naturally, 60 looks “better.”
But if Repo A has an extremely strong gravitational field—multiple Architects, highly refined structure, battle‑tested abstractions—then 35 in that context may actually be remarkable.

Normalization trap: EIS’s relative normalization means the top contributor in each team scores 100, so the top score in one repo might be mediocre in another.
Normalization is a calculation issue; Engineering Relativity is a structural issue. The codebase itself changes the meaning of the score.

How to Account for Relativity

1. Look at eis analyze --team

Structure: Architectural Engine → Strong gravitational field (scores are hard‑earned)
Structure: Unstructured          → Weak gravitational field (scores come easily)

Total: 40 inside an Architectural Engine
Total: 40 inside an Unstructured team

The same total score has completely different meanings.

• The more Architects on a team, the harder it is to raise your Design axis.
• Scoring Design: 60 in a team with three Architects is likely harder than scoring Design: 100 in a team with none.

2. Recursive Cross‑Repo Analysis

eis analyze --recursive ~/workspace

Analyzing across multiple repositories reveals an engineer’s “gravity beyond a single universe.”

• Producer in one repo, Architect in another – that pattern reveals adaptability and latent capability.

eis timeline --span 6m --periods 0 --recursive ~/workspace

Codebase structure isn’t static. Member departures, refactoring, new features – all shift the gravitational field. Timelines let you distinguish:

• Engineers whose scores rise when structure weakens
• Engineers who maintain stable scores regardless of structural strength

Architect Reproducibility

Truly great engineers create gravity in any universe—different codebases, teams, tech stacks. This can be called Architect Reproducibility.

When you analyze an entire workspace with --recursive, an engineer who is consistently an Architect across multiple repositories has general‑purpose design capability that doesn’t depend on any specific codebase.

Gravitational Lensing in Codebases

In astrophysics, massive objects are detected by how they bend the light of objects behind them—gravitational lensing.

In codebases, an Architect’s gravity is often most visible not in their own scores, but in how it shapes everyone else’s scores.

• When a strong Architect is present:

  • Other engineers’ Survival scores may be lower (the Architect’s code dominates blame).
  • The team’s Design axis distribution is skewed (one person absorbs most architectural changes).
  • New joiners show a characteristic “ramp‑up curve”—they start low and gradually contribute to the existing structure.

• When that Architect leaves:

  • Multiple engineers’ scores shift simultaneously.
  • A Design Vacuum risk appears.
  • The “flattening” of score distributions signals the loss of a gravitational center.

You can observe this with eis timeline --team: the moment a gravitational center disappears, the entire team’s metrics ripple. The gravity was real—you just needed to look at its effects on others to see its full shape.

Bottom Line

Engineering Relativity isn’t a limitation of EIS; it’s a feature that reflects the real, dynamic relationship between engineers and the codebases they inhabit. Understanding and accounting for this relativity lets you:

1. Interpret scores in context rather than in isolation.
2. Identify truly adaptable architects who can generate gravity across universes.
3. Detect the hidden influence of strong architects through the lens of their teammates’ metrics.

By embracing relativity, you turn raw numbers into a richer story about people, structures, and the ever‑shifting gravity that binds them together.

Engineering Relativity

When measuring engineering impact, how can you make fair comparisons?
But I see this not as a limitation — as a feature.

When relativity was discovered in physics, the fact that “there is no absolute time or space” was counter‑intuitive. Accepting it led to an exponentially deeper understanding of the universe.

EIS is the same.

The fact that scores change with environment teaches us that comparing engineers while ignoring their environment is inherently meaningless. An engineer’s real capability cannot be measured in a vacuum; it always exists in relationship with the codebase — the universe they operate in.

Truly great engineers create gravity in any universe.
But that gravity looks different depending on the universe.

That’s Engineering Relativity.

Chapters

1. Measuring Engineering Impact from Git History Alone
2. Beyond Individual Scores: Measuring Team Health from Git History
3. Two Paths to Architect: How Engineers Evolve Differently
4. Backend Architects Converge: The Sacred Work of Laying Souls to Rest
5. Timeline: Scores Don’t Lie, and They Capture Hesitation Too
6. Teams Evolve: The Laws of Organization Revealed by Timelines
7. Observing the Universe of Code
8. Engineering Relativity: Why the Same Engineer Gets Different Scores (this post)

Tools

• GitHub: engineering-impact-score – CLI tool, formulas, and methodology are all open source.
• Install via Homebrew:

brew tap machuz/tap && brew install eis

If this was useful…

Feel free to star the repository, share the concepts with your team, or contribute improvements!