This is a response to the following article Programming as craft
Programming is a craft. I will never claim to be a master of the craft but to say that programming cannot be considered a craft overlooks many elements of the profession. Sure, groups of developers aren't building artisan furniture or designing magnificent cathedrals but none of these crafts were perfected overnight and relatively speaking programming is in its infancy.
The notion that programming is not a craft stuck me in an odd sense and I have been wrestling internally with its contents for a few weeks now. This response is not a critique of the authors points but rather a different perspective reflective of a personal journey that I've had in my career as a developer. I hope to address a few of his criticisms and point out some possible overlooked areas of the profession.
I'm not an expert in software development by any means. On the Dreyfus model I would place myself somewhere around competent. But my career has had its lows and highs as every job does, however it took a career defining mistake to really drive home that my approach to my work was all wrong.
When your boss's boss calls you into a meeting to discuss your quality of work it's typically not a very good thing. Especially when hours before you had a similar conversation with your boss about the same thing. Sitting there with the fear of being fired and another child on the way really brings things into focus. You realize that there must be something missing, either a culture issue at your company, or a lack of insight into your work habits. For me I wasn't taking my job seriously enough and it showed.
Feeling deeply remorseful and fearful of my career I asked my boss's boss what can I do to become a better developer? His recommendation was to read a book titled The Pragmatic Programmer
The Pragmatic Programmer
This book really changed the way I view my career. I used to think it was as the TechCrunch article described as a career where "languages ebb and flow" and to not be on the bleeding edge puts you at a disadvantage. That the whole industry goes towards trends that are constantly changing. To me it seemed like to be successful in this career you needed to be on the newest technology or you'd be stuck in a dead-end job.
Yet in the first few pages of The Pragmatic Programmer I found a more soothing answer:
Programming is a craft. At its simplest, it comes down to getting a computer to do what you want it to do.
To look at this career through that lens establishes a foundation for understanding your work as a craft. It's the same as telling a carpenter that at its simplest things can be made from wood. It is the skill set that a carpenter develops overtime that defines their mastery level. In the same way a developer can establish skill sets that help them develop code.
These skills sets are not languages but approaches to development or best practices. Almost every language supports commenting code and most languages today support test code. These are language independent skills!
Journey to Mastery
The journey to becoming a master of a craft in any area is to become a master of the tools you use. To take the tools and use them against a medium to make something new. I would argue that code, the language itself, is the medium not the tool. Tools help shape that medium into something new and great.
A great chef uses many different ingredients to create many different meals. Each meal or ingredient will have its time as a popular option, but the tools generally remain the same. Knives, whisks, etc all become tools of transformation. Process and technique in using these tools helps underline a certain mastery level. Programming is the same way. We have tools and techniques at our disposal that help us mold code (in any language) into something great.
When I sat down to originally write this piece I intended to go into more detail and examples of how a developer can be considered a master of the craft of programming. Yet each tool, technique, and design deserve their own time in the sun and so I am hoping to continue this writing on this subject of mastering the craft of programming.
In this series I hope to address testing techniques, importance of documentation, establishing good standards and practices, etc. I think it will be worthwhile because I'll be on this journey with you. As I said before I view myself as competent but with a lot to learn. Things I have learned need revisited and honed.
In the end I believe that mastering a craft is how you view your approach to work and the quality you expect from it and yourself. Mastery of a craft is a journey, one without an end. To truly be a master you need to be able to identify quality and create quality.
“Peace of mind produces right values, right values produce right thoughts. Right thoughts produce right actions and right actions produce work which will be a material reflection for others to see of the serenity at the center of it all.”
-- Robert M. Pirsig - Zen and the Art of Motorcycle Maintenance