Technological sensibility is a practice

A reflection by Jaime Gómez-Obregón brought back some memories of my work at Carto. A singular company, where Git sat at the centre of a good part of its operations.

Not the engineering operations. The operations. Contracts, documentation, proposals, decisions. Which meant that a person joining in a commercial or a support role acquired, without any of it being framed as training, a working intuition about branching, merge conflicts, history and the fact that some things cannot be undone.

It also led me into several interesting conversations where I got to underline again a few themes I always give a lot of weight to.

Sensibility towards software is internalised through use

You cannot read your way into it. This is the part that resists every attempt to solve it with a course.

Michael Polanyi's distinction is the useful one: there is knowledge we can articulate and knowledge we can only demonstrate, and the second kind is acquired by doing. You can explain what a merge conflict is in ninety seconds. What that explanation does not transmit is the feeling of having caused one, the small dread of realising two people solved the same problem differently, the instinct that leads you to communicate earlier next time. That instinct is what product decisions actually run on, and it does not arrive through a diagram.

Which is why the value of Git being at the centre of Carto's operations was not the tool. It was the exposure. A non-engineer who has genuinely lived inside a repository understands something about irreversibility, about parallel work, about the cost of divergence, that no amount of explanation would have installed.

Sennett's account of craft makes the same argument from the other end: judgment about a material is earned through time spent with the material, and there is no shortcut, only substitutes that feel like shortcuts.

Some classic Unix ideas remain the gold standard

For understanding the nature of software, I still have not found anything better than the Unix tradition. Doug McIlroy's formulation is the compact one: write programs that do one thing and do it well; write programs to work together; write programs that handle text streams, because that is a universal interface.

It reads like engineering advice. It is closer to a theory of organisations. Every one of those constraints is about the boundary between one piece of work and the next — about making your output usable by someone whose plans you do not know. Kernighan and Pike's book is largely an extended demonstration of what becomes possible once that discipline exists, and Eric Raymond's later synthesis is the argument for why the discipline survived competitors with far better funding.

The properties it produces are exactly the ones product organisations claim to want. Things you can inspect. Things you can replace without a rewrite. Small pieces you can reason about separately, which is the only defence against systems nobody understands. This is the practical answer to the black box problem: you cannot eliminate opacity, but you can decide how much of it you build in on purpose.

Software transforms organisations entirely

Software, as an oil stain, transforms organisations completely, making everyone in some way that "technical person" Jaime talks about.

The transformation is not that people learn to code. It is that the boundary of who has to think about software stops holding. Support decides what counts as a bug. Sales makes commitments that become architecture. Legal writes a clause that turns into a data model. Finance picks a billing period that will shape a schema for a decade. None of these people have engineer in their title and all of them are making software decisions, usually without being told that is what is happening.

Which makes the sensibility a distributed requirement rather than a departmental one. And distributed requirements cannot be met with a training budget. They are met by arranging the work so that people touch the material — by putting the repository, the logs, the error rates, the deployment somewhere they cannot avoid.

Linus Torvalds's memoir is worth reading for exactly this reason, and not for the biography. What comes through is somebody who understood a system because he used it every day for years, with no plan to understand it and no curriculum. The understanding was a by-product of the touching.

You do not acquire technological sensibility. You practise it, or you do not have it.