It's hard to be a junior

I was really lucky - when I first found a job in 2010, I got into a good company and worked alongside high-level professionals and just good people. Next to them, I quickly grew. I have always been shown good practices and have really given me time.

But not everyone was so lucky - many began their careers in offices of a rather average level, where there was simply no one to teach them. Or did not want to.

I just want to consider a few real-life cases from novice developers that I’ve heard and compare these cases with my experience. I will consider only 3 situations, each of which will consist of 4 small parts:

• The story I heard
• What's wrong with it
• As it was with me
• Brief conclusion

If there are no questions, then let's go.

Situation 1: assessment of the time work for the task.

History : a novice developer, still a student, joins the company and hears from the team leader: “This task is done in 8 hours. Tomorrow I wait for the result. ”

What is wrong : to hear that this task is being done in N hours is already stress, and in stressful conditions our brain works worse. Junior starts to panic even more when the number of hours worked approaches N. Besides, what is done with the team leader in 8 hours, the junior can take everything 40 away.

As it was with me : when I got a little comfortable on the project, my team leader asked me to independently evaluate the tasks, and not just give out the final figure, but describe in detail where the time goes. Thus, he taught me to decompose the task into many smaller ones. He understood that junior assessments should not be put on top in a rigid form, but at the same time he did not allow me to inflate temporary labor costs. He always asked me to justify why this was the case, and usually this led to a more adequate assessment on my part.

A brief conclusion : you need to understand that you have taken a novice. He needs to devote time and realize that even quick tasks sometimes take time.

Situation 2: rewriting code.

History : novice developer gets the task and performs it. Timlid, after some time, sees the code written within this task, quietly curses and rules it. Having finished editing, he, satisfied with himself, commits him and forgets about everything.

What is wrong : the junior did not understand exactly what his joint was. After refactoring, he sees even an excellent code, but he will hardly understand it. Timlid consistently spends his time refactoring instead of spending it on training his Padawan and cultivating a strong specialist, who even in a year will require much less control.

As it was with me : the tmlid, after checking my code, sat beside me and said: “Look, but what happens if I pass the empty string to the method for this method?”. And I then hesitantly answered: “NullPointerException?”. He agreed and suggested that I myself guess how to avoid this situation. Usually, it didn’t take us more than 5 minutes to discuss, and then in the next 5 minutes he explained in detail to me what else I need to take into account. As a result, the time spent on the Timlide was spent: 10 minutes. The result: worth it.

Conclusion : Teach your subordinates. If you are rewriting the beginner code, explain to him why this was done and point out his mistakes. This will allow to avoid these errors and unnecessary rewriting.

Situation 3: code-review. More precisely, its absence.

History : similar to the story from the previous paragraph. The student writes the code as part of some task, then the team leader with one eye and diagonally looks at the code and checks that everything works. Then gives the student the following task.

What is wrong : it is difficult to take into account all the changes, just a quick scan of the brunch. In addition, the revision code is aimed precisely at avoiding bad code, as well as educating people and pointing out their jambs. And, of course, to help them get rid of these jambs.

As it was with me : unfortunately, when I started, this practice was not used very actively on our project. Therefore, the team leader carefully compared my brunch with the main one (then he was called trunc (svn)), and then sat down at me and said: “Look, what happens if ...”. Well, then you already know.

Short conclusion : always use the full power of code review. This not only prevents bad code from sneaking into the system, but also helps to display all problem areas in a convenient and understandable form, explain its jambs to the junior and help him overcome them.

Mentoring

I also want to talk about such a useful thing as mentoring. This thing is very, very good, and it is really difficult to overestimate its benefit. It somehow includes all the previous points and not only. Share knowledge - recommend books, answer questions and help sort out trivia.

As a conclusion

Long final speeches will not work, so just - motivate beginners to reach the top and give them a friendly atmosphere. Everyone is pleased to work in companies that value their employees, even the youngest. But after a year or two, these young employees will become quite mature and will be able to bring real value to the company without additional control. In addition, it is always nice when someone takes over your experience, and it helps him to become at least something better.

Well, it is always worth remembering that in the deadlines it is not “the junior that is digging for a long time in the code” who is to blame, but his team leader.