CraftsmanSHIP. Not CraftsmanSHIT.

Pilots have a word for the thing that separates competent from dangerous. They call it airmanship.

The FAA defines it as a sound knowledge of flight principles, the ability to operate an aircraft with competence and precision, and the exercise of sound judgment. A NATO research symposium went further: airmanship is a personal state that enables aircrew to exercise sound judgment, display uncompromising flight discipline, and demonstrate skillful control of an aircraft and a situation.

Two things stand out in that definition: the first is discipline (not talent, discipline). The second is that airmanship is maintained through continuous self-improvement. It is not a credential you earn once. It is an ongoing practice you take for life.

Software has a similar word to airmanship. We call it craftsmanship.

In 2008, Robert C. Martin stood up at the Agile conference and proposed a fifth value for the Agile Manifesto: “Craftsmanship over Crap.” He later softened it to “Craftsmanship over Execution.” It was never adopted. The developers who cared about this idea got their talks rejected from the main Agile conference. So they held their own summit in Libertyville, Illinois, and by 2009 they had published the Manifesto for Software Craftsmanship.

The manifesto is four lines long: Not only working software, but well-crafted software. Not only responding to change, but steadily adding value. Not only individuals and interactions, but a community of professionals. Not only customer collaboration, but productive partnerships.

That was 17 years ago. Look around. How’s it going?

Agile started as a software methodology. XP, pair programming, TDD, continuous integration. Technical practices created by developers for developers.

Then Scrum got popular. Scrum is a management framework. It does not mention code quality, testing practices, or refactoring. It talks about sprints, ceremonies, and roles. Project managers became Scrum Masters. The daily standup replaced the technical conversation.

Agile stopped being about how you build software. It became about how you manage people who build software.

The developers who wrote the Agile Manifesto watched their creation get adopted by the people it was supposed to protect them from. Craftsmanship was the response. It was an attempt to reclaim the technical side of Agile before it disappeared completely.

The term itself has evolved. Many communities now use “software crafters” instead of “software craftsmen.” The SoCraTes conference changed its name. 8th Light started calling their developers crafters. Cambridge Software Craftsmanship became Cambridge Software Crafters. The language moved toward inclusion, which is good. I thought about using “crafters” in the title of this post, but then the joke would not work.

The name change is not the problem. The problem is what I see people calling craftsmanship in the wild.

Here are 4 flavors of craftsmanSHIT:

Over-engineering disguised as quality. You know this one. Someone builds an event-driven architecture with six microservices for a CRUD app that serves 5 users. They call it “doing things right.” They spend three weeks designing an abstraction layer that will make the system “future-proof.” The future arrives and nobody needs the abstraction. They needed faster page loads.

Over-engineering feels like craftsmanship because it looks like effort and care. It is neither. It is building for an imaginary problem instead of the real one. A craftsperson builds what is needed, not what is impressive.

Shortcuts rebranded as pragmatism. A deadline is tight. Someone skips the tests, hard-codes the config, copies a 200-line function instead of extracting the shared logic. “We’ll clean it up later.” Later does not come.

This is the one people get wrong in both directions. Cutting scope to meet a deadline can be craftsmanship. Incremental delivery is a real practice. Ship the thin slice that’s usable and valuable. Add the next layer when you learn what matters. That is strategy. It’s different from dumping garbage into the codebase and excusing it as a business decision.

Coding interviews that reward ego over discipline. The whiteboard interview asks you to solve an algorithmic puzzle in 45 minutes. No tests. No refactoring. No working in small increments. Just raw speed and memorized patterns.

Craftsmanship is not how fast you can solve a problem alone. It is how reliably you can build something others (or yourself in a year) can maintain.

What does a timed puzzle with no test suite tell you about a candidate’s discipline? Nothing. It tells you they can perform under pressure while someone watches. That is a circus act, not engineering. TDD is slow and deliberate by design. It is the opposite of what most coding interviews reward. We screen for performance and then wonder why the codebase is full of clever, untested, unmaintainable code.

“Good enough” as a permanent philosophy. This is the most common flavor. The team builds an app. It works. It makes money. It makes A LOT of money. And then it calcifies. New features take months. Small changes break unrelated things. The architecture is a tangle of special cases and workarounds. Nobody can explain the data model.

Someone suggests investing in quality. The response: “It brings in millions. Why would we change it?” Because the thing that brings in millions evolves slower than the roadmap demands. Because every quarter, the cost of change goes up. Because one day a competitor ships something you cannot match, not because they are smarter but because their codebase lets them move.

