Take a look at the class you’re currently hacking away at in your project and ask yourself this: “If I showed another developer this class, and only this class on its own, would they understand what it does?”

Quite often, the answer is “no”. And that is a maintenance problem. Your next question then, should be: “How can I make the answer to that question ‘yes’?”

A great place to start is to take more care in how you name things. Give your class a name that clearly states what its responsibility is. Give your methods names that for commands clearly explain what action they will perform, and for queries what results they will return. Don’t forget to also think about the names of method parameters.

If something is difficult to name, consider the possibility that this is a symptom of poor design: Perhaps you’ve broken the single responsibility principle?

This may sound like trite advice, but developers are always in such a hurry. So slow down, spend a few seconds extra right now and make sure the code you write isn’t a sloppy mess, and you will be rewarded for it down the line where those few extra seconds spent could have saved you or your coworker half an hour of debugging because you misunderstood how a poorly named class/method functioned.

A couple of months back I spoke at the MSDN Live conferences in Norway. One of my talks was on ASP.NET 4.0, and I had some demo code that I used to explain some of the new features. Recently I got some feedback that some people had been baffled about the “quality” of my demo code – why would I bother to write unit tests, apply design patterns and so forth in a silly little demo application? Surely that’s overkill and a sign that I was prone to overengineering my code.

Practice makes perfect

If you want to become good at something, you need to practice. We often talk about this in terms of internalizing a certain set of skills; practicing something until it becomes second nature to do it. There are many ways to accomplish this. One that’s become popular lately, is katas. A kata is a Japanese concept, which basically means to practice a fixed choreography over and over.

Check out this recording of Uncle Bob Martin performing his Prime Factors kata, in which he’s honing his TDD skills in Ruby:

Another great example is this video by Chad Myers, in which he implements FizzBuss in less than 4 minutes with the mouse disabled:

Solving small, insignificant-seeming problems in order to try out and practice methodologies, technologies or patterns is a great way to become familiar with these so that they are in your toolbox ready to be applied instantly when you’re on a deadline and don’t have time to fool around.

University only ever taught me one truly valuable skill: Studying; the art of research. Approaching a problem academically, looking at how other people have solved the same or similar problems in the past, learning from the collective experience of the community of professionals that surrounds me.

I’m young yet – of my 25 years I’ve only been a full-time software engineer for four. Today I’ve signed the manifesto of software craftsmanship, because it embodies what I aspire towards whilst standing on the shoulders of giants.