First of all an apology to the ladies and an assurance that I am not trying to be sexist in my choice of words in this article. I have used the terms brotherhood and craftsmanship instead of humanhood and crafter due to their wider usage and acceptance. I will slip between the terms crafter and craftsman in this blog. You may also notice I slip between British and American English (on account of having lived in both countries and having trouble remembering when to use which spelling). Finally, I will also be slipping between the term Extreme Programming and it’s abbreviation XP.
What Makes a Brotherhood?
In my experience, Code Crafters have the ability to work together and be productive almost instantly. This is not to say that crafters are necessarily better developers than non-crafters. The point I’m making is that code crafters are able to work together in a productive way quicker than non-crafters.
It feels like a brotherhood to me because we share common values, understand each other, and help each other out (to be better coders). This connection gives crafters a head start to productivity when they find other crafters in their team. This secret can be used to your organisation’s benefit in a way that I will make clear further in the article. But perhaps you need to understand what I mean by crafter first.
Definition of a Code Crafter/Code Craftsman
Code crafting is best characterized by the practices of Extreme Programming, Clean Coding, and care for Technical Excellence (one of the agile principles). Sure things have moved on since XP was created, and we now have modern development practices and modern XP, but the essence remains the same (and if nothing else, classic XP is a really good foundational step on your path toward mastery).
Crafting vs. Smart
I’ve met too many developers who are smarter than me for me to claim that I am a master developer. I know the XP practices, and I use them when I code. It is the way that I code that makes me a craftsman and not the cleverness of the algorithms I produce. Crafted code is easy to improve on (or refactor) so when a smarter team member than me looks at my code, they should be able to refactor it easily. Even better if they pair with me to mentor me while doing said refactoring, giving me the chance to learn and grow from their expertise and knowledge. For this reason, I love being able to work with crafters smarter than me. The desire to share and coach others in our skills is a large part of why it feels like a brotherhood. We are all trying to help each other get better at our craft and profession.
Humility was a big pill I had to take at the start of my journey into craftsmanship. Before XP, my title was Senior Developer. After XP, I dropped that title and called myself a Code Crafter.
Pairing is Caring
One of the core XP practices is Pair Programming. The mere mention of Pair Programming often causes contention, but I feel it is a big part of what makes code craftsmen brothers and sisters in our craft. Unless you have experienced good pair programming firsthand, you may never have experienced the connected feeling of brotherhood that comes with it.
Bad pairing experiences will turn people away from pair programming. (Agile coaches take note.) If you are one of those that pairing has left a bad taste, I’m sorry. I hope that you can experience pairing the way it should happen and be open enough to give it another chance.
In short, pair programming is about being a coach, being coachable and knowing when to switch between these two states. Lyssa Adkins would use the word mentor in place of the word coach in this context, and she would be technically more correct. Whichever word (coach or mentor) works best for your understanding in this article, run with it.
Craftsmen are Journeymen
Technical Excellence is not a destination; it’s a journey with no endpoint. Craftsmen are always looking for ways to improve. Those of us who travel the path of code craftsmanship join a brotherhood of caring about code quality. Perfectly crafted beautiful code is the Holy Grail for craftsmen and the quest that brings journeymen onto a shared path.
An Example of Brotherhood and Shortened On-boarding
A few years back, I was fortunate enough to be assigned as a contract developer to a small start-up in Redmond Washington that I would characterize as a Ri-level Extreme Programming team (using the Shu-Ha-Ri analogy of a team’s maturity). It felt like coming home to be able to pair with developers that shared my coding values and practices. Code crafters can recognize each other almost instantly when paired at a keyboard. There is no secret handshake – it just becomes obvious with coding style and ways of thinking. It felt good to be able to add value so quickly and feel part of the team.
Code Retreat
There is a one-day event called Code Retreat. I have been amazed time and time again at just how effective this class’ simple format has been at creating a sense of brotherhood and learning among the participants. For many, this is their first introduction to test-driven development (TDD) and pair programming. Participants come away with the sense of what it is to be a code crafter in a safe, non-threatening environment.
If you have not experienced Code Retreat before, I can’t recommend it highly enough. Once you have done the class, read Corey Hains’ book Understanding The Four Rules of Simple Design and then do the class again. And again. *Understanding The Four Rules of Simple Design* is a fantastic book that will help you on your journey into craftsmanship. I will recommend a few other books later in this article.
Fast Team Formation
A team of non-crafters needs to go through the phases of Forming – Storming – Norming – and Performing, to become a team. This usually takes months. Code crafters can get to the same point within hours!
> Code crafters can form a productive team within hours!
This is the secret that can be leveraged by your organization: By becoming a place that values craftsmanship, you will attract the kind of developers who can not only get up to speed quicker but will also do the right thing with your code.
Why Make Your Organization a Place for Craftsmanship?
- Code crafters can form a productive team within hours
- Few defects (near zero)
- Low technical debt (no legacy code)
- Easily maintained code base (long-term sustainability of your product)
- The cost of adding new features stays low (instead of growing over time)
- Low staff turnover
- Low cost/time of onboarding new team members
- No siloing of information/skills and being held hostage by senior developers
- Attract quality staff
- Able to hire juniors and build them quickly into seniors (lower salary costs)
Breaking “A’s Hire A’s, B’s Hire C’s” Pattern
This will be a topic for a blog in itself, but the short version is that taking on Craftsmanship as a core value in your company will allow you to build A’s from some of the B’s. A’s started out as B’s in their career. If you put a B into an environment of craftsmanship, coaching, and pairing and have a few A’s in the team, you will watch those B’s grow into A’s. Watch this space for a blog on the topic of Recruiting for Success for more insights into this.
Reading List
- Understanding The Four Rules of Simple Design by Corey Hains
- Extreme Programming Explained: Embrace Change (1st Edition) by Kent Beck
- The Art of Agile Development by James Shore
- Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin
- The Pragmatic Programmer: From Journeyman to Master by Andrew Hunt
Summary
Continuous attention to Technical Excellence enhances your firm’s agility. Embracing a culture of Code Craftsmanship comes with a host of benefits and cost savings. I suggest creating a training and hiring strategy to invest in Code Craftsmanship and hope this article has helped convince you of this.
