You Aren’t Just a Developer, You’re a Polyglot

And that doesn’t mean you can write both Java and C#.

Software development as a craft is an exercise in being multilingual. The most primitive view (read: outmoded) of a software engineer doing their job is someone who rolls into work at 10:30 am, just in time for standup. Right after our Socially Compulsory Run-on Update Meeting, we make a dash for our desk and, avoiding eye contact, slide on headphones and open up Red Bull #2. Maybe we leave for lunch, maybe we power right through. By the time we leave for the night, some code has been written. That’s the job, right? We’re just writing code.

It’s not quite “just” writing code though. In the process of doing so, there are at least three translations happening. The first language is that of the Requirement. Requirements have a very loose syntax, and depending on the team size or who is writing them it’s possible that the requirements can be in a few different regional variations. To do the job right, we must be fluent in the regional variation that the team speaks. The comprehension of this language affects everything that follows.

Next, we take Requirement and pass it through User. Depending on the situation, User may not be a language in its own right, more of a dialect, but it’s just as important as Requirement. User isn’t always very well documented. We pick it up through meetings, conversations with the client, domain knowledge about the clients’ industry, and user research. Here we make discernments about what we learned in Requirement and line it up with what we know the user needs.

The next language is our favorite. This is the point where we get to translate Requirement and User into Code. Luckily, Code is formulaic. It’s consistent. It’s complex and hard, but at least it’s predictable and (usually) well documented. In this translation, we take what we know and turn it into something that a computer can understand and execute. Code is where we spend the majority of our time and focus. The months of research and years of practice rarely go into Requirement, they almost always go into Code.

Finally, we can’t forget Maintainer. Our time will end on every project. Inevitably, someone will come in a few years later, it might even be us, and try to make sense of what’s going on. Uncle Bob says, “The first priority of a programmer is to communicate with other programmers” and guess what, we probably won’t know them. That’s why Maintainer is so important. It’s another dialect of Code and is spoken through practices like naming functions and variables descriptively and using the most appropriate built-in methods like `filter` or `reduce` instead of unnamed `for` loops.

While these are the first languages we need to speak, it doesn’t stop there. As we progress in our careers and take on more complex roles we need to become fluent in more languages. There’s a reason there are thousands of resources on “business speak” and “communicating to executives.” As software engineers, it’s our job not to learn how to write the purest function or the most efficient sorting algorithm, but to learn fluency in as many languages as we can.

In doing so we can more effectively move up and down the Architect Elevator, improve communication between ourselves and others, and write code that doesn’t just get the job done, but does it well.