posted 11/28/2009 6:07:00 PM by Steve Andrews
Note: There is still so much more I want to say on this topic, but that will have to wait for another post as I further distill my thoughts.
At the end of my three week stint in Redmond, WA in October and November I was thrilled to be able to support Sara Ford as she tested for her second dan (second degree black belt) in Shotokan karate. Apart from being a cold and rainy night in Bellevue, it was a utterly humbling experience. The strength, speed, focus, and control of all those who tested for 1st, 2nd, and 3rd degree black belts was amazing. More so, what I experienced that evening has really started to change the way I think about software development and community in general.
As an aside, Sara alone was so completely focused and exhibited such speed and control that I think my eyeballs melted and are just now recovering.
Dojos and Schools of Thought
“A dojo (道場, dōjō) is a Japanese term which literally means "place of the way". Initially, dojos were adjunct to temples. The term can refer to a formal training place for any of the Japanese do arts but typically it is considered the formal gathering place for students of any Japanese martial arts style to conduct training, examinations and other related encounters.” – Wikipedia
Each dojo is unique, both taking practice and methodology from those before them, and molding in their own style and techniques. More importantly though, no dojo is inherently wrong. There are no ‘my camp is better than your camp’ mantras. In the software developer community however, I find people taking sides on any number of issues: databases, version control, testing, design patterns, and even hardware. Similarly, such arguments often fail to take into account all the variables and environmental issues that must be considered to make a decision. This has long troubled me as I tend to be very pragmatic. Sure, I nag the heck out of folks on Twitter about Team Foundation Server and MSTest, but at the end of the day if they’re using a tool and TFS doesn’t solve any pain points they have with that tool then there is absolutely no reason to change. There is no one right answer. There can’t be. Life isn’t that simple.
Philosophies and Mindsets
"The ultimate aim of Karate lies not in victory or defeat, but in the perfection of the character of the participant." - Gichin Funakoshi (1868–1957)
In each Shotokan dojo, the precepts are displayed on a wall somewhere. These precepts typically include seeking perfection of character, being faithful, endeavoring to excel, and respecting others.
Similarly, I believe that the goal of practicing software development should not be producing software, but rather to continually improve and subsequently solve real business needs. The real value of software is not technical. The real value of software is to improve someone’s life. Whether that involves automating a manual accounting system, building an e-commerce website to provide online revenue, or any other countless systems that software developers build. The philosophy of software development should also not just be about the technology. It should also encompass the attitude and character of the developer.
Senseis and Teachers
From Japanese 先生 sensei, literally "one who lived before" - Wiktionary
In Shotokan, the term Sensei is reserved for those who have achieved fourth dan or higher. Once achieving the sensei status, students are expected to start teaching others. It does not however mean the end of direct learning; senseis continue to be taught by those their senior. Teaching others is to be taught in return; I have been privileged to learn far more by teaching than by simply being taught.
During the exam, I was immediately hit square in the face by the attitudes of the senseis: learning is never complete and the goal of any good teacher is to help the student improve. During the course of the exam, students were called out periodically for not having demonstrated a particular technique correctly. Many times they were made to re-do the technique solo with instruction from the senseis. Instead of ridiculing or degrading the student however, it was recognized as an important time to provide instruction to help the student become more proficient, and it was done in a loving and fatherly manner with the aim of helping the student improve, not improving the sensei’s position. In fact, it might even be considered shameful to dojo sensei in front of the guest seventh and ninth degree black belts who administered the exam. Nevertheless, the student’s success is their success.
Unfortunately, I am seeing the opposite in software development. Mistakes or misunderstandings often seem to be used as opportunities to devalue someone and make them feel worthless, especially in non-physical environments such as Twitter and blogs. The underlying reasons for this lies in Relational Dynamics and the Lifeboat Syndrome (think high school), but that’s another topic entirely. At the end of the day though, anyone who attempts to teach or instruct without a real desire to help the student improve is not worthy the title sensei.
Exams and Measurement
The exams were broken up into three parts: Kihon, Kata, and Kumite. Kihon, the basics, involves demonstrating individual techniques such as kicks, punches, sweeps, strikes, blocks, and throws. Kata, or forms, is a sequence of choreographed movements sometimes up to ten minutes long that demonstrate Kihon as well as stepping, twisting, turning, dropping to the ground, and jumping. Kata is the practical application of Kihon; understanding perfection via repetition. Kumite, or fighting, is the practical application of Kihon with a real opponent through non-scripted sparring.
In software technology, our current methods of evaluating an individual’s proficiency in a particular technology has been largely limited to Kihon. Do you know what framework class to use to send mail and the appropriate properties to set? What is the precision of a decimal? And yes, I’ve been asked both questions. The problem with solely using Kihon to test someone’s ability is that no matter how any particular test may be structured, it comes down to nothing more than rote memorization. Anyone can memorize the .NET framework’s namespaces and classes and answer multiple choice questions, but said individual may not have a clue as to how to use them appropriately or use multiple Kihons together in a Kata to form a more perfect solution.
We as an industry need to find ways to more thoroughly evaluate an individual’s proficiency in a particular technology area or multiple technology areas. This means formulating ways to test individuals at a Kata and Kumite level. Some industries have worked to address this by adopted the idea of apprenticeship or internship. During such a period, an individual works hands-on with a sensei who not only can evaluate the person’s Kihon, but also their Kata: reasoning, decision making, thought process, practical application, and can provide guidance to help the person improve. Finally, we need to test at the Kumite level before someone can be called a master at any particular level. Microsoft provides some of this in the form of the Masters exams, hands-on Q&A with other recognized masters. But we need a way to provide Kata and Kumite level evaluation at every level of a person’s career, not just the architect level.
Belts and Expertise
While the belt system varies somewhat by school, there are 6 levels of colored belts in Shotokan as a student approaches dan, the black belt. There are also ten levels of black belt. One amazing tidbit I learned about belts is that one has to wait 3-5 years before advancing to the next belt level. This could mean 50 or 60 years before reaching tenth dan, a lifetime of dedication. As Sara pointed out to me, “Karate is a way of life,” even if it means missing a Saint’s game.
Our industry has tried to establish levels of expertise, typically using job titles such as Junior, Mid-Level, Senior, Architect. However, these title can be rather arbitrary as typically no real measure of proficiency has been evaluated other than a simple Kihon interview. As was mentioned above, we need a way to more thoroughly evaluate an individuals proficiency beyond rote memorization. This may include pair programming as part of the interview process (Kata), complex situational analysis for an optimal solution (Kumite), and test-driven technical skills analysis (Kihon/Kata).
[Similarly, many companies fall victim to the mentality that hiring a team of yellow belt (junior) developers will have the same result as one second degree black belt (senior or architect) developer. This is just simply not the case.]
So what would Shotokan development look like? Hypothetically:
First, there would be dojos: schools of similar thought, each one able to reach the same goals though maybe through differing techniques and technology.
Second, there would be senseis who are the proven masters of their domain who would teach, encourage, and instruct their students, always in a positive manner towards the betterment of the student.
Finally, there would be belts: skills, techniques and attitudes demonstrated using Kihon, Kata and Kumite to earn the next level.