Growing from craftsman to meta-rational engineer

Aspects: effective action (meta-systematic) · epistemology (understanding in context) · breadth of considerations

Signals you are in this situation

• You are the strongest coder on the team and projects still fail.
• Promotion feedback says impact and influence and you hear politics.
• You avoid the meetings where the problem gets decided.
• Your code was right and the wrong thing was built.
• You measure yourself by the ticket, not by what happened after it closed.

The situation

Einar Høst tells the story of finding his identity as a programmer in the idea of software craftsmanship: a journeyman on the way to mastery, armed with test-driven development and design principles, responsible for the quality of the code and answerable to nobody else. Over years of practice the identity stopped fitting. He kept meeting projects whose success or failure had nothing to do with how well the code was crafted. Communication patterns, weak concepts, ambiguity, and conflict avoidance in the organisation seeped into the code, and no coding discipline could keep them out. His conclusion was that programmers do not make software; organisations do, and a developer who attends only to code has drawn the boundary of their responsibility in the wrong place.

Keavy McMinn describes the same widening from the other end. As a senior engineer who chose not to become a manager, she found that her most valuable work was no longer writing the code but figuring out which problems needed solving a year or two out, prototyping to test those ideas, forming and pitching strategies, and talking to engineers, product managers, designers, lawyers, sales people, and users to move things forward. She still writes code. The change is in what she is responsible for.

The meta-rational perspective

Chapman reads Høst’s talk as an account of the move from what he calls advanced rationality to meta-rationality. The craftsman has already got past naive rationalism: they know that large codebases are organic and unpredictable and that no method guarantees a result, which is why they call the work a craft rather than engineering. What the craftsman still assumes is that the code is where all the action is. Høst’s argument is that domain modelling, the organisation’s structure and dynamics, and the purposes the software serves are where much of the action actually is, and those are exactly the concerns Chapman’s table puts in its right-hand column.

Two things follow for anyone trying to make this move. First, it is not a promotion on the same ladder. Høst is sharp about the guild model of apprentice, journeyman, and master, because it implies that failure means you were not yet good enough, when the failures he kept seeing were of a kind that more skill could not have prevented. Chapman puts it as taking on a wider scope of responsibility and thereby becoming a different sort of practitioner, rather than acquiring a new skill. Second, there is no manual for it. Chapman’s overview of meta-rational practice opens by saying there cannot be one, because the work is about situations that definite methods do not fit; what can be offered is landmarks and equipment, not procedures. His guidance on when to get meta-rational is that the need grows with responsibility for a system that touches nebulous reality, and that the skill to develop is a feel for the points at which explicit judgment about method is worth the interruption.

That is why this guide has been about skills at all. Skills are procedures, and procedures are rational instruments. They cannot do the meta-rational work for you. What they can do is give the wider scope of responsibility somewhere to live: a glossary that records what a word was decided to mean, a decision record that says why, a questionnaire that admits whose knowledge was missing, a map of open decisions that outlasts one session. Høst’s craftsman had no practices against organisational forces. The practices in this guide are not defences against those forces either, but they are ways of taking responsibility for them in writing.

Failure path

The craftsman's path, where the code is the only thing worth attentionHow to readExpand

The craft is learned well. Tickets are taken as given, because deciding what the problem is belongs to someone else, and the words in them are taken as given, because naming things belongs to the business. The code is excellent. The project fails anyway, for reasons that were never inside the code, and the lesson drawn is that more practice is needed, which returns the developer to the same bubble at a higher level.

Corrected path

The same path with responsibility widened at each stepHow to readExpand

The craft stays; nothing on this path abandons tests, review, or clean code. What changes is that the developer takes responsibility for the problem and not only the ticket, goes looking for whose purposes the code serves, makes the domain’s words and decisions durable, and treats a misfit in use as information rather than as evidence of insufficient skill. The final node is the one Chapman describes: a wider scope, and with it a different kind of practitioner. The two loops show that misfit reopens the why rather than the skill level, and that the widening rests on the same craft underneath.

Skills for this situation

Skill	When to invoke it here	What it changes	Example
grill-with-docs	When you would once have picked up the ticket and started coding.	Grilling the problem and writing the glossary and decisions as you go is the concrete form of taking responsibility for the problem instead of the ticket.	/grill-with-docs the request to add a retry queue: what problem is it for?
to-questionnaire	When the why leads to someone outside engineering.	Names the person whose knowledge is missing and asks them, in writing, instead of guessing from inside the bubble. This is the step Høst’s craftsman had no practice for.	/to-questionnaire for the finance lead: what does month-end close need from this system?
domain-modeling	Whenever a term in the organisation turns out to be ambiguous.	Høst names weak, ambiguous language as the primary cause of accumulating complexity. Recording terms in CONTEXT.md treats language as part of the developer’s responsibility.	/domain-modeling: "account" means three things across sales, billing, and support
writing-for-agents	When writing CONTEXT.md, an ADR, or AGENTS.md.	The craft of making judgment durable for the next reader, human or agent. A decision that lives only in a conversation is not yet a responsibility taken.	/writing-for-agents review the ADR on the retry queue before I commit it
wayfinder	For McMinn’s kind of work: problems a year or two out, too large for one session.	Charts the open decisions as a shared map, so strategic work has a form other people can see and contribute to.	/wayfinder the destination is a data-import platform other teams can adopt without us
implement	For the code itself.	Unchanged as a discipline. The corrected path keeps the craft; it stops treating the craft as the whole job.	/implement issue #31
teach	When bringing someone else along.	Høst prefers a group of peers with complementary skills to a one-way mentorship. The teaching workspace keeps the state of what someone is learning, so the relationship can run in both directions.	/teach me how the billing context's ADRs came to be, and where they are now wrong
handoff	At the end of a session on strategic work.	Compacts the conversation for the next agent or colleague, pointing at specs, ADRs, and issues rather than repeating them. Widened responsibility has to be transferable or it stays personal.	/handoff the next session will pitch the import platform proposal to the platform team

Where to go from here

This is the last situation in the guide. The skills index lists every skill mentioned on these pages with a paragraph on what it does and a link to its source, and the Start here page has Chapman’s table if you want to place a situation of your own against its rows. The situations here are ten common ones; the aspects in the table are the general instrument for recognising the rest.

Sources

• Einar W. Høst, Death of a Craftsman.
• Keavy McMinn, Thriving on the Technical Leadership Path.
• Tanya Reilly, The Staff Engineer’s Path (book), a career guide covering the same widening of responsibility.
• David Chapman, Meta-rational software development: Readings, sections on developing meta-rational competence, Death of a Craftsman, and the technical leadership path (part-paid post).
• David Chapman, Meta-rational practices: Overview 1 (paid post), on why there is no manual for meta-rationality and when to get meta-rational.