In a past life, before Benefitfocus, I was a Software Developer. Now, I am a Software Engineer. I never really put too much stock in titles. As long as I get to solve problems and write code, I am happy. However, I recently started thinking a little bit more about this title, engineer, and I started to ask questions about what it actually means. I still don't really care too much about what my official title is, but in the process, I came upon some interesting thoughts about language and how it communicates ideas.
When engineers communicate among themselves effectively, they use precise language based on science. By using such language, it allows for claims to be tested and for the results to be documented and verified without ambiguity. As an example, if an engineer claims that a piece of metal can hold ten tons of weight, there are tools that can easily verify this claim. The piece of metal is put on a machine capable of generating a great load and it is stretched until it breaks. The design for the piece of metal can then be given a maximum load rating for its intended usage. Another engineer who is building a bridge can then simply arrive at a decision on whether to use that piece of metal in the bridge based on the rating versus having to make a decision.
These techniques set those who employ them apart from people who use everyday language because everyday language leads to a great deal of ambiguity. This is because the human brain is very good at filling in gaps in cases where it does not have a complete picture. Normally, this ability is a good thing and is one of the qualities that sets humans apart from other species. However, more often than not, two different brains will fill in the gaps differently. So it shouldn’t come as a surprise that using every day language to discuss requirements and designs leaves the door open for miscommunication.
When engineering solutions together, we strive to communicate as clearly and effectively as possible. So, I am challenging software engineers to think of their tools as a means of precise communication about their designs. Here are a few examples of what I mean by that statement.
- Code mockups to allow others to evaluate your design by actually experiencing it.
- Write stress tests that push your designs and measure how they respond to load.
- Use unit tests as a way to document precisely how you intend for your API to be used in the language of code.
- If you need to communicate a bug in an API to its author, write a test in code as a demonstration. I guarantee that will get better results than an email written in everyday language will.
It is easy to fall back on everyday language. That is why it is so important to take a cue from engineers and strive to communicate in precise terms. I hope that this short blog post inspires you to think of your software engineering tools as a means of communication. Just as physical engineers have tools that reduce ambiguity about their designs, so do software engineers, and when they are used as a tool for communication, you will find that you will tend to have success.