Everything Starts With Version Control

Table of Contents

Sometimes it is worth looking at the things we have taken for granted for more than two decades, the ones everybody stopped talking about because they just work. Version control is one of them.

In 2000, Joel Spolsky published the Joel Test: twelve yes/no questions about how software gets made. It begins with:

Do you use source control?

Almost two decades later, Accelerate drew on surveys of thousands of technology professionals. Much of the delivery system described by its research rests on versioned changes. Lead time starts with a commit, which records a state of the work. CI tests that commit, review evaluates the proposed change, and a deployment identifies the commit it ships.

That is not a coincidence, and it is worth spelling out why everything starts there.

Reliable systems are correctable systems

Every safeguard misses things. Reliability comes from being wrong safely: small changes, limited blast radius, fast detection, and a practical way back.

Version control supplies the addressable states that correctability requires.

The smallest useful unit of work is a coherent change

A coherent change is one decision that can be evaluated and reverted on its own. Code, configuration, tests, and documentation that belong to that decision move together. Version control records the resulting state. Comparing two states produces a diff.

We grow up with intuition for physical material. Lift a board and you immediately feel its weight and balance. Digital material has no such direct feedback. A program’s behavior is distributed across compilers, libraries, configuration, and distant code. Even Markdown needs a renderer before its layout, links, templates, and embedded diagrams can answer back.

For digital material, that feedback gesture has to be built. Each kind of feedback we need should be available through one end-to-end command. “One” describes the interface. Behind it, a command may prepare the environment, install dependencies, generate artifacts, and run checks. Building that command may be as hard as constructing the artifact itself.

Different kinds of feedback may use separate commands or one that composes them; each path remains end to end and repeatable. Whatever defines these commands belongs in the repository beside the material, so the artifact and the way it answers back can change together in one diff.

We cannot sense digital change directly. A diff makes the transition visible.

The size of a change says nothing about its consequence. One character can invert a Boolean expression, while a large mechanical refactoring can preserve behavior exactly. Review should assess the coherent change, regardless of line count.

Changes compose into construction

Kent Beck compressed this sequencing into “make the change easy, then make the easy change”. Linux kernel maintainers craft whole patch series this way, and git rebase -i lets authors shape history. Digital construction means iteration in small, inspectable steps when not everything can be foreseen.

Digital construction resembles mathematical induction: establish a reproducible base state, then advance through small changes while evaluating the same properties at every step.

Shift left means moving evidence

Once a state has an address, evidence can attach to it early. Builds, tests, security checks, and previews evaluate the proposal at the beginning of the process, where correction is usually cheap. In production, the same defect may become an incident.

CI runs these commands automatically against each proposed state; without CI, a person should still be able to run them locally. They might build the work or start a digital replica for inspection. Without an executable feedback path, version control can preserve a history of states nobody knows how to validate.

Repeatable evidence makes one exact state inspectable. Understanding and judgment remain necessary.

Shift left moves evidence to where it is cheap while responsibility and monitoring remain. The pull request is the place where that evidence collects around one exact change.

Delays create large batches and encourage bypasses. Evidence must arrive while the change is still small enough to act on.

Separate the right to propose from the authority to activate

Gate the change, not the contributor.

A branch lets contributors construct and validate a possible future without receiving production access. CI and previews can evaluate it before specialists review it. The merge is the boundary where limited authority decides what becomes the shared version.

Even a merge conflict belongs to this design: it makes incompatible changes explicit instead of choosing silently between them.

History is how an organization learns

A team fixes an incident in a chat thread, forgets the reasoning, and repeats the mistake six months later. In the better story, the team turns the failure into a test or policy and records why in the relevant history. Version control lets a lesson modify the path that produces future changes. A good history shows more than the end result: it shows how a vision materialized in steps, which alternatives were tried, and how the people involved actually worked together.

In 9 Books I Wish Every CTO Had Read I described this as an architecture of care. Version control keeps history legible for the next person and lets lessons outlive the people who learned them.

The diff is where work becomes social

Everything above holds for one person working alone. Version control addresses the nature of digital material, so a solo project still needs named states and a way back.

The diff as canvas is older than Git. Unix diff dates from 1974, Larry Wall’s patch from 1985, and changes traveled as mailed hunks between maintainers for decades; the Linux kernel ran on emailed patches without any version control at all for its first ten years. Git inherited that culture and made distributed patch workflows fast and practical: it stores snapshots and presents changes as diffs. The pull request inherited the shape of an emailed patch.

A diff on the canvas of a pull request is a shared object. Everyone discusses the same visible change instead of an abstract intention. Someone comments on an exact line and exposes knowledge no single author had.

How version control became infrastructure

Twenty years ago, plenty of people treated version control as developer complexity that would disappear, and applications shipped their own versioning, locked inside opaque formats: track changes in binary documents, history buried in tool-managed databases. Instead, the opposite happened. More work moved under version control, often as inspectable text and declarations.

Markdown made plain-text writing approachable, Terraform turned infrastructure into declarations, and documentation became docs as code. Over two decades, digital work reshaped itself around version control.

Teach version control as the foundation of digital construction

Schools teach mathematical primitives because they let people reason about quantity and structure. They should also teach the primitives of digital construction. Students should learn to compare states, reproduce evaluations, and use diffs and version-control history to understand how work changes.

When I create a folder for technical or creative work, I initialize a git repository and give it one command that produces end-to-end feedback. It might hold code, a letter, a brain dump, or a configuration. Version control begins paying off with the second meaningful state.

Further reading