Analysis on the survival of new programmers in the workplace

This is actually a letter sent to me by a reader in the book "0 bug -- C/C ++ commercial engineering path". This reader is already a technical backbone in the company, having strong practical experience, I started to bring new people. Then, when I encountered some problems, I came to consult with you.

I thought it would be better to reply to him directly, but I thought it would be better to make a public reply, because I felt that his questions were representative. In fact, it brings out a very sensitive topic: "What should I do after a new employee joins the company ?"

Well, let's take a look at the original text and analyze it again. Let's say that. You are welcome to make a brick.

Original article:

I read the sample chapter on chinapub. Although there is no classic-style code (laugh, it is definitely not a joke), I will buy a book to recommend it to new students for reading, after all, the thickness of CC is scary.
In addition to expressing admiration, I also asked non-technical questions.
I am a cainiao in the industry and have been in the industry for more than a year. Currently, the company that works for has opened up a new field, and the old business needs to be maintained. As a result, many people have been recruited, so I became the first employee of this group, the main task is to maintain old products.
After six months of destruction, I finally realized that writing a program is actually dealing with people, and I can also make some suggestions to influence the decisions of the technical director, although he often said that his design is too cool =. =, For example, I always advocate that we should try to use the compiler to constrain the users of the Code (or the features of the Code itself), as long as it is unexpected (dislike) the calling method (or a feature) is the best for compiling and prevents code contamination.
From time to time, I will pay attention to the Code in the hands of New and Old students, and consider how to refactor and sort out the development library.
It doesn't matter if you don't look at it. It's depressing when you look at it. I am a lazy person. When I see someone making a wrong decision, I may feel anxious when I make a mistake. Once anxious, it will become cruel t_t
A typical example is that Mr. A, who has been in service for six months, is now holding one of the main modules (this module has never been officially delivered to me for maintenance, but this module has produced a serious bug, I have participated in debugging ).
Test in the new platform and find that some seemingly unrelated calls after a handle is disabled fail due to platform differences. Therefore, Mr. A opened the handle before these calls, wrote about 100 lines of code, and introduced a non-serious bug.
After discovering the bug, we recommend that you check it again (then test it). After one day, the bug remains. So I pointed out the bug and suggested that we should not solve the bug directly in this way. Instead, we should first consider it. At this time, a handle is closed, so it is designed? Or an implicit bug? And whether the principle of triggering this bug is completely clarified.
After two days, let's take a look at the changes. After another discussion, Mr. A indicates that the bug has been fixed and there is no problem, however, the mechanism of the Bug still cannot be clearly expressed (I don't know if John understands it ). In fact, this issue is an implicit bug. Those calls should be executed before handle is disabled.
What Will Old Xiao do at this time?
My approach is to directly find my opinion from the technical director, and then invite a senior Maintainer of the previous generation to confirm my opinion and delete the 100 lines of code, adjusted the time To disable handle.
Afterwards, I thought about whether my handling method was too rough. Should I try a more direct way to communicate with Mr. A first, not just suggestions. However, I feel that the more direct method is not necessarily effective if I still haven't changed my suggestions. Rather than worrying myself, it would be better to be confused. If I was busy with other things and forgot to ask, wouldn't I have another time bomb.
After introspection, I felt that the status was not right. I 'd like to hear from Lao Xiao.

My answer:

Hello, this friend. I have read your letter carefully and thought about it for about a week. It is really hard to answer. I can only try my best. If the answer is poor, please forgive me.

Let's take a look at it first. Let's just say that there is a foreshadowing, so I can breathe a sigh of relief.

"For example, I always advocate that we should try to use the compiler to constrain the users of the Code (or the features of the Code itself), as long as it is unexpected (dislike) the calling method (or a feature) is the best for compiling and prevents code contamination."

This sentence makes it clear that I think you are right and should carry forward. We know that it is a little difficult to implement a zero-bug program. The main reason is that we programmers are human, and people may make mistakes, have an inertial mindset, and have misunderstandings, or it is simply because the problem is not comprehensive, and a piece of information is missing during design, which may lead to bugs.

In fact, anyone with development experience should know that bugs are not difficult. As long as bugs are found, programmers will always have a way to revise them. What is difficult is Bug search and locating. We have worked overtime countless times due to bugs, in fact, more are looking for bugs, rather than modifying bugs.

