When you know too much to be helpful
Earlier this week, I talked to a lawyer about my upcoming venture. I went into the call with questions about legal structures, liabilities, and due dates. They were doing their best to answer those questions for me. Unfortunately, it didn’t always work.
Many of these topics are new to me. Going into something of this size, I want to avoid as many expensive mistakes as I can. During our conversation, the topic of employment contracts came up. In the legal structure I am going for, I will hold different roles at the same time. I will be both the majority shareholder and the managing director of this company. Those are two different positions with different responsibilities.
That means that I will sign an employment contract with myself. Yupp, I am hiring me to do a job for me, signing the contract as both the employer and the employee.
When I asked him what had to go into such an employment contract, he replied with:
“Only the usual information you’d put into any employment contract.”
That… that’s not helpful. Having never written an employment contract, “the usual information“ means nothing to me. Now there I was, feeling stupid because I don’t know how to write employment contracts. Not a great feeling.
It is easy to see where they were coming from with their response. For them, writing and reviewing employment contracts is a weekly, if not daily task. They were too familiar with what they do every day that they did not consider their audience. They had no idea their reply wouldn’t help me, because they don’t remember what it’s like to not know this information.
The same happens to us when we get good at something. I remember the confused looks on my colleagues’ faces when I told them to “pass a callback to the function”. Or when I asked them to “dispatch an action in the event handler so the reducer can update the store”. Those things seem reasonable when you have done them hundreds of times. Someone that never even heard some of these words will not know what they mean.
No matter what field you are in, chances are you have picked up the language experts speak. That can be a hindrance when trying to explain something to someone. To be helpful, you have to start by finding out where the other person is at. Will your industry’s terms, like callback and reducer, be obvious to them? If not, dial back your explanation and try again from there.
This doesn’t mean you need to dumb everything down. Explaining something to beginners does not mean treating them like idiots. It means taking them by the hand and bringing them up to where you are. If that means you need to go over the basics first, do that. You can’t be helpful to others if you don’t pick them up where they are at.
Clever code isn’t always the most readable. Especially when working in teams, readability has to come first.
Job interviews are tests for both sides. Use them to figure out if the company you are applying to is a place you really want to work at.
Annoyed with how browsers log variables to the console? We can access and do more useful things with them.