When I moved from the United Kingdom to the U.S. several years ago, there were many new laws, rules, and cultural differences for me to take in and learn. What were school buses and what were you supposed to do when they stopped? Why were my bug reports of “colour spelt incorrectly” being rejected? Why do I need snow tires? (My first Michigan winter taught me why on that last one.)
I gradually learned all of these but still had things that would trip me up. A recent example was, what is this “ope” that people use in Slack? (For readers not in/from the Midwest “Ope is an interjection somewhere between “oops” and “uh-oh” used to express surprise or apology.”)
An employee handbook or manual isn’t going to tell you this. It might tell you the expected working hours and how and where to log these hours, but it won’t tell you what it means when your co-workers say “ope.”
And (for U.S. readers), think back. When and how did you learn what to do when encountering a school bus on the road? It will be a law written down somewhere, but did you learn it by reading about it, were you tested on it, or was it something you just picked up along the way?
These differences can be referred to as tacit and explicit knowledge.
Tacit knowledge
This is knowledge that is personal and difficult to articulate. It is gained through experience, interactions, and observations. It includes skills, intuitions, perceptions, and cultural understandings
Explicit knowledge
This is knowledge that can be easily codified, documented, and shared. Being aware of these differences can help you in your day-to-day job.
Explaining your job
For example, when trying to explain how you are testing an app, there will be explicit tests where you are testing against requirements. That might look like this: “Check that when you enter 2+2 you get the answer 4.”
There’s also tacit knowledge.
“Test what happens when you enter 99e99 as one of the values,” since you have experience of apps crashing if they treat the ‘e’ as an exponent.
Testing Requirements
It’s important to check with the client that the app meets not only their explicit requirements but the tacit ones as well. What things just happen because it’s a Tuesday? Or December?
Is there some workaround in the system that’s unwritten but everyone knows it? “We set that as J99 and the other system knows how to deal with that.” Or, “Oh, yeah. For the customer we always…”
Working with a team
When working with a team, what are the unwritten guidelines for working with them? Are they “midwestern nice” and so you need to tone down your British sarcasm? Giving the team this handy guide could be an explicit way instead of relying on tacit knowledge so they can understand me better.
Being aware of these differences can help things from going Pete Tong. (That’s Cockney rhyming slang for “wrong.”)
Have you come across any “ope” or Pete Tong or school bus moments? Let me know in the comments.