Well, don't get me wrong. This is not my advice. I am not a "good" software technician for the moment.
Yes. Over the past few days, I have come from the United States with a few experienced colleagues. Because the Chinese team is relatively young, I have arranged a "Open Forum" seminar, let them share their growth experience with Chinese colleagues. One of them is Chinese, and they graduated from Tsinghua University and went to the United States with 10 years of work experience. The other is American and has 20 years of work experience.
One person asked a question: "What do you think is the most important thing to become a senior and excellent technician ?" These two students have basically agreed on the following points:
-
- Don't treat the code you not own as blackbox
Written by everyoneCodeIt involves more than just the modules you are responsible for. You often need to consider the problem at the system level: How do the modules on which I am dependent work, how can we use them correctly? How to use them efficiently? And who depends on me, what impact will my changes have on subsequent modules, and so on. It sounds simple, but it is not that easy to do. Especially in a large system with hundreds of modules. Many people directly send a mail to ask the owner or expert of the module, which is indeed "efficient", but if you need to work in this system for a long time, you need to be familiar with these modules frequently. The most "efficient" way is to study these modules and find out their composition and working methods. Do not think that this has nothing to do with me, you can ignore it, think of it as a "blackbox", in fact, inProgramAs long as you want, everything is "whitebox", and no program has any magic, just something that combines the simplest rules and logic.
The most important thing is that only in this way can you make progress and gradually become an expert in a certain field. Otherwise, as you have noticed, some people asked him how the entire system was working after N years of practice, and he could not say anything ugly.
- Don't assume, just confirm
Let's assume that you are killed, killed yourself, or killed others. Here are two examples:
1. during program debugging, we often make self-righteous assumptions: The registry should be okay, And the DLL data initialization will not go wrong. Will it be a message passing error? It does not seem like ~~~. We have been thinking, but we do not want to prove it. This so-called thinking is assumptions, and then the farther we go under the wrong assumptions. This is killing yourself.
2. as the authority of a certain field, people send a mail to ask you a question. You are not sure, so I replied, "I think" should be like this, or it should be like that, then they tried it for a day as you "felt", but they couldn't. Then they told you that they didn't work, and then you "felt" again, and then wasted a day on Earth. This is killing others.
In fact, why do you want to make these assumptions? You can just stop and spend five or ten minutes to confirm it. That's nothing? Step by step is the true way forward, depending on those cloud-like assumptions, you are always shaking. In addition, it is this confirmation that constitutes your real experience. Otherwise, after a few years, you only haveYour own assumptionsAndWhat people tell you.
In fact, the key to not doing this is to be lazy: Too lazy to study, too lazy to confirm. Therefore, it is hard work to become a good technician!
