On Others Asking For Help
I think I underestimate the general fear that people have of being wrong, looking dumb, or something like that. I pretty much don’t get it.
I work primarily with engineers, and at FAANGs there seems to be a palpable fear of being wrong that prevents people from simply clarifying, or exposing something that is incomplete. Instead they hold back hide from the ambiguity and avoid any chance that they lose face. Unfortunately, there are many obvious (at least to me) drawbacks that I don’t seem to be able to communicate.
I was working with an engineer recently, and there was clearly some ambiguity in what they had been asked to do, and what the outcome was going to be. However, an unhealthy behavior had emerged and it was almost impossible to work out how to break out of it.
- As an engineer, it’s hard for people to know that you are doing something if they don’t see it. So if you write code, be super liberal with sharing your code [#1].
- Requirements are hard, you don’t know all the requirements until you are in the middle of the code and you spot an ambiguity. When that happens, you communicate and clarify[#2].
- When you don’t understand the way the system works, you determine a theory of operation and test your theory. If your theory of operation doesn’t work, then you ask and clarify.[#3]
- When you don’t understand how a external system or component works, create a theory of operation and test your theory. If it doesn’t work as expected, then you ask and clarify.[#4]
I find it completely confounding that the simple task of asking for clarification (#2, #3, #4) is so scary. There is a reasonable amount of research that indicates that active recall cements understanding very well. Further, small emotional pain (ie: being wrong) actually helps rewrite the memories faster. So being wrong, isn’t bad, or wrong. It’s actually an effective way to learn.
Now with code, if you don’t put code up for review, you can’t get feedback. Mark it as WIP or incomplete. There is no point hiding it. Everyone craps the same way. It’s ugly, it’s messy, and it’s completely normal. Given that code is not a biological function, what’s the worst thing that is going to happen? People are going to say that your early code is messy. You aren’t saying it’s complete, so why hide it. If it’s an unpubslished review, no one really cares about it. But you can at least ask questions about it. If it’s only on your system, there is no value in you keeping it only to yourself.
Now when you are pushing code out, if you get stuck with #2, #3, or #4, then you’ve got a set of options…
- Make a call, and implement it. You have a reasonable chance of being wrong. But that’s okay.
- Work out how to test your assumptions, and try them out.
- Where you need to make a decision, decide, capture, and communicate.
- If you’ve made a decision as it impacts code, tag it as being an ambiguity and move forwards.
When you put a code review up. Capture where you’ve made a design decision. Make it clear that you did the coin toss, and made a decision, but also accept that it is wrong. Better yet, when you hit that ambiguity, ask and move forward. If your judgement is right, then you will not lose time. If you are wrong, you’ve got minimal sunk cost.
Just ask, just clarify. You can be wrong.