The path of professional growth on the example of Dr. Bykov and his interns
When I watched the TV series "Interns", I kept saying to myself that Bykov reminds me of someone, and the relationship that he had with his interns I had already met somewhere.
The feeling of deja vu did not leave me, and finally I understood where I was all going. Approximately the same relationship I have always considered and I consider the most effective for achieving a certain professional growth. In general, if you transfer such relationships to the programmer’s educational process, you get a rather viable and effective system of education.
Dr. Bykov displeased with his interns
')
It’s not by chance that I wrote “a certain professional growth” and moreover, I can say that it’s not for everyone
the method will work.
For those who are not familiar with this series, I will briefly introduce you. Four interns were assigned to Dr. Bykov. At the same time, his interns are not completely satisfied with the method their teacher uses, in particular, he is not shy to go through the intricate phrase on the mental abilities of his students, maliciously jokes about them, constantly leaves them on night duty and for the most part only distributes tasks and makes ready decisions . He comments on solutions in the spirit of “how could you come up with it at all”, if it is 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 in business.
Without claiming the ultimate truth, I single out three methods by which programmers “grow”.
The first one I call myself “Ingenious”. This is when a programmer grows by himself, he does not need anyone to grow. Such programmers usually quietly dig in the new code for a certain time and then swim in it like a fish in water. In some incomprehensible way, everything is clear to them, or they can quickly find the answer to their question without help. Perhaps this is not even a growth method, but simply a situation when a professionally accomplished programmer starts work. But practice shows that such programmers are growing in the process of working with the code. Typically, these programmers are quite professional and their level is often above average, closer to the top.
The second method is “begging.” This is when the student "neither fish nor meat." On simple questions, the answers to which lie on the surface and you just need to delve a little into the problem, they beg for a ready answer from the teacher. If they run into such people as the Bulls, sooner or later they either change their place of work or even their specialization. With a “soft” leader, they grow professionally, either for a long time or not at all, for the most part they are parasitic. You can reduce the negative effect of such relationships, if you firmly demand the correct solutions to the problems that have already been met. In other words, suggest, 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 persistent people who constructively perceive 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 is that this method requires the teacher to mercilessly criticize the decisions that the student offers, and roughly say, send the man, make them look for similar solutions that are correct and ideal, in some typical situations suggest what to do when the student presented a close solution. At the same time, the best move on the part of the teacher will be not just criticism, but constructive criticism, for example, ideally citing examples in which a student with his decision will “sit in a puddle”. In this case, the stream of criticism can vary, and be both very dense and medium, and the lynching itself can be expressed not so brightly. I think most established programmers "grow" using this method.
It is this method that forces the student to work with sources of information and learn independence so that, sooner or later, the student can use the first method.
I had direct experience practiced by the third method. And I will say this very effectively, at first the work is similar to hell, and you feel just like a specific idiot, visit the idea that you are not suitable for this work. Those things that seemed ideal to you in fact are rejected at the root and you have to find a solution for the seemingly obvious and trivial problem. But gradually there are fewer and fewer claims to your code, and the claims themselves are moving to a more important plane - not at the level of implementation, but at the level of design, architecture, and chosen solutions. In principle, here a student can already be considered a strong performer who has reached the average level.
Then you actually feel that you have grown to the level of your teacher, but do not rush to conclusions, you may simply have grown to a level where a nuclear missile does not take off from your actions on the production server and there is still room to grow, although not so intensely.
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 my code were passed without the slightest criticism in production.
I can advise with a certain confidence to avoid the second method, it definitely does not lead to anything good.
The first method is not available to everyone, but according to the third method, it is possible to grow to the 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 feeling of deja vu did not leave me, and finally I understood where I was all going. Approximately the same relationship I have always considered and I consider the most effective for achieving a certain professional growth. In general, if you transfer such relationships to the programmer’s educational process, you get a rather viable and effective system of education.
Dr. Bykov displeased with his interns
')
It’s not by chance that I wrote “a certain professional growth” and moreover, I can say that it’s not for everyone
the method will work.
For those who are not familiar with this series, I will briefly introduce you. Four interns were assigned to Dr. Bykov. At the same time, his interns are not completely satisfied with the method their teacher uses, in particular, he is not shy to go through the intricate phrase on the mental abilities of his students, maliciously jokes about them, constantly leaves them on night duty and for the most part only distributes tasks and makes ready decisions . He comments on solutions in the spirit of “how could you come up with it at all”, if it is 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 in business.
Without claiming the ultimate truth, I single out three methods by which programmers “grow”.
The first one I call myself “Ingenious”. This is when a programmer grows by himself, he does not need anyone to grow. Such programmers usually quietly dig in the new code for a certain time and then swim in it like a fish in water. In some incomprehensible way, everything is clear to them, or they can quickly find the answer to their question without help. Perhaps this is not even a growth method, but simply a situation when a professionally accomplished programmer starts work. But practice shows that such programmers are growing in the process of working with the code. Typically, these programmers are quite professional and their level is often above average, closer to the top.
The second method is “begging.” This is when the student "neither fish nor meat." On simple questions, the answers to which lie on the surface and you just need to delve a little into the problem, they beg for a ready answer from the teacher. If they run into such people as the Bulls, sooner or later they either change their place of work or even their specialization. With a “soft” leader, they grow professionally, either for a long time or not at all, for the most part they are parasitic. You can reduce the negative effect of such relationships, if you firmly demand the correct solutions to the problems that have already been met. In other words, suggest, 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 persistent people who constructively perceive 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 is that this method requires the teacher to mercilessly criticize the decisions that the student offers, and roughly say, send the man, make them look for similar solutions that are correct and ideal, in some typical situations suggest what to do when the student presented a close solution. At the same time, the best move on the part of the teacher will be not just criticism, but constructive criticism, for example, ideally citing examples in which a student with his decision will “sit in a puddle”. In this case, the stream of criticism can vary, and be both very dense and medium, and the lynching itself can be expressed not so brightly. I think most established programmers "grow" using this method.
It is this method that forces the student to work with sources of information and learn independence so that, sooner or later, the student can use the first method.
I had direct experience practiced by the third method. And I will say this very effectively, at first the work is similar to hell, and you feel just like a specific idiot, visit the idea that you are not suitable for this work. Those things that seemed ideal to you in fact are rejected at the root and you have to find a solution for the seemingly obvious and trivial problem. But gradually there are fewer and fewer claims to your code, and the claims themselves are moving to a more important plane - not at the level of implementation, but at the level of design, architecture, and chosen solutions. In principle, here a student can already be considered a strong performer who has reached the average level.
Then you actually feel that you have grown to the level of your teacher, but do not rush to conclusions, you may simply have grown to a level where a nuclear missile does not take off from your actions on the production server and there is still room to grow, although not so intensely.
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 my code were passed without the slightest criticism in production.
I can advise with a certain confidence to avoid the second method, it definitely does not lead to anything good.
The first method is not available to everyone, but according to the third method, it is possible to grow to the 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?
Source: https://habr.com/ru/post/130368/
All Articles