This is the last part of the series. You might want to read up on part 1 and part 2, because they were about programming related ideas. In this article, we’ll look at the non-programming areas where you need good linguistic skills.
Below, above and around you
When I was young, my idea of a programmer was the typical hacker type of look, either ingenious, obscenely obese, pizza-eating-grubby-fingers-typing, or skinny, pallid and anti-social (or any combination of them). Programmers were depicted as reclusive because of their obsession with computers, sometimes to the exclusion of communicating with other people.
In this current world, programmers need to talk to many types of people. Programmers talk to new staff, testers, managers, customers, sales people, marketing people and their peers. They talk to people of all levels, below them, above them and around them.
If you only know how to talk in code, the only people reasonably expected to understand you are your peers.
Chicken and Duck speak
There’s a Chinese saying “Ji Tong Ya Jiang”, which translates to “chicken talking with duck”. Both are of the fowl family, yet neither can understand each other. It’s used in situations where person A is talking to person B using words that person B understands, yet person B cannot understand the whole sentence when all the words are put together. Comprende?
For example, I know a friend who’s a programmer and work at the same floor as me. One day, I passed by his desk, and saw an SQL reference book in Chinese on the table. I picked it up and leafed through it. Individually, I could read the Chinese words. It’s when they’re strung together that I don’t know what they mean. It was terrible. Only when I looked at the SQL code did some of the sentences begin to make sense.
Ever had someone ask you why something failed due to “select access to such-n-such-table not granted”? Do you tell her the problem’s fixed and access granted? Or do you go into detail about how the database table was recreated and select access was not granted, causing the error? She might know what a database table is, but frankly she doesn’t really care.
Ever had someone ask you why an application is so slow? Do you tell her it’s a database problem and let it go at that? Or do you launch into an explanation on why a particular database table had a missing index, even going so far as to name the database table, and that you recreated the index, and that should speed up the retrieval SQL query, which in turn speeds up the application?
Use the appropriate words for the appropriate types of people you talk to. A manager can understand a slow server response answer. A technically knowledgeable tester can understand a slow database server response answer. A programmer can understand a slow database server response caused by an inefficient algorithm in an SQL stored procedure answer.
The only way you’re going to use the appropriate words is if you already know the appropriate words. Of all the people involved in a software project, you as a programmer are the most intelligent of the lot (I’m biased of course *smile*). Since you’re the most intelligent, it’s up to you to have a wider range of vocabulary so you can talk to anyone, and even translate for others.
Which brings us to writing documents understandable by everyone…
Put it in writing please
It doesn’t matter what you call them. They’re specification documents, including general business information, business logic, technical information and anything concerning the software project.
When you write a technical specification document for programmers, you translate business logic into near-pseudo code. You detail the database tables involved, perhaps a modification of existing table columns, perhaps a new database table. You might include a mockup screen shot, with some details on what that button should do, and what this datagrid should display. You note down validation checks based on what is reasonably expected from the business logic.
When you write user guides for users, you write in a different manner. Lots of pictures involved. Text in snappy sentences, preferably free of technical jargon. Validation checks explained in “between 1 and 10 inclusive” instead of “
1 <= i && i <= 10".
Do you write for the right people?
The importance of your linguistic skills must be emphasised. Today's world creates situations where you need to talk to non-programmers, and non-programmers talking to you. A phone call from a user. A face-to-face conversation with a tester. An email to a customer.
I find it difficult to understand how someone who can tell the difference between
short, cannot tell the difference between "lose" and "loose". You're an intelligent person. You should be above simple spelling and grammatical errors.
Non-programmers don't communicate with you through your code. They communicate with you through your language. Be a better programmer. Have better linguistic skills.