Differences between Software Craftsmanship and Engineering

Mastering your craft isn't the same as mastering your engineering.

One of my most important learnings and findings was that I needed to engineer an architecture, codebase, and process that is understandable and maintainable by people who understand less about it than I do.

Adrian

“Master your Craft” is often a phrase used by Senior Developers, especially publically, to point out what is right or wrong, in their opinion. This behavior is similar to what society knows from the “Apprenticeship Model (Apprentice, Journeyman, Mastercraftsman).” This model is medieval but has lasted until today in many countries, even in software development.

The problem with being a Mastercraft primarily is that the entire apprenticeship model is based on the “individual” person. It’s always about a person becoming better in a very specific field. The knowledge to acquire is based on the following three aspects:

• Learn what your “Master” teaches you

• Learn what is common about your craft

• Gather your own experience later

The big problem regarding software development is that this can lead to a great software craftsman, but it ignores the aspects of software engineering entirely.

Software Engineering is about the process and product, not the craft itself, even though the craft is necessary to execute. Important to say that the process is what we often refer to as the team, company, product, or product life cycle.

So we engineers, as a group of people, contribute to a common effort; it is extroverted while improving craftsmanship is introverted; it’s about your personal skills.

The problem with focusing on mastering your craft instead of focusing on engineering.

I grew up in the apprentice model, became a Journeyman (Yet I was never on a Journey 😀), and later a Mastercraft in Media Engineering, which combined Media and IT. Eventually, I earned my certificate as a State Certified Engineer later on.

There was a huge mindset shift in my life when I started to “engineer” and optimize the processes in our company in Germany back then. The CEOs realized it and made me Head of Production. Before that, I was solely focused on becoming very good in what I do as an individual to shine and become valuable.

But being just a “great programmer,” a problem solver, or someone called when heroics are needed is not really what we need in Software Development.

👉 Which is why I prefer the term Software Engineering instead.

Software is complex, fast-paced, and ever-changing. To become successful with software, you need to learn how to scale, and you don’t scale just by being a Mastercraft; you need to engineer the scaling process.

Scaling with Software Engineering

Shortly after becoming Head of Production, the company accelerated in the IT field, and Software became the new foundation of the business. That resulted from the engineering process, in particular, getting away from individualistic, siloed solutions to software not usable by the average personnel. This is a key factor you should never underestimate.