Second Discipline : Be a Hero
We know that learning is mainly based on imitation and imitation can only happen when we are exposed to valuable models. These models constitute the good food our brains need. Either by reading books or attending conferences, we feed us with the result of years, if not decade, of experience and reflection in a few hours. These models, when incarnated in human beings, become the league of heroes we should desire to join.
What, in the case of software craftsmanship, could it mean to be a hero. How in our field of activity, could we exercise valiance, courage and wit? Here are some suggestions:
- let us be a hero for our clients: they are the prime reason we wake up in the morning and the true motivation of our professional endeavors, so we must embrace their cause and deliver the best value possible, even on the things we build but they do not see,
- let us be valiant for always walking the extra mile: when the little bell that warns us of a potentially crappy line of code start ringing in our head, we should not turn our back on it but refactor as soon as possible, and, if we are too tired to solve the issue right away, at the very least we should comment the risks or doubts so nothing remains in the shadows,
- let us do supernatural things like: stealing the overhead projector of your favorite salesperson, plugging it into your workstation to explore interactive programming or design sessions with your peers ; hacking an AmbientDevice to display your test coverage status or the time left before the next release ; training a RoboSapien to pick-up the phone when you do not want to be disturbed by your favorite salesperson (looking for his OHP)...
While pursuing this quest for software craftsmanship heroism, let us not aim the wrong goals. Though they might be reached in the journey, this is not glory and fame that we are seeking: we are looking for doing the right thing at the right time, and that will be heroic enough.
