What is JSON? Assumptions and "basic knowledge"

In consultanting, I'm constantly interacting with people from very different technical backgrounds. Sometimes it's a PHD with more understanding of distributed systems theory than I could hope to have, sometimes it's a non-technical C-suite executive, sometimes it's a 30-year veteran that at some point found themselves stuck in a certain era of technology.

As a result, I've found that assumptions about what "basic knowledge" is can be detrimental to group understanding and communication. Even something as familiar to me as JSON, which has been the standard for API/front-end communication since I started in the field, can be a foreign concept to many. Feigning surprise, a term I first read in the Recurse Center's excellent manual, may be a common reaction, but it's certainly not productive or helpful. Instead, aligning with the person you're talking to and discussing pros and cons in an unopinionated way has worked wonders for me. Instead of pushing an opinion ("JSON is better, what the heck are you doing with XML still?!"), you simply present facts and let the discussion go from there. Not only does it give someone the space to digest, play with, and figure out how the new information fits into their existing understanding, but it also keeps communication open and many times unspoken business requirements come to the surface.

So if you're not familiar with JSON yet and are interested in getting your bearing on what it is and when you should use it, check out this write-up I recently did for InfoWorld.

What assumptions have led you down the wrong path with others in the past? How has putting those assumptions aside helped? Share with us on Twitter: @spantreellc

References:

• Huge thanks to Julia Evans for posting about "No Feigning Surprise", which led me to the Recurse Center's manual in the first place.