Technopark Lectures: Alexey Rybak Master Class “About what I would like to be told while I was studying”
Today we are starting a series of publications of new master-classes of Technopark. And the first of them is the master class of Alexei Rybak on a free topic, in which he shared with students ideas about how work in real life differs from studies. You watch video on our website , and the adapted decoding - below.
I have been working at Badoo for a long time, and before my eyes this project turned from a small startup into a large company with hundreds of engineers and a thousandth fleet of servers distributed across several data centers. Now I would like to tell you that I consider interesting enough for students who have chosen the profession of a programmer.
I will not talk about modern trends and today is important and necessary - many can tell you about it. Instead, let's talk about some universal adaptation of former students to the work that each person undergoes for one or even several years. This process is quite painful, and not all “correctly” go through this adaptation. It is this topic that should interest students and graduates more than some fashionable technological pieces. Although we will also talk about them when we touch on the topic of self-education.
')
We end the university with some baggage, which includes an idea of their position in this world, a certain value system. And in the first years of work, this baggage is clearly visible to others: as a rule, the young employee’s value system is somewhat biased. Let's take a look at why.
Study sets a certain rhythm. Examinations make us work intensively while we study. Although in different universities learn differently. I, for example, studied at the university approximately as follows: from session to session, it is rather relaxed, and during the session, on the contrary, with multiple loads. Some teachers tried to do intermediate colloquiums, asked for additional work, which maintained a certain rhythm, but the really intense workload was only twice a year. In between, everyone learned as best they could.
Next is the exam. Also, the thing is quite simple. Already in the first or second year I took an old mother's robe, cut off a piece of A4 paper the size of it, sewed a jacket and “bombed” all the tickets. Of course, at the same time I thought them through, spent time on preparation. I graduated with honors. The preparation of the “bombs” helped greatly to understand the topic and to remember it. But this doesn’t seem close to what awaited me later, when I started working. At the university, by and large, everything is decided for you - the rhythm of your study is completely determined from the outside. But as soon as you start working, everything will change.
Now about what was taught. I was not taught computer science, the base had to be tightened independently. And this, first of all, algorithms of different levels of complexity. It seemed to me that every IT specialist should be well versed in algorithms. But life has shown that it is not. There are not so many works where it is really necessary to be an expert in creating algorithms. Almost all that is required today is to know the basic algorithms and to be able, while reading the text of the program, to determine its algorithmic complexity.
The next point is the attitude to the program as to the text. When we just start working, we consider our programs, first of all, not as something that the machine performs, but simply as text. And take care that the text is beautiful and clean. Nothing wrong with that. But if at the same time the main values for us are beauty, and not convenience of decomposition, ease of understanding or interaction of the program with iron, then it will be quite difficult to work. I know people who have changed jobs, arguing that “the company is bad because I made a cool app, very beautiful and cool. But it slowed down in production, came to me. Why me? Admin let him find out why she slowed down. Let them buy the iron or even think of something. ” This is a clear example of the bias of the value system. The programmer must write such code that will work optimally. And if it turns out that it does not work optimally, then it is the programmer who has to figure it out.
During my studies, I asked myself questions: “Which programmers are the coolest? Who does any super-corporation employ? ” Then I thought that first of all they take olympiadists. Of course, there is nothing bad in this, but victories at olympiads have a indirect relation to work. Yes, olympiadniki can solve complex problems in a stressful environment in a short time. It is remarkable that almost every serious university has not one, but several teams of olympiads. As a result of hard selection at the top of the pyramid are decent people. But this process has its drawbacks:
Modern society imposes on us an egocentric value system. Works of art, scientific discoveries - all this is created by bright personalities, and often completely individually. But in the production of software (and not only), the situation is quite different: the success of almost every project depends on the efforts of groups of people, teams, and not individuals. While you are studying at a university, you have the impression that there is no collaboration . You think that you can go to an uninhabited island, do science there, write brilliant programs, create masterpieces, and interact with someone completely unnecessary.
For the past couple of centuries, society has become increasingly homogeneous in terms of education and civil rights. Many may consider this statement controversial, but in general it can be said that society is becoming more and more humane. And in the past few decades, the idea of ultra-liberalism has gained popularity, according to which the state is considered solely as an institution to serve its citizens. In general, a rather beautiful idea, but there is a fear that it works only on a small scale, in homogeneous societies, in general, with many reservations. However, many of us, having some idea of what is good and what is bad, what an ideal state should be, and how the outside world should relate to us, project this vision on companies that come to work. This is a big mistake. Only on very large scale can you treat your company as a state, and expect it to interact with you in the same way as a state.
Next moment. Over the past 20 years, thanks to the Internet, various communities of interest have been formed and received a very strong development. People create new languages, programming environments, components. As a rule, these societies are created not around some companies or educational institutions, but around enthusiasts. And some of these communities declare very dubious values. Here in the Perl community there is such a common phrase: “We encourage you to develop the three most important programmer virtues: laziness, impatience and pride”) . It sounds very strange. At the same time, the author of the phrase, Larry Wall, had to explain at one time what exactly he had in mind and why he chose these, in general, not the most positive qualities. But it was a long time ago. And then this is what happened. Not sure if it’s related to one another or not, but this community, instead of developing Perl, decided to create a machine for all programming languages and through it make Perl 6. In a few years, the project changed several architects, and the Perl community split into pragmatists , remaining on Perl 5, and on strange people who actually brought the project to a standstill. (Note: To be extremely precise, in September 2015 something similar to a stable release appears, but, firstly, it is unclear how ready it is for production use, and, secondly, more than 15 years have passed, during which the perl-developer community is very impoverished.)
In the first post-graduate years, I realized that the interviews ask questions that have nothing to do with work. The strangest was this: "How do you feel about the work of Carlos Castaneda?". I replied: “I don’t belong at all. I know that there is such a person, but I'm sorry. ” I also like to ask at the interview what a “bad programmer” is. At first glance, this is also a rather strange question, but at least it involves some kind of dialogue, because a person will be forced to reveal his values, tell what is good and what is bad. The answer to the question "What is a good programmer" is more or less predictable - here you can use some cliches. And what is bad? What confuses you, what's not to like? It is very useful to know.
When I started working, I suddenly found out that in many companies personal qualities are valued almost more than professional. Very often it was possible to hear that what is needed is not a “cool programmer” or a “cool coder”, but a “sane person.” This was a new requirement for me. I even heard that in a number of companies, motivational schemes were used rather strange for me then: there was a coefficient of goodwill, that is, employees regularly received marks for goodwill - the size of the premium depended on it. Sounds like utopia, but it is a reality. Such companies really were, and maybe now are.
You can be super-productive, but in any project you have to interact with other team members. And all the failures and losses in a big project do not happen because of someone's illness or because someone has overslept. Usually the root of many problems is that someone didn’t work well with someone. People did not agree on the choice of a very important component, did not agree on any rules, and then everyone began to pull the blanket over himself. Therefore, in a large project it is very important to pump such a skill as cooperation. This is not the same as benevolence, although they are interrelated. The point is that a large project should live for years, but our self-centered baggage in the form of an offset system of values greatly hinders this.
According to our engineers from London, a good programmer can be called a person who writes correct, good, easily readable code, with a good design, who understands all the components for which the team is responsible. Also to the signs of a good programmer is the ease of working with him. Constructiveness of code review plays great importance. Reviews on the code from a colleague. In large companies, no code will commit to the repository if your colleague does not look at it. If the code does not meet the standards, or something is wrong with it, then the colleague should not give trolling feedback, but explain what is not and why, and give some recommendations. That is, the dialogue should be constructive. This is partly indicative of goodwill.
Also among the qualities of a good programmer singled out the fact that a person must be effective at meetings. This is also very interesting. It would seem, how can you be ineffective in meetings with colleagues? We gathered to discuss something. But when you start working in a company, you will realize that some meetings take a huge amount of time just because people cannot make a decision or there is no presenter who would manage the discussion process. Therefore, in a number of agile scenarios standup rally - standing meetings are used. Due to the fact that people get tired of standing for a long time, they try to work out a common solution as quickly as possible. As a rule, to be effective means to act in a direction where, maybe, you don’t like something, but you know for sure that you will achieve your goal in a certain period of time. You need to learn how to plan and forecast costs, choose less risky ways. For example, if you want to use a new interesting technology (which you have never used), and the timeline is compressed, it is better not to risk it, but to choose a solution based on proven technologies.
To the signs of a good programmer is a productive pastime in the office. It seemed to me that in the office a person works for eight hours. This is very optimistic. There are a lot of distractions, sometimes you just need to be distracted, read something, learn something. As a result, much less than eight hours are spent on productive work.
One of the most important qualities of a good programmer is that, working in a team, the programmer is responsible for deadlines. It is necessary at least to warn colleagues in advance that the development process is not going exactly as it was intended for the team to rebuild something, change some tasks, be ready. No need to endure to the very end, and then at the time of the deadline to say: "But I have not yet ready." We need to plan our work, fulfill promises, adequately assess deadlines.
All these values are very simple, they seem trivial. But when I started working, my own value system did not in many respects coincide with the listed criteria of a good programmer.
In any process it is very cool to find some model, build it, find and try some attributes, twist them and see how the model changes. Let's take as an attribute of the size of the program and the time of its life. And as a model I propose to consider programmers. Let's start with a single programmer who did something useful. He realized that the user has some kind of problem, designed the interface, programmed the necessary functionality and put it somewhere.
Let's change our attribute: let the application be bigger and live longer. There are problems with quality. When the program is small, the probability of the appearance of bugs is not very high. But with the expansion of the code base and the increase in the lifetime, the risk of detecting bugs increases greatly. If our hypothetical programmer makes a mobile application, then there are a lot of additional problems associated, for example, with a variety of devices. On each model, the product should work in the same way, but it may well turn out that the application works incorrectly on some tablet or smartphone. And in order to preserve the loyalty of users, this problem should be solved as soon as possible.
Sometimes it happens that after the release you need to fix several errors at once. Even if you are alone, then at least explode, but it is necessary to correct. And while you solve one problem, people swear because of the others. So, there is a team - a few people.
Now it is important to develop in such a way that it is easy to make changes so that the code is clear. So that your colleagues can quickly understand your code and make changes if necessary. If several people work with the code, then it is necessary to agree in advance on all procedures for making a new one and correcting the old one.
If you have created a web application, and it has received a sufficient number of users, then you need to ensure its round-the-clock performance. This means that you need to build a support infrastructure, and it should be as simple as possible. If you create an application with a lot of functions, then this is a different level of complexity - you have several groups of developers, each of which needs to determine its own direction, to establish the relationship between the groups, etc. So, the scale steps are as follows:
In the transition from one step to another, other requirements come to the fore, the attitude to certain things changes dramatically. What works on a small scale may not work at all on a large scale or even prove harmful. At one time, the realization of this came to me not immediately, and it became for me a sufficiently large discovery. I was adapting to the new value system. I think that almost all former students who begin to work go through this.
Big companies face the question: how to help new employees to adapt as quickly as possible, how to build the right culture? In principle, this problem exists when interacting with any community. You can accept the current needs of members of this community and try to achieve your goals, hiding something, manipulating someone. Or honestly say: “Guys, you lived wrong. Need to do like this. On the one hand, the theater, on the other - the Academy. " Therefore, many companies specifically promote a value system within their teams, their own understanding of what a good employee is.
I want to give an example from real life. Somewhere in the early 2000s, Netflix’s big presentation leaked to the network, the meaning of which is: “We will treat our employees as fully formed adults, and if we deviate from our view, we’ll explain: , it doesn't suit us. ” And examples were given of what criteria employees must meet. Everything revolved around priorities. In a large company, there are many difficult situations when there is obviously no right solution, but you need to choose some side. How to proceed? For example, if you choose between what you personally need and what your group needs, then you should choose the interests of the group, because the product is created by the group, not by you personally. And sometimes the choice is between the interests of the group and the needs of the company as a whole. If the group developed the product, but for some reason it needs to be changed not in the way you thought was right, try to look at it from the point of view of the whole company. When making a difficult choice, first of all try to understand what the company needs. As soon as a company reaches a certain size, there is a high risk of hazing or some privileged teams that are engaged in very interesting tasks, and give all the junk to newcomers. Such behavior is unacceptable if the company wants to create a healthy culture.
Another of the postulates of the same Netflix presentation: “Do not tolerate brilliant jerks” (“Do not tolerate geniuses if they behave like assholes”). No matter how gifted an employee is, but if he does not work together with people, then he will have to say goodbye to him.
Next moment. Any company allocates certain budgets, and there are two approaches: either you begin to regulate it, or you say: “All adults. We will not invent a bunch of rules for all occasions, but you will simply spend this money as if it were your own. ” I will give an example. A number of employees moved to work from Moscow to London. The easiest way to account for the money spent is to provide checks. But there may be a lot of them, because there may be many small expenses. To do this, select a person who will then deal with these checks. And you can do it differently: “Here's a sum for you, you can dispose of it somehow, don’t report it, just don’t come to us with a change.” As a result, the company does not need to spend time checking every check, while we save on transaction costs, as employees will not come for money for minor expenses.
I want to mention the rule "50 to 50". When there is a choice who should bear financial or temporary expenses, who should be responsible, often employees believe that the company should bear all expenses. A simple example. My colleagues and I often go to conferences and move between offices in different countries - it takes a lot of time. The rule “50 to 50” is very simple: you can spend the whole working day on a trip (I went on a business trip - this is work), but you can work half a day and spend half a day on a trip. You will arrive a little later, settle in the hotel in the late afternoon, but you will not lose anything from you. 50% of the time worked, 50% took away from this time for the flight.
This helps to get rid of many of the rules. We can say: “Guys, we are adults - let's treat each other responsibly, to the company and to the costs. If everything is regulated, this will not benefit the internal culture of the company. A lot of rules are very tiring. ”
In many companies, employees say: “While working with us, you can safely go for interviews. Sell yourself more than you get. Find out what the current market situation is - this is what determines your wages. If you have any unique skills, most likely they will be in demand. Going around the market is absolutely normal. If you are offered more than we pay, we will raise the salary if we want to keep it. If not, then we will say goodbye. We don’t really want to hold on to you, you got a lot more money. In general, everyone is happy. Hello".
This approach is quite effective. Of course, you should not tell everyone about how you were there yesterday, today here - this does not very well affect the team. But keep in mind that it is necessary to go around the market in order to understand the current situation.
After all, human psychology is designed in such a way that, no matter how much money you receive, at some point you will begin to feel that you are underpaid. Especially often such a thought comes to mind when a person suddenly finds out that in another company they pay more. “So we are deceived here! In fact, what wages are awesome. ” That is, the conclusion is made on one dimension, without any adequate statistics. Therefore, all that an employer can do is say: “Go to other places, find out, understand, is this really an average situation in general or for the most gifted. We'll see if they make you an offer, maybe you really are worth so much. ”
Summarizing the above: get rid of old baggage, look around, interact with people, create a joint project, feel that the power is in collaboration and communication. Learning how to work in a team is task # 1, especially if you have already started working.
The X axis represents an abstract “external pressure”, which, as a rule, comes from your company, from your colleagues, and from your bosses. On the y-axis is your productivity. Two versions of the chart: “without detonation” and “with detonation”. If someone or something pushes you - it's good. Usually it helps to increase your productivity. Another thing is that there is a certain psychological limit, for everyone is different. And if you cross it, then nothing good will come out: either the productivity will simply decrease, or decrease abruptly, very much. Increasing productivity means controlling yourself. To control yourself is:
In essence, these are the four functions of any management, this is true for the management of both the collective and the state. Try a little different look at what you are doing. And as soon as you understand what the goals were and how you achieved them, you can ask the question: what could be done to achieve them more quickly? Try to start doing this as early as possible.
Self-discipline and self-control are connected with stress - you have to force yourself to do something in a limited time. And there are people who do not want to force themselves to do anything. When they are pushed from the outside, they perceive it as aggression, and instead of changing, they leave, run away. About runaway, I will tell you later.
To facilitate the task of planning goals for yourself and your colleagues, you can use the SMART principle.
For programmers, the biggest problem is time. There are even those who say: “Guys, let's conduct the development in such a way that we simply have no deadlines. Deadlines are stressful. ” Probably, such people achieve something in life, but I am convinced that with this approach unplanned losses can turn out to be quite a lot. If you really want to be productive, each of your goals should be determined by some period. You can break this deadline, but then you can ask yourself the question: “Why didn’t I fulfill it on time? How I did not fulfill it? What could I do to perform on time? ” And if you have designated the term approximately, then you will move it without any reflection, without self-improvement.
In the development of large projects, the most important thing is that the different components have weak connectivity. So with setting goals for yourself. The less connectedness you have, the less likely it is that, due to the inhibition or inoperability of one component, the achievement of all other goals and objectives will be delayed. If you are building some complex plans and understand that you have complex relationships, you can decompose and recycle the list of goals.
Often we fall into the trap of our optimism: “Okay, let's move forward. We do not fully understand things, but we will definitely cope with this, we will do it. ” Such an approach - I see a goal, I don’t see obstacles - it is very important. But if you are excessively optimistic, then some gray areas appear in your plans, about which you say: “Fuck knows how to do it”. And no matter what it will be about: performance, quality, support, etc. Then it turns out that this gray area is a stumbling block for launching something big. Therefore, in planning it is very important that these gray areas do not exist, or there must be someone who is fully responsible for the gray areas and guarantees that this part of the work will be completed within a certain time frame.
When the manager came and set you some task - this is a switch of responsibility. And all that he wants in this situation is that this switch goes as precisely as possible, so that there is no misunderstanding: the manager thinks that the responsibility has been switched, the work has begun, and you have a lot of questions, and you are waiting for their clarification, and nobody else for the work not accepted. In such a situation, the transfer of responsibility to each other often occurs - it is not clear, it is not clear. , . . — «» . - , , : «, ».
. , . : « . , - ». , - , , . , . , — . : «, - ».
. , , : «, ». , , . : - , — . , , , - , , -. , .
, , , , . -, « ». . — . - . . . , , , , . .
, . - , , , — , - . , , -, , . , .
What to do with it? , - , . , .
— . : «, . , ». , , — - , . : , . , , . , , .
, .
, «»: - , . . : « , ». , , devops .. , , , release engineering .. . , « », — , . , , . .
: « , , . ». , . , , . , , , . , , . , . , - .
. , , , . — . - , , ! , , , , — . - , , ó -, - - . , - , , .
, . , MySQL. , , , , ? , . , .
, - , : «, , ! - . - , ORM SQL, ORM- data storage». , «, ? , ». : « Python , — , , - . , , ». , , ORM — , .
, . , , — . .
. , . , . , , . , , — . , . . .
— . , - — . , .
— . , : « , ». , , . , , — .
, , . , localhost' — .
, , — , , , . , , .
, , : , . , .
, , . — , — - . - , - , - , - , - . , : — . . : , , , .
. , . , . , . . , , . , . , .
: . , . , , , - . , , , . - , , . server side — , . , .
- , . : « , , ». ? , - , , . , , .
, « ». , . : , , . backlog. , , . , , , .
, , . , . — . , , , , . , . , ( 1 , 2 , 3 , 4 ). :
I wish all students to build their future work in such a way as to make you as comfortable as possible and to effectively and quickly integrate into real processes at your future place of work.
I have been working at Badoo for a long time, and before my eyes this project turned from a small startup into a large company with hundreds of engineers and a thousandth fleet of servers distributed across several data centers. Now I would like to tell you that I consider interesting enough for students who have chosen the profession of a programmer.
I will not talk about modern trends and today is important and necessary - many can tell you about it. Instead, let's talk about some universal adaptation of former students to the work that each person undergoes for one or even several years. This process is quite painful, and not all “correctly” go through this adaptation. It is this topic that should interest students and graduates more than some fashionable technological pieces. Although we will also talk about them when we touch on the topic of self-education.
')
Luggage
We end the university with some baggage, which includes an idea of their position in this world, a certain value system. And in the first years of work, this baggage is clearly visible to others: as a rule, the young employee’s value system is somewhat biased. Let's take a look at why.
Study sets a certain rhythm. Examinations make us work intensively while we study. Although in different universities learn differently. I, for example, studied at the university approximately as follows: from session to session, it is rather relaxed, and during the session, on the contrary, with multiple loads. Some teachers tried to do intermediate colloquiums, asked for additional work, which maintained a certain rhythm, but the really intense workload was only twice a year. In between, everyone learned as best they could.
Next is the exam. Also, the thing is quite simple. Already in the first or second year I took an old mother's robe, cut off a piece of A4 paper the size of it, sewed a jacket and “bombed” all the tickets. Of course, at the same time I thought them through, spent time on preparation. I graduated with honors. The preparation of the “bombs” helped greatly to understand the topic and to remember it. But this doesn’t seem close to what awaited me later, when I started working. At the university, by and large, everything is decided for you - the rhythm of your study is completely determined from the outside. But as soon as you start working, everything will change.
Now about what was taught. I was not taught computer science, the base had to be tightened independently. And this, first of all, algorithms of different levels of complexity. It seemed to me that every IT specialist should be well versed in algorithms. But life has shown that it is not. There are not so many works where it is really necessary to be an expert in creating algorithms. Almost all that is required today is to know the basic algorithms and to be able, while reading the text of the program, to determine its algorithmic complexity.
The next point is the attitude to the program as to the text. When we just start working, we consider our programs, first of all, not as something that the machine performs, but simply as text. And take care that the text is beautiful and clean. Nothing wrong with that. But if at the same time the main values for us are beauty, and not convenience of decomposition, ease of understanding or interaction of the program with iron, then it will be quite difficult to work. I know people who have changed jobs, arguing that “the company is bad because I made a cool app, very beautiful and cool. But it slowed down in production, came to me. Why me? Admin let him find out why she slowed down. Let them buy the iron or even think of something. ” This is a clear example of the bias of the value system. The programmer must write such code that will work optimally. And if it turns out that it does not work optimally, then it is the programmer who has to figure it out.
During my studies, I asked myself questions: “Which programmers are the coolest? Who does any super-corporation employ? ” Then I thought that first of all they take olympiadists. Of course, there is nothing bad in this, but victories at olympiads have a indirect relation to work. Yes, olympiadniki can solve complex problems in a stressful environment in a short time. It is remarkable that almost every serious university has not one, but several teams of olympiads. As a result of hard selection at the top of the pyramid are decent people. But this process has its drawbacks:
- the guys solve extremely specific tasks, which in reality are EXTREMELY rare, they are no more than 1%;
- the bad thing is that they do it in a very short time. Yes, this is an indicator of remarkable abilities and resistance to stress, but in life applications are usually written not in such short time intervals, and not alone.
Offset Values
Modern society imposes on us an egocentric value system. Works of art, scientific discoveries - all this is created by bright personalities, and often completely individually. But in the production of software (and not only), the situation is quite different: the success of almost every project depends on the efforts of groups of people, teams, and not individuals. While you are studying at a university, you have the impression that there is no collaboration . You think that you can go to an uninhabited island, do science there, write brilliant programs, create masterpieces, and interact with someone completely unnecessary.
For the past couple of centuries, society has become increasingly homogeneous in terms of education and civil rights. Many may consider this statement controversial, but in general it can be said that society is becoming more and more humane. And in the past few decades, the idea of ultra-liberalism has gained popularity, according to which the state is considered solely as an institution to serve its citizens. In general, a rather beautiful idea, but there is a fear that it works only on a small scale, in homogeneous societies, in general, with many reservations. However, many of us, having some idea of what is good and what is bad, what an ideal state should be, and how the outside world should relate to us, project this vision on companies that come to work. This is a big mistake. Only on very large scale can you treat your company as a state, and expect it to interact with you in the same way as a state.
Next moment. Over the past 20 years, thanks to the Internet, various communities of interest have been formed and received a very strong development. People create new languages, programming environments, components. As a rule, these societies are created not around some companies or educational institutions, but around enthusiasts. And some of these communities declare very dubious values. Here in the Perl community there is such a common phrase: “We encourage you to develop the three most important programmer virtues: laziness, impatience and pride”) . It sounds very strange. At the same time, the author of the phrase, Larry Wall, had to explain at one time what exactly he had in mind and why he chose these, in general, not the most positive qualities. But it was a long time ago. And then this is what happened. Not sure if it’s related to one another or not, but this community, instead of developing Perl, decided to create a machine for all programming languages and through it make Perl 6. In a few years, the project changed several architects, and the Perl community split into pragmatists , remaining on Perl 5, and on strange people who actually brought the project to a standstill. (Note: To be extremely precise, in September 2015 something similar to a stable release appears, but, firstly, it is unclear how ready it is for production use, and, secondly, more than 15 years have passed, during which the perl-developer community is very impoverished.)
In the first post-graduate years, I realized that the interviews ask questions that have nothing to do with work. The strangest was this: "How do you feel about the work of Carlos Castaneda?". I replied: “I don’t belong at all. I know that there is such a person, but I'm sorry. ” I also like to ask at the interview what a “bad programmer” is. At first glance, this is also a rather strange question, but at least it involves some kind of dialogue, because a person will be forced to reveal his values, tell what is good and what is bad. The answer to the question "What is a good programmer" is more or less predictable - here you can use some cliches. And what is bad? What confuses you, what's not to like? It is very useful to know.
Team
When I started working, I suddenly found out that in many companies personal qualities are valued almost more than professional. Very often it was possible to hear that what is needed is not a “cool programmer” or a “cool coder”, but a “sane person.” This was a new requirement for me. I even heard that in a number of companies, motivational schemes were used rather strange for me then: there was a coefficient of goodwill, that is, employees regularly received marks for goodwill - the size of the premium depended on it. Sounds like utopia, but it is a reality. Such companies really were, and maybe now are.
You can be super-productive, but in any project you have to interact with other team members. And all the failures and losses in a big project do not happen because of someone's illness or because someone has overslept. Usually the root of many problems is that someone didn’t work well with someone. People did not agree on the choice of a very important component, did not agree on any rules, and then everyone began to pull the blanket over himself. Therefore, in a large project it is very important to pump such a skill as cooperation. This is not the same as benevolence, although they are interrelated. The point is that a large project should live for years, but our self-centered baggage in the form of an offset system of values greatly hinders this.
What is a good programmer?
According to our engineers from London, a good programmer can be called a person who writes correct, good, easily readable code, with a good design, who understands all the components for which the team is responsible. Also to the signs of a good programmer is the ease of working with him. Constructiveness of code review plays great importance. Reviews on the code from a colleague. In large companies, no code will commit to the repository if your colleague does not look at it. If the code does not meet the standards, or something is wrong with it, then the colleague should not give trolling feedback, but explain what is not and why, and give some recommendations. That is, the dialogue should be constructive. This is partly indicative of goodwill.
Also among the qualities of a good programmer singled out the fact that a person must be effective at meetings. This is also very interesting. It would seem, how can you be ineffective in meetings with colleagues? We gathered to discuss something. But when you start working in a company, you will realize that some meetings take a huge amount of time just because people cannot make a decision or there is no presenter who would manage the discussion process. Therefore, in a number of agile scenarios standup rally - standing meetings are used. Due to the fact that people get tired of standing for a long time, they try to work out a common solution as quickly as possible. As a rule, to be effective means to act in a direction where, maybe, you don’t like something, but you know for sure that you will achieve your goal in a certain period of time. You need to learn how to plan and forecast costs, choose less risky ways. For example, if you want to use a new interesting technology (which you have never used), and the timeline is compressed, it is better not to risk it, but to choose a solution based on proven technologies.
To the signs of a good programmer is a productive pastime in the office. It seemed to me that in the office a person works for eight hours. This is very optimistic. There are a lot of distractions, sometimes you just need to be distracted, read something, learn something. As a result, much less than eight hours are spent on productive work.
One of the most important qualities of a good programmer is that, working in a team, the programmer is responsible for deadlines. It is necessary at least to warn colleagues in advance that the development process is not going exactly as it was intended for the team to rebuild something, change some tasks, be ready. No need to endure to the very end, and then at the time of the deadline to say: "But I have not yet ready." We need to plan our work, fulfill promises, adequately assess deadlines.
All these values are very simple, they seem trivial. But when I started working, my own value system did not in many respects coincide with the listed criteria of a good programmer.
In any process it is very cool to find some model, build it, find and try some attributes, twist them and see how the model changes. Let's take as an attribute of the size of the program and the time of its life. And as a model I propose to consider programmers. Let's start with a single programmer who did something useful. He realized that the user has some kind of problem, designed the interface, programmed the necessary functionality and put it somewhere.
Let's change our attribute: let the application be bigger and live longer. There are problems with quality. When the program is small, the probability of the appearance of bugs is not very high. But with the expansion of the code base and the increase in the lifetime, the risk of detecting bugs increases greatly. If our hypothetical programmer makes a mobile application, then there are a lot of additional problems associated, for example, with a variety of devices. On each model, the product should work in the same way, but it may well turn out that the application works incorrectly on some tablet or smartphone. And in order to preserve the loyalty of users, this problem should be solved as soon as possible.
Sometimes it happens that after the release you need to fix several errors at once. Even if you are alone, then at least explode, but it is necessary to correct. And while you solve one problem, people swear because of the others. So, there is a team - a few people.
Now it is important to develop in such a way that it is easy to make changes so that the code is clear. So that your colleagues can quickly understand your code and make changes if necessary. If several people work with the code, then it is necessary to agree in advance on all procedures for making a new one and correcting the old one.
Features of "adult" development
If you have created a web application, and it has received a sufficient number of users, then you need to ensure its round-the-clock performance. This means that you need to build a support infrastructure, and it should be as simple as possible. If you create an application with a lot of functions, then this is a different level of complexity - you have several groups of developers, each of which needs to determine its own direction, to establish the relationship between the groups, etc. So, the scale steps are as follows:
- lone programmer;
- small team / department (5-7 people);
- several groups / teams that interact with each other;
- company consisting of groups of departments.
In the transition from one step to another, other requirements come to the fore, the attitude to certain things changes dramatically. What works on a small scale may not work at all on a large scale or even prove harmful. At one time, the realization of this came to me not immediately, and it became for me a sufficiently large discovery. I was adapting to the new value system. I think that almost all former students who begin to work go through this.
Teamwork
Big companies face the question: how to help new employees to adapt as quickly as possible, how to build the right culture? In principle, this problem exists when interacting with any community. You can accept the current needs of members of this community and try to achieve your goals, hiding something, manipulating someone. Or honestly say: “Guys, you lived wrong. Need to do like this. On the one hand, the theater, on the other - the Academy. " Therefore, many companies specifically promote a value system within their teams, their own understanding of what a good employee is.
I want to give an example from real life. Somewhere in the early 2000s, Netflix’s big presentation leaked to the network, the meaning of which is: “We will treat our employees as fully formed adults, and if we deviate from our view, we’ll explain: , it doesn't suit us. ” And examples were given of what criteria employees must meet. Everything revolved around priorities. In a large company, there are many difficult situations when there is obviously no right solution, but you need to choose some side. How to proceed? For example, if you choose between what you personally need and what your group needs, then you should choose the interests of the group, because the product is created by the group, not by you personally. And sometimes the choice is between the interests of the group and the needs of the company as a whole. If the group developed the product, but for some reason it needs to be changed not in the way you thought was right, try to look at it from the point of view of the whole company. When making a difficult choice, first of all try to understand what the company needs. As soon as a company reaches a certain size, there is a high risk of hazing or some privileged teams that are engaged in very interesting tasks, and give all the junk to newcomers. Such behavior is unacceptable if the company wants to create a healthy culture.
Another of the postulates of the same Netflix presentation: “Do not tolerate brilliant jerks” (“Do not tolerate geniuses if they behave like assholes”). No matter how gifted an employee is, but if he does not work together with people, then he will have to say goodbye to him.
Next moment. Any company allocates certain budgets, and there are two approaches: either you begin to regulate it, or you say: “All adults. We will not invent a bunch of rules for all occasions, but you will simply spend this money as if it were your own. ” I will give an example. A number of employees moved to work from Moscow to London. The easiest way to account for the money spent is to provide checks. But there may be a lot of them, because there may be many small expenses. To do this, select a person who will then deal with these checks. And you can do it differently: “Here's a sum for you, you can dispose of it somehow, don’t report it, just don’t come to us with a change.” As a result, the company does not need to spend time checking every check, while we save on transaction costs, as employees will not come for money for minor expenses.
I want to mention the rule "50 to 50". When there is a choice who should bear financial or temporary expenses, who should be responsible, often employees believe that the company should bear all expenses. A simple example. My colleagues and I often go to conferences and move between offices in different countries - it takes a lot of time. The rule “50 to 50” is very simple: you can spend the whole working day on a trip (I went on a business trip - this is work), but you can work half a day and spend half a day on a trip. You will arrive a little later, settle in the hotel in the late afternoon, but you will not lose anything from you. 50% of the time worked, 50% took away from this time for the flight.
This helps to get rid of many of the rules. We can say: “Guys, we are adults - let's treat each other responsibly, to the company and to the costs. If everything is regulated, this will not benefit the internal culture of the company. A lot of rules are very tiring. ”
Search for a better beat
In many companies, employees say: “While working with us, you can safely go for interviews. Sell yourself more than you get. Find out what the current market situation is - this is what determines your wages. If you have any unique skills, most likely they will be in demand. Going around the market is absolutely normal. If you are offered more than we pay, we will raise the salary if we want to keep it. If not, then we will say goodbye. We don’t really want to hold on to you, you got a lot more money. In general, everyone is happy. Hello".
This approach is quite effective. Of course, you should not tell everyone about how you were there yesterday, today here - this does not very well affect the team. But keep in mind that it is necessary to go around the market in order to understand the current situation.
After all, human psychology is designed in such a way that, no matter how much money you receive, at some point you will begin to feel that you are underpaid. Especially often such a thought comes to mind when a person suddenly finds out that in another company they pay more. “So we are deceived here! In fact, what wages are awesome. ” That is, the conclusion is made on one dimension, without any adequate statistics. Therefore, all that an employer can do is say: “Go to other places, find out, understand, is this really an average situation in general or for the most gifted. We'll see if they make you an offer, maybe you really are worth so much. ”
Summarizing the above: get rid of old baggage, look around, interact with people, create a joint project, feel that the power is in collaboration and communication. Learning how to work in a team is task # 1, especially if you have already started working.
Personal productivity
The X axis represents an abstract “external pressure”, which, as a rule, comes from your company, from your colleagues, and from your bosses. On the y-axis is your productivity. Two versions of the chart: “without detonation” and “with detonation”. If someone or something pushes you - it's good. Usually it helps to increase your productivity. Another thing is that there is a certain psychological limit, for everyone is different. And if you cross it, then nothing good will come out: either the productivity will simply decrease, or decrease abruptly, very much. Increasing productivity means controlling yourself. To control yourself is:
- planning: create a plan for yourself goals that need to be achieved. You can not be productive if there are no goals;
- organization: if something interferes with the implementation of the plan - to remove or change;
- motivation: you must motivate yourself;
- control: track the result at intermediate points.
In essence, these are the four functions of any management, this is true for the management of both the collective and the state. Try a little different look at what you are doing. And as soon as you understand what the goals were and how you achieved them, you can ask the question: what could be done to achieve them more quickly? Try to start doing this as early as possible.
Self-discipline and self-control are connected with stress - you have to force yourself to do something in a limited time. And there are people who do not want to force themselves to do anything. When they are pushed from the outside, they perceive it as aggression, and instead of changing, they leave, run away. About runaway, I will tell you later.
To facilitate the task of planning goals for yourself and your colleagues, you can use the SMART principle.
- S - specific. Each goal must be defined. That is exactly here we need to do this.
- M - measurable. The goal must be measurable. An example of a poor goal setting is to improve code coverage. “Well, guys, did you improve?” - “Improved” - “Improved?” - “Improved” - “And how?”. The correct wording is “Increase code coverage with tests from 50 to 55%.
- A is achievable. The goal must be achievable - this is obvious. You can set yourself a global goal: to become very rich in a year. But, most likely, the goal should be a small number of subgoals, a certain number of concrete steps, and the more realistic they will be, the more you will develop a positive attitude towards this method.
- R - relevant. Outlining some tasks, you need to be aware that their implementation will help you achieve your goals.
- T - time-related. Any goal should have a deadline - a period by which everything should be done. Of all five points, this one is the most important.
For programmers, the biggest problem is time. There are even those who say: “Guys, let's conduct the development in such a way that we simply have no deadlines. Deadlines are stressful. ” Probably, such people achieve something in life, but I am convinced that with this approach unplanned losses can turn out to be quite a lot. If you really want to be productive, each of your goals should be determined by some period. You can break this deadline, but then you can ask yourself the question: “Why didn’t I fulfill it on time? How I did not fulfill it? What could I do to perform on time? ” And if you have designated the term approximately, then you will move it without any reflection, without self-improvement.
In the development of large projects, the most important thing is that the different components have weak connectivity. So with setting goals for yourself. The less connectedness you have, the less likely it is that, due to the inhibition or inoperability of one component, the achievement of all other goals and objectives will be delayed. If you are building some complex plans and understand that you have complex relationships, you can decompose and recycle the list of goals.
Often we fall into the trap of our optimism: “Okay, let's move forward. We do not fully understand things, but we will definitely cope with this, we will do it. ” Such an approach - I see a goal, I don’t see obstacles - it is very important. But if you are excessively optimistic, then some gray areas appear in your plans, about which you say: “Fuck knows how to do it”. And no matter what it will be about: performance, quality, support, etc. Then it turns out that this gray area is a stumbling block for launching something big. Therefore, in planning it is very important that these gray areas do not exist, or there must be someone who is fully responsible for the gray areas and guarantees that this part of the work will be completed within a certain time frame.
Leadership Interaction
When the manager came and set you some task - this is a switch of responsibility. And all that he wants in this situation is that this switch goes as precisely as possible, so that there is no misunderstanding: the manager thinks that the responsibility has been switched, the work has begun, and you have a lot of questions, and you are waiting for their clarification, and nobody else for the work not accepted. In such a situation, the transfer of responsibility to each other often occurs - it is not clear, it is not clear. , . . — «» . - , , : «, ».
. , . : « . , - ». , - , , . , . , — . : «, - ».
. , , : «, ». , , . : - , — . , , , - , , -. , .
, , , , . -, « ». . — . - . . . , , , , . .
, . - , , , — , - . , , -, , . , .
What to do with it? , - , . , .
— . : «, . , ». , , — - , . : , . , , . , , .
, .
- — , , , , . . : , , , . «, - -. -. - . — ». , . , , , , .
- , - . , . , — - , , .
, «»: - , . . : « , ». , , devops .. , , , release engineering .. . , « », — , . , , . .: « , , . ». , . , , . , , , . , , . , . , - .
. , , , . — . - , , ! , , , , — . - , , ó -, - - . , - , , .
, . , MySQL. , , , , ? , . , .
, - , : «, , ! - . - , ORM SQL, ORM- data storage». , «, ? , ». : « Python , — , , - . , , ». , , ORM — , .
, . , , — . .
. , . , . , , . , , — . , . . .
— . , - — . , .
— . , : « , ». , , . , , — .
, , . , localhost' — .
, , — , , , . , , .
, , : , . , .
New technologies
, , . — , — - . - , - , - , - , - . , : — . . : , , , .
. , . , . , . . , , . , . , .
: . , . , , , - . , , , . - , , . server side — , . , .
- , . : « , , ». ? , - , , . , , .
, « ». , . : , , . backlog. , , . , , , .
, , . , . — . , , , , . , . , ( 1 , 2 , 3 , 4 ). :
- « ». — . SQL, - .
- « ». — . C, . computer science, . .
- « -». . , , , , .
- « ». — . , , , . , .
- "Zen and the art of motorcycle care." The book is not about IT at all, not about programming, but about the attitude to technology. The story of a man who travels on a motorcycle, he repairs it himself and writes a lot about how he does it, how he sorts out what is important in caring for a motorcycle. All the values that a person painstakingly writes out can be transferred to any technique, and to the attitude to the software, and to the role of the system administrator, and to the role of QA.
I wish all students to build their future work in such a way as to make you as comfortable as possible and to effectively and quickly integrate into real processes at your future place of work.
Source: https://habr.com/ru/post/269687/
All Articles