As a parent who is interested in psychology, I find childhood development fascinating. If you take a box of crayons and fill it with candy in front of a young child, they will correctly be able to tell you that the box contains candy. When you ask that same child what their sibling in another room will think is in the box, they will still answer candy.
Every other Friday, the TriumphPay engineering team has a game hour. We pick a game, and a group of folks get together to play. This last week we played Code Names. If you haven’t played, it’s both fun and simple. Two teams play against each other. Each team is made up of a spymaster and one or more operatives. The goal is for the spymaster to give a one-word clue and a number of tiles to allow their team to guess which words belong to them. Here’s a sample board:
If I were the red spy master, I might give a clue like “Hospital 2” hoping my team would guess “Nurse” and “Stethoscope”. When I look at this board, those two seem like obvious answers. Of course, I’m saying that with full knowledge of the board. I’m like the kid who saw that the crayon box contained candy. On the other hand, my team sees the same board without any color coding. They are the kid that just sees a crayon box. Without the private knowledge of the red words, I might wonder if “Death” is one of the words based upon the given clue. Suddenly, I’ve become the little kid with the crayon box. I guess it’s not just kids who have this problem.
If this only impacted boxes of crayons and games, I wouldn’t be writing this article. This knowledge gap has a big impact in the world of software. When I try to explain my design of a feature to another developer, my deep knowledge of the work I’ve done means we aren’t seeing the same thing. My perception of the world is colored by my knowledge which causes me to skip over important details in my explanation. We also see this when talking to end users. When I ask them to show me their process for solving a certain problem, it’s common for users to omit talking about critical steps because they are obvious to the user. That becomes a big problem when my automation of this work neglects the unspoken but critical detail.
So how do we improve? For kids, time will help. As kids get older, they start to learn about private knowledge and will realize that only people who saw that the crayon box had candy in it will know the true content. For adults, we have a much harder road. Still, we can get better at communicating this kind of knowledge if we practice.
My favorite method of figuring out what important hidden knowledge I hold is to try to teach a concept to somebody. I’ve found when I start teaching a concept it becomes easy to notice when I’ve skipped some private knowledge. Either the learner will look confused or, if I’m lucky, they will ask what appears to be a simple question. This feedback gives me the opportunity to think about what important bit of information I failed to share.
When communicating asynchronously, this is much harder. Without the interpersonal cues that a person is confused, it’s possible that two people will talk past each other. For this reason, I often will ask folks to write back what they heard from a message. This mirroring allows me to understand whether I’ve left any important concepts out.
Another method for better making private knowledge public is to spend time with a beginner mindset. The more time I spend being a beginner at things, the better able I am to empathize with others. As an expert, one of my biggest fears is sounding condescending. As a beginner, however, I rarely feel offended when somebody over explains a concept. This time spent as a beginner helps me triangulate on the right level of detail to communicate.
I’d love to hear from others about their experience. When has unstated private knowledge tripped you up? I’ve love to hear your experiences at mmangino@triumphpay.com. In the meantime, I hope you can enjoy a crayon box filled with candy and a great game of Code Names.
