Jeff Atwood of Coding Horror and Stackoverflow fame needs no introduction.
His recent blog post on The Ferengi Programmer was an especially poignant one for me. Specifically, it was this paragraph in his entry:My style of development and testing is highly agile. I am agile in that I am prepared to question and rethink anything. I change and develop my methods. I may learn from packaged ideas like Extreme Programming, but I never follow them. Following is for novices who are under active supervision. Instead, I craft methods on a project by project basis, and I encourage other people to do that, as well. I take responsibility for my choices. That’s engineering for adults like us.
I am not sure if Jeff has a martial arts background or not, but a great analogy I can draw from my own experience with Karate is the concept of “Shu Ha Ri”.
The Wikipedia definition says it quite well:Jeff’s perspective is from the outermost circle of experience, Ri, where programming decisions are natural and intuitive to him. Under pressure, he has the volume of experience to assess a situation and generally find the correct resolution. Reaching a state of mind like that requires a flexible set of “guiding principles” but nothing like the 285 Rules of Acquisition.
Jeff goes on to state:Guidelines, particularly in the absence of experts and mentors, are useful. But there’s also a very real danger of hewing too slavishly to rulesets.
And needless to say, he is dead right. A programmer enslaved to rules, procedures and methodologies is going to be stuck in the Shu circle of experience and will struggle for original thought under conditions of duress. There is only so much you can learn from books or Katas. There is no replacement for experience - whether it is real-world programming or Kumite. The more you do, the more you transcendent you become in your craft.
The problem with an intricate set of rules is that they are based on preset constraints formulated through the experience of another person or group. Unfortunately, constraints change all the time, which, through inference, would require the rulesets to be re-evaluated or redefined as well. The more you subscribe, the more boxed in you get.
So, in a nutshell, my advice to the programmer in you:
Learn the fundamentals of your craft. Be loyal to the guiding principles inferred from this education. Go out there and put them to the test. Early. Often. And under various states of duress. That’s right, search for trouble. And most important of all, learn to refine your principles with every fire you extinguish.
Thanks for writing about this topic Jeff!