Engineering Craft and Its Nine Sub-Disciplines

Every CV I have ever screened leads with the same evidence: languages, frameworks, repositories — proof of the ability to write code. Almost none leads with evidence of the ability to read code, test it, debug it under pressure, or explain why it is safe to move money through it. In part 1 I made the case for a competency model that commits to numbers; this part spends the largest of them. Engineering Craft carries 25 of the framework's 100 points — the technical quarter — and splits into nine sub-disciplines, more than any other discipline in the model. Writing code is one of the nine, and it earns 18 points of that quarter. The other 82 are what this article is about.

The quarter everything else stands on

Engineering Craft is the technical foundation of the model — the skills that distinguish a software developer from every other knowledge worker in the building. I weighted it at 25, the highest single number in the framework, because without technical competence none of the other disciplines has anything to work with. You cannot ship in increments if you cannot build. You cannot argue an architecture you do not understand. You cannot own a production incident without the skills to see inside a running system.

But 25 is also a ceiling, and the ceiling is the point. Engineering Craft is necessary and nowhere near sufficient — it is a quarter of the model, and the six professional disciplines around it carry the other 75. Part 1 made that argument at the level of the whole framework; this part makes the mirror-image argument inside the quarter itself. Even within the purely technical discipline, the skill most people optimise for — writing code — is a minority holding.

Here are the nine, in weight order:

Nine sub-disciplines is a lot, and the count is deliberate. The breadth is the message: modern software development demands more distinct technical capabilities than any other discipline in the framework, and an engineer who has invested in only one of them is operating at a fraction of their potential.

Writing code is the front door, not the house

Eighteen points makes Writing Code the heaviest sub-discipline in the quarter, and it should be. It is the generative skill — the one that turns intent into something that exists. Languages, frameworks, paradigms, idioms, performance awareness, the discipline of matching the team's conventions rather than decorating the codebase with your own: all of it lives here, and none of the other eight sub-disciplines has anything to verify, structure or observe until this one has produced something.

The reason it stops at 18 is the distinction I care most about in this entire discipline. There are engineers who can write code and engineers who can build software, and the difference between them is the other eight rows of the table. Consider an engineer — call her Mira — who writes the cleanest code on the team: expressive names, tight functions, idiomatic use of the language. If Mira cannot design the test suite that proves the code correct, cannot trace a defect through it six months later, cannot reason about what an attacker would do to its inputs, and cannot explain how it fits the system around it, then her craft score is 18 points of a possible 100. The framework prices raw code production honestly: the most visible skill, the most fundamental skill — and less than a fifth of the technical discipline it belongs to.

Architecture is the most leveraged fifteen points in the model

Software Architecture takes 15 because it is the highest-leverage technical skill an engineer possesses. Architectural decisions constrain every decision that follows them. Choose the right boundaries and every future feature lands in an obvious place; choose the wrong ones and every future feature pays a toll that compounds. A poor line of code costs you the hour it takes to rewrite it. A poor architectural decision costs a little on every change, every week, for years, and by the time the cost is undeniable it is load-bearing.

That asymmetry is why architecture outweighs testing, debugging and understanding despite being exercised less often. System design, API design, data modelling and the judgement to make technical decisions at the right moment are skills you might use in earnest a handful of times a quarter — but each use sets the price of hundreds of hours of other people's work.

Testing and debugging are one loop

I think of Testing (14) and Debugging (11) as the two halves of a verification loop: one runs before the defect exists, the other after. Testing earns the higher weight because it is the preventive half — test design, automation, test-driven development, and the judgement of what to verify at which level of the pyramid. Testing is not a phase that follows development; it is a discipline woven through it, and the engineers who treat it that way ship defects at a rate the phase-minded never match.

Debugging is applied reasoning under pressure. Form a hypothesis, design the experiment that would falsify it, read the evidence, and refuse to confuse a symptom with a cause. Debuggers, profilers and stack traces are the instruments, but the skill is the epistemology — which is why the best debuggers I have worked with are also the people you want in any ambiguous technical discussion. Its 11 points sit below Testing's 14 for the same reason prevention beats cure everywhere else.

Reading beats writing by the time it matters

Understanding Code carries 12 points, and I will make a claim from my own years in the field: across every codebase I have maintained, the hours spent reading code dwarf the hours spent writing it. Reviews, incident investigations, dependency upgrades, the archaeology of a legacy module whose author left in 2019 — the day-to-day of real engineering is mostly comprehension. The sub-discipline covers reverse-engineering intent from implementation, navigating unfamiliar languages, and building a mental model of a system too large to hold in one head.

So why does Writing Code outweigh it, 18 to 12? Because the weights describe a balanced engineering role, and writing remains the skill nothing else can substitute for. But the ratio between the two is where seniority lives. A junior engineer's output is measured in code produced; a senior engineer spends their highest-value hours reading — reviewing designs, auditing the blast radius of a change, deciding whether the legacy system can be trusted. Juniors are hired for the code they can write; seniors are trusted for the code they can read. If I were tuning these weights for a staff-level role rather than a balanced one, Understanding Code is the first number I would raise.

Security is craft, priced at ten

Security gets 10 points, and it sits in this discipline on purpose: it is a craft skill of every engineer, not a separate speciality you escalate to. The sub-discipline covers secure coding practice, authentication and authorisation patterns, input validation, encryption, dependency hygiene, the common vulnerability classes catalogued by OWASP, and enough threat modelling to ask “what would an attacker do with this input” as routinely as you ask “what would a null do”.

The weight reflects consequence rather than frequency. Most weeks, security skill is invisible — it shows up as the injection that never happened and the token that never leaked. But it is the sub-discipline where negligence carries the most severe cost of the nine, which is why it outranks three sub-disciplines you will exercise far more often. Organisations in regulated industries should move this number up; the framework expects that adjustment rather than resenting it.

The three that look outward

The tail of the table faces away from the code and towards the world it runs in. Product Utility (8) is the bridge between technical correctness and human value: a feature can be well-written, well-tested and well-architected and still fail completely because it does not solve the user's actual problem. Usability, accessibility and the shape of real workflows are engineering concerns here, not someone else's department.

Observability (7) exists because production is the one environment where you cannot attach a debugger. Structured logging, metrics, tracing and alert design are how a system explains itself from the outside — and the engineer who instruments well is the engineer whose 2 a.m. incident lasts twenty minutes instead of four hours.

Metrics Accumulation (5) is the smallest holding in the framework: the discipline of knowing what to measure, building the means to measure it, and using the numbers to inform decisions without being misled by them — because a measure that people are judged on has a way of drifting away from the truth it was meant to capture. Five points is not a dismissal; it is a scoping decision. Measurement matters enough to be in the model and rarely enough at the individual level to sit at its edge.

The logic of the ordering

Read down the weights and there is a consistent argument underneath them. The generative skill comes first, because nothing exists without it. The structural skill comes second, because it multiplies or taxes everything built afterwards. Then the verification pair, then comprehension, then the consequence-heavy protective skill, and finally the three that connect the code to users, operations and evidence. Fundamentality, then leverage, then consequence — that is the ordering principle, and it is arguable at every line, which is exactly what part 1 promised a weighted model should be.

The quarter, though, only describes what an engineer can build. The next discipline in the framework — 18 points, the second-largest — is about whether anything actually ships. Next: Delivery Is a Discipline, Not a Date.