This week’s question comes from Mark L. and Scott S. who have both noticed some companies hire programmers who all speak the same language. Spanish is a common example. And they want to know why. What are the benefits of a software development team that all speak a language other than English?
I explain in this episode the importance of culture and how it really helps to match your primary customers. By itself, hiring programmers who all speak a language other than English won’t help you create better designed software. But it will help the software engineers to better understand the customer needs. And that leads to software applications that have more value for the customers.
I also talk about the importance of keeping the source code as well as any other material such as log files in English only. These are resources intended just for the development team and I talk about some of the trouble you will have if you try mixing languages. It will make your source code harder to read if you mix other spoken languages into the names of your variables, methods, and classes.
I suggest keeping everything English only that involves the actual software development and then make full use of the team’s preferred language and culture for everything else.
You can listen to the full episode or read the full transcript below.
Transcript
I can answer this with one word. Culture. I should also say that this whole question really only applies to regions where English is the majority. If you’re listening to this podcast in a country where some other language is more widely spoken, then of course, you’re going to find teams forming that match the majority of local people available. Keep listening though because I have some suggestions that’ll help you also.
A lot of times we think of software that’s designed and built for English speakers first and then gets modified for other languages later. But that doesn’t always have to be the best way. It all comes down to what your customers need. If your customers need and expect a certain language, then that’s what you should provide.
Hiring software engineers who all speak the same language won’t automatically give you software that’s better designed but it will give you engineers who feel more comfortable with your target customer. And that’s always a good thing.
The smart companies realize that engineers should not be kept isolated from the customers. Sure, you want some people on the team who’s primary role is dealing with customers because let’s face it, it takes a certain set of skills to enjoy programming and be good at it. Since we tend to get better at the things we do more often, it makes sense to have some roles focused on customer interaction because that’s what they’ll be best at. But for software developers to write more valuable software, it has to be perceived as more valuable by the customer. And interacting with the customer is the best way to gain this understanding.
So if you have a customer base that identifies with a specific culture, then having a development team share that culture will help you establish better relations with your customers.
Now that you have a large portion of the software developers sharing a specific language and culture, this will spread to other new hires and soon it’s easy to end up with an entire team of engineers that all speak the same language.
There’s nothing wrong with this. But I would caution against letting this creep into the source code too. Here’s why:
Programming languages are a language in themselves.
They’re highly specific and detailed in order to provide instructions that can have just a single meaning.
Now have you ever tried speaking in multiple languages at the same time? I’m not talking about learning multiple languages so you can switch from one language to another when talking to different people. I’m talking about within the same sentence bouncing back and forth between languages. You’d be lucky if anybody could understand even simple statements.
Programming languages are the same. Each programming language has a set of keywords that are reserved to have special meaning in the language. While you can name your variables, and methods, and classes anything you want, you can’t use the reserved keywords for anything other than their intended purpose. And you have to use those keywords for those purposes.
These keywords are in English.
Maybe there’s a programming language with keywords in a different language but I’ve never seen one. At least not yet. I wouldn’t be surprised if programming languages like this eventually appear. But for now, all the major programming languages have an English tendency.
It’s tempting to name your variables, methods, and classes with names that sound like words from some other language. The problem though is that you are now trying to speak multiple languages at once. Reading your source code becomes more difficult as you have to switch back and forth sometimes several times on each line.
My advice is to stick with English only for the actual programming and let the increased cultural identity manifest itself in other ways.
If your software produces log files, I also suggest that you keep the log file messages in English only.
Beyond that though, your software should look and behave exactly as the customers expect.
And this is where having a unique company culture helps.