The path of professional growth on the example of Dr. Bykov and his interns
When I watched the series “Interns”, I kept saying to myself that Bykov reminds me of someone, and the relationship that he had with his interns I already met somewhere.
The sense of deja vu did not leave me, and finally I realized where I had it all. About the same relationship I have always considered and still consider the most effective for achieving a certain professional growth. In general, if you transfer such a relationship to the educational process of a programmer, you get a fairly viable and effective learning system.
Dr. Bykov is dissatisfied with his interns.
It is not by chance that I wrote “a certain professional growth” and, moreover, I can say that this
method will not work for everyone .
For those who are not familiar with this series, I will briefly introduce the course of affairs. Four interns were assigned to Dr. Bykov. At the same time, his interns are not entirely satisfied with the method used by their teacher, in particular, he does not hesitate to go through the catchy phrase on the mental abilities of his students, maliciously jokes at them, constantly leaves them on night shifts and for the most part only gives out tasks and makes ready-made decisions . He comments on the decisions in the spirit of “how could you come up with this at all”, if it’s wrong, he sends them to look for the right solution. Of course, in some places he goes too far, but in general it can be said that everything is on the case.
Without claiming to be the ultimate truth, I highlight three methods by which programmers “grow”.
The first I call myself "Ingenious." This is when a programmer grows on his own; he does not need anyone to grow. Such programmers usually quietly delve into the new code for a certain time and then swim in it like a fish in water. In some incomprehensible way, they understand everything, or they can quickly find the answer to their question without outside help. Perhaps this is not even a growth method, but simply a situation when a professionally established programmer starts work. But practice shows that such programmers grow in the process of working with code. Typically, such programmers are quite professional and their level is often above average, closer to the top.
The second method is to beg. This is when the student is "neither fish nor meat." To simple questions, the answers to which lie on the surface and you just need to delve deeper into the problem, they beg the teacher for a ready answer. If they run into people like Bykov, sooner or later they change either their place of work, or even their specialization. Under a “soft” leader, they grow professionally either for a long time or do not grow at all, for the most part they are parasitic. It is possible to reduce the negative effect of such relations if it is firmly required to make the right decisions on tasks that have already been met before. In other words, prompt, but only once. There is an option in which professional growth follows the third path. The level is usually below average.
Actually, the third method of professional growth is “through lynching”, which is practiced in the series. It works well on stubborn people who constructively take criticism or who simply “need” it all. All that is necessary for the growth of a programmer in this method is perseverance, basic knowledge and the ability to learn from analogies.
The main thing that is required in this method from the teacher is to mercilessly criticize the decisions that the student offers, and roughly speaking send them to read man, to force them to look for similar solutions that are correct and ideal, to prompt somewhere in typical situations how to do when the student presented a close solution. At the same time, the teacher’s best move would be not just criticism, but constructive criticism, for example, ideally citing examples in which the student with his decision will “sit in a puddle”. At the same time, the flow of criticism can vary, and be both very dense and average, and the lynching itself may not be so pronounced. I think most successful programmers "grow" using this method.
It is this method that makes the student work with sources of information and learn independence so that sooner or later the student can use the first method.
I had direct work experience practiced by the third method. And I’ll say it very effectively, at first the work is like hell, and you feel just like a concrete idiot, people think that you are not suitable for this work. Those things that seemed ideal to you are actually rejected in the bud and you have to look for a solution to a seemingly obvious and trivial task. But gradually, your claims become less and less claims, and the claims themselves go into a more important plane - not at the level of implementation, but at the level of design, architecture, and chosen solutions. In principle, here the student can already be considered a strong performer who has reached an average level.
Further, in fact, there is a feeling that you have grown to the level of your teacher, but do not rush to conclusions, maybe you just have grown to the point where a nuclear missile does not take off from your actions on the production server and there is still room to grow, though not so intensively.
Why am I all this? Yes, this method helped me, maybe it will not work for you, but I would be very happy if you came to a new job and met Bykov there. And on the contrary, I would be wary if your code were missed without the slightest criticism in production.
I can advise with certainty to avoid the second method, it certainly does not lead to anything good.
The first method is not accessible to everyone, but according to the third method, you can grow to a sought-after artist even if the chances of success are small.
Even Lobanov will sooner or later become a good doctor ... I hope.
And what method helped you?
The sense of deja vu did not leave me, and finally I realized where I had it all. About the same relationship I have always considered and still consider the most effective for achieving a certain professional growth. In general, if you transfer such a relationship to the educational process of a programmer, you get a fairly viable and effective learning system.
Dr. Bykov is dissatisfied with his interns.
It is not by chance that I wrote “a certain professional growth” and, moreover, I can say that this
method will not work for everyone .
For those who are not familiar with this series, I will briefly introduce the course of affairs. Four interns were assigned to Dr. Bykov. At the same time, his interns are not entirely satisfied with the method used by their teacher, in particular, he does not hesitate to go through the catchy phrase on the mental abilities of his students, maliciously jokes at them, constantly leaves them on night shifts and for the most part only gives out tasks and makes ready-made decisions . He comments on the decisions in the spirit of “how could you come up with this at all”, if it’s wrong, he sends them to look for the right solution. Of course, in some places he goes too far, but in general it can be said that everything is on the case.
Without claiming to be the ultimate truth, I highlight three methods by which programmers “grow”.
The first I call myself "Ingenious." This is when a programmer grows on his own; he does not need anyone to grow. Such programmers usually quietly delve into the new code for a certain time and then swim in it like a fish in water. In some incomprehensible way, they understand everything, or they can quickly find the answer to their question without outside help. Perhaps this is not even a growth method, but simply a situation when a professionally established programmer starts work. But practice shows that such programmers grow in the process of working with code. Typically, such programmers are quite professional and their level is often above average, closer to the top.
The second method is to beg. This is when the student is "neither fish nor meat." To simple questions, the answers to which lie on the surface and you just need to delve deeper into the problem, they beg the teacher for a ready answer. If they run into people like Bykov, sooner or later they change either their place of work, or even their specialization. Under a “soft” leader, they grow professionally either for a long time or do not grow at all, for the most part they are parasitic. It is possible to reduce the negative effect of such relations if it is firmly required to make the right decisions on tasks that have already been met before. In other words, prompt, but only once. There is an option in which professional growth follows the third path. The level is usually below average.
Actually, the third method of professional growth is “through lynching”, which is practiced in the series. It works well on stubborn people who constructively take criticism or who simply “need” it all. All that is necessary for the growth of a programmer in this method is perseverance, basic knowledge and the ability to learn from analogies.
The main thing that is required in this method from the teacher is to mercilessly criticize the decisions that the student offers, and roughly speaking send them to read man, to force them to look for similar solutions that are correct and ideal, to prompt somewhere in typical situations how to do when the student presented a close solution. At the same time, the teacher’s best move would be not just criticism, but constructive criticism, for example, ideally citing examples in which the student with his decision will “sit in a puddle”. At the same time, the flow of criticism can vary, and be both very dense and average, and the lynching itself may not be so pronounced. I think most successful programmers "grow" using this method.
It is this method that makes the student work with sources of information and learn independence so that sooner or later the student can use the first method.
I had direct work experience practiced by the third method. And I’ll say it very effectively, at first the work is like hell, and you feel just like a concrete idiot, people think that you are not suitable for this work. Those things that seemed ideal to you are actually rejected in the bud and you have to look for a solution to a seemingly obvious and trivial task. But gradually, your claims become less and less claims, and the claims themselves go into a more important plane - not at the level of implementation, but at the level of design, architecture, and chosen solutions. In principle, here the student can already be considered a strong performer who has reached an average level.
Further, in fact, there is a feeling that you have grown to the level of your teacher, but do not rush to conclusions, maybe you just have grown to the point where a nuclear missile does not take off from your actions on the production server and there is still room to grow, though not so intensively.
Why am I all this? Yes, this method helped me, maybe it will not work for you, but I would be very happy if you came to a new job and met Bykov there. And on the contrary, I would be wary if your code were missed without the slightest criticism in production.
I can advise with certainty to avoid the second method, it certainly does not lead to anything good.
The first method is not accessible to everyone, but according to the third method, you can grow to a sought-after artist even if the chances of success are small.
Even Lobanov will sooner or later become a good doctor ... I hope.
And what method helped you?