The intern I brought has gotten a full-time job!

Hello, I'm crooked.

I recently brought an intern. In fact, it has been three full months recently, and it has been going through the normal process.

I still remember when he came, in order to get a close relationship with him, one day after talking about business affairs, he talked to him.

Then I said: In our group, you don’t need to be cautious. When you communicate with each other, you don’t have a relationship between superiors and superiors. Open your heart and don’t have too many worries. Our atmosphere is very open, and we communicate a lot. In fact, don't look at my elders, I am not too old, I am 94 years old. By the way, what year did you come from?

He replied: 2000.

At that moment there was actually an impact.

Because I was surprised to find that the original post-00s have slowly entered the workplace.

After they took over the "Beat Generation" baton from our post-90s, they will soon hand over the baton to the post-10s.

Time flies!

Feedback and thinking

After he joined the team, he encountered a good opportunity when he received a new requirement. In order to complete this requirement, I will build a microservice from 0.

I asked him to participate from the project design stage, and finally followed the project online. Experienced the whole process of a project going online.

For him, it was an opportunity.

For me, it is actually a challenge, because the overall time for this project is not enough, and the allocation to the development link is even more tense. In order to ensure the progress, two other colleagues were urgently transferred from the project team to work with me on this matter, so the human resources were still particularly tense. The task progress needs to be advanced on a daily basis.

The leader asked me: How would you like to arrange this intern?

I said: Let him develop this project with us. I will assign tasks to him and report development resources.

In fact, when I said "half" of manpower, I was playing drums in my heart. Because he didn't come in through my interview, he joined the project team for about a week. I haven't even seen the code written by him yet, and I don't know what level of his technical ability is.

But judging from the final result, in fact, the transcript he handed over in the project is far more than half-manpower.

In other words: the overall performance exceeded expectations.

for example.

I split a task for him, after clarifying the background of the requirements, let him go to implement the code.

He writes and writes that he will find that somewhere is a detail that the requirements have not taken into consideration.

So he will give me feedback quickly, and at the same time bring his own solution, and ask if it can be implemented in this way.

feedback with solutions.

It sounds like a simple and natural thing, but I find that the more newcomers in the workplace, the better.

The old fried dough sticks, including myself, are actually not good enough in many cases. Will go to delay, will cover up, will feel that this is not a big problem, will go to find a plan of course and change it...

But I think there are several layers of logic behind this simple thing.

first logic of 1616cf1520241e is: I found the problem myself.

Can find the problem, at least show that you have a certain degree of understanding of the background of the code you wrote.

Only on the basis of understanding the needs in place, can we autonomously discover problems in the landing link.

Generally speaking, everyone can do this layer.

second level of logic is: if you find a problem, do you not respond?

No feedback. In fact, from the perspective of the division of responsibilities, even if there is a problem, the main responsibility is not with me. I didn't consider this problem when I raised the demand.

The feedback went up, and finally it was solved. What increased my workload was.

At this level, some students will decide after a fierce ideological struggle: time is too late, so let's do it for now. No feedback, it's not a big problem.

The embankment of a thousand miles was destroyed in an ant's nest.

There are too many small problems in the project, and big problems will arise.

If it is really a small problem, even if you type a TODO and mark it there? Prevent yourself from forgetting in the future.

In fact, in most cases, such problems can also be found in the testing process.

But if you can predict it, why should it be delayed until the test link is exposed?

In other words, after a fierce ideological struggle, I decided: I know how to change this place. I just need to change it directly. I won't discuss it with others, and I don't want to give feedback.

This is actually a taboo, it is easy to bury the hole.

For example, you don't know where to get a value for a field, and there is no clear requirement on the requirement. But you can take it out from somewhere by yourself, or pass it on upstream.

So you decide to fetch it yourself, so you don't have to bother upstream.

Because there are two sources, even when you write the code, the two sources must be strongly equivalent, but as the system develops, there may be different situations, and when such a situation occurs, here is pit.

Perhaps by that time, you yourself have forgotten that this value is obtained by you somewhere, rather than passed down by the upstream.

When there is a problem, you can check the code: which sb wrote the code? Why not let the upstream pass in?

Then you look at the historical submission records angrily, and you start to be silent.

third layer of logic is: bring your own solutions when giving feedback.

In my opinion, active feedback is something that should be done.

As for whether we can bring a solution, it's hard to say.

Because sometimes, because of their inadequate control of the overall situation, it is true that they can only find problems but cannot solve them.

Therefore, this cannot be forced for new employees or interns, but it is the best thing to be able to do it.

For example, this intern, every time he comes to me for feedback, he will talk about the plan he has thought of after he finishes the question and ask if he can do so.

In fact, many times the solution he gave is not good, for example, he wants to do processing based on a certain return value, and I think a better solution should be based on a certain state of the data, or add a database field specifically to do it. This matter.

This is more in line with the logic of program design.

The solution he gave is not unusable, but there are better ones.

However, this reflects his own further thinking.

From the actual situation, he also proposed a lot of good implementation plans, which I adopted.

