Do you speak the "programmer's language" well?

When you speak your language you usually do not ask yourself if you use it properly, what are it's strength and weakness or if you speak it better or worse than the other people. You simply use the words you know to communicate something. The communication may be faster or slower (read "more efficient" or "less efficient) independent of the communication medium. One may be able to use a rich dictionary to pass the same message using just a few properly put, sophisticated words. The other would describe the same thing with simple words. It would just take more time. Talking is natural to us and being faster or more sophisticated sometimes does not mean better. Why not? The problem with the "smart" speaker may be that there will be not to many listeners who will be able to understand him. It all depends on the environment you are in.

Now imagine what happens when a PhD. in whatever subject is put in a room with a person who did not even finish a primary school. Are they able to communicate? Well... Yes. Kind of. The problem is that the PhD. guy will use 5% of his communication skills, start building long sentences of simple words just to be explain the other guy some stuff that seems basic to him. I think you already know where I am going... :-)



The programmers are very much like usual people who instead of "speaking" the "normal, common language", "speak" programming languages, design patterns, recent technologies and some other funky stuff. (Well, at least the real programmers do.). We all know that programmers who know "the sophisticated words" can be much more efficient then those who "speak" the basics. That is mostly the reason why large companies try to hunt down the best to work for them. The problem with programmers however is that it's not that easy to verify their "spoken" skills. To do it correctly, the recruiter must actually be able to speak "the programmer's language" on at least the "considered as minimum of the best need to have" level. Why? Call back the PhD and primary school guy conversation. Accidental addition of a poorly skilled guy to your team of professionals, may (and will) lead to terrifying results. The overall team performance will go down because the communication between the developers will have a bottleneck. In the end paying big money for your experts will make no sense at all since their efficiency will be limited by other group members. The more "average" people are add, the worse the performance is. In the end the company would be better of hiring cheaper developers, as this would not make any difference for the project performance.



Just to illustrate this; imagine a group of developers who all know what a strategy pattern is. Since it's definition is obvious to them, they simply say, "we use the strategy pattern here, and we will use it also there". A guy who does not know what this term means will have no idea of what are they actually talking about.. and thus, can not contribute to the conversation. Asking for explanation is correct but.. it reduces the groups performance. Now instead of simply saying the "strategy pattern" they will need to explain the poor guy what it is what they actually mean step-by-step. Looks like unnecessary effort to me.

Now, why am I writing about all this well known stuff? It's actually very important to me :-) One of the hints that I'll try to keep in my mind at all times is to make sure I work with great people only! They are the source of the success, nothing else. Motivated, educated and experienced freaks who feel like they want to build something great. Get them, set the free and let them build together!

B.t.w. Today I learned that knowing "the language" good does not necessarily mean the ability of using it to "discus". You know... even if you knew all the names of the European poisonous mushrooms you would not be able to really discuss about them, right? This is however another subject. For now, just make sure your people know well "the thing" they are building. The fact that they know "how to build" does not mean that they are also able to use this skill to "understand and discuss about" whatever YOU are building. Know that they want to build it too!