Wax on, Wax off

Zed’s post on mastery is great, as usual. I have only this to add: that while mastery transcends rules, no one achieves mastery without first acquiring discipline. The masters, who eschew wrote practices to cut straight to the heart of a problem, first spend years practicing forms, repeating katas, and studying theory.

I think every programmer goes through stages of being enamored with certain practices. Just like many other coders after I first read Design Patterns I looked for excuses to use patterns everywhere. After becoming “test-infected” I wouldn’t write code without tests up-front – even if it meant spending a lot of time constructing elaborate test harnesses. And then later on, just like many programmers before me, I moved on to a point where these practices were no longer ideologies but merely tools in my toolbox.

As programmers and engineers we are obsessed with optimizing processes, and I think for many of us after we “level up” our skill we look for ways the learning process could have been optimized. A lot of developers, when moving past strict rule-based approaches to coding adopt the idea that all those rigid procedures are really for the stupid mediocre programmers; here among the 10% we don’t need that sort of thing. But I don’t think it’s that simple.

There are things you learn from consistent practice of a discipline which no amount of reading about the discipline can instill. Learning to view software in terms of patterns and antipatterns improved my skill. So did learning to illustrate software in UML. So has practicing strict TDD. So has practicing pair-programming. The agile masters will tell you to practice one of the Agile methodologies fully and strictly before trying to customize it for your organization. There is intangible value in discipline.

I’m all for embracing simplicity (so long as we’re clear about what we mean by it). But I think we should recognize that disciplines, while not the end goal, are also not necessarily obstacles to ahieving mastery. Rather, they are essential stepping stones.

4 comments

      1. I did.

        I like Avdi's example of tests.

        After T(almost)ATFT for around two years now, I can say that the tests themselves are just a fraction of the benefit I derive.

        Yes, I have less fear about refactorings causing unanticipated side-effects, I can more easily spot code that is never called and I catch bugs I would have deployed otherwise.

        But, more importantly, I feel like I write much better (non-test) code as a result, because there's a strong correlation between the testability of software and the quality of that software. Once you have written a lot of tests, it becomes a habit to write cleaner interfaces, lower the coupling between objects, avoid overly-long methods, take logic out of views, etc.

        Just like how Daniel-san did indeed get better at waxing and unwaxing cars, but — more importantly — upped his hand skills in the process of doing so.

        Thank you, Misters Miyagi.

  1. I did.

    I like Avdi's example of tests.

    After T(almost)ATFT for around two years now, I can say that the tests themselves are just a fraction of the benefit I derive.

    Yes, I have less fear about refactorings causing unanticipated side-effects, I can more easily spot code that is never called and I catch bugs I would have deployed otherwise.

    But, more importantly, I feel like I write much better (non-test) code as a result, because there's a strong correlation between the testability of software and the quality of that software. Once you have written a lot of tests, it becomes a habit to write cleaner interfaces, lower the coupling between objects, avoid overly-long methods, take logic out of views, etc.

    Just like how Daniel-san did indeed get better at waxing and unwaxing cars, but — more importantly — upped his hand skills in the process of doing so.

    Thank you, Misters Miyagi.

Leave a Reply

Your email address will not be published. Required fields are marked *