I can’t shake the feeling that we pay a toll for living in between language worlds, where you write task descriptions in English, and discuss the solution in the local language, switching languages mid-thought when a colleague who only speaks english joins a call.
The job of developing software has always made the most sense to me as a process rooted in language and analytical thought. That which you can talk about clearly, you can think about clearly and write good code concerning, especially when it comes to business software, where there is no mathematical notation to act as a lingua franca.
I feel like our day to day is spent not having a good conceptual grasp of what we do, and that the cost for this is confusion and poorer quality solutions.
On the stakeholder side, business terms are frequently unclear, with details being lost in translation or muddled because the local language has its own legal framework that almost but not quite matches the closest english term, causing trouble when trying to research prior work in the field.
When discussing technical details, we don’t have a set of clear labels for the code itself (block/scope, statement/expression) or the larger units (service, module, component, API etc.).
My feeling is that this puts a ceiling on the possible quality of the solution. Conceptual innovation can’t possibly stem from conceptual confusion.
Devs who have made the jump from mixed-language to English-only environments, do you find that the quality of thought is higher when everyone only works in english? Is there some other facet of this that I’m missing? Should I prioritise working for english-only companies if I value the ability to think and communicate clearly at work?
Despite that unrelated conversation among pilots can still be local language. Discussions among air traffic control off the radio can still be local language.
With regards to software all things related to work and product should be English only without exception. Things related to code theory outside of the product or personal education can be local language. That provides the flexibility to do what is most comfortable for self-learning but ensures there exists a fixed standard for work.
By the way, English became the language of the skies for safety reasons, not for communication purposes. Forcing English usage cuts through cultural dimensions that inhibit more honest expression by less senior people.
I spend a year at a research institution in Germany where English was commonly used (lots of people worked there from all over the world but especially the E.U..) but I might have been the only native English speaker.
All the time at talks I saw people struggle to understand things because English was the second or third language of both the speaker and the listener.
It’s an unexamined phenomenon for many reasons not least the people involved think they are really smart and would have their feelings hurt if they knew how bad it was.
Having a global team doing English first for every aspect of the company life is good and helps a lot, but hardly a pure solution you seem to aim at. If you accept it and start doing personal notes, tasks, code etc. in English, you will notice how easy it is to work on that instantly with the team, without any preparation, convert automatically into docs or presentations etc. It helps to find common understanding and push prototypes faster, as some decisions and tweaking doesn't have to be made: English is the default for all. If your speakers are NOT perfectly fluent it may have a side benefit - you need to boost your overall clarity.
For instance. if I struggle with pronunciation (especially the r's) I weight every word carefully and have to slow down and keep it shorter than I'm used to. I add two takes (sentences/examples) to complex topics to make sure I use different phrasing to be fully understood.
But English is also not immune to local drift (domain specific language, regulatory enforced language or company/topic specific). It's also insanely confusing language that does rely on intuition or axioms that... many don't know. Double meanings, extremely high reliance on context, phrasal verbs, inconsistent pronunciation and spelling, US date format, written text (l, 1, i; 1, 4, 7, A; dot and comma as separators). How many is, respectively, 1m, 1M, 1MM? ... It heavily depends who you talk to. Add to the mix a fact that native speakers often suck at both clear communication AND understanding (in my experience, by being completely unaware they use grammar, accent and vocabulary specific to their region, while having poor ability to understand other regions) and you again end up in a somewhat muddy communication. Damn, even emphasis is different depending on region. Awkwardly, In Polish "akcent" means literally "emphasis" in sentence. In English (used by actual native speakers) emphasis in sentence is actually shifted to words next to the ones other nations find intuitive. So it's confusing as it stresses "wrong" words but is such a gentle thing that most people will never even consider investigating.
Domain specific language (or local, or company specific...) will still be a thing and it's not always a bad thing. You will keep translating English to English. You will create simple phrases that are clear and precise, but will clash with your users using intuition instead of documentation (we can't really blame them here) and misinterpret your carefully standardized phrasing anyway.
The easiest example I came across this year was when I started working with lots of Germans. I noticed they used Productive to indicate Production IT system. I found it weird and incorrect, as productive already has a different meaning. Germans I asked about it agreed, but said they don't really see it as an issue.
But then I realized I'm not in finance any more. We have PRODUCTION. Physical machines and people who produce physical object in a highly organized way. So Productive is much safer and precise word in this context.
You will always have that domain specific language and will have to translate between teams, even when you thing you use same language. It happens on any level of complexity and you have to either be constantly vigilant or just let it go.
Disclaimer: I never worked in a really small company/startup. I don't code much, more of an admin/DevOps/solution architect. I participate in code reviews and do automation, CI/CD, IaC, Infra design and support, sometimes help to design the business product.