Sterotypically for programmers, many many year ago I used to do martial arts.
I trained with a man named Nick Arnold in Canterbury college sports hall. I learned some valuable lessons from these few years of training. Once I trained with Nick’s trainer a man named Tony Felix.
Tony Felix was fairly legendary in the martial arts world. As the story went, he was originally a professional rugby player, with an interest in external martial arts. Unfortunately he contracted a serious life threatening disease so traveled to China where he sought out the most revered internal martial arts teachers, to learn from them. For many years he trained internal martial arts in the east and eventually recovered from his illness. Returning to the western world, he taught, had different jobs, from being a bouncer to being Wesley Snipes training partner and body guard. As I said, somewhat of a legend.
So the caliber of people I was training with there was very high, a lot of top students from other martial disciplines had traveled some way to come to this training session. In a stereotypical fashion of a high testosterone environment many of them were showing off. With various types of somersaults and high kicks. This made me feel slightly disheartened.
At the end of the training session, I went up to Tony Felix and asked him if he though it would be a good idea for me to go off and learn a single martial art really well before I got to the more advanced stuff he was teaching. I always remember his reply:
It’s much easier to take a good fighter and make him a martial artist, than it is to take a martial artist and make a good fighter.
For the last few days, this phrase has been ringing in my ears. Why? Because I have been interviewing.
There is a lot on the Internet about doing interviews and choosing who to hire. Personally I find Joel Spolsky’s interview guide to be a good general roadmap. Smart and gets things done is a good principle to live by, but it’s not so concrete.
For example sometimes I find myself in a position where I hear that someone is technically amazing, but that a candidate is not so good socially and this was why what Tony Felix said was ringing in my head.
I would like to take what he said and adapt it to the world of programming:
It’s much easier to take a good communicator and make him a programmer, than it is to take a good programmer and make him a good communicator.
It sounds obvious but sometimes it’s not. Think about it a moment. Perhaps a candidate has spent 5 years programming, that means he’s probably in the age range of twenty to thirty. But what has been doing the other fifteen years? Learning to communicate. If it’s taken fifteen years to learn to communicate and he’s still bad at it, then it will be a lot of hard work to undo that. Whereas if he’s a good communicator but inexperienced programmer, then in a few years time he will easily learn the programming skill but have the advantage that he can also communicate.
In the world of agile, where pair programming should become a day to day activity, communication and team work is key to being successful. Without it you won’t be able to create the innovation and productivity you need to survive.
So when hiring, communication is far more valuable than technical ability in the long term.
