Sharpening the saw through pair programming
Today I stumbled across a post by Ken Howard referencing the need for developers to regularly "sharpen their saw". That is a phrase I regularly hear, though most of the time it is referring to the way developers stay sharp by being on the edge of emerging technology and aware of new techniques/methodologies.
I'd like to offer an alternative: sharpening the saw is also the process of being critical about your own and others code. An excellent way to do that is through pair programming. Pair programming is simply put: working together (2 or more developers) on the same task. All too often, developers can be thought of as silos, where they are each given their own tasks, they complete them, and all the tasks come together to form the project. However there is far more to be gained from working together rather than separately.
At Telligent, I've been working on our Search Feature Team (aka Super Search), which is comprised of three others and myself. Pairing is something we've only recently begun to adopt at Telligent as a part of our new focus on true agile processes. To many, pairing can be a fairly intimidating thing. You are asking someone to be critical of your code, and you to be critical of someone else's. In a silo workplace, people can often be guarded of their own work, taking criticisms as directed at them versus their code, as there is more of a sense of ownership. Additionally, it can also be viewed as wasteful of time, since if you have 3 people working on the same thing for an hour, you burned three man-hours.
On the contrary, I think pairing is far more productive. Some quick reasons:
- First, it is not about criticizing code, it is about looking at it critically. Code is never perfect, code is never bug free. Suggestions are meant to improve the product.
- You are not the developer you were a year ago, you are not the developer you were a month ago, not even a week ago. You are always learning, evolving, and adopting new and better practices. Don't feel at blame for poor code from a year ago. Realize you know better now. I'm probably more critical of my own code now than other people's. When pairing, I've looked at my own code and thought "WTF was a thinking back then?" "How did I ever pass this off as a test?" I look forward to refactoring my own code most of all.
- Pairing with others provides alternative views to solving the problem at hand. By offering alternatives, it helps you flesh out the best structure from the beginning rather than finding out further own the road that the solution at the time didn't fit all your requirements. Additionally, thinking out alternatives helps you further your knowledge, as someone else might know about a technique you aren't as familiar with. It gives you a chance to interactively learn from others.
- Questioning the code you're working on helps you fully understand your own reasoning for choosing your solution. Others might not understand the goal/process, or might have alternative ideas (which you might not even go with). By thinking out alternatives and working to explain your solution, you not only help someone else learn, but also help yourself by gaining a better understanding of what you are trying to do.
So get out and pair with someone else! Even if they aren't familiar with what you're doing... in many cases, that presents a unique opportunity. We've been starting to pair daily and I definitely feel it showing in the quality of my code each day. If you work at Telligent and are looking to pair, feel free to drop a line! I know others like Leon are always welcoming to lend a hand as well.