Tuesday, October 20, 2009

Backgammon and good code

I'm not yet done with How We Decide, but this example of deliberate practice jumped out at me.
Robartie didn't become a world champion just by playing a lot of backgammon. "It's not the quantity of practice, it's the quality," he says. According to Robertie, the most effective way to get better is to focus on your mistakes.
You might recall that deliberate practice appears in Talent Is Overrated as the key to high performance. Focusing on one's mistakes reminds me, again, of Test Driven Development. I'm not a TDD nut -- I have never personally worked on a devoted TDD team -- I'm just pulling these threads together. TDD focuses on your mistakes before you make them. You'll still make some, and so your TDD gets better and better, along with your results and productivity.

This sentence also struck me:
After a few years of intense practice, Robertie had turned himself into one of the best backgammon players in the world. "I knew I was good when I could just glance at a board and know what I should do," Robertie says. "The game started to become very much a matter of aesthetics. My decisions increasingly depended on the look of things, so that I could contemplate a move and see right away if it made my position look better or worse."
I have long believed that good code is clean code, exemplified by Joshua Bloch's axiom that good code reads like prose.

Concern for aesthetically-pleasing code strikes some coders as just unnecessary housekeeping chore. But I think programmers who consistently produce solid code write clean and organized code as a matter of routine. And those who don't do it routinely, but have to go back after the fact and clean things up, maybe refactor a bit, will improve over time and eventually get to the point of routine. It no longer becomes a chore, but just a standard way of doing it.

The counter-argument is a whistle-clean, beautifully modular code that fails miserably at what the users wanted. That's actually a different problem: bad communication or bad specs. But I bet that code did exactly what the programmer wanted it to do.

No comments:

Post a Comment