Habits, Not Process

Why software runs on the experience you can’t write down.

I’ve spent the last eight years or so training Kung Fu. And I can share the One Simple Trick™ that’s taken me from white sash to brown sash with a goal of getting my black belt sometime this year: I didn’t stop.

That’s it, as platitudinous and tautological as it sounds. I could have practiced a lot more. I could have come in with better physicality. Either would have made the journey faster. But none of it would have mattered without the unglamorous truth — the single biggest factor was that I was there, twice a week, most (not all) weeks, for eight years. Stacking small wins over that timeline leads to things I didn’t think were possible.

That’s how habits work. They aren’t a process you follow. They’re something you build, and then, when the moment calls for it, they show up for you.

The confusion of process

Most of the business world, including teams building software, likes to think of process instead.

Process attempts to make people interchangeable. You don’t need to think; you need to follow the steps. Plug anyone in, run the process, get the result. That’s the promise. It’s why process-thinking dominates in settings where variance is genuinely dangerous — manufacturing, regulated compliance, anywhere the cost of a bad judgment call exceeds the value of a good one.

Habits are the opposite. They might look like process from the outside (a checklist before release, a code review ritual, a strong antipathy to a framework that failed in the past) but they extend from the individual instead of being imposed from outside. They’re personal. They’re hard to separate from the people who have them. They can be copied, learned, and repeated, but not as a script. A habit trusts the person to make the call. A process exists because someone decided not to trust the person to make the call.

Software isn’t industrial manufacturing. It’s a creative endeavor. It looks industrial from the outside — inputs go in, products come out — but the actual work is discovery and judgment. The hard parts aren’t the grunt work of production. They’re the insight and the creation. Trying to force creative work into an industrial frame is how you end up with process theater — the ceremony of work without the substance of it.

Drilling builds habits, not processes

When you drill a technique in Kung Fu, you learn it as a sequence. If someone grabs you here, you step here, turn there, strike. Step one, two, three. You do it a thousand times. From the outside, it looks like you’re practicing a process.

You aren’t. Nobody is going to grab you in exactly the way you drilled. Nobody attacks you in the “proper” form. The technique you actually use in a real situation is never the clean one-two-three you repeated. If you tried to run the process in the moment, you’d freeze looking for step one.

What the repetitions are really building is a habit — a set of movements and decisions that becomes part of how you respond, without conscious sequencing. You drilled it as a process so it could become a habit. That’s the whole point.

This is why Kung Fu seems so impractical at first. You can’t show up and learn something in two weeks that you can just apply. “Why am I learning all these forms and breathing and flowery stuff?” The reality is that all of that is about building experience. When I watch our grandmaster apply something, it’s not simply that he understands the technique better (he does), but rather the subtle knowledge of experience and the feel for how to apply that knowledge.

What this looks like on a software team

The same is true for highly experienced engineers. Of course they often understand an API surface better or have more knowledge of a framework. But the real difference is the intuitive sense of what they need from an API, or the dread of a risk that bit them in the past. That isn’t process knowledge. It’s habit, built up through years of doing the work.

Leaning on software process (like Big-A Agile I blogged about recently) is like trying to learn a Kung Fu technique and assuming it’ll protect you when rigidly applied.

Process is a substitute for experience you don’t have

Process is almost always an attempt to capture the lessons of someone else’s experience and make them available to people who don’t have that experience yet. That’s not a bad goal. It’s how organizations try to scale beyond the people who built them.

But process can only encode the shape of what experience taught. It can’t transmit the experience itself. A checklist tells you what to verify. It can’t tell you which item on the checklist is the one that matters today, or what to do when the situation isn’t on the checklist at all. A framework tells you what steps to run. It can’t tell you which step to skip when the cost of running it exceeds its value.

The habits an experienced engineer brings to the work are the residue of all the times they got something wrong, or watched something fail, or saw a clean approach decay over five years into something nobody wanted to touch. Those habits don’t transfer through documentation. They don’t transfer through onboarding. They transfer the way Kung Fu transfers — through doing the work, getting it wrong, watching someone with more experience get it right, and slowly building the instincts that show up unbidden when they’re needed.

Process attempts to build around the insights gained from experience. It can’t be a substitute for the experience itself.

Habits inside, process at the boundary

There’s a useful place for process, and it isn’t the inside of the team.

The inside of a working team is where the experience lives. The people doing the work share enough context, enough history, enough tacit understanding that habits do most of the lifting. Adding process there usually substitutes ritual for judgment.

The boundary of the team is different. At the seams — the handoffs to other teams, the audit points, the places where someone outside the work needs to know what to expect — those are precisely the places where people don’t share the experience. A predictable surface at the boundary is what you owe the people on the other side of it.

What this means in practice

A team’s capacity to handle the unfamiliar — the situation that wasn’t in the documentation, the failure mode nobody anticipated — comes down to who’s in the room and how long they’ve been doing the work. If the path was predictable, then process would suffice. But so much about making great software is about discovering and embracing the constraints in ways that make new things possible.

This is part of why we built BiTE the way we did. We place an inordinately high value on experience and talent because the kind of work we take on doesn’t reward process-thinking. It rewards habits. And habits take years to build.

The temptation, especially when scaling a team or a company, is to try to bottle what the experienced people do and hand it to people who haven’t earned the experience yet. Sometimes you can capture a piece of it. But every pattern rigidly applied by someone who doesn’t understand why it was first conceived eventually becomes an anti-pattern.

In the end, the work is done by humans and the habits they bring from the experience that has shaped them. Building great software is about leaning into those habits rather than trying to compress it into a predictable process.