This is not pragmatism. It is a bet that the future will be kind.

The global developer population hit 47 million in early 2025. That is a 50% increase from 31 million in Q1 2022, according to SlashData. Some projections had the population doubling to 45 million by 2030. We passed that number five years early.

You can debate the exact figures. SlashData counts hobbyists and students alongside professionals. JetBrains puts the professional developer count closer to 21 million and if you consider vibe coders that write a "build an app that does X" and consider themselves engineers, then the number is off the charts. The trendline, regardless of which dataset you trust, points the same direction: more people writing code, faster than the industry can absorb them.

More developers is not the problem. The problem is what happens when the population grows faster than the culture of mentorship. Who is teaching the next 20 million developers what well-crafted software looks like? Who is pairing with them on their first production codebase? Who is reviewing their pull requests with patience instead of just clicking approve?

The population of developers is growing. The population of mentors is not growing at the same rate.

Agile was supposed to fill this gap. Craftsmanship was supposed to fill this gap. Both got diluted. One was absorbed by management. The other stayed a niche conference circuit. The developers entering the profession today are more likely to learn from Stack Overflow, an LLM, or a YouTube tutorial than from a senior engineer sitting next to them.

Something is missing. I think it is mentorship at scale.

On October 29, 2018, Lion Air Flight 610 took off from Jakarta. A faulty angle-of-attack sensor fed bad data to the Boeing 737 MAX’s Maneuvering Characteristics Augmentation System. MCAS forced the nose of the aircraft down. The pilots fought back, trimming the nose up again. MCAS pushed it down again. This happened more than 20 times in 11 minutes. The pilots did not know MCAS existed. Boeing had removed it from the flight manual and from pilot training. The aircraft crashed into the Java Sea. All 189 people on board died.

Less than five months later, Ethiopian Airlines Flight 302 took off from Addis Ababa. Same aircraft. Same faulty system. The pilots this time knew about MCAS. They followed Boeing’s published procedure to disable it. The procedure did not work at the speed and altitude they were flying. They could not manually crank the stabilizer back against the aerodynamic forces. The aircraft crashed six minutes after takeoff. All 157 people on board died.

346 people dead. Two crashes. One root cause: a system designed without redundancy, tested without rigor, and shipped without honest documentation. The engineers at Boeing knew about the MCAS problem before either crash. The FAA had privately predicted that 15 MCAS-related accidents could occur over the 45-year life of the fleet if the system was not redesigned. They did not ground the aircraft after the first crash.

The Boeing 737 MAX crashes show craftsmanSHIT at an industrial scale. It is cutting corners on a system where the cost of failure is measured in human lives.

Software does not fly airplanes in every case. But it runs hospitals, financial systems, power grids, and autonomous vehicles. The gap between “our software works” and “our software is well-crafted” is the gap between a system that fails gracefully and one that fails catastrophically.

Captain Chesley “Sully” Sullenberger, responding to Boeing’s attempt to blame the pilots, wrote that airmanship means absolute mastery of the aircraft and the situation. But he added: inadequate training and poor design do not excuse themselves by pointing at the person in the cockpit.

The same is true in software. You cannot blame the developer for sloppy work when the system around them rewards speed over discipline, skips code review, and treats testing as optional.

So what am I doing about it?

I write posts like this one. I help organize, attend and talk at meetups. I post on Hacker News and Reddit and LinkedIn because disseminating these ideas is part of the practice. I push my own team-mates to invest in continuous improvement, not as a line item on a roadmap but as a daily habit.

These are small actions. They do not scale the way a framework or a certification does. But craftsmanship was never a framework. It was a commitment between practitioners. One person showing another person how to write a test. One team deciding that “good enough” has a higher bar than it did last quarter.

One of the 346 people on those two flights could have been your brother. Your mother. Your child. The software in that aircraft was someone’s codebase.

• Someone decided it was good enough.
• Someone decided the documentation could wait.
• Someone decided the redundancy was not worth the cost.

That is the distance between craftsmanship and craftsmanSHIT. One is a practice. The other is a bet that nothing will go wrong.

And you? What are you doing to help?

If you liked this, you might like readplace.com, built for exactly this kind of reading.

Thanks for reading. If you have some feedback, reach out to me on LinkedIn, Reddit or Github.