I talk to a lot of people who ask for input on how they can get better at what they do. This is something I think about. So I want to share how I think about it and perhaps people can add comments on what works for them (since that is how *I* get better).
How can someone get better at being a programmer? I think of the following things that contribute to being “good” (with the idea that improving them makes one “better”):
For now, I want to talk about how we can get better at writing code. The quality of our code directly influences everyone else in the organization. In “QSM, Vol 1” Jerry Weinberg says “Quality is value to some person”. Off the top of my head I can think of a couple ways a person might value code:
I am sure there are more. The many different types of value that exist contribute to the challenge of building software. Even worse, if you try to build code to satisfy a particular person’s value, you may end up making the code worse for someone else! This leads to inevitable conversations around quality trade-offs - “If I build it the ‘right’ way, it will take longer”, “This code does what the user wants but is impossible to test”, “We are done with the code but component XXX requires manual deployment”, etc.
Attempting to address all known (and unknown!) interpretations of quality is a herculean feat. So what we do instead is try to come up with techniques and processes, which if followed, allow us to write code that delivers a consistent level of quality to known parties and provides a solid foundation for those people who have yet to give their input on the value they are looking for.
The specific code that you write has a direct impact on many notions of quality. How do you decide when you introduce a new class? How do you determine which method you should change when you need to introduce new logic? What is the best data structure for storing a particular entity? These are just a couple of the thousands of decisions that are made every time you touch source code. How do you get better at making those decisions? You read books, you search Google and you learn about techniques for doing things. You may even try those techniques as you code each day. But then you end up with different techniques and approaches sprinkled all over the code making it harder for other developers and even yourself to go back and look at something weeks or months after you wrote it.
To get better at something, you need to practice it. How do you practice coding?
One technique I’ve used is code katas. A small number of people at work have taken me up on the offer to do the bowling game code kata.
Another technique for practicing coding is something called a coderetreat. Code Retreats are focused, one-day sessions, for programmers to practice the craft of programming. You can read more about coderetreats at http://coderetreat.ning.com/profiles/blogs/how-a-coderetreat-works.
We have code retreats scheduled for the 18th and 19th of this month with Corey Haines, one of the founders of this technique. Here is a link to learn about code retreats as well as some of the other interesting aspects, such as “TDD as if you meant it”, which is at http://gojko.net/2009/02/27/thought-provoking-tdd-exercise-at-the-software-craftsmanship-conference/
I think this is some pretty cool stuff. Let me know what you think.