In my book "0bug-the path to C/C ++ commercial engineering", I proposed a non-error-free programming method. In fact, it is mainly to solve this problem. First of all, my tone is that I don't trust people, including myself, because I am also a person. Therefore, I emphasize the programming norms in my book, the program is easy to understand, and the variable conversion and multi-definition are strictly prohibited. Not only do I prevent bugs in my mind, but I am also talking about methods and habits. That is to say, it is a lot of practical, with a specification, with a habit to solve a whole aspect of the bug.

For example, if (I = 0) on the left side of a judgment statement, if the if (I = 0) expression is always false, it is wrong. However, if we develop the habit of writing constants to the left, we always write if (0 = I). When we write less =, the compiler immediately reports an error, because constants cannot be assigned values in syntax. There are many other examples. My memory pool registration mechanism is to use the program itself to count the usage of pointer variables. Once the pointer is found to have not been released, an alarm is triggered immediately to prevent memory leakage.

Note that none of these specifications, methods, and habits, I tried my best to draw closer to the syntax conventions of C, or the Error Boundary of the compiler, in an attempt to make errors compile at the first time, when the program is run for the first time, it is reported and helps the programmer locate the error. Is this bug terrible?

Also, I emphasize in my book that the Hungarian naming method is like that it has a strict Convention. When a member variable is changed to a global variable, the variable must be renamed according to the naming requirements, changed from m_xxx to g_xxx. With this change, the compiler will find a bunch of call errors. So, is it helping us? Check every call point carefully. Let's determine whether this change will change the scope of the variable, is it reasonable and there is no hidden danger.

Therefore, I would like to give a clear note to young friends. Please use the compiler as much as possible. It is much more accurate than finding a bug. A good program does not have any bugs when it is written. Instead, it compiles a lot of bugs for the first time. Then, we modify it. When it is changed to the compiler, there will be no bugs in our program, in my opinion, this is the ideal zero-bug program. At the same time, this programmer can be called a zero-bug programmer.

Okay. Now let's discuss the second question.

The second problem is that, after reading the obvious bug in the code of small A, you are a little anxious and the communication effect is poor. Although small A has changed, but it is not changed to the root node, and the bug remains. I told you that you cannot do this.

Why are you not talking about small a? The reason is simple: you are better than him. We used to bring our team with the same principle. If a Team commits the same mistake, a young employee or a newly hired employee will not only give me a few complaints, but also give me some comfort. Senior Personnel will scold us, in particular, the higher the level, the more malicious the hacker and the more fierce the ox, because there is a principle, "qualification = responsibility ".

For example, in the railway station waiting room, a person suffers a heart attack, and everyone has nothing to do with it. Only one person is a doctor, but he has not shot yet. This person finally died. Think about it, do you scold everyone or the doctor? It must be a doctor, because he has the ability and qualifications to cure the disease, but if he fails to cure the disease, he is not responsible. Others are not responsible because they do not understand it.

Therefore, although I am not very clear about your company's administrative position, you have a responsibility as long as you come one day earlier than him.

Of course, it doesn't mean how many mistakes you have made in this case. However, I personally suggest you improve your communication methods. Generally, we have a principle in doing things: "a major problem, meeting now ".

You must know that employees at any level in the company have the right to have a meeting. The meeting is not complicated. It is not to say that only the supervisor can have a meeting. Even if a younger brother has been hired for one day and finds a problem, the method I teach them is to contact me first and discuss it. Once the problem is found to be serious, a meeting is usually held immediately. I am responsible for inviting a supervisor with a higher position than me to participate together.

The purpose of the meeting is not to remind everyone that we have a problem and an important issue. If we do not solve it, it will affect many of the subsequent work. Therefore, this is an important event. Please be aware of it. In addition, we should discuss how to do this and also commend new employees. This discovery has helped us prevent bugs and save costs.

Therefore, I think your second question is actually a matter of meeting. You can ask your supervisor or manager to hold a seminar to solve the root cause of the problem, make an analysis and conclusion, come up with the correct solution, and then entrust this small A to implement it.

As in your example, the root cause of this problem is that Mr. A did not understand the original intent of the program design and opened a closed handle, resulting in a new bug. So, during the meeting, naturally, you can find out why handle was originally designed to be closed, and how it went. If it was to be reused, how should it be done? In fact, it should be difficult to spread it out at the meeting, now that I understand the ins and outs and the principles, I think that the implementation of small A should have no more bugs.

