Professional techsplaining

Professional techsplaining

Riding a bicycle is easy once you know how to do it. Once you’ve internalised a skill, it’s almost effortless to apply it.

Working in tech is like that.

Through the course of our careers, we pick up new things, grapple with them and add them to our backpack. Once we understand how REST services work, we can apply them to different problems. They’ve become easy now.

Experienced techies understand complex matters and handle them with ease. For the less experienced or the self-proclaimed non-technical people, this can be intimidating.

There are often situations where we’ll need to discuss technical complexities with people who do not have them in their backpack.

Discussing an asynchronous system with someone from HR. Explaining GraphQL to a database engineer. Talking about unit testing with a junior developer.

The more experienced we get, the more we need to work on finetuning those conversations. There are plenty of wrong ways to do this and unfortunately, they seem to be popular in our industry.

“If they don’t understand database transactions, they why are they in the meeting?”

“Machine Learning isn’t that difficult. It’s a little bit of math. Just try to master these 3 frameworks.”

“If they don’t understand, they’ll ask.”

On the other side of the conversation are people who don’t want to feel like an idiot. Not understanding a technological component can feel like a professional shortcoming, especially in tech. They are not likely to interrupt and ask “dumb” questions. In fact: they’ll never ask anything again.

If we want to bridge the gap in knowledge, it’s up to us to accommodate our partners.

Gauging someone’s technical understanding is tricky. It can be a minefield.

Aim too low, and you risk coming across as condescending. You’ll make them feel disrespected.

Aim too high and you’ll intimidate them. They will try to save face and not ask questions.

If we are going to explain, we should act as a host and make our guest feel as comfortable and welcome as possible. We should aim low, but make our assumptions explicit.

“I don’t know how much you know about Kubernetes, so interrupt me if it’s too obvious…”

“Dependency injection can take time to wrap your head around, so don’t worry if it’s still unclear. It’s not straightforward.”

Doors open when people feel comfortable around you. They’ll ask “dumb” questions that turn out to be vital information. They’ll ping pong their ideas off you and you’ll both learn.

When I started my coding career, junior devs would ask questions and they would get a list of reading recommendations in return. That was unsupportive in a time when tech was confined to the IT department.

These days, software is everywhere. RTFM is just unprofessional.