Speaking multiple languages is a superpower. It abstracts your thoughts away from words and closer to the object models. It makes you more attractive to potential romantic partners. For software engineers, learning English is essential: most of the research papers are in English, most libraries are documented primarily in English, even the keywords in programming languages are all English. We pick it up, we understand the docs, we get things rolling. But at what cost?

Processing Delay

One of the penalties for non-English speakers is taking more time and processing power to listen. When on a conference call, without any assistance from non-verbal communication hints, understanding (and formulating when speaking) may take so much of (my) resources that nothing is left to actually analyze the data. So conference calls may work for syncing-up at best, there is hardly any brainstorm or productive discussion. When multiple parties are involved, naturally, those with English as the main language get more room to speak and (what is more important) to think.

To help with this issue, a meeting organiser can make sure that one of the following is true:

  • meeting doesn’t require active analysis and idea generation
  • there is no more than 2-3 parties in the meeting

Fragmented Associations

Our minds are mostly filled with associations. Associations often define what an object is. Associations allow the brain signal (a thought) to jump from one place to another and make progress. An efficient brain would have rich associations for distinct nodes. It wouldn’t have, for example, two different nodes for “bear” with their own sets of associations.

When non-English speakers read about information systems, they rarely try to translate everything into their language to draw associations from. Instead, they take each concept/keyword as a new node in the association graph. For example, “git commit” becomes this thing I use to turn temporary changes into local tree changes. These are all the associations I get from working with git and reading documentation on it. It’s sufficient. But it doesn’t include any of the meaning of the word “commit” in my native language that I’d use in other contexts, such as “commit to relationship”.

As a result, all the terms and concepts of software engineering become dry and thin on the association front. They become separated from the very thing they are named after, in the brain of non-English speaker. This makes it harder to understand and operate new concepts. Most importantly, it erases any intuition one would have about a concept. If I don’t have rich associations of something, I can’t anticipate how it behaves in situations I don’t clearly know.

Fighting this is hard, but I believe trying to find the proper native words to describe the very same English terms is useful to connect the treasures of associations we have. And it doesn’t matter if the native words were also borrowed from other languages (like French) back in 1800. What matters is that you grew up with them, and your associations are wired up accordingly.

Sence of Superiority

English words have become a part of the day-to-day vocabulary of software engineers. Their use is associated with professionality, high qualifications. Naturally, mentioning exactly the same things in the proper language becomes less respected. Anyone want an Electronic Computing Machine? No, everybody wants a computer.

The effect of English term substitution is subtle, but it is very widespread, and it accumulates with time. It plants the seeds of anything from the English word being automatically superior. It teaches to borrow instead of create. It corrupts the culture and serves as a weapon of cultural domination.

Not everybody agrees with this being an issue. If you do, it helps to understand the technologies deeper. With deep understanding, you don’t rely on terms or language in which they are expressed as much. So you can be fair in judgement.