Natural Language Proficiency is a Hard Skill in Software. No, Not as in "Difficult." Hard.

Because software development is fundamentally an exercise in translation, and being a good translator requires knowing two languages really well.

That's it. Truly. If you understand and agree with that statement, you can hit the thumbs up on the article and off you go. Thanks for coming to my TED talk.

"I don't understand." - Some of You

That is either a beautiful little nugget of irony (because you lack requisite natural language proficiency in English), or maybe you're not in software.

If your situation is the former, continuing to read won't really help you. It only gets weirder from here. However, if you can understand English just fine (thank you very much) and you're either not in software or you just really dig my writing and want to see where this goes and how I'm inevitably going to stick my foot in my mouth, please: read on. It's going to take me a little more effort to earn that sweet, sweet thumbs-up validation that I so desperately crave, but I am committed.

Say It Again, But Different. Assume I Am Not In Software.

Alright, let's start with the assertion that software development is fundamentally a translation exercise. I'm going to give you Matt's Patently-Stupid And Overly-Reductive Formula For Software Engineering.

Here it is:

1. Customers are people (humans), who want things. We'll phrase these simplistically as "problems," but they can also be desires. Depending on your particular life philosophy, I may be repeating myself there.
2. Hopefully, our customers also have money.
3. Customers tell Software Developers their problems, using a natural language like English or Swedish or Pig Latin -- whichever one they speak.
4. Software Engineers build solutions to these problems. Solutions are basically hypotheses that test our understanding of the problems. We build them using math, playlists full of (probably obscure) indie music, and truly unhealthy quantities of caffeine.
5. Software Engineers present these solutions back to customers in order to validate our understanding of the problems.
6. If the Software Engineers didn't get it right, we learn something about the problem that we didn't understand before and try again, with more math, angsty-er music, and even greater quantities of caffeine.
7. When the Software Engineers get it right (understood the problem correctly), we get money from the customers. Sometimes.

In Case You Missed It

• Problems, described in a language people speak, go in.
• Solutions, which are effectively descriptions of those problems, come out.
• The solutions are written in a different language from the one that went in. The languages that we use are programming languages. They have names like Java or Python or Rust (if you absolutely must be cooler than everyone else) and we nerds will fight unceasingly about which ones are best, but they are all, at their core, abstractions for MATH.

This means that:

Software Development is a translation exercise from natural language to math.        

Also, this is really fucking cool and crazy difficult because as far as languages go, natural languages are super ambiguous and meaning is largely context dependent, and math is neither of those things. It is unforgivingly and punishingly precise. Software Engineers are wizards, applications are spells, and the truly fascinating thing is that understanding how it works makes it more magical, not less.

Assertion 2: Natural Language Proficiency is a Hard Skill (In Software)

This might be hard to accept at first because we almost always discuss communication in the context of software development as a "soft" skill. You probably have context for the definition of "soft" vs "hard" skills, but I'll offer a definition here anyways, just to make sure we've level set:

• Hard Skills are things that can be acquired/taught in a relatively straightforward manner because they have generally accepted "right" and "wrong" answers and usually aren't very context dependent. Importantly, these hard skills are usually the things you're being paid to exercise primarily.
• Soft Skills are typically more context dependent and tend to describe whether you're good at the baseline activities of being a human in an organization. They can be more difficult to teach because our behaviors in the soft skills area tend to be rooted in our values and insecurities, and changing them requires a lot of time, dedication, and the liberal use of spray bottles and shock collars.

As an example, Jenny, a Nuclear Physicist, will need the hard skills of Chemistry, Math, and Particle Physics. She needs that knowledge so she can design a nuclear plant that doesn't end up with an incident named after it. Jenny also needs soft skills, like being able to talk to other physicists without getting hung up on (and arguing over for hours on end) the color of the bike shed.

So coming back to our space, here's the question:

For a person whose job is to translate, let's say between French and German, are the skills of French and German hard or soft?

Oui mon ami! Sie sind hart!

In this context, they're hard skills. French and German, as languages, are things you can study and get good at, and they are the main skills -- the brot and beurre -- of your daily work if your job is to translate between them.

And importantly, only being good at one of them, French OR German, would make you pretty shitty at that job. You need to be good at both. Really good. Like fluent good. You don't have to be a native speaker of both, but you need to have achieved fluency.

Just like software engineering.

This is where I'm going to get in trouble.

Listen, we both knew it was coming. I'm here to say outrageous shit and make stupid comparisons, and so far I've only made a bunch of stupid comparisons.

Here it is:

Natural language proficiency is something we can, and should, screen candidates for to ensure a level of fluency that meets our expectations for the role. Software Engineers that lack fluency in the chosen natural language of your company and/or predominant customer base will be worse at building software products than engineers of equivalent programming skill who are also fluent in the natural language that is being used to describe the problems they are translating.        

Said another way: "Garbage In -> Garbage Out", and "Garbage In" can be a comprehension problem.

Before the pitchforks and torches come out, I want to draw attention to the fact that I never said "English" in there. There is, admittedly, an uncomfortable systemic inequality and bias inherent in the market reality that the biggest, best paying, cushiest jobs in tech tend to be American firms who speak English internally and serve English-speaking customers (think FAANG).

I can't really change that, but you can. What I've done here is effectively show my work for a logical proof that supports the assertion in the title of this article.

Now you get to choose your own adventure. Here's what you can do with that information:

1. Get angry. Say "uck-fae ou-yae" and go start your own company that speaks Pig Latin as its chosen internal language and serves Pig Latin-speaking customers. Or Swedish, whatever -- "bork bork" can't possibly be real words in a real language. More seriously, you can change the landscape of natural languages in software if you decide not to go work for FAANG or build primarily for American consumers. Many of the problems that we humans have cross language and cultural barriers. It really is possible to build successful tech ventures in other countries, cultures, and natural languages serving non-English speakers as your primary problem describers. It's not easy, but it is possible.*
2. If you're an engineer, you need to ensure that you're fluent in the natural language of your company and its customer base. You'll be a better software engineer for having invested that effort if you're not already fluent. You can be a badass Scala Ocelot (or whatever mascot Scala people prefer), but you'll never be great if you don't master your input language.
3. If you're hiring engineers, evaluate natural language fluency for the hard skill that it is, and understand that new hires who lack fluency in the natural language of your company and customers will result in less accurate translations -- meaning slower engineering velocity and more product iterations. This can go on a sliding scale, too, just like we evaluate programming language skill on a sliding scale based on the title level we're hiring for. The main point is that we shouldn't ignore it.**

*If you are not a native English speaker, please know that my point in saying this is not some ham-fisted attempt at saying "go be with your own people, we don't want you!" I love you and the diversity of thought, perspectives, and experience that you bring to our teams. The message here is that you have more options than just "you have to learn English."

**There's obviously a huge caveat here: if you are a horrible bigot and you're using this as an excuse to reject candidates who genuinely have great language skills, I have a choice phrase in Pig Latin for you.

That's it.

Now hit the thumbs-up and off you go. Thanks for coming to my TED talk.