Little Tips for Senior on Junior
Why do newbies do the wrong thing from time to time? Why don't they understand senior engineers? Is this always due to a lack of experience? And why, from time to time, during conversations in the kitchen, the same newcomers call their leads "m * ducks"?
I apologize in advance for the Englishisms encountered in the article, but, as it seems to me, without them some sentences would look rather tongue-tied.
Let's start from afar. When I was still in school, I had a hobby - games. Namely Warcrtaft III. And I constantly played, played, played it. At first, it was limited to games with bots, then, in the beautiful year 2003, I got the Internet and games with live people started.
I lost my first game - from nerves and the thought that I could lose, my hands shook and my fingertips froze, and somewhere in the middle of the game a cold sweat appeared on my back. It’s clear that with this attitude I lost the first game. I lost once, then another, and then a third. This went on for quite some time, until one of my friends advised me to start watching the recordings of the games of other professional players.
I was smart enough to obey him and start watching the professionals. After watching the recordings, the first few weeks I tried to repeat the strategies that they used for the game. Over and over again, I began to succeed in winning, but these victories were somehow very hard, exhausted, and after three or four games I felt complete exhaustion of the body. At that moment, the thought began to creep into my head that I was doing something wrong.
After a couple of months, a couple of hundred games and a couple of hundred viewed records, while watching the next replay of the game, I finally had an idea in my head that should have arisen right away: professional players weren’t nervous .
They knew what to do at each subsequent moment in time; they knew how to react to every movement of the enemy. They could go astray, something could go wrong what they planned, something they could do not quite right - but one thing remained the same: they were not nervous . Their body worked like a well-tuned and tuned machine. And at that moment, a second obvious thought shot in my head: Nerves add errors .
These obvious and well-known truths at that moment became a revelation for me. Yes, I have often heard these thoughts from other people, but I did not attach special importance to them (they say and say, I have my own life) until I felt the consequences from my own experience. At that moment I decided not to be nervous anymore and not to rush. I really didn’t really succeed, but I diligently tried. Indicators of victories with the same strategy of the game markedly went up. Instead of three games, I became able to play up to ten matches a day.
Returning directly to the article and to beginners, young specialists. Two basic rules that almost none of them follow:
1. Do not rush
2. Do not be nervous
Regarding the first point, we will again be a little distracted and I will tell the parable story about the conversation with the lead even when I was just starting my career.
Again, I’ll start from afar, but then I will return to the essence of the story, I promise.
Garry Kasparov, the world chess champion, was once asked how many moves ahead he thinks in the game, planning the next move. The questioners believed that he would report some impressive figure, and then they will understand what makes him the winner. But what he said showed people that they incorrectly perceive even the essence of the game: “The main thing in chess is not how many moves ahead you think, but how well you analyze the current situation.”
The essence of this method is that, not knowing objectively their entire situation, people begin to calculate options that initially turn out to be erroneous. And since it is not possible to calculate everything, the line never reaches the correct moves. As a result, we choose the best option from the worst. The best of those that we tried to consider so carefully.
Applying the same strategy to life, we can understand how often we, instead of objectively evaluating what is happening, try to calculate the moves ahead, and how often later these moves turn out to be directed not to the front, but to the side.
To clearly understand the real situation is to make the options open themselves. He who says that he does not know what to do next, just does not know what is happening to him now.
Returning to the conversation with the leader: when I first came to him for advice, I was very surprised by one thing: he asked about a dozen clarifiers to my question on the task, then fell silent for three minutes, then clarified something else. I then thought: "what does he do when the problem starts, the answer is somewhere nearby." After a pause, he began to ask questions about which I simply did not think about, because I did not know what I really needed to do. And only then, when he knew everything that interested him, did he give me an answer. As a result of such “inhibitory behavior” as it seemed to me at the beginning, the problem was solved in half an hour correctly .
Once every couple of weeks I continued to approach him and ask similar questions - and his behavior remained the same: completelyfind out the initial conditions, ask additional questions and only then start thinking.
At some point in our joint work, I asked him the same thing that had once been asked of Kasparov. To which he replied that he did not think ahead, until he fully understood the current situation. There was not even a thought in his head to move forward until it was clear what was surrounding him. At that moment, another brilliant thought shot in my head : yes, he’s right!
Since then, my list of professionals has expanded to the third point: before you start acting, find out what surrounds you .
In other words, upon receipt of the first knowledge of the task, a peculiar “mess” forms in the head. The goal is to get rid of this porridge and turn it into a strictly structured model when everything is in place. How to do this is the topic of a separate article.
That is, in other words, to write good code, and indeed to do any business in good faith, you must follow three rules:
1. Do not be nervous
2. Do not rush
3. Find out what surrounds you
What all beginners lack is the ability to formulate thoughts correctly. In particular, ask the right questions. How often have you come across a newbie coming up to you and asking, “how to add animation for a tab of policies?”. You look at him and understand that from all his question you know only the word “animation”. Of course, the example is exaggerated, but I think you understand what is at stake.
In the head of all beginners sits the thought that you all know. It is necessary to dispel this myth as soon as possible, otherwise fuzzy, poorly formulated questions will continue.
Now consider the problem that the old-timers of the project face: some of the old people for some reason do not want to understand or do not understand what is happening in the minds of young developers. They do not teach to ask questions, they do not explain simple, in their opinion, things. They do not tell how to think and how to build chains of thought.
This is their fatal mistake - a person needs to be explained exactly how to do it, what exactly to do and why exactly. It seems to some that the beginner will get to everything himself, in the process. But reality is far from always as good as it seems to them.
Faced with a problem, people begin to get hung up, spend time deciding what they could tell or ask. They ask the wrong questions because they can’tarticulate your thoughts correctly. They do the wrong thing because they don’t know what they want to achieve.
And the main problem is that they interpret the slightest ambiguous indication of the lead in their own way!
In order not to be unfounded, I will give an example that took us an extra ten working days of development. Lead sent a letter to the middle engineer with a description of the assignment (real text of the card):
1. User login with read access to Invoice view
2. Admin remove access for user to Invoice view
3. User refresh page with Invoice view
4. User still has access to Invoice view
5. User relogin to the system
6. User has not access to Invoice view
What does a person do as a diligent middle engineer? He begins to understand why this happens, writes clarifying letters to the customer, learns the details of which systems may be affected if he corrects the behavior in the system where this bug is reproduced. Then all this is discussed, implementation details are agreed with the seniors. It takes 5 days. Another 5 days for implementation and testing.
A week passes, an angry letter arrives from the product of the partner with an approximate content: "what you have done, everyone on the carpet." We begin to understand, and after several calls and letters it turns out that the functionality that the developer rules was actually Correct! And the tester who created the card, with the description of the task, just meant "clarify whether the application is working correctly or is it a bug!".
For some reason, each person believes that his own thoughts, so simple and clear, somehow magically appear in the head of others. That all "superfluous and unnecessary words" can be omitted, because these are for granted truths. And people begin to cut back on their proposals, stop completely introducing the performer into the course of things, something remains unsaid "because it goes without saying."
BUT!
BUT this never works. You always need to show and tell, and not brush off the problem. Cross the idea of “c'mon, they will understand everything there, not stupid” and write everything point by point, every word that you mean.
And from here a very simple and very important conclusion: never allow ambiguity in the formulation of the task .
Summing up, I repeat: if you need to “lead” newcomers, tell and explain to them from the first days that for the further development of a software engineer’s career they are highly recommended to learn to observe four rules:
1. Do not be nervous
2. Do not rush
3. Find out what
4. surrounds you . Avoid ambiguous language of your thoughts.
I apologize in advance for the Englishisms encountered in the article, but, as it seems to me, without them some sentences would look rather tongue-tied.
Let's start from afar. When I was still in school, I had a hobby - games. Namely Warcrtaft III. And I constantly played, played, played it. At first, it was limited to games with bots, then, in the beautiful year 2003, I got the Internet and games with live people started.
I lost my first game - from nerves and the thought that I could lose, my hands shook and my fingertips froze, and somewhere in the middle of the game a cold sweat appeared on my back. It’s clear that with this attitude I lost the first game. I lost once, then another, and then a third. This went on for quite some time, until one of my friends advised me to start watching the recordings of the games of other professional players.
I was smart enough to obey him and start watching the professionals. After watching the recordings, the first few weeks I tried to repeat the strategies that they used for the game. Over and over again, I began to succeed in winning, but these victories were somehow very hard, exhausted, and after three or four games I felt complete exhaustion of the body. At that moment, the thought began to creep into my head that I was doing something wrong.
After a couple of months, a couple of hundred games and a couple of hundred viewed records, while watching the next replay of the game, I finally had an idea in my head that should have arisen right away: professional players weren’t nervous .
They knew what to do at each subsequent moment in time; they knew how to react to every movement of the enemy. They could go astray, something could go wrong what they planned, something they could do not quite right - but one thing remained the same: they were not nervous . Their body worked like a well-tuned and tuned machine. And at that moment, a second obvious thought shot in my head: Nerves add errors .
These obvious and well-known truths at that moment became a revelation for me. Yes, I have often heard these thoughts from other people, but I did not attach special importance to them (they say and say, I have my own life) until I felt the consequences from my own experience. At that moment I decided not to be nervous anymore and not to rush. I really didn’t really succeed, but I diligently tried. Indicators of victories with the same strategy of the game markedly went up. Instead of three games, I became able to play up to ten matches a day.
Returning directly to the article and to beginners, young specialists. Two basic rules that almost none of them follow:
1. Do not rush
2. Do not be nervous
Regarding the first point, we will again be a little distracted and I will tell the parable story about the conversation with the lead even when I was just starting my career.
Again, I’ll start from afar, but then I will return to the essence of the story, I promise.
Garry Kasparov, the world chess champion, was once asked how many moves ahead he thinks in the game, planning the next move. The questioners believed that he would report some impressive figure, and then they will understand what makes him the winner. But what he said showed people that they incorrectly perceive even the essence of the game: “The main thing in chess is not how many moves ahead you think, but how well you analyze the current situation.”
The essence of this method is that, not knowing objectively their entire situation, people begin to calculate options that initially turn out to be erroneous. And since it is not possible to calculate everything, the line never reaches the correct moves. As a result, we choose the best option from the worst. The best of those that we tried to consider so carefully.
Applying the same strategy to life, we can understand how often we, instead of objectively evaluating what is happening, try to calculate the moves ahead, and how often later these moves turn out to be directed not to the front, but to the side.
To clearly understand the real situation is to make the options open themselves. He who says that he does not know what to do next, just does not know what is happening to him now.
Returning to the conversation with the leader: when I first came to him for advice, I was very surprised by one thing: he asked about a dozen clarifiers to my question on the task, then fell silent for three minutes, then clarified something else. I then thought: "what does he do when the problem starts, the answer is somewhere nearby." After a pause, he began to ask questions about which I simply did not think about, because I did not know what I really needed to do. And only then, when he knew everything that interested him, did he give me an answer. As a result of such “inhibitory behavior” as it seemed to me at the beginning, the problem was solved in half an hour correctly .
Once every couple of weeks I continued to approach him and ask similar questions - and his behavior remained the same: completelyfind out the initial conditions, ask additional questions and only then start thinking.
At some point in our joint work, I asked him the same thing that had once been asked of Kasparov. To which he replied that he did not think ahead, until he fully understood the current situation. There was not even a thought in his head to move forward until it was clear what was surrounding him. At that moment, another brilliant thought shot in my head : yes, he’s right!
Since then, my list of professionals has expanded to the third point: before you start acting, find out what surrounds you .
In other words, upon receipt of the first knowledge of the task, a peculiar “mess” forms in the head. The goal is to get rid of this porridge and turn it into a strictly structured model when everything is in place. How to do this is the topic of a separate article.
That is, in other words, to write good code, and indeed to do any business in good faith, you must follow three rules:
1. Do not be nervous
2. Do not rush
3. Find out what surrounds you
What all beginners lack is the ability to formulate thoughts correctly. In particular, ask the right questions. How often have you come across a newbie coming up to you and asking, “how to add animation for a tab of policies?”. You look at him and understand that from all his question you know only the word “animation”. Of course, the example is exaggerated, but I think you understand what is at stake.
In the head of all beginners sits the thought that you all know. It is necessary to dispel this myth as soon as possible, otherwise fuzzy, poorly formulated questions will continue.
Now consider the problem that the old-timers of the project face: some of the old people for some reason do not want to understand or do not understand what is happening in the minds of young developers. They do not teach to ask questions, they do not explain simple, in their opinion, things. They do not tell how to think and how to build chains of thought.
This is their fatal mistake - a person needs to be explained exactly how to do it, what exactly to do and why exactly. It seems to some that the beginner will get to everything himself, in the process. But reality is far from always as good as it seems to them.
Faced with a problem, people begin to get hung up, spend time deciding what they could tell or ask. They ask the wrong questions because they can’tarticulate your thoughts correctly. They do the wrong thing because they don’t know what they want to achieve.
And the main problem is that they interpret the slightest ambiguous indication of the lead in their own way!
In order not to be unfounded, I will give an example that took us an extra ten working days of development. Lead sent a letter to the middle engineer with a description of the assignment (real text of the card):
1. User login with read access to Invoice view
2. Admin remove access for user to Invoice view
3. User refresh page with Invoice view
4. User still has access to Invoice view
5. User relogin to the system
6. User has not access to Invoice view
What does a person do as a diligent middle engineer? He begins to understand why this happens, writes clarifying letters to the customer, learns the details of which systems may be affected if he corrects the behavior in the system where this bug is reproduced. Then all this is discussed, implementation details are agreed with the seniors. It takes 5 days. Another 5 days for implementation and testing.
A week passes, an angry letter arrives from the product of the partner with an approximate content: "what you have done, everyone on the carpet." We begin to understand, and after several calls and letters it turns out that the functionality that the developer rules was actually Correct! And the tester who created the card, with the description of the task, just meant "clarify whether the application is working correctly or is it a bug!".
For some reason, each person believes that his own thoughts, so simple and clear, somehow magically appear in the head of others. That all "superfluous and unnecessary words" can be omitted, because these are for granted truths. And people begin to cut back on their proposals, stop completely introducing the performer into the course of things, something remains unsaid "because it goes without saying."
BUT!
BUT this never works. You always need to show and tell, and not brush off the problem. Cross the idea of “c'mon, they will understand everything there, not stupid” and write everything point by point, every word that you mean.
And from here a very simple and very important conclusion: never allow ambiguity in the formulation of the task .
Summing up, I repeat: if you need to “lead” newcomers, tell and explain to them from the first days that for the further development of a software engineer’s career they are highly recommended to learn to observe four rules:
1. Do not be nervous
2. Do not rush
3. Find out what
4. surrounds you . Avoid ambiguous language of your thoughts.