Software Craftsmanship is more than a set of technical practices. It's a posture, an ethic of work well done that guides every line of code written.
The craftsman metaphor isn't new in our field — it traces back to the Software Craftsmanship Manifesto of 2009. But beyond the slogans, what does it concretely change in a developer's daily life? Quite a lot, actually. The craftsman takes care of their work independently of deadlines. They refactor code they touch, even when the initial task didn't require it. They leave the codebase in better shape than they found it — the Boy Scout Rule.
This translates into specific habits: writing tests before code (TDD), conducting serious code reviews rather than rubber-stamp approvals, caring about the business context not just the JIRA ticket. The craftsman asks questions. They refuse to ship something they're not proud of, while knowing that perfection is the enemy of good. They seek the balance between pragmatism and excellence.
The risk of this posture is arrogance or paralyzing perfectionism. A craftsman also knows how to deliver, iterate, accept that some parts of the code are imperfect. Honesty about technical debt — identifying it, documenting it, prioritizing it — is also a mark of craftsmanship. What truly distinguishes the craftsman is the continuity of effort: learning every week, reading, practicing, sharing.
Working in a network rather than inside a large organisation
There is a tension that many experienced developers eventually feel inside large organisations: the bigger the structure, the less craftsmanship survives. Not for lack of individual talent — skills are often real — but through systemic mechanics. Validation processes stretch out. Technical decisions are made by committee, far from the code. Technical debt accumulates because nobody has the mandate to truly address it. Institutional inertia ends up overriding quality.
The expert network model addresses this structurally. Rather than an oversized permanent team with its hierarchical layers, it's about assembling the right skills at the right time — experienced professionals who have chosen autonomy, who maintain their technical level by conviction rather than contractual obligation. Each expert stakes their reputation on every engagement. There is no junior to offload the awkward part to, no activity report to fill in to justify being there.
This structure has concrete effects on the quality of delivered code. A senior working within a network will generally refuse the compromises that would be imposed on a salaried employee. They can say no to a bad technical decision without risking their career. They can propose a refactor when it's necessary, not just when the budget allows. And because they work across multiple contexts in parallel, they bring a perspective that an in-house developer — focused on a single product for years — often no longer has.
Software craftsmanship thrives in small, agile structures — not in large organisations with strong inertia. This is one of the reasons why the expert network model, well orchestrated, often produces better software — not despite its smaller size, but because of it.