Growth & Cognition by Yuan Wufan
This is the 27th original article for Pointers
Many of my readers would assume that people at my level are very thoughtful and decisive.
I will make a rational and correct decision based on the truth of the matter.
But the truth is that almost no one, not even me, makes every decision rationally and correctly.
Our brains actually make a lot of decisions for us without you even knowing it.
These decisions are based on imperfect information and our mood at the time and ignore key facts.
Our brain is not software. When a bug occurs, we can debug it and find the wrong code.
But our brains have bugs all the time, and one of the most common bugs is cognitive bias.
There are many kinds of cognitive biases, and Wikipedia lists about 90 common cognitive biases.
Below I’ll show you the most common errors in the programmer community, “code,” from the perspective of cognitive bias.
To give you a better understanding of how these biases affect our thinking and actions.
About the author:
Dachang technical director, share years of personal experience and experience in career development, technical management, career promotion, technical growth, etc. Grow together!
Pandownload is also available at 60M/S download speed.
Add my wechat PointersSS, pull you into the group, and communicate with the group leaders, technical managers, technical directors, CTO.
1
mind-set
I’ll give you two examples.
A,
In the mid-19th century, gold was discovered in California. Many saw it as a once-in-a-lifetime opportunity to make a fortune, and many unfortunate prospectors were tortured to death instead of becoming rich. There was a man named Merkle who made thousands of dollars selling water in a very short period of time, which was quite a fortune in those days.
Second,
The second and third floors of our company building are cafeterias. The elevator entrance wuyang Wuyang is full of people, waiting for the elevator, like crowded Tokyo subway, middle-aged fat man like me is unable to squeeze on. So I thought of a way, the stairs to the first floor, obviously feel a lot less, only a few sporadic people, and then it is very easy to take the elevator.
Thus, when we are struggling to solve the problem, in fact, as long as a little change of thinking, the problem is easily solved.
In the process of project development, I often hear programmers give me feedback that the design should be based on the understanding of requirements and the specification given by the leader should be like this.
In the process of work, the programmer is very easy to be limited by such or such requirements, and over time, it forms a thinking pattern, which is difficult to break through once formed. The firm instinct believes that it will not be wrong to complete according to the requirements, but it is not necessarily right or the best and most efficient.
Because your leadership will be limited by their own thinking, of the request is a relatively ideal but was never going to be the most ideal, which is why all companies to ask chang innovation, want to innovation is the most ideal state, we need to each program apes in the work constantly thinking, constantly breakthroughs, constantly sharing, constantly revising rules and requirements, So that you can innovate and become more efficient, and at the same time, you can gain a sense of fulfillment and value outside of work through the process of constant change.
Take myself as an example.
In 2015, I left my old club and came to Haikang.
In the first month, I was generally familiar with the team atmosphere, company system and culture, but I found that the compatibility and expansibility in the code were poor, and the coupling was particularly large. I forced myself to come to the company very early every morning and leave work at 11 or 12 o ‘clock in the evening. I produced a software architecture solution within a month and handed it to the leader.
In the end, there were still some loopholes in the scheme, but there were no major problems. In the second year, I gradually switched to the architecture I designed
The original software architecture has been a big problem, why did it take me to complete the reconstruction?
You may say that other people are less capable than you are and that they have less power than they want.
But I think the biggest problem is stereotypes. Everyone on the team was so used to the code that they only thought about how to make their new code fit the current architecture, not how to redesign the architecture.
2
biased
Highly unlikely coincidences happen every day.
Let’s take 2020 as an example. From the outbreak at the beginning of this year to the downward pressure on the global economy, we have all witnessed history.
While this outbreak may be the worst in human history, such events are certainly not uncommon when viewed on the timeline of life on Earth.
We feel abnormal because none of these disasters ever happened in our memory or in our parents’ memory (or even grandparents’ memory). But that doesn’t mean they won’t happen, nor does it prevent them from happening several times in a row at once.
I’ll give you a number.
Americans are about one in six million likely to be killed by lightning each year. That may sound like a small number, but dozens of people are still killed by lightning.
I’ll give you one more statistic.
Americans die from falling beds about one in 400,000 times a year. That seems like a pretty small number, and you might not think it’s dangerous. It’s rare, but every year, hundreds of people die from falling beds.
All of these things are a warning to every programmer not to take things that are not observed, or extremely unlikely, as impossible.
Any detail you ignore could cause your software to crash at some point in the future.
As you design your code, think about what you might have missed, what you might not have thought of. Take the time to review “impossible” outliers or “highly unlikely” cases.
If they do happen, you’ll spend 10 times or even 100 times as much time and energy trying to solve them.
So, remember: little doesn’t mean nothing.
3
Need to clear
For TV dramas with no ending, detective movies without finding the real killer.
How do you feel about that? Is it very uncomfortable?
It’s a strong signal from our brains that we’re uncomfortable with doubt and uncertainty.
We will do our best to resolve the unresolved issues and come to a conclusion.
But have you ever thought that uncertainty can also be a good thing: keeping your options open.
Forcing premature conclusions forces you to give up your options and make mistakes.
Let me give you an example.
When your boss gives you a new requirement, and you give it a development deadline on simple thought, that’s a big mistake.
You gave the deadline hastily without rigorous evaluation and without considering the uncertainty of the project, which is actually a kind of self-cover-up, and ultimately you will be in bad luck.
What should you do? You can tell your manager that I will estimate the amount of work required in half a day and then tell you the development time for each detail.
This behavior is not more justified.
So we need to get used to uncertainty.
In project development, there are so many uncertainties that we don’t know when the project will end. I wonder if there are any difficult bugs that cannot be solved for the time being. There are too many uncertainties to interfere with the project.
With the progress of the project, the answers to these uncertainties were finally found and slowly moved towards certainty.
Can’t we do something about it?
Of course, there are steps we can take to reduce this uncertainty.
For example, we can design and demonstrate requirements in detail. You can outline your code rigorously, and so on.
Although measures are more or less effective, they are always missed and cannot be considered comprehensively. Of course, they cannot cure the problem.
This is not a bad thing, this process from uncertainty to certainty, it’s a process of exploring things, it’s a process of growing.
The most important thing is to get your mind right and not rush.
4
Fundamental attribution error
This actually involves the concept of psychology, cut from baidu Encyclopedia.
Fundamental attribution misdescribes the dual tendency of people to overestimate tendentious factors (blame or praise others) and underestimate situational factors (blame or praise the environment) when examining the causes of certain actions or consequences.
What do you mean?
Is that people tend to attribute the actions of others to their personalities, regardless of the context in which the actions occurred.
For example, miss A is usually lively, cheerful and extroverted. If someone tells you that she drank too much at A party, she lost her poise.
You think it’s possible, you even believe it happened.
You wouldn’t believe someone who told you she was shy and reserved when meeting clients, her hands shaking as she poured water.
You would think that an extrovert wouldn’t be suddenly introverted or particularly nervous.
You naturally think that extroverts do extroverted things and introverts do introverted things, which is a bias, but it’s not true.
Here’s an even simpler example: People generally assume that people with good faces are good, and people with bad faces are bad.
In life, we often judge people by their appearance, which is also due to the error of attribution.
In general, there are three kinds of fundamental attribution bias.
One is internal attribution, which is when something happens, the person points all the blame at himself.
External attribution is when something happens, the person is used to summarizing the factors that happen as external factors.
Synthetic attribution is something that happens and the person evaluates it both internally and externally.
So some people think they are never wrong, which means they are habitual external attributions, for example, they don’t get promoted or stay in the same place, they will blame themselves because they have no connections and no background, so they can’t get promoted.
However, people with internal attributions tend to point the factors at themselves. For example, if they are not promoted, they will think that all the problems happen to them because they do not work hard enough and have a good interpersonal relationship, so they cannot get promoted.
In general, people who are used to external attributions tend to complain and become angry;
People who are used to internal attributions tend to be harder on themselves and end up putting a lot of pressure on themselves.
Therefore, if we want to look at something most objectively, we must learn to combine internal and external attributions. Only by adopting comprehensive attribution can we get more accurate information, and also can we better help ourselves grow up and acquire more three-dimensional information.
5
Selfish prejudice
In project development, you have not encountered this situation.
Some of the more skilled programmers will use technology implementations that are relatively difficult to understand, or syntactic new features, or new libraries.
Often features developed using these techniques can be logically implemented only by the author, and are difficult or even incomprehensible to other members of the team.
This development creates technical barriers so that no one else can get into the business, and as the business grows, the barriers get higher and higher.
This kind of technical barrier can guarantee your position in the project, but it is selfish.
Once there’s a bug in the business, even if you’re busy, you can’t get rid of it.
Because no one understands, only you to solve, no one else can help you.
If the business is constantly changing, you can imagine how painful it will be.
Even more damaging is that this selfish behavior is holding you back professionally, because technological barriers prevent you from getting out as well as others from getting in.
Because you can’t get away from this barrier, many opportunities will be given to others, and you will only become the most familiar programmer in the business over time.
I’ve interviewed a lot of programmers who have been working for 5 years or so. They’ve been in the same business for a long time, but their technical skills are average.
Why is that?
Because they know their business, too comfortable, comfortable in their own business to be a warm frog.
The last jump, showing his true colors, no competitiveness.
In the final analysis is responsible for their own business set up business barriers, but it is selfish.
If a new friend asks you a business code, will you be patient and explain it clearly to him or her and make him fully understand? If not, you are building your own business barriers.
If you do, please stop immediately and discard your selfishness.
You need to share your skills and business experience with peers and subordinates without reserve. So they can grow and even surpass you.
When there is a new requirement or a bug, your colleagues can help you share it and work together as a team. You also have more time to learn new technology and improve yourself.
Another kind of people, if the project is successful, the biggest function is his, has always stressed that their contribution to the project is great, but was wronged by the leader. And once the project fails, pass the buck, all the failure has nothing to do with him.
This behavior, as a personal defense mechanism, is also a selfish bias.
Remember that regardless of failure, all members of the team bear the burden.
Finally, since the choice to be a programmer this path, selfish psychology should be discarded. This will take you further.
I’m Yuan Wufan, a career mentor for programmers. My wechat id is “Pointers”.
If you have any questions, please contact me on wechat: “PointersSS” has limited slots on a first-come-first-served basis.
Recommended reading (dry)
7 years, from “game boy” to dachang technical director of the reverse road
Three leaps for programmers to become senior managers
7 years summary of technical director, how to communicate correctly?
7 years of experience. From software development, senior software development, technical manager to technical director, share personal experience and experience in career development, technical management, career promotion and technical growth. Grow together!
Pay attention to me ↓↓, help you answer your questions!