Following the method of the previous chapter, the analysis of bugs can always make progress. However, there are always times when ideas run out, and the help of others is especially important at this time.
As a FAE, I often help others to solve bugs. I found that many people can't communicate, and they can't understand what happened after talking for a long time. Today, I will talk about communication skills when looking for help.
-1- Describe the bug clearly
Just change the written language in the previous chapter " Analyzing BUG (2) " into spoken language. I won't go into details here.
-2- Don't mislead others
When we describe bugs to others, we must base them on facts and do not make any deletions, otherwise we will lead other people's ideas to your own. Your own way of thinking can no longer solve the bug, and others can't solve it by thinking according to your way of thinking. I often get calls from clients like this, and before I can figure out what's going on, the client starts his tirade. If it wasn't for my experience, I stopped the customer in time, or I would definitely be led into the ditch by his ideas. Often the more this is the case, the final cause of the bug must be different from the customer's thinking. Because such a customer has a certain analytical ability, and has a certain amount of work patience to analyze it carefully, if he does not find a clue under his operation, then there is a high probability that his thinking is in the wrong direction. (Notice no, this is an example using probability analysis). We seek help from others in order to have different ideas and must not mislead others.
-3- We are here to fix bugs, not to convince others
As a tech support, someone often tries to convince me of his point of view. Some engineers feel that their code is fine, and their hardware is fine. If a bug occurs, then there is a problem with your supplier's chip. Then find various reasons to explain that it is a problem with your chip.
This becomes persuading others.
"I have checked the configuration here, it must be fine, is there a bug in your chip?"
I have heard this many times, and every time I encounter this situation, it turns out that their own code is wrong, not our chip.
Some people want to dump the blame and throw bugs to us, and in some cases, it is the characteristics of the engineer's personal habits and personality. There are not many of them, but every company has a few. When we seek help from others, we are not persuading them to agree with your ideas, let alone getting them to agree with your emotions, so as to gain comfort. We are there to solve problems, to get a different perspective on the problem. Even if you feel that the other party's perspective is wrong, you must look for evidence based on the actual situation.
On the road of DEBUG, anything can happen, and the real world is so weird, so we must rely on facts. Open your mind to get the clues you want.
Today, this chapter made a little grumbling, so here we go.
If you like it, please like, "watching" and follow it
Welcome to share, let more people discover "the eighth brother"