Constant improvement does not require judgmental reflection

June 9, 2009 at 6:49 pm (Scala, Week 12) (, , , , )

I spent much of the morning wrapping tests around the state machine code I’d written last week and over the weekend. Obviously, this isn’t the ideal way to write tests. I want to be a programmer who does TDD all the time, but I wasn’t that programmer on parts of this project. In the sections of the application where I’d done similar things before (the board and the players, for instance), I had no problem incrementally describing the functionality in specs and implementing it. But as I wrote my first state machine code and experimented with a new interface to Swing, I found myself implementing more and testing less.

As I gain experience and learn from colleagues through pair programming, I imagine that my discipline and abilities with regard to TDD will continue to improve as they have in the past few months. In the time being, I’m proud of the amount of code I’ve been able to delete as I write tests and discover the functionality that is really necessary. There is plenty left to do, but my Scala code is much simpler and easier to modify than the Java version of Tic-Tac-Toe, even though the language is still pretty unfamiliar, and the documentation sparser than Java’s.

I was complaining to Doug late this afternoon about the variations in GUI frameworks that make it difficult to get started in a new one, and I realized that what I really want is to know Swing and Limelight as well as I know XHTML/CSS. Again, I think this is a case of frustration based on lack of experience: once I have years of day-to-day Swing experience under my belt, that will feel great, too. I’m slowly learning to reflect on my coding in a less judgmental way. Bruce Eckel’s recent blog post, “A Career in Computing”, advises “There is no right answer … and always a better way. Show and discuss your code, without emotional attachment. You are not your code.” This gels with my experience in music, where I find it very easy to beat myself up mentally for mistakes that I’m not yet skilled enough to avoid. My goal here is not to feel good about bad code, it’s to learn from my mistakes and engrain a healthy state of mind when coding. If I’m frustrated when coding, I’m teaching myself (unconsiously, of course) that it’s the correct way to feel when coding, and inevitably I’m going to make less progress.

Permalink Leave a Comment