Suck-a-doodle doo

<whine>Had to do a complete reinstall of Solaris which wiped out my user partition and I lost all my stored email, my resume and web site</whine>

Now that I've got that off my chest, I just wanted to share a very interesting idea I ran across today. It's a post on Dave Thomas' blog (now a wiki entry) talking about practicing. Practice seems to be more of a, well, a practice with people who have vocations requiring physicals skills (musicians, athletes, etc.). But shouldn't programmers practice too? Dave says yes, and after reading what he has to say, I'm inclined to agree. Especially for those of us who aren't in "agile" shops, and who perhaps spend two months designing, six weeks coding and two months testing. After spending the last couple of years honing my skills with design patterns, UML and other high-level concerns, Dave's katas have brought me "back down to earth", with their focus on the basics: what is the best data structure to use, how do I decide what's the best algorithm for this situation, is it better to write some code or just invoke a system utility?

Maybe it's just me (stuck in the middle of the "two months of testing" leg of the cycle), but thinking about these aspects of system design really brought home the essence of development: deliver a system that solves someone's problem(s). Not that I haven't been doing that, but lately I've been more focused on delivering solutions using "industry best practices" than I have with actually solving the problem. I'll defend myself by saying that the design artifacts are, on my current project, a deliverable, and so I spent a large amount of time making sure that I followed The Process. But in the end, it's the solution that matters, and I wonder if I might not have been led, perhaps by hype, somewhat astray.