Coder – Your days are numbered.

Neil Mcallister of infoworld wrote an opinion piece “Coder, your days are numbered” which turned out to be a long winded way of saying that the typical computer programmer needs more than “l337 haxXing skillz” in the modern business environment, they need good English and communication skills. Leaving aside the details of why English is the dominant language in programming, what Mcallister was saying, while true, was hardly new. Programmers need to see their place in the business context and also participate as fully as they can in the process of business in order to reach their full potential. It’s one thing to be an amazing developer but if you can’t express and interact with your non-tech colleagues then you will probably remain marginalized, waiting for someone that can express what you do on your behalf and indirectly highlighting the fact that you couldn’t do it yourself. Most frustratingly is the inability to apply great problem solving ability and insight to non-traditionally tech problems. I believe that a good programmer doesn’t need a keyboard and mouse to practice their craft.

So we’ve established that communication and interpersonal skills are important for the business embedded programmer. Fine, but what office dweller doesn’t need these skills? I think that the vital point is the ability to communicate a solution in the same language as the problem. I don’t just mean English or even Java vs. C#. I mean using the appropriate domain – It is a mistake to solve an accounting problem using pseudo-code or poetry. Accounting has a language of it’s own, so does marketing, HR, sales etc. and it behooves the modern programmer to become comfortable and proficient in as many of these domains as possible. It cuts both ways as well. I wish that more sales people could speak a little developer (it would certainly make bug reports easier) or marketing and product managers meeting us half way with a better grasp of spec writing.

I know that I have drifted off the point of the article. At the end of the day I was mostly uninspired by the idea that English is the dominate language. However it did spark in me the importance of choosing the same language to communicate in. I also realized how much we fudge this common language through metaphor and analogy. The old joke of reducing all programming examples into that of motor cars is something, in my opinion, that needs to die. Metaphor is a literary device NOT a technological device – I don’t care how good your analogy is, don’t waste yours and my time trying to approximate a communication exchange. If something has to be reduced to analogy then I would say you have critically failed finding the appropriate language and knowledge domain to express accurately what you really mean.

So often communication between the business and information technology practitioners happens in the metaphor and more often than not it results in miscommunication or over simplification. User stories should be written by users in their native knowledge domain using actual terms and expressions. The software developer can then translate this into functional specs and test cases. The role of the software tester is to ensure that the developer actually delivers what they said they would deliver. The role of user acceptance testing is to test the solution against the user story. I have become acutely aware recently that even great developers that write awesome specs and hundreds of unit tests and deliver exactly the solution that they said they would and the tester has confirmed total fidelity to the spec hasn’t necessarily proven that the developer and tester even understood the business users’ user story in the first place.