How to Become a Software Craftsman
Reposted from 2016
How to become a Software Craftsman has become a huge subtext in the software community and the development conversation. One of the things that I’ve been exploring is how do we get there? How do we go from where we are to becoming true software craftsmen?
It’s not this magical “Oh, we’re agile, we put posters of the manifesto everywhere, so now we’re agile and we’re software craftsmen.” It takes work, and it takes activities. I’ve been doing a lot of exploration into this and believe I have discovered three paths to the summit of software craftsmanship.
Software Craftsman Defined
Let’s first define what I mean by a software craftsman. Everybody has their own views, but I think of a software craftsman as someone who has practiced the techniques of XP, agile, and DevOps till those techniques have worked themselves into the person’s subconscious. This software craftsman creates software using these techniques almost through muscle memory. They no longer have to think about what they need to do to create beautiful code, they just execute in their relentless pursuit of creating amazing software products.
How You Get to be a Software Craftsman
So now that we have defined what being a software craftsman means to me, let’s explore how we get there. I’ve found that there are three paths to becoming a software craftsman. These paths are comprised of software development skills that need to be developed. The first path develops the people skills, the second path develops the technical skills and the third path explores the principles derived from the other two paths.
Let’s survey what each of these paths covers.
The People Path
One of aspects that I’ve been exploring a lot is that there are people problems and there are technical problems to DevOps and software craftsmanship. Of course, the technical skills are critical, but no more so than the people side. Just like it does a person no good to only strengthen their right arm, while their left atrophies, it does us no good to only strengthen our technical skills, while our people skills go to waste.
We must learn and apply technical tools from a people perspective. Craftsmanship means doing things by hand and knowing how to execute with an artist’s touch. It’s not enough to say, “I expect you to be doing test-driven development.” You have to be able to help people understand what test-driven development is.
Those of us in the software development community must help foster craftsmanship because it certainly isn’t being taught in school. The typical computer science college graduate does not understand how to do test-driven development or agile. We’re making some progress, but it’s still not good enough.
The Technical Path
There is also the technical side to keep in mind. Practices include test-driven development, refactoring and continuous integration. It is also important to know when and how to write acceptance tests and how to apply these as well as how to automate these. These are the nuts and bolts of a solid software craftsman. The idea of refactoring becomes part of daily life, not just using the buzzword but intuitively building it into everything you do.
These are the steps you’re going to continue with, and at some point that will lead you to DevOps and continuous delivery. These technical practices and methodologies are more organizational than individualized, but DevOps and continuous delivery do require a discipline that only a software craftsman can really, truly supply.
The Principles Path
I’ve found that you can break this down into certain areas of foundational skills that need to be developed. The first of those foundational skills is coding. Sounds kind of silly to say it, but it’s worth saying; a programmer needs to be excellent at coding.
Coding
By coding I don’t mean one language. You must be astute in multiple languages. No true craftsman only knows one way of doing anything. It doesn’t matter what languages, but there needs to be at least two, preferably more.
Design
Designing is an important aspect, but is tricky in the agile world because we say, “don’t get caught up in big, up front designing.” I believe that, but you do need to understand design. Whether it be unit design, large architectural pieces or systems design, you do need to understand and be able to apply good design.
Applying Agile Principles
Learning the 12 principles of the Agile Manifesto isn’t very difficult; applying them is much harder. You have to understand when they apply, when simplicity really is essential, what simplicity is and how to apply simplicity to a particular problem.
Tooling
We have many tools available to us. Mastering these tools as a true craftsman is not about simply using them, it’s about knowing how to use them wisely. Like the saying goes, “If you need a hammer, whatever tool is handy is a hammer.” That’s not necessarily the best approach. A craftsman seeks the right tool for the right job and uses that tool masterfully.
Work Habits
You need to be able to establish strong work habits. You need to be able to, not just by yourself, but in a team, practice these habits. Test-driven development and continuous integration are tools to help us with practice our work habits. Having the work habits and the discipline around those work habits to be able to say yes or no and to be able to say, “This is what I need to do, and it’s what I will do” is crucial.
Professionalism
Professionalism is something you notice more often when it’s not there than when it is. There is a quiet confidence and understanding in professionals. There is the ability to know where you’re going and what you’re doing without conscious thinking. You have confidence in professionals because you know that they will do great work. That’s what I mean by professionalism, it’s very difficult to define, but it’s absolutely vital to a strong development shop. Especially, as we aspire to craftsmanship.
Traditional Craftsman Education
To learn how to teach software craftsmanship, we have to look no further than the trades where craftsmanship originated. Traditionally, craftsmen were created through apprenticeships. By going through an apprenticeship program, young craftsmen, no matter what their background or their education, learn not just what they should do but how to do it. They’d learn the tricks and techniques that don’t necessarily come just from reading a book, taking a class or passing a test. It’s about learning from doing, and it’s learning by doing things together.
The next component of how craftsmanship has been historically taught is recognizing progress. To recognize progress, you need a path to follow. It’s no secret that there’s no really well-defined career path for software developers.
The typical path of a developer is to start as a junior software engineer, progress to a senior software engineer and, if you’re really good, you become a tech lead. As a tech lead, you have to now tell other people how to do it. Then, if you’re really good at that, they take you completely out of the thing you love, which is programming, and make you a manager. Then, you get to try to figure out how to make other people do what you love to do most. That path has never really worked.
Micro-certifications are becoming very popular in the world of education and development. Think of micro-certifications as similar to boy scout badges. You could have a badge in test-driven development, concrete data systems or web design. By obtaining these badges, you can recognize progress and simultaneously you can be recognized for that progress. When taking an approach such as this you should start associating some of the compensation and programs with the development of these badges.
When you are done with your apprenticeship, you are, of course, not done learning. At this stage, you grow into a journeyman. A journeyman is a very time-honored tradition. The idea of a journeyman is that now you are good enough to go out on your own. In the traditional craftsmanship model, a journeyman would have wandered from village to village practicing their craft.
In the software world, this might mean you work on a team for a year or maybe two. Then, you go to another team. The wandering part doesn’t have to be quite as frequent as the traditional journeyman, but the idea is that you need to continue to develop your skills and to develop them not in a single place but to explore other areas.
If you’ve been doing nothing but data mining for six months, then maybe for the next six months you should be focused on webpages so that you are building a broad base of skills. That’s what a journeyman’s life is. We should be spending the majority of our time as journeymen.
Conclusion
These are the steps. It’s not the easiest path in the world, but it’s absolutely worth it as you go along. We should all aspire to be great at our craft and be true craftsmen in our discipline. I hope this has inspired you to take a look at what areas you can develop to become a stronger software craftsman.