The adoption of the form of meetings has many advantages. People are all faces. When a person does things on his own, it is easy to ignore his own bugs and be a little self-defeating to himself. Even if there is a problem, he will not think carefully. However, when problems are exposed to everyone, people tend to take their responsibilities seriously. In fact, this helps small a develop good professional ethics.

Of course, there is a way to hold a meeting. We once stipulated that two or more people will discuss the work together and call it a meeting. We do not recommend opening a long meeting or a meeting without any results, each meeting should have conclusions, every conclusion should be recorded, and should be managed in the work diary. The supervisors should check the implementation results below. Do you understand?

Well, let's talk about the third question.

The third is that you directly consult with me. Is it good for you to contact the supervisor?

My answer is yes or no. Well, you can contact the supervisor and start to seek support from the team. You can find the former developer and solve the problem. From the work effect, good.

However, there is also a bad side. You find that there is no such thing in the middle. What do you think about him? Is there no face? Will he feel inferior, hurt, depressed, and resigned?

We often say that a new employee has a high turnover rate and the boss will scold us. What's wrong with the current young man? The Supervisor also scolded me for raising a pig. In fact, sometimes, in turn, do our supervisors have their own responsibilities? Is it because we often fail to do well, leading to irreparable results? A new employee is good. My suggestion is that the boss can scold me, but the supervisor is better off, because he will often scold himself.

My suggestion is the best practice. You and Mr. A will hold a briefing to discuss whether there are any potential bugs in the design. When you reach a consensus, contact the supervisor, let the author of the previous generation and Mr. A explain what the principle of this Dongdong is. You should attend the discussion with the supervisor and guide Mr. A to summarize the root cause of the problem and the solution, let him tell him whether the solution is correct. When he can say yes, do you think it is still difficult to solve this problem?

It is obvious that you have not blamed Mr. A for his lack of knowledge and experience. He is helping him improve his knowledge and improve his ability to solve problems, and come up with a solution to solve the problem. Do you say that he has a good face?

When a new employee arrives at a new company, his supervisor carefully teaches, does not criticize, only trains, and constantly improves himself. In addition, he can solve key problems of many companies, I feel that I have gradually grown into an important person and backbone employee of the company. Will this new employee be able to leave alone?

The following shows a management method: "You cannot issue an event, hold a meeting, or discuss it in private ". This is also a management experience I have summarized myself. You cannot issue problems on your own or on your own. I suggest you refer to this principle. Generally, if you do this, all your concerns will be taken into consideration. In the end, Mr. A is praised and your comments will not be wrong.

Of course, the necessary communication skills are essential during this period. communication skills are not just about speaking politely. They are a combination of many qualities, including empathy, including patience and listening, this includes guiding thinking, etc. It is recommended that you learn a little bit about communication in the future, which will be very helpful for your work.

Well, from this question, I will introduce the fourth question, that is, from the perspective of small a, what should I think about it.

This is actually an empathy. We have finished talking about your senior employee, or a friend in charge. So, what should we do as a new employee, Mr., in order to better meet the company's needs.

In "0 bug ---- C/C ++ commercial engineering path", I have mentioned and explained this issue many times. I will explain it again here.

In the book, I told a story about a previous team member who completed a project independently but apparently did not do well. He did not discuss the algorithm with us, or we didn't pay much attention to the important algorithm key points we showed him during the meeting. We made a simple database tree directory system parsing module, and he did it for nearly four months. Finally, all our colleagues completed the module and waited for him for two months.

I couldn't help. Finally, I took over his work two days before the died line project. I found that he made the problem too complicated and wrote 15000 lines of code, in the middle, numerous bugs have been found. In the end, jobs cannot be handed over. It is not that the program has not been written, but that there are too many bugs and it cannot run stably.

I have no way to refactor his code. In the middle, I introduced a "tool class" method I invented, with 1200 lines of code. It was made in two days, once and 0 bugs. He was shocked at the time. Finally, he was invited to tea and go to work in another company because of his poor performance.

This story is recorded in the tool class section "0 bug ---- C/C ++ road to commercial engineering". If you are interested, read it.

Let's take a look at his problem?

After so many years of practical program experience, I found that new programmers often make two mistakes when they enter the workplace:

1. They do not like asking for help. New people do not regard their teams as their own resources. They want to express themselves more. Therefore, if they encounter problems, they like themselves. In particular, they also have a certain concept of face, I was afraid that I would be told a joke when I asked a silly question. As a result, I could not help myself. Everyone wanted to help me. I was in a hurry. The last thing was not done well.

Here, I suggest that you set your position when you enter the workplace for the first time. You are new people. New people do not understand this. It is normal. If you have any problems, you can come up with a new method, you can take the initiative to talk to an old employee or supervisor. You didn't ask him, but you told him about your solution and asked them to ask for advice. Is it reasonable? No one will usually reject it, in addition, you can get very effective help, which is much better than thinking about it all by yourself.

We do not recommend that new employees do not have to worry about anything and rely on others' help. However, we stress that it is best for new employees to ask their supervisors and senior engineers to help them with their comments, it is a good habit to help you identify missing vacancies and make fewer mistakes.

2. I like playing tricks and playing cool. This is also a mistake new employees like to make. Many new recruits are eager to express themselves because they have no position in the company. This is reflected in the development process, and they especially like to play some in-depth algorithms, to show that you are good, and try to make everyone pay attention to or respect yourself through these performances. This is also mandatory.

I often like to talk about some new employees, "playing tricks on self-harm. Coding, obviously there is a convenient vs2008, no, you have to use VI, it seems that you do not need this, it is not considered a Linux programmer. When he typed, the two hands flew on the keyboard like a butterfly. The final result shows that his output is the least, and his mistake is the most.

I have written n Linux servers, and now I don't need VI. I just edited them in vs2008. Then, VC compilation, running, passing through, FTP to Linux, make, run, pass, the editing environment of VC is very easy to use. Let's tap the code and enter the variable name and function name only once. Copy it here and click it to bring it up automatically, which of the following is incorrect.

This is okay. It is just a habit problem that affects a little output at most. Some friends are even more reluctant. A simple passive pool algorithm is also a dynamic memory allocation, a linked list, and a tree, busy for a long time. Finally, a bunch of bugs come out, it's hard to fix bugs, test QA, program unavailability, and refactoring. The reason is very simple. The impact of memory fragmentation is not taken into account, and the operation requirements cannot be met within 7x24 hours.

Like our old engineers, look at the data boundary. Well, there are a maximum of 1024 units. Well, a static array is done, and then some reuse logic is made in the array based on probability analysis, efficiency is no worse than dynamic allocation. The program is much simpler, and there are no bugs, static arrays, and memory fragments. Close the job.

Which one do you think is better?

These are all examples I have encountered in the past. I also share the book "0 bug ---- C/C ++ commercial engineering path". Many times, do not write programs to write programs. Be smart.

I often advise my younger brother during meetings, "Please write programs in your mind, rather than handwritten programs." What do you mean?

Now, let's sum up.

At present, many of our friends are not good at finding a job, mainly because of the knowledge in the school, which is not very useful. There is a gap between the demand of enterprises and our strength. However, in my opinion, this problem is not difficult to solve. At present, there are many good training courses and many excellent training institutions. As long as we study for a while, it is not difficult to master basic enterprise development skills.

However, I found that we seldom discuss a problem, that is, "What should we do after we get in ?"

Today, I will talk about how the supervisor manages new people and how the new people integrate into the Enterprise Development Team, hoping to help you.

In fact, these things are not complicated. They are not worth a few dollars. However, please pay attention to the differences between ideas, ideas, and methods, some people can quickly locate in the new company, without breaking the score, and finally grow into the backbone of the company's business, to achieve reuse and high-tech, but some people, there is no way to get stable work, finally, it turned into a flea, jumping around and never achieving your own career. Which one do you want to do?

In fact, I wrote the book "0 bug ---- the path to C/C ++ commercial engineering". I often think about it myself. What is the focus of my speech, I am a programmer. Of course I should write technology, but half of my ideas have changed a little. When books come out and are available, I find that what I actually write is how to behave and how to do things.

I have always suggested that the Code is not worth the money, so don't be fascinated by the Code. to jump out of the code and look at your thoughts, it is because I think a new person is in the workplace, technical issues are really not a big problem. The biggest problem is how to find the right way to work, make fewer mistakes, and strive for correction and progress. I think this is the most important thing.

I may have written some books due to my limited level. I have mentioned this point, but I have not highlighted it and it is not eye-catching. Only I have to post more posts here. Please pay attention to this point.

You are welcome to discuss this issue with me in the future. I hope to help as many friends as possible to get a satisfactory job and do a good job to achieve your own career.