I’m starting this blog to share my experience and ideas and to participate in the discussions which shape the profession of software development. As an engineering discipline, software engineering, which is only about 60-odd years old, is a relative newcomer when you think about the engineering that went into building the pyramids in Egypt, the Parthenon in Greece, etc. As a profession, we’re young, dumb, and full of… scrum.
The goal of this blog is to participate in a discussion which moves the profession toward maturity, and which helps you, the reader, and me as well, move from pedantry toward mastery.
What does that mean? In “How to Solve It”, mathematician George Polya described the difference between pedantry and mastery as follows:
Pedantry and Mastery are opposite attitudes to rules.
To apply a rule to the letter, rigidly, unquestioningly, in cases where it fits and in cases where it does not fit, is pedantry. Some pedants are poor fools; they never did understand the rule which they apply so conscientiously and so indiscriminately. Some pedants are quite successful; they understood the rule, at least in the beginning (before they became pedants), and chose a good one that fits in many cases and fails only occasionally.
To apply a rule with natural ease, with judgment, noticing the cases where it fits, and without ever letting the words of the rule obscure the purpose of the action or the opportunities of the situation, is mastery.
This idea of pedantry, even if you never heard the word before, should seem familiar to most software developers. We are told many rules and things that we should or should not do, until we find that we’re “should-ing all over ourselves”. Technology changes quickly, so we can’t always wait until we’ve mastered everything, but mastery is the goal, and mastery allows us to do our best work.