As software engineers, we all strive to speak the same language. We have named design patterns, our own terms and phrases, and even built systems to help us all be on the same page. As a result, it can be easy sometimes to think “If I understand this, then so does everyone on my team”
If only that were true.
As engineers, we tend to forget that we have only used a small fraction of tools, concepts, and technologies available in our field. We forgot that others might not know the same tools or speak the same language. And when we forget that, we create conflicts and problems for our teams.
Let me tell you a quick story of how this happened to me.
I was working on some code the other day, when I started to overhear a conversation about some merge issues. I decided not to jump in because I needed to focus on my code and I was sure that the rest of the team members talking would be able to sort it. I put my headphones on and kept working.
About 5 minutes later, I get a Slack message. Then another. Then another. A fury of messages complaining that our team was terrible and someone had lost a day of productivity because of someone else’s changes to the mainline. Not a good way to wrap up the day.
I went over to understand the problem. This developer had “had it” with trying to get their code to work after merging in the mainline that morning and was clearly frustrated. We were eventually able to reset and focus on the problem and let go of complaining or grumbling.
We discovered that there had been a change to a maven plugin to enforce higher code coverage that was causing another plugin to not run on a certain profile. Essentially, we had a profile for our standard lifecycle (compiling, testing, etc.) and one for doing a black-box performance test. The code coverage plugin and the performance test plugin were on the same lifecycle, however. This created a problem where we were skipping all of the unit and integration tests on our performance profile, but the code coverage check would fail since we had 0% coverage according to the profile.
We realized we could simply set an already exposed configuration property for the plugin or we could change the phases for another one. We agreed that we both thought that setting the property was the best approach. We conferred with another team member and decided to give it that approach a try. We walked away thinking things would be fine.
A while later, I get another Slack message: “I still don’t know what to do”.
Turns out this colleague didn’t fully understand the maven lifecycle and what we meant by phases and how our profiles were structured. We eventually got it figured out, but I was surprised by how long this took.
We All Have Different Prior Knowledge
The lesson is that we have to work on both sides of the conversation to find common-ground for communicating about a problem. We can’t adopt vernacular from a tool right off of the bat with our all of our team members and expect them follow along. We have to work to be non-offensive in asking about someone’s knowledge of a concept, tool, or technology. And we have to not be offended when someone asks us the same.
It’s a delicate balance to be sure. Asking someone if they know what you mean likely won’t be the best way to start. Using phrases like “Are you keeping up?” or “Do you not know how to do this?” isn’t helpful either.
Questions Over Statements
We want to ask questions that allow our team members to state their knowledge rather than respond to our assumptions.
Some helpful questions might be:
- How much have you used this tool before?
- Out of curiosity, how much do you know about this idea?
- How comfortable are you with this technology?
- What is it you don’t feel comfortable with about this idea?
After that, you also need to continue asking more and more of these questions to get to specific things between your understanding and theirs. It might take some time. In the long run though, it will save you hours of confusion and thinking you are all on the same page.
At the end of all of this, we all need to be more comfortable not understanding. We need to ask questions to our teams rather than Google. We need to not be offended if someone assumes we don’t know something when we do — and not offended when they assume we do as well.