It is good to be able to bring a solution to show that you have a deeper thinking.

Thinking and feedback, no matter what the stage, are very important.

Sometimes I myself do not do well enough, but I often remind and ask myself like this.

Give another example

Here is another small example of feedback:

After I assigned him the task, I told him when to do it before.

During this period, he will take the initiative to tell me what progress I have achieved. If he can't finish it before the expected time, he will tell me in advance what the difficulty is.

This will allow me to control the progress of the entire project in time and prevent risks in advance.

I have brought colleagues who have worked for a few years before, and sometimes the task progress is lagging, and the feedback from the test classmates will make me very passive.

Of course, I should also take the initiative to ask about progress occasionally.

But in my logic: In most cases, you didn't say that you didn't find me to coordinate, then I think the project is proceeding according to the normal schedule.

I think if the task is risky, feedback a few days in advance, but it is too important. This should be the basic professionalism.

As for how to define the low, medium and high risks, and what kind of attitude to respond to, that is another skill.

At the same time, in the whole project development process, I actually kept putting pressure on him. In the trial and error, I also knew that his ability is still good and he has strong execution ability.

Therefore, after the completion of this project, in another project immediately following, I gave him a bunch of development tasks on key nodes and told him the key significance of this development task in the entire call chain.

Judging from the current development progress, he has done very well.

To be honest, at the very beginning, I assigned him some "dirty work", because these things must be done by someone.

As a newcomer or intern, even if you have the ability to shake things up, when I don't know what your abilities are, you can only start with these simple tasks.

If you want to talk about the shortcomings, it is that the code he finally took out is functionally usable.

But in terms of code layering, code specification, subsequent expansion, and programming habits, there are still some deficiencies.

I raised these questions to him from the very beginning.

Judging from the code submitted by him now, there is some progress, but there is still a lot of room for improvement.

Now he may still be in the stage of deliberately imitating, maybe he can't understand why the last shelf of the code is like this, anyway, it is written like this in the project.

Because of his code, I will focus on review every time, in fact, every review will find some coding structure problems.

For example, he may pass the objects in an interface all the way to the dao layer; for example, he may write a new sql to match it every time he interacts with the database, without considering reusability; for example, he Put a lot of logic into the same method...

I think this is an inevitable process for students who have just entered the work position. They change from their own Demo-level code to writing actual engineering-level code. It is bound to require a process of adaptation and sharpening. This is not something What is accomplished overnight is what is tempered in repeated development practices.

To be aware of this problem, to practice and overcome it, is to grow.

And I found that he deliberately imitated, because he saw that he would also use a big try-catch to wrap the entire code block, and the code he submitted earlier was not like this.

Sometimes I am lazy and use a big try-catch to wrap the entire code block. In fact, the code written in this way is easy to use, but it is not elegant and is not recommended.

Exceptions should be caught where they need to be caught. The whole method is wrapped, which is a tricky solution. It shows that you are not absolutely in place for the exception analysis of the code you wrote, and you are trying to use a rough way to cover it.

This is not good, not good.

So after discovering this problem, I communicated with him in time, and at the same time put forward higher requirements to myself.

You can't be lazy in coding. Some bad habits cannot be passed on.

So I gradually realized that this is not only a process of bringing new people, but also a good opportunity to be disciplined.

Oh, right.

I only learned when I went to attend his conversion defense meeting that there was a mentor canvassing session.

So I hurriedly recorded a few points in the mobile phone memo:

transfer

In my career, every team I have met and the "mentors" in every team have been very good to me, and they have done their best to share with me the good things they have mastered.

So I also hope to pass on this good thing forever.

I still remember that when I was doing an internship, a field came in from the front end, and it would eventually fall into the database. It involved the conversion of several objects between several layers. I just didn't get it right after several hours.

Take my colleague to sit next to me, and the music comes from his earphones from time to time. In the current anxious mood, a trace of music makes me feel irritated.

So I said to him: Can you turn off the music first?

He heard what was wrong with me, turned off the music, and then said: Did you encounter any thorny problems?

In the end, he taught me how to solve this problem.

Later, I told him about this during a meal: I said I thought I was terrible at that time. I didn't manage such a simple thing for several hours. In the end, you had to get out of the way.

He said: I don't think you are bad, and I am not afraid of you. What I'm afraid of is that you do it by yourself, and don't ask me if you can't figure it out. If you don't ask me, I don't know how to help you. Some things are beyond the scope of your ability. No matter how hard you work, it is difficult to see the benefits. Some things are within the scope of your abilities, things you should be able to but not, then you should refine your skills. The hard part is how do you clearly identify these problems. For example, what you said, you should also know that it is something you should do but not, then you should improve your related skills. You did it too. Now that you encounter that problem again, it should be resolved soon. This is growth.

I have brought interns, and I have brought people who have worked longer than me.

This line is not like some old craftsmanship. It needs to be passed on and taught from generation to generation.

But there are some good things summarized by predecessors in this industry, which should be passed on.

Okay, let's stop here.