July 5, 2013 at 00:51The main feature of our developers
A recent article comparing Russian developers with foreign inspired. And I have something to say about this.
This article is revised from an internal instruction that I wrote for newly hired Russian-speaking developers. For a habr adapted, reduced and removed excessively categorical and obscene phrases. (Let your imagination spare no expression)
For liveliness I illustrate with stories from my life.
In my opinion, this article is the most important thing I have done in my life. Not the most difficult, voluminous or interesting, but important.
I describe here only one feature of Russian developers and the captain in every way, but this is a key feature that distinguishes our developers, testers and even sound engineers, as it turned out. The history of Makarevich under the cut.
Further: real stories from my life, a description of the problem, arguments, an English-Russian educational program, as well as a comparison of American, European, Japanese and our developers in terms of team lead.
I won’t write how many years I’ve been a lead developer, how much experience I have as an architect and technical director, and what jokes I have seen in this connection. Not significant.
Only two circumstances are significant:
And the whole essence of the article is described by such a life case:
Once I come to the developer (our developer) and bring a request for a new thing to do-screw. The little thing, in principle, is small, but obviously useful, necessary for the end user, not ambiguously useful from all sides, is not in doubt. About five minutes we discuss, I tell you what and where exactly we need to get. The mission conveyed, it is clear and crystal clear. That's it, the task delivery stage has passed.
There is a second pause, and then the developer says that this is impossible. I am surprised. The thing is that this programming is a little from a completely different field and the developer is a specialist in this field, and I am a specialist in another. I have no reason not to trust the developer’s qualifications, but it takes me a bit of a flurry, and I'm interested in the developer why can’t this little thing be implemented? After all, I do not see any fundamental difficulties.
The next five minutes, the developer tries to somehow justify and find some significant obstacle. The degree of conversation rises. It ends with such a dialogue:
- This cannot be done, because it can never be done for anything!
- Yes, I do not ask why this cannot be done! I ask: how to do this ?!
I freaked out a little, I really wanted to say everything that I think with obscenities. But to his credit, he restrained himself.
He spat on everything, sat down and did the thing himself in a day and a half.
Attention to the screen:
in a day and a half I figured out a completely different area of programming, found a way to do things (there were no ready-made solutions in Google), wrote code, tested and installed.
The code is not the most ideal, but I am not ashamed of it, especially since it is stable, reliable and productive. (I think a specialist in that area would have done everything in half a day).
This is the main feature of our programmers:
instead of starting to think how to solve the problem, they often start thinking why the problem cannot be solved. And the most amazing thing is that in the vast majority of cases, our programmer has enough experience and knowledge to solve the problem without even really straining. I do not see anything good in this feature of our programmers, it turns out from all sides a negative feature.
No, this is not a critical view of the problem with our developer. That developer from the example above did not even think to ask a question: do we really need this thing? Or maybe we need this thing in a different form? And so on? I would answer him that I definitely need it, I need it just in this form, in the simplest form, it was for this purpose that I came personally to verbally tell the details and discuss what is not clear.
This thing will give these and these opportunities to the end user, the user will like it, the user base will grow.
I would explain that this directly means the income of our commercial company in a market economy. I don’t know how in charitable foundations (or there in recoiling ones), and commercial companies should be profitable, they are intended for this. I would explain that our director does not have a printing press in the basement to print a bag of money for us for a bonus and salary, all the money comes from customers. And the gandir also has no extra bag of money. No, he’s not a radish, he just doesn’t have an extra bag of money. We need to earn a bonus. Yes, in the truest sense of the word. We all need to work and create conditions so that the client brings us money. It is from them that the salary and bonus will be!
Yes, I greatly exaggerate, but our developers often do not have the thought of linking their work directly to the fact that the company is commercial and must make money. (And in general, where does the salary come from.)
The following case from my life:
Once I left work early, a little after lunch, at around 4:00 p.m. And the next day I came to work later in the morning, at about half past five. (Why? I have the right and all things :-)
In general, I go out to work and find out that my immediate American subordinate fired his immediate subordinate in my department - our programmer (Belarusian). I'm starting to find out what happened. And it was all very similar to the first story. The American came to his immediate subordinate (Belarus-programmer) and brought him a new task. Good, clear task. Make a new thing. Do not catch some kind of flashing bug, not some kind of dullness or dullness, but a normal task. Not difficult, but not simple. I am sure that our programmer was able to do it, because he was a real normal programmer, he could have done it without straining. No, the programmer was not loaded. In all the stories, the developers were not loaded above their heads, but were engaged in secondary projects of reduced importance, time was in bulk.
So the American comes to the subordinate with the task and gets a direct, very similar answer to the one that I described in the first story.
For an American, this is shock and stupor. This does not fit in his head. How? How is this possible? For an American (as well as a European), this looks very clear: the employee does not want to work, does not want to make money for the company! What's happening? Here he worked fine, everyone worked fine, earned money and then bang and such parsley! No, the American is not a fool, but a completely competent developer. No, not a dumb chief of jokes, but a sane team leader.
The American is in shock and he is trying to explain what this thing needs to be done. This thing will bring money. In response, he receives quite logical harmonious explanations from our programmer why he will not do this thing. But this lies in a completely different plane. Excuses do not channel! The American sincerely does not understand how you can not try to solve the problem and refuse to do a new thing for the company. And he would understand if there were direct arguments against the new thing or the way of implementation.
Here is the time to give a small English-Russian educational program:
When we say: We have a problem, the server crashed., Then these are troubles.
Russian words: Our problems, your problems, problems - do not translate the problem as a problem.
Problem is a fundamental conflict of interest.
Problem in Russian is translated as:
And now back to the story: the
American brings the task, our developer tells him that he will not do the task, because it’s tra la la. And if here we declare to the American that we have a problem here, then his stupor will be deeper.
But sooner or later, the American dries up and begins a discussion. From his point of view, the story looks like an absolute nonsense. I said that the American is adequate. And at first he tries to figure out what is happening, asks clarifying questions for this, and even tries to motivate ours to do his job. Ours sees that counterarguments are being brought to his arguments and begins to respond with counter-Arguments, that he will not do this task. The American is convinced that yes, he doesn’t dream of it and immediately dismisses the Belarusian.
This is not a question: is it difficult to do this thing or simple. My last phrase:
- Yes, I do not ask why this can not be done! I ask: how to do this ?!
It looks like this dumb ensign is commanding. But therein lies the essence.
You can’t do a new thing in general? Well, let's think about how to make it private, in this particular one! And bring money to the company. There are no ready-made solutions in Google? Let's think about how you can make a thing yourself. Is there a solution, but is it ugly? But this is wonderful! It’s great that there is a solution! Let's first make a simple crutch decision since there are no others and make money for all of us!
For a small web studio, a single new thing can be a matter of life or death. For a grocery software company, this is a lot of money and speeding up to success or down to bankruptcy and shit. For the giant of the size of Yandex / Google, any even the smallest web service, an increase in the share by hundredths of a percent is millions!
I confess that I wouldn’t fire the Belarusian. If I were in the workplace, then I would admonish him, gently or hard, according to the circumstances. If anything, then I know how to fire both ours and foreigners. And when I arrived at work, what did I do? Nothing. The American is essentially right; Well, yes, here you can discuss and debate how cruel he is, but he is right.
I wrote only a farewell letter to the Belarusian: bye, bye, be, see you. I don’t know if history has taught him anything or whether he still thinks that the American is a radish. He got an invigorating kick, yes.
This story with a Belarusian and an American is not unique. Peer-to-peer to me the head of the neighboring department, the American did exactly the same in a similar situation.
Honestly, I do not know the exact reason for this behavior of our programmers (testers, engineers, etc.). This is not even laziness, not a lack of qualifications.
It’s all about a cultural feature.
Here is how Makarevich describes his work at an English recording studio:
In my opinion, Europeans in this regard are isomorphic to Americans, only more delicately.
They also wonder how one can refuse to do their job and not make a profit for the company.
But here is the exact opposite of our developers: these are the Japanese.
In absolutely the same initial data, the Japanese take a visor, say: “Yes!” And go to his workplace. Notice, the Japanese just do not know exactly how difficult the task is in reality, what kind of solution is, whether the solution exists in nature at all. He just goes to solve the problem. And, as a rule, he finds a solution in two to three days.
Note that this is not a matter of qualification. Qualifications are equally good.
The Japanese have their own joke: they can’t say no. Because they say yes, they go to do and do their job. Successfully mostly.
There are a lot of other problems with this Japanese feature, but this is a separate article (available on the hub).
The minimum is that if the Japanese do not come up with a solution in three days, then question him in detail, find out the current state of affairs and solve the problem together.
In general, a recommendation to the Timlids: if you can hire a smart Japanese developer - hire without hesitation. Beware of Chinese fakes! :-)
Well, our developers and testers have such a feature. Moreover, our developers have their own unique advantages and, other things being equal, I would take our developer.
I repeat that I do not know exactly why it is so, but it is so and this must be taken into account.
And I even know a solution that will work in most cases:
JFDI
If there is someone knowledgeable in sociology / psychology or personally acquainted with a sociologist / psychologist: please clarify.
Ladies and gentlemen, if you minus karma / article: please write in the comments what exactly you do not agree with, this is important for me.
This article is pain and hope of mine. The quintessence of experience. MANIFESTO. I dream that everyone who can read Russian should read this article.
Today I even made a special site in addition:
http: //xn-----6kcfbtd3audiumjf4b2f0cxa2d.xn--p1ai/
(carefully, profanity)
Ladies and gentlemen, welcome to comments! Let's discuss it constructively!
(Typos and technical flaws, send by personal message, please).
Long years and prosperity!
This article is revised from an internal instruction that I wrote for newly hired Russian-speaking developers. For a habr adapted, reduced and removed excessively categorical and obscene phrases. (Let your imagination spare no expression)
For liveliness I illustrate with stories from my life.
In my opinion, this article is the most important thing I have done in my life. Not the most difficult, voluminous or interesting, but important.
I describe here only one feature of Russian developers and the captain in every way, but this is a key feature that distinguishes our developers, testers and even sound engineers, as it turned out. The history of Makarevich under the cut.
Further: real stories from my life, a description of the problem, arguments, an English-Russian educational program, as well as a comparison of American, European, Japanese and our developers in terms of team lead.
I won’t write how many years I’ve been a lead developer, how much experience I have as an architect and technical director, and what jokes I have seen in this connection. Not significant.
Only two circumstances are significant:
- It just so happens that I'm a developer. I pay special attention. I write code every day. Today, yesterday, earlier. The article is NOT about the boss-subordinate relationship.
- In addition, there is experience in managing a development team of both ours and not ours.
For five years I have not had Russian on a working computer. As unnecessary.
And the whole essence of the article is described by such a life case:
Once I come to the developer (our developer) and bring a request for a new thing to do-screw. The little thing, in principle, is small, but obviously useful, necessary for the end user, not ambiguously useful from all sides, is not in doubt. About five minutes we discuss, I tell you what and where exactly we need to get. The mission conveyed, it is clear and crystal clear. That's it, the task delivery stage has passed.
There is a second pause, and then the developer says that this is impossible. I am surprised. The thing is that this programming is a little from a completely different field and the developer is a specialist in this field, and I am a specialist in another. I have no reason not to trust the developer’s qualifications, but it takes me a bit of a flurry, and I'm interested in the developer why can’t this little thing be implemented? After all, I do not see any fundamental difficulties.
The next five minutes, the developer tries to somehow justify and find some significant obstacle. The degree of conversation rises. It ends with such a dialogue:
- This cannot be done, because it can never be done for anything!
- Yes, I do not ask why this cannot be done! I ask: how to do this ?!
I freaked out a little, I really wanted to say everything that I think with obscenities. But to his credit, he restrained himself.
He spat on everything, sat down and did the thing himself in a day and a half.
Attention to the screen:
in a day and a half I figured out a completely different area of programming, found a way to do things (there were no ready-made solutions in Google), wrote code, tested and installed.
The code is not the most ideal, but I am not ashamed of it, especially since it is stable, reliable and productive. (I think a specialist in that area would have done everything in half a day).
This is the main feature of our programmers:
instead of starting to think how to solve the problem, they often start thinking why the problem cannot be solved. And the most amazing thing is that in the vast majority of cases, our programmer has enough experience and knowledge to solve the problem without even really straining. I do not see anything good in this feature of our programmers, it turns out from all sides a negative feature.
No, this is not a critical view of the problem with our developer. That developer from the example above did not even think to ask a question: do we really need this thing? Or maybe we need this thing in a different form? And so on? I would answer him that I definitely need it, I need it just in this form, in the simplest form, it was for this purpose that I came personally to verbally tell the details and discuss what is not clear.
This thing will give these and these opportunities to the end user, the user will like it, the user base will grow.
I would explain that this directly means the income of our commercial company in a market economy. I don’t know how in charitable foundations (or there in recoiling ones), and commercial companies should be profitable, they are intended for this. I would explain that our director does not have a printing press in the basement to print a bag of money for us for a bonus and salary, all the money comes from customers. And the gandir also has no extra bag of money. No, he’s not a radish, he just doesn’t have an extra bag of money. We need to earn a bonus. Yes, in the truest sense of the word. We all need to work and create conditions so that the client brings us money. It is from them that the salary and bonus will be!
Yes, I greatly exaggerate, but our developers often do not have the thought of linking their work directly to the fact that the company is commercial and must make money. (And in general, where does the salary come from.)
The following case from my life:
Once I left work early, a little after lunch, at around 4:00 p.m. And the next day I came to work later in the morning, at about half past five. (Why? I have the right and all things :-)
In general, I go out to work and find out that my immediate American subordinate fired his immediate subordinate in my department - our programmer (Belarusian). I'm starting to find out what happened. And it was all very similar to the first story. The American came to his immediate subordinate (Belarus-programmer) and brought him a new task. Good, clear task. Make a new thing. Do not catch some kind of flashing bug, not some kind of dullness or dullness, but a normal task. Not difficult, but not simple. I am sure that our programmer was able to do it, because he was a real normal programmer, he could have done it without straining. No, the programmer was not loaded. In all the stories, the developers were not loaded above their heads, but were engaged in secondary projects of reduced importance, time was in bulk.
So the American comes to the subordinate with the task and gets a direct, very similar answer to the one that I described in the first story.
For an American, this is shock and stupor. This does not fit in his head. How? How is this possible? For an American (as well as a European), this looks very clear: the employee does not want to work, does not want to make money for the company! What's happening? Here he worked fine, everyone worked fine, earned money and then bang and such parsley! No, the American is not a fool, but a completely competent developer. No, not a dumb chief of jokes, but a sane team leader.
The American is in shock and he is trying to explain what this thing needs to be done. This thing will bring money. In response, he receives quite logical harmonious explanations from our programmer why he will not do this thing. But this lies in a completely different plane. Excuses do not channel! The American sincerely does not understand how you can not try to solve the problem and refuse to do a new thing for the company. And he would understand if there were direct arguments against the new thing or the way of implementation.
Here is the time to give a small English-Russian educational program:
When we say: We have a problem, the server crashed., Then these are troubles.
Russian words: Our problems, your problems, problems - do not translate the problem as a problem.
Problem is a fundamental conflict of interest.
Problem in Russian is translated as:
- issue (to be discussed)
- task (which must be solved), task (which must be done)
- topic (research in science)
And now back to the story: the
American brings the task, our developer tells him that he will not do the task, because it’s tra la la. And if here we declare to the American that we have a problem here, then his stupor will be deeper.
But sooner or later, the American dries up and begins a discussion. From his point of view, the story looks like an absolute nonsense. I said that the American is adequate. And at first he tries to figure out what is happening, asks clarifying questions for this, and even tries to motivate ours to do his job. Ours sees that counterarguments are being brought to his arguments and begins to respond with counter-Arguments, that he will not do this task. The American is convinced that yes, he doesn’t dream of it and immediately dismisses the Belarusian.
This is not a question: is it difficult to do this thing or simple. My last phrase:
- Yes, I do not ask why this can not be done! I ask: how to do this ?!
It looks like this dumb ensign is commanding. But therein lies the essence.
You can’t do a new thing in general? Well, let's think about how to make it private, in this particular one! And bring money to the company. There are no ready-made solutions in Google? Let's think about how you can make a thing yourself. Is there a solution, but is it ugly? But this is wonderful! It’s great that there is a solution! Let's first make a simple crutch decision since there are no others and make money for all of us!
For a small web studio, a single new thing can be a matter of life or death. For a grocery software company, this is a lot of money and speeding up to success or down to bankruptcy and shit. For the giant of the size of Yandex / Google, any even the smallest web service, an increase in the share by hundredths of a percent is millions!
I confess that I wouldn’t fire the Belarusian. If I were in the workplace, then I would admonish him, gently or hard, according to the circumstances. If anything, then I know how to fire both ours and foreigners. And when I arrived at work, what did I do? Nothing. The American is essentially right; Well, yes, here you can discuss and debate how cruel he is, but he is right.
I wrote only a farewell letter to the Belarusian: bye, bye, be, see you. I don’t know if history has taught him anything or whether he still thinks that the American is a radish. He got an invigorating kick, yes.
This story with a Belarusian and an American is not unique. Peer-to-peer to me the head of the neighboring department, the American did exactly the same in a similar situation.
Honestly, I do not know the exact reason for this behavior of our programmers (testers, engineers, etc.). This is not even laziness, not a lack of qualifications.
It’s all about a cultural feature.
Here is how Makarevich describes his work at an English recording studio:
Hidden text
- At the Abbey Road studio there is the same mixing console on which the Beatles were written, and you sang in the same Beatle microphones ...
- You understand, “Abbey Road” is amazing in that the studio employees did not throw anything away in 81 years. Do you want a console that recorded "The Dark Side of the Moon"? They’ll bring it to you now, don’t worry - just pay the money. Do you want the piano that Lennon played? Here it is, please. They have everything, and through the Beatles console we drove the voices, drove the drums, used all these old tube amplifiers. It was crazy experiment - when the museum flutter disappears, you already begin to watch how engineers work, how sound engineers work. How is it all instantly, how is it all for sure, how are they trying to do everything so that the musician is thrilled, so that he does not spoil his mood, so that he does not wait - this is amazing!
- Can this be compared with work in our studios?
- There is one, in my opinion, fundamental difference. In principle, everything is the same. The studio is very similar to GDRZ, the same in size, the sense of holiness from touching the Beatles console quickly passes, and you begin to watch how it works ... But there it is different. In our studio, when you set the sound, each sound engineer will consider it necessary to tell you how to fix something, where to add something, the tops, bottoms, and the guitar, they’ll say in the end, you have shit, if there’s another, take our try ... And there’s the main man is a musician. If you built a sound on the amplifier and you like it, then the sound engineer cannot tell you: you have some shitty sound. He is obliged to transfer this sound to film so that you like it and you gasp. He will change microphones, push them back, move them, walk around you silently, saying all the time: good-good, very good, and now it will be even better, now listen. And it scares you up in your own eyes. Nobody teaches you, everyone behaves very delicately, including the producer. By the expression on his face, I was only trying to understand whether he really liked everything or something, maybe not so. It was necessary to pull out ticks from it.
- You understand, “Abbey Road” is amazing in that the studio employees did not throw anything away in 81 years. Do you want a console that recorded "The Dark Side of the Moon"? They’ll bring it to you now, don’t worry - just pay the money. Do you want the piano that Lennon played? Here it is, please. They have everything, and through the Beatles console we drove the voices, drove the drums, used all these old tube amplifiers. It was crazy experiment - when the museum flutter disappears, you already begin to watch how engineers work, how sound engineers work. How is it all instantly, how is it all for sure, how are they trying to do everything so that the musician is thrilled, so that he does not spoil his mood, so that he does not wait - this is amazing!
- Can this be compared with work in our studios?
- There is one, in my opinion, fundamental difference. In principle, everything is the same. The studio is very similar to GDRZ, the same in size, the sense of holiness from touching the Beatles console quickly passes, and you begin to watch how it works ... But there it is different. In our studio, when you set the sound, each sound engineer will consider it necessary to tell you how to fix something, where to add something, the tops, bottoms, and the guitar, they’ll say in the end, you have shit, if there’s another, take our try ... And there’s the main man is a musician. If you built a sound on the amplifier and you like it, then the sound engineer cannot tell you: you have some shitty sound. He is obliged to transfer this sound to film so that you like it and you gasp. He will change microphones, push them back, move them, walk around you silently, saying all the time: good-good, very good, and now it will be even better, now listen. And it scares you up in your own eyes. Nobody teaches you, everyone behaves very delicately, including the producer. By the expression on his face, I was only trying to understand whether he really liked everything or something, maybe not so. It was necessary to pull out ticks from it.
In my opinion, Europeans in this regard are isomorphic to Americans, only more delicately.
They also wonder how one can refuse to do their job and not make a profit for the company.
But here is the exact opposite of our developers: these are the Japanese.
In absolutely the same initial data, the Japanese take a visor, say: “Yes!” And go to his workplace. Notice, the Japanese just do not know exactly how difficult the task is in reality, what kind of solution is, whether the solution exists in nature at all. He just goes to solve the problem. And, as a rule, he finds a solution in two to three days.
Note that this is not a matter of qualification. Qualifications are equally good.
The Japanese have their own joke: they can’t say no. Because they say yes, they go to do and do their job. Successfully mostly.
There are a lot of other problems with this Japanese feature, but this is a separate article (available on the hub).
The minimum is that if the Japanese do not come up with a solution in three days, then question him in detail, find out the current state of affairs and solve the problem together.
In general, a recommendation to the Timlids: if you can hire a smart Japanese developer - hire without hesitation. Beware of Chinese fakes! :-)
Well, our developers and testers have such a feature. Moreover, our developers have their own unique advantages and, other things being equal, I would take our developer.
I repeat that I do not know exactly why it is so, but it is so and this must be taken into account.
And I even know a solution that will work in most cases:
JFDI
If there is someone knowledgeable in sociology / psychology or personally acquainted with a sociologist / psychologist: please clarify.
Ladies and gentlemen, if you minus karma / article: please write in the comments what exactly you do not agree with, this is important for me.
This article is pain and hope of mine. The quintessence of experience. MANIFESTO. I dream that everyone who can read Russian should read this article.
Today I even made a special site in addition:
http: //xn-----6kcfbtd3audiumjf4b2f0cxa2d.xn--p1ai/
(carefully, profanity)
Ladies and gentlemen, welcome to comments! Let's discuss it constructively!
(Typos and technical flaws, send by personal message, please).
Long years and prosperity!