November 2, 2015 at 13:05Lectures of the Technopark: a master class by Alexei Rybak “About what I would like to be told while I was studying”
Today we are starting a series of publications of new Technopark master classes. And the first of them is a master class by Alexei Rybak on a free topic, in which he shared with students thoughts on how working in real life differs from studying. Watch the video on our website , and the adapted transcript 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 thousand-strong fleet of servers distributed across several data centers. Now I would like to talk about what I consider interesting enough for students who choose the profession of a programmer.
I will not talk about current trends, and today it is important and necessary - many can tell you about this. Instead, let's talk about a kind of universal human adaptation of former students to the work that each person goes through for one, and sometimes several years. This process is rather painful, and far from all “correctly” go through this adaptation. This topic should be more interested in students and graduates than any fashionable technological chips. Although we will also talk about them when we touch on the topic of self-education.
We finish the university with some baggage, which includes an idea of our 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 look at why.
Learning sets a certain rhythm. Exams make you work hard while we study. Although in different universities they study differently. For example, I studied at the university like this: from session to session, it’s quite relaxed, and during the session, on the contrary, with multiple loads. Some teachers tried to do intermediate colloquia, asked additional work, which supported a certain rhythm, but the really intense load was only twice a year. In between, everyone studied as they could.
Next is the exam. Also, the thing is quite simple. Already in the first or second year, I took my old mother’s robe, cut off a piece from it the size of a sheet A4, sewed it into my jacket and “bombed” all the tickets. Of course, at the same time I thought over them, spent time preparing. I graduated with honors. The preparation of the "bombs" greatly helped both understand the topic and remember. But this is not at all close to what awaited me later, when I started working. In the university, by and large, everything is decided for you - the rhythm of your learning 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, I had to pull up the base myself. And these are, first of all, algorithms of different difficulty levels. It seemed to me that every IT specialist should have a good understanding of algorithms. But life has shown that this is not so. There are not so many jobs where it is really necessary to be a specialist in creating algorithms. Almost all that is required today is to know the basic algorithms and be able, by reading the text of the program, to determine its algorithmic complexity.
The next point is the attitude to the program as a text. When we are just starting to work, we consider our programs, first of all, not as something that the machine performs, but simply as text. And we make sure that the text is beautiful and clean. There is nothing wrong with that. But if at the same time, the main values for us are beauty, and not the convenience of decomposition, ease of understanding, or the interaction of the program with hardware, then it will be difficult to work. I know people who changed jobs, arguing that “the company is bad, because I made a cool application, very beautiful and cool. But it slowed down in production, they came to me. Why to me? The admin let him find out why she slowed down. Let them buy iron or come up with something else. ” This is a good example of a bias in the value system. A programmer should write code that works optimally. And if it turns out that it does not work optimally, then the programmer should figure it out.
During the training, I wondered: “Which programmers are the coolest? Whom is any super corporation hiring? ” Then I thought that first of all they take the Olympiad. Of course, there is nothing wrong with that, but victories at the Olympiads are indirectly related to work. Yes, olympiads can solve complex problems in a short time under stressful conditions. It is remarkable that practically every serious university has not one, but several teams of Olympic Games. As a result of tough selection, worthy people are at the top of the pyramid. 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 completely 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 get the impression that there is no collaboration . You think that you can go to a desert island, do science there, write brilliant programs, create masterpieces, and interact with someone is completely optional.
Over the past couple of centuries, society has become increasingly homogeneous in terms of education and civil rights. Many may find this statement controversial, but overall it can be said that society is becoming more humane. And in the past few decades, the idea of ultra-liberalism has been gaining popularity, according to which the state is considered exclusively as an institution for serving its citizens. On the whole, it’s a pretty pretty 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 a certain 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 onto the companies in which they come to work. This is a big mistake.
The next moment. Over the past 20 years, thanks to the Internet, various kinds of interest communities have formed and received very strong development. People create new languages, programming environments, components. As a rule, these societies are not created 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 will encourage you to develop the three great virtues of a programmer: laziness, impatience and hubris" ("We urge you to develop the three most important virtues of a programmer: laziness, impatience and pride") . It sounds very strange. At the same time, the author of the phrase, Larry Wall, had in due time to explain for a long 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 what happened. I’m not sure if it’s connected with one another or not, but instead of developing the Perl language, this community decided to create a machine for all programming languages and make Perl 6 through it. For several years the project changed several architects, and the Perl community split into pragmatists left over to Perl 5, and to the weird people who actually stumped the project.(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 at interviews they ask questions that have nothing to do with work. The strangest one was: “How do you feel about the work of Carlos Castaneda?” I replied: “I am not in any way. I know that such a person exists, but I'm sorry. " I 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 a certain dialogue, because a person will be forced to reveal his values, to 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 bothers you what you don’t like? This 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 ones. Very often one could hear that what was needed was not a “cool programmer” or a “cool coder”, but a “sane person”. This was a new requirement for me. I even heard that a number of companies used quite strange motivational schemes for me at that time: there was a goodwill coefficient, that is, employees regularly received an assessment for their goodwill - the size of the bonus depended on it. Sounds like utopia, but it's a reality. There really were such companies, and maybe even now.
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 large project do not happen because of someone else’s illness or because someone overslept. Usually the root of many problems is that someone did not work with someone. People didn’t agree when choosing a very important component, didn’t agree on any rules, and then everyone began to pull the blanket over themselves. Therefore, in a large project, it is very important to pump such a skill as cooperation. This is not the same as goodwill, although they are interconnected. The point is that a large project should live for years, but our self-absorbed baggage in the form of a displaced value system impedes this greatly.
According to our engineers from London, a good programmer can be called a person who writes the correct, good, easy to read code, with a good design, who understands all the components for which the team is responsible. Also, the signs of a good programmer include the ease of working with him. Of great importance is the constructiveness of code review - code reviews from a colleague. In large companies, no code is committed to the repository unless your colleague looks at it. If the code does not meet the standards, or something is wrong with it, then the colleague should not give a trolling feedback, but explain what does not comply and why, and give some recommendations. That is, the dialogue should be constructive. This is partly evidence of goodwill.
Also among the qualities of a good programmer were the fact that a person should be effective in meetings. This is also very interesting. It would seem, how can one be ineffective in meetings with colleagues? We got together to discuss something. But when you start working in a company, you will realize that some meetings take up a huge amount of time just because people cannot make a decision or there is no facilitator who would manage the discussion process. Therefore, in a number of agile scenarios, stand-up meetings are used - standing meetings. Due to the fact that people get tired of standing for a long time, they try to work out a common solution as soon 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 predict costs, choose less risky ways. For example, if you want to use an interesting new technology (which you never used), and the deadlines are tight, then it’s better not to risk it, but to choose a solution based on proven technologies.
Signs of a good programmer include a productive pastime in the office. It seemed to me that a man worked in an office for eight hours. This is very optimistic. There are a lot of distractions, sometimes you just need to be distracted, read something, and study something. As a result, much less than eight hours is 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. You should at least warn colleagues in advance that the development process is not going exactly as intended, so that the team rebuilds something, changes some tasks, and is ready. You do not have to endure to the very end, and then at the time of the deadline say: "But I have nothing ready yet." It is necessary to plan your work, fulfill promises, adequately evaluate the timeline.
All these values are very simple, they seem trivial. But when I started working, my own system of values did not coincide in many respects with the listed criteria of a good programmer.
In any process, it is very cool to find a model, build it, find and try some attributes, twist them and see how the model changes. Let's take the size of the program and its lifetime as such an attribute. And as a model, I propose to consider programmers. Let's start with a lone programmer who did something useful. He realized that the user had some kind of problem, designed the interface, programmed the necessary functionality and laid it out somewhere.
Let's change our attribute: let our application be larger and live longer. There are quality problems. When the program is small, the likelihood of bugs is not very high. But with the expansion of the code base and the increase in the operating life, 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. The product should work the same on each model, but it may well turn out that the application does not work correctly on some tablet or smartphone. And in order to maintain user loyalty, you need to solve this problem 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 tear, but you need to fix it. And while you are solving one problem, people are cursing about others. So, a team appears - a few people.
Now it is important to design in such a way that it is easy to make changes so that the code is understandable. So that your colleagues can quickly understand your code and make changes if necessary. If several people work with the code, then you need to agree in advance on all the procedures for introducing 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 it is necessary to ensure its round-the-clock operation. This means that you need to build support infrastructure, and it should be as simple as possible. If you create an application with many functions, then this is a different level of complexity - you have several groups of developers, each of which needs to determine its direction, establish a 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 greatly. What acts on a small scale, on a large one, may not work at all or even prove harmful. At one time, awareness of this did not come to me immediately, and it became a rather big discovery for me. I was adapting to the new value system. I think that almost all former students who start working go through this.
Large companies are faced with the question: how to help new employees adapt as quickly as possible, how to build the right culture? Basically, this problem exists when interacting with any community. You can accept the current needs of the members of this community and try to achieve your goals by hiding something, manipulating someone. Or honestly say: “Guys, you lived wrong. You have to do like this. On the one hand, the theater, on the other - the academy. ” Therefore, many companies specifically promote within their teams a value system, their own understanding of what a good employee is.
I want to give an example from real life. Somewhere in the early 2000s, a large Netflix presentation leaks into the network, the meaning of which is: “We will treat our employees as fully formed adults, and when we deviate from our view, we will explain: guys 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 one 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 it is the group that creates the product, and not you personally. And sometimes the choice is between the interests of the group and the needs of the company as a whole. If a group has developed a product, but for some reason you need to change it differently from what you thought was right, try to look at it from the point of view of the whole company. When making difficult choices, first of all try to understand what the company needs. As soon as the company reaches a certain size, there is a great risk of hazing or some privileged teams that are engaged in very interesting tasks, and give all the junk to beginners. This behavior is unacceptable if the company wants to create a healthy culture. what the company needs. As soon as the company reaches a certain size, there is a great risk of hazing or some privileged teams that are engaged in very interesting tasks, and give all the junk to beginners. This behavior is unacceptable if the company wants to create a healthy culture. what the company needs. As soon as the company reaches a certain size, there is a great risk of hazing or some privileged teams that are engaged in very interesting tasks, and give all the junk to beginners. This 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 jerks”). No matter how gifted the employee is, if he doesn’t work with people, he will have to say goodbye.
The next moment. Any company allocates certain budgets, and there are two approaches: either you begin to regulate this, or say: “All adults. We will not come up with 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 are moving to work from Moscow to London. The easiest way to report on funds spent is to provide checks. But there can be a lot of them, because maybe a lot of small expenses. To do this, you need to select a person who will then deal with these checks. Or you can do it differently: “Here is the amount for you, you can dispose of it as you like, don’t report, just don’t come to us with a trifle”. As a result, the company does not need to spend time checking each check, while we save on transaction costs,
I want to mention the rule "50 to 50". When it is a choice who should bear financial or time expenses, who should be responsible, often employees consider that all expenses should be borne by the company. 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 “50 to 50” rule is very simple: you can spend the entire working day on a flight (I went on a business trip — it's work), or you can work half a day, and spend half a day on a trip. You will arrive a bit later, check into a hotel in the late afternoon, but will not leave you. I worked 50% of the time, 50% took away from this time for the flight.
This helps to get rid of many prescribed rules. We can say: “Guys, we are adults - let's be responsive to each other, to the company and to the costs. If everything is regulated, then this will not benefit the internal culture of the company. A lot of rules are very tiring. ”
In many companies, employees are told: “Working with us, you can go for interviews without fear. Sell yourself more expensive than you get. Find out what the current market situation is - this is what determines your salary. If you have any unique skills, most likely they will be in demand. Walking the market is absolutely normal. If they offer you 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. Everyone, in general, is happy. Hi".
This approach is quite effective. Of course, you should not tell everyone about how you were there yesterday, here today - this does not affect the team very well. But keep in mind that you need to walk around the market to understand the current situation.
After all, human psychology is designed so that, no matter how much money you receive, at some point it will begin to seem to you that you are being underpaid. Especially often this idea comes to mind when a person suddenly finds out that another company pays more. “So they deceive us here! Actually, what salaries are cool. ” That is, the conclusion is made in one dimension, without any adequate statistics. Therefore, all that an employer can do is say: “Go to other places, find out, understand whether this is really an average situation in general or for the most gifted. We’ll see if they will offer you, maybe you really cost so much. ”
To summarize the above: get rid of old baggage, look around, interact with people, create a joint project, feel that the strength lies in collaboration and communication. Learning how to work in a team is task number 1, especially if you have already started working.
The x-axis represents the abstract “external pressure,” which usually comes from your company, from colleagues, from superiors. The Y axis indicates your productivity. Two variants of the graph: “without detonation” and “with detonation”. If someone or something is pushing you - that’s good. This usually helps to increase your productivity. Another thing is that there is a certain psychological limit, different for everyone. And if you cross it, then nothing good will come of it: either productivity will simply decrease, or it will decrease stepwise, very much. Increasing productivity means managing yourself. To manage yourself is:
In fact, these are the four functions of any management, this is true for managing both the team 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 faster? Try to start doing this as soon as possible.
Self-discipline and self-control are associated 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 at all. When they are pushed from the outside, they perceive it as aggression, and instead of changing, they leave, run away. I’ll tell you more about running away later.
To make it easier for yourself and your colleagues to plan goals, you can use the principleSMART
For programmers, the biggest problem is deadline. There are even those who say: “Guys, let's conduct the development in such a way that we simply do not have deadlines. Deadlines are stress. ” Probably, such people achieve something in life, but I am convinced that with this approach there can be quite a lot of unplanned losses. If you really want to be productive, each of your goals must be determined by a certain term. You can break this deadline, but then you can ask yourself the question: “Why didn’t I meet the deadline? How far have I not fulfilled it? What could I do to do it 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 different components have weak coherence. So with setting goals for yourself. The less connected you are, the less likely it is that due to braking or inoperability of one component, the achievement of all other goals and objectives will stall. If you are building any complex plans and understand that you have complex relationships, you can decompose and revise the list of goals.
Often we fall into the trap of our optimism: “Okay, let's move forward. "We don’t fully understand some things, but we will definitely cope with this, we will do it." This approach - I see the goal, I see no obstacles - is very important. But if you are an overly optimistic person, then you have some gray areas in your plans, about which you say: “Hell knows how to do this.” And it doesn’t matter what exactly will be discussed: performance, quality, support, etc. Then it turns out that this gray zone 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 ensures that this part of the work is completed on time.
When the leader came and set you some task - this is a shift of responsibility. And all that he wants in this situation is to make this switchover as clear as possible, so that there is no misunderstanding: the manager thinks that responsibility has been switched, work has begun, and you have a lot of questions, and you are waiting for their clarification, but no one is working not accepted. In such a situation, responsibility is often shifted to each other - this is not clear, this is not clear. This happens not only between the leader and subordinate, but also between colleagues. Such situations are unpleasant and lead to temporary and emotional loss. The most important thing is to grasp and overcome the desire to “recapture” the transfer of responsibility. If you really want to clarify something, then ask all the questions, and then say: “Yes, I have accepted the task and am going to do it.”
But the leader wants more than that. He wants you to come to him. Very often people say: “Nobody needs anything from me. I’m sitting quietly here, studying something. ” You can’t imagine how many leaders would support any of your new beginnings or ideas if you would come and prove that they are really needed. A huge number of good projects are done on enthusiasm, because they were born in your head. And the only thing that needs to be agreed on the shore is whether it will be in demand. So that the leader does not tell you: “Listen, for some reason we cannot do this.”
I highly recommend you to be proactive from the very beginning. The initiative is punishable in the army, and in ordinary life a huge number of leaders dream that you open the door and say: “Listen, I came up with such a cool thing.” You will be given opportunities and you will be happy doing your work. The reverse situation: there is some kind of problem, and you are silent about it - this will lead to missed opportunities. It’s enough just to talk, discuss, compare values, change something, transfer you to another project, help you with something. But if you are silent, then the project may have many problems.
Of course, there are objective problems with which, most likely, nothing can be done. Firstly, this is the so-called "context switch." I will explain the example of multitasking in operating systems. After all, there is multitasking even on one core - for this you just need to crowd out one process and load another. A certain conditional kernel program is responsible for the operation of several parallel processes. We divide all the time into some quanta and give each process one quantum. Switching running processes is called context switching. But, for example, there are situations when you have many simultaneously living processes, inside of which a large number of switches are initiated. That is, switching can greatly affect system performance.
Plunging into work at the beginning of the day, you do not immediately go to the peak of productivity. After some time, the phone rings, a colleague approaches, the messenger blinks, a letter arrives - you switch, do something. But even if it took a minute, returning to the previous task, you will have to remember something, dive again, and it takes time. We can say that this is an analogue of context switching.
What to do about it? Reduce the number of switching between tasks, negotiate with colleagues and management about changing some procedures in order to less often be distracted from tasks performed. Turn off all sorts of notifications, check mail on a schedule or at least less.
The next objective factor is when you have to deal with completely unknown things in your work. There is a natural rejection: “Well, the story is not completely clear to me. I need to know this, this and this. ” And the task, most likely, involves a creative approach - that you think out some things yourself, and not push the task. As in physics lessons you can sometimes hear from the teacher: all that is is given. That is, build the model yourself and decide what you need and what not. These are wonderful tasks, do not be afraid of them, you can think up the conditions yourself from general considerations and correct the situation.
And now that is almost impossible to fix.
Finally, let's get back to running away: when we don’t like something, and we try to avoid it. There are different cases. For example: "I do not want to develop a user interface, I want to do a backend." Such a runaway is permissible if a person has special abilities in system programming, if he wants to pump like devops, etc. Many companies have a small number of people engaged in either tasks in the field of system programming, or automating the calculation, release engineering, etc. But such tasks are not very many. Moreover, such a runaway is fraught with sitting in a "dusty corner", because in most companies the main value is to make a product, that is, to satisfy the user. If you do not want to engage in a user interface, you are running away from the product, that is, you start doing side things. This in a way reduces your value to the company.
The next runaway option: “Too much control, too much pressure, I don’t want that. I want to work from home. ” There are many teams that work remotely. It seems that working this way is more convenient, more efficient and more comfortable. But you need to understand that if you are comfortable, it is not at all a fact that you are as productive as possible. If there is no control, then most likely there is no effectiveness. If the idea of remote work occurred to you, then I would highly recommend talking to the leader. Maybe you can find some more effective ways to interact.
Programmers terribly dislike control. Despite the fact that it is important that there will still be control, programmers do not really like this. And the programmer’s worst dream is if they begin to measure its performance in the number of lines of code. But some things, oddly enough, can be measured in lines of code! For example, test coverage, how much coverage increases over time for different teams, which team is great, and which is not very good. Or, before some big release, you can measure the speed of introducing new lines of code into the repository in order to assess whether most of the changes really concern bug fixing, or still the team still commits new features. In the latter case, it is more likely that the release would be wise to slightly move, if possible, of course.
Even when working with shareware technologies, there are a lot of things that you can pump. For example, you are working with a MySQL database. Learn how it works internally, what is its architecture, how to optimize queries, how to make your circuit efficient on a lot of data? All of the above will be enough for a year of self-study, if not two. And this will become a very useful skill for you, because you will learn how to create applications of a completely different level.
Often, when a programmer is just starting his career, he says: “Oh, damn it, programming patterns! I will apply such and such patterns. I’ll write object-oriented code, which through my ORM layer will automatically turn into SQL, my ORM tool will automatically work with all data storage. ” Or, “Damn, why do we write in this language? Look, there’s another cool language around the corner. ” Or here is a quote from Habr: “I love Python the way it is - smart, concise, has a lot of useful things out of the box. For example, you can find out if a number is a polymorph in just one line. " Many languages, patterns, ORMs are not the most important, and I would advise you to learn other things.
To begin with, how money is made in your company. This will immediately give you an understanding of what is important for the company and what is not - at least at a general level. This will help to relate the values of the company to their own.
Further study the standards and approaches adopted by your company. For example, how to work with errors. The code should be written so that in case of an error it was possible to pick up all the necessary information and find the reason. But sometimes the code is written in such a way that it is generally not clear what happened. You know that there was a problem, and in what - it is not clear. Sometimes the logs are not collected at all, no one looks at them. In any company, a certain style of working with errors is developed. You need to study it and match it.
Learn to communicate - online and in meetings. Sometimes we think that online we can afford some other communication style - we don’t need to do that. Learn to be as useful as possible at meetings, and direct meetings in a constructive way.
The next very important skill is to learn how to quickly make a pilot version. When we undertake development, a perfectionist sometimes works in us: “It’s better to spend more time, but I’ll do everything cool.” In fact, it is important to make the pilot as fast as possible, even with crutches, then you can always redo them. But you will spend a lot of time creating a pilot, and then it turns out that he is not needed - it will be very disappointing.
Learn not new programming languages, but the infrastructure associated with your work. I do not urge you to become system administrators, but you can become a system administrator at least localhost - it will open up a lot of opportunities for you.
If you work with a database, there are a lot of directions here - find out how it works, how to configure it, read the manual for the system administrator. Any such dive will give you an understanding of how the database is organized, how to prepare it.
And finally, the most important thing: wherever and on whatever device your program works, there will always be performance problems. It is advisable to be able to figure out what affects the performance and how you can speed up the application.
We want to study them, this is our need, we want to implement them in our products. But one thing is when we make an application for ourselves, another thing is when we offer some new technologies in a team. A lot of conflicts arise precisely because we hoped to use some kind of technology, and for some reason we were not allowed to introduce it, so we need to rewrite something, redo something. So, in order to avoid such conflicts, I recommend just looking at the new technology from this perspective: any change has a certain cost and certain risks - this is how life works. When replacing one technology with another or when choosing one technology from several, there is also a risk. These risks are very simple: increased complexity, closedness or openness of technology with all the ensuing consequences like training,
There is also the concept of quality. Technology can be very cool, but can be very dependent on maintenance. If this is one person, then everything depends on his personal qualities. For example, how quickly it will respond to bug reports. Even such things must be considered when choosing a technology. Finally, different dependencies are important when one technology depends on the availability or availability of another technology or product. The more complex the system, the greater the likelihood of failures. The more dependencies, the worse.
Now the financial question: is the cost of transition and the cost of support. You wrote in one language, offer to switch to another. As a rule, one simply cannot change the language, there is a certain machine, it is built in somewhere. And the product or service where it is built may work well for one community simply because it is larger. Or due to the fact that many large companies used it at random to the production, and all identified bugs have already been fixed. In the server side area, support is almost half the work that a large organization does. Therefore, the cost of support is no less important than the cost of development.
If you offer any new technology, then you need to enlist the support of a sufficient number of colleagues. In large companies, there is a rule: “We develop in different languages, but only those languages in which at least a certain number of people develop” fall into the standard set. Why is such a restriction imposed? It often happens that an employee initiates a migration to another language, starts to drag everyone, and in the middle of development, he suddenly loses interest and leaves. The project is in a completely collapsed state, because the main enthusiast has left, and other programmers speak this language still poorly.
There is such a thing as “ technical duty". If you are focused on the fastest release of the product, then your technical debt is growing. It is very important to understand: if you choose a solution between a crutch, the right one and a good one, then a crutch solution will increase your technical debt. In this case, put the task in the backlog. When you will be more free in terms of features, get it, do refactoring. If, from the very beginning, you try to do everything well and correctly, then perhaps your product will no longer be needed by the time it is completed.
I recommend reading, first of all, the blogs of programmers and developers. And as soon as possible to reach out to people who can become your mentors. As long as you have the opportunity and desire to read, read more. Then life will be such that, most likely, you will have neither time nor desire. Therefore, the more you read now, the better. As for books, there are a great many of them ( 1 , 2 , 3 , 4 ). Now offhand I can identify five books:
I wish all students to build their future work in such a way that you are as comfortable as possible, and that you effectively and quickly join the real processes at your future work place.
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 thousand-strong fleet of servers distributed across several data centers. Now I would like to talk about what I consider interesting enough for students who choose the profession of a programmer.
I will not talk about current trends, and today it is important and necessary - many can tell you about this. Instead, let's talk about a kind of universal human adaptation of former students to the work that each person goes through for one, and sometimes several years. This process is rather painful, and far from all “correctly” go through this adaptation. This topic should be more interested in students and graduates than any fashionable technological chips. Although we will also talk about them when we touch on the topic of self-education.
Luggage
We finish the university with some baggage, which includes an idea of our 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 look at why.
Learning sets a certain rhythm. Exams make you work hard while we study. Although in different universities they study differently. For example, I studied at the university like this: from session to session, it’s quite relaxed, and during the session, on the contrary, with multiple loads. Some teachers tried to do intermediate colloquia, asked additional work, which supported a certain rhythm, but the really intense load was only twice a year. In between, everyone studied as they could.
Next is the exam. Also, the thing is quite simple. Already in the first or second year, I took my old mother’s robe, cut off a piece from it the size of a sheet A4, sewed it into my jacket and “bombed” all the tickets. Of course, at the same time I thought over them, spent time preparing. I graduated with honors. The preparation of the "bombs" greatly helped both understand the topic and remember. But this is not at all close to what awaited me later, when I started working. In the university, by and large, everything is decided for you - the rhythm of your learning 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, I had to pull up the base myself. And these are, first of all, algorithms of different difficulty levels. It seemed to me that every IT specialist should have a good understanding of algorithms. But life has shown that this is not so. There are not so many jobs where it is really necessary to be a specialist in creating algorithms. Almost all that is required today is to know the basic algorithms and be able, by reading the text of the program, to determine its algorithmic complexity.
The next point is the attitude to the program as a text. When we are just starting to work, we consider our programs, first of all, not as something that the machine performs, but simply as text. And we make sure that the text is beautiful and clean. There is nothing wrong with that. But if at the same time, the main values for us are beauty, and not the convenience of decomposition, ease of understanding, or the interaction of the program with hardware, then it will be difficult to work. I know people who changed jobs, arguing that “the company is bad, because I made a cool application, very beautiful and cool. But it slowed down in production, they came to me. Why to me? The admin let him find out why she slowed down. Let them buy iron or come up with something else. ” This is a good example of a bias in the value system. A programmer should write code that works optimally. And if it turns out that it does not work optimally, then the programmer should figure it out.
During the training, I wondered: “Which programmers are the coolest? Whom is any super corporation hiring? ” Then I thought that first of all they take the Olympiad. Of course, there is nothing wrong with that, but victories at the Olympiads are indirectly related to work. Yes, olympiads can solve complex problems in a short time under stressful conditions. It is remarkable that practically every serious university has not one, but several teams of Olympic Games. As a result of tough selection, worthy people are at the top of the pyramid. But this process has its drawbacks:
- the guys solve extremely specific problems, which in reality are extremely rare - there are no more than 1% of them;
- what they do in a very short time is bad. Yes, this is an indicator of remarkable abilities and stress resistance, but in life applications are usually written not in such short time intervals, and not alone.
Biased value system
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 completely 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 get the impression that there is no collaboration . You think that you can go to a desert island, do science there, write brilliant programs, create masterpieces, and interact with someone is completely optional.
Over the past couple of centuries, society has become increasingly homogeneous in terms of education and civil rights. Many may find this statement controversial, but overall it can be said that society is becoming more humane. And in the past few decades, the idea of ultra-liberalism has been gaining popularity, according to which the state is considered exclusively as an institution for serving its citizens. On the whole, it’s a pretty pretty 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 a certain 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 onto the companies in which they come to work. This is a big mistake.
The next moment. Over the past 20 years, thanks to the Internet, various kinds of interest communities have formed and received very strong development. People create new languages, programming environments, components. As a rule, these societies are not created 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 will encourage you to develop the three great virtues of a programmer: laziness, impatience and hubris" ("We urge you to develop the three most important virtues of a programmer: laziness, impatience and pride") . It sounds very strange. At the same time, the author of the phrase, Larry Wall, had in due time to explain for a long 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 what happened. I’m not sure if it’s connected with one another or not, but instead of developing the Perl language, this community decided to create a machine for all programming languages and make Perl 6 through it. For several years the project changed several architects, and the Perl community split into pragmatists left over to Perl 5, and to the weird people who actually stumped the project.(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 at interviews they ask questions that have nothing to do with work. The strangest one was: “How do you feel about the work of Carlos Castaneda?” I replied: “I am not in any way. I know that such a person exists, but I'm sorry. " I 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 a certain dialogue, because a person will be forced to reveal his values, to 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 bothers you what you don’t like? This is very useful to know.
Collective
When I started working, I suddenly found out that in many companies personal qualities are valued almost more than professional ones. Very often one could hear that what was needed was not a “cool programmer” or a “cool coder”, but a “sane person”. This was a new requirement for me. I even heard that a number of companies used quite strange motivational schemes for me at that time: there was a goodwill coefficient, that is, employees regularly received an assessment for their goodwill - the size of the bonus depended on it. Sounds like utopia, but it's a reality. There really were such companies, and maybe even now.
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 large project do not happen because of someone else’s illness or because someone overslept. Usually the root of many problems is that someone did not work with someone. People didn’t agree when choosing a very important component, didn’t agree on any rules, and then everyone began to pull the blanket over themselves. Therefore, in a large project, it is very important to pump such a skill as cooperation. This is not the same as goodwill, although they are interconnected. The point is that a large project should live for years, but our self-absorbed baggage in the form of a displaced value system impedes this greatly.
What is a good programmer?
According to our engineers from London, a good programmer can be called a person who writes the correct, good, easy to read code, with a good design, who understands all the components for which the team is responsible. Also, the signs of a good programmer include the ease of working with him. Of great importance is the constructiveness of code review - code reviews from a colleague. In large companies, no code is committed to the repository unless your colleague looks at it. If the code does not meet the standards, or something is wrong with it, then the colleague should not give a trolling feedback, but explain what does not comply and why, and give some recommendations. That is, the dialogue should be constructive. This is partly evidence of goodwill.
Also among the qualities of a good programmer were the fact that a person should be effective in meetings. This is also very interesting. It would seem, how can one be ineffective in meetings with colleagues? We got together to discuss something. But when you start working in a company, you will realize that some meetings take up a huge amount of time just because people cannot make a decision or there is no facilitator who would manage the discussion process. Therefore, in a number of agile scenarios, stand-up meetings are used - standing meetings. Due to the fact that people get tired of standing for a long time, they try to work out a common solution as soon 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 predict costs, choose less risky ways. For example, if you want to use an interesting new technology (which you never used), and the deadlines are tight, then it’s better not to risk it, but to choose a solution based on proven technologies.
Signs of a good programmer include a productive pastime in the office. It seemed to me that a man worked in an office for eight hours. This is very optimistic. There are a lot of distractions, sometimes you just need to be distracted, read something, and study something. As a result, much less than eight hours is 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. You should at least warn colleagues in advance that the development process is not going exactly as intended, so that the team rebuilds something, changes some tasks, and is ready. You do not have to endure to the very end, and then at the time of the deadline say: "But I have nothing ready yet." It is necessary to plan your work, fulfill promises, adequately evaluate the timeline.
All these values are very simple, they seem trivial. But when I started working, my own system of values did not coincide in many respects with the listed criteria of a good programmer.
In any process, it is very cool to find a model, build it, find and try some attributes, twist them and see how the model changes. Let's take the size of the program and its lifetime as such an attribute. And as a model, I propose to consider programmers. Let's start with a lone programmer who did something useful. He realized that the user had some kind of problem, designed the interface, programmed the necessary functionality and laid it out somewhere.
Let's change our attribute: let our application be larger and live longer. There are quality problems. When the program is small, the likelihood of bugs is not very high. But with the expansion of the code base and the increase in the operating life, 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. The product should work the same on each model, but it may well turn out that the application does not work correctly on some tablet or smartphone. And in order to maintain user loyalty, you need to solve this problem 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 tear, but you need to fix it. And while you are solving one problem, people are cursing about others. So, a team appears - a few people.
Now it is important to design in such a way that it is easy to make changes so that the code is understandable. So that your colleagues can quickly understand your code and make changes if necessary. If several people work with the code, then you need to agree in advance on all the procedures for introducing a new one and correcting the old one.
Features of the "adult" development
If you have created a web application, and it has received a sufficient number of users, then it is necessary to ensure its round-the-clock operation. This means that you need to build support infrastructure, and it should be as simple as possible. If you create an application with many functions, then this is a different level of complexity - you have several groups of developers, each of which needs to determine its direction, establish a 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;
- a company consisting of departments consisting of groups.
In the transition from one step to another, other requirements come to the fore, the attitude to certain things changes greatly. What acts on a small scale, on a large one, may not work at all or even prove harmful. At one time, awareness of this did not come to me immediately, and it became a rather big discovery for me. I was adapting to the new value system. I think that almost all former students who start working go through this.
Team work
Large companies are faced with the question: how to help new employees adapt as quickly as possible, how to build the right culture? Basically, this problem exists when interacting with any community. You can accept the current needs of the members of this community and try to achieve your goals by hiding something, manipulating someone. Or honestly say: “Guys, you lived wrong. You have to do like this. On the one hand, the theater, on the other - the academy. ” Therefore, many companies specifically promote within their teams a value system, their own understanding of what a good employee is.
I want to give an example from real life. Somewhere in the early 2000s, a large Netflix presentation leaks into the network, the meaning of which is: “We will treat our employees as fully formed adults, and when we deviate from our view, we will explain: guys 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 one 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 it is the group that creates the product, and not you personally. And sometimes the choice is between the interests of the group and the needs of the company as a whole. If a group has developed a product, but for some reason you need to change it differently from what you thought was right, try to look at it from the point of view of the whole company. When making difficult choices, first of all try to understand what the company needs. As soon as the company reaches a certain size, there is a great risk of hazing or some privileged teams that are engaged in very interesting tasks, and give all the junk to beginners. This behavior is unacceptable if the company wants to create a healthy culture. what the company needs. As soon as the company reaches a certain size, there is a great risk of hazing or some privileged teams that are engaged in very interesting tasks, and give all the junk to beginners. This behavior is unacceptable if the company wants to create a healthy culture. what the company needs. As soon as the company reaches a certain size, there is a great risk of hazing or some privileged teams that are engaged in very interesting tasks, and give all the junk to beginners. This 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 jerks”). No matter how gifted the employee is, if he doesn’t work with people, he will have to say goodbye.
The next moment. Any company allocates certain budgets, and there are two approaches: either you begin to regulate this, or say: “All adults. We will not come up with 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 are moving to work from Moscow to London. The easiest way to report on funds spent is to provide checks. But there can be a lot of them, because maybe a lot of small expenses. To do this, you need to select a person who will then deal with these checks. Or you can do it differently: “Here is the amount for you, you can dispose of it as you like, don’t report, just don’t come to us with a trifle”. As a result, the company does not need to spend time checking each check, while we save on transaction costs,
I want to mention the rule "50 to 50". When it is a choice who should bear financial or time expenses, who should be responsible, often employees consider that all expenses should be borne by the company. 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 “50 to 50” rule is very simple: you can spend the entire working day on a flight (I went on a business trip — it's work), or you can work half a day, and spend half a day on a trip. You will arrive a bit later, check into a hotel in the late afternoon, but will not leave you. I worked 50% of the time, 50% took away from this time for the flight.
This helps to get rid of many prescribed rules. We can say: “Guys, we are adults - let's be responsive to each other, to the company and to the costs. If everything is regulated, then this will not benefit the internal culture of the company. A lot of rules are very tiring. ”
Search for the best share
In many companies, employees are told: “Working with us, you can go for interviews without fear. Sell yourself more expensive than you get. Find out what the current market situation is - this is what determines your salary. If you have any unique skills, most likely they will be in demand. Walking the market is absolutely normal. If they offer you 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. Everyone, in general, is happy. Hi".
This approach is quite effective. Of course, you should not tell everyone about how you were there yesterday, here today - this does not affect the team very well. But keep in mind that you need to walk around the market to understand the current situation.
After all, human psychology is designed so that, no matter how much money you receive, at some point it will begin to seem to you that you are being underpaid. Especially often this idea comes to mind when a person suddenly finds out that another company pays more. “So they deceive us here! Actually, what salaries are cool. ” That is, the conclusion is made in one dimension, without any adequate statistics. Therefore, all that an employer can do is say: “Go to other places, find out, understand whether this is really an average situation in general or for the most gifted. We’ll see if they will offer you, maybe you really cost so much. ”
To summarize the above: get rid of old baggage, look around, interact with people, create a joint project, feel that the strength lies in collaboration and communication. Learning how to work in a team is task number 1, especially if you have already started working.
Personal productivity
The x-axis represents the abstract “external pressure,” which usually comes from your company, from colleagues, from superiors. The Y axis indicates your productivity. Two variants of the graph: “without detonation” and “with detonation”. If someone or something is pushing you - that’s good. This usually helps to increase your productivity. Another thing is that there is a certain psychological limit, different for everyone. And if you cross it, then nothing good will come of it: either productivity will simply decrease, or it will decrease stepwise, very much. Increasing productivity means managing yourself. To manage yourself is:
- planning: plan for yourself the goals you need to achieve. You cannot be productive if you have no goals;
- organization: if something impedes the implementation of the plan - remove or change;
- motivation: you need to motivate yourself;
- control: track the result at intermediate points.
In fact, these are the four functions of any management, this is true for managing both the team 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 faster? Try to start doing this as soon as possible.
Self-discipline and self-control are associated 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 at all. When they are pushed from the outside, they perceive it as aggression, and instead of changing, they leave, run away. I’ll tell you more about running away later.
To make it easier for yourself and your colleagues to plan goals, you can use the principleSMART
- S - specific. Each goal must be specific. That is, specifically here we need to do this.
- M is measurable. The goal must be measurable. An example of 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 - 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 sub-goals, a certain number of specific steps, and the more realistic they are, the more you will develop a positive attitude towards this method.
- R is relevant. When planning any tasks, you must be aware that their implementation will help you achieve your goals.
- T - time-related. Any goal should have some deadline - the deadline by which everything should be done. Of all five points, this is the most important.
For programmers, the biggest problem is deadline. There are even those who say: “Guys, let's conduct the development in such a way that we simply do not have deadlines. Deadlines are stress. ” Probably, such people achieve something in life, but I am convinced that with this approach there can be quite a lot of unplanned losses. If you really want to be productive, each of your goals must be determined by a certain term. You can break this deadline, but then you can ask yourself the question: “Why didn’t I meet the deadline? How far have I not fulfilled it? What could I do to do it 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 different components have weak coherence. So with setting goals for yourself. The less connected you are, the less likely it is that due to braking or inoperability of one component, the achievement of all other goals and objectives will stall. If you are building any complex plans and understand that you have complex relationships, you can decompose and revise the list of goals.
Often we fall into the trap of our optimism: “Okay, let's move forward. "We don’t fully understand some things, but we will definitely cope with this, we will do it." This approach - I see the goal, I see no obstacles - is very important. But if you are an overly optimistic person, then you have some gray areas in your plans, about which you say: “Hell knows how to do this.” And it doesn’t matter what exactly will be discussed: performance, quality, support, etc. Then it turns out that this gray zone 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 ensures that this part of the work is completed on time.
Manager Interaction
When the leader came and set you some task - this is a shift of responsibility. And all that he wants in this situation is to make this switchover as clear as possible, so that there is no misunderstanding: the manager thinks that responsibility has been switched, work has begun, and you have a lot of questions, and you are waiting for their clarification, but no one is working not accepted. In such a situation, responsibility is often shifted to each other - this is not clear, this is not clear. This happens not only between the leader and subordinate, but also between colleagues. Such situations are unpleasant and lead to temporary and emotional loss. The most important thing is to grasp and overcome the desire to “recapture” the transfer of responsibility. If you really want to clarify something, then ask all the questions, and then say: “Yes, I have accepted the task and am going to do it.”
But the leader wants more than that. He wants you to come to him. Very often people say: “Nobody needs anything from me. I’m sitting quietly here, studying something. ” You can’t imagine how many leaders would support any of your new beginnings or ideas if you would come and prove that they are really needed. A huge number of good projects are done on enthusiasm, because they were born in your head. And the only thing that needs to be agreed on the shore is whether it will be in demand. So that the leader does not tell you: “Listen, for some reason we cannot do this.”
I highly recommend you to be proactive from the very beginning. The initiative is punishable in the army, and in ordinary life a huge number of leaders dream that you open the door and say: “Listen, I came up with such a cool thing.” You will be given opportunities and you will be happy doing your work. The reverse situation: there is some kind of problem, and you are silent about it - this will lead to missed opportunities. It’s enough just to talk, discuss, compare values, change something, transfer you to another project, help you with something. But if you are silent, then the project may have many problems.
Of course, there are objective problems with which, most likely, nothing can be done. Firstly, this is the so-called "context switch." I will explain the example of multitasking in operating systems. After all, there is multitasking even on one core - for this you just need to crowd out one process and load another. A certain conditional kernel program is responsible for the operation of several parallel processes. We divide all the time into some quanta and give each process one quantum. Switching running processes is called context switching. But, for example, there are situations when you have many simultaneously living processes, inside of which a large number of switches are initiated. That is, switching can greatly affect system performance.
Plunging into work at the beginning of the day, you do not immediately go to the peak of productivity. After some time, the phone rings, a colleague approaches, the messenger blinks, a letter arrives - you switch, do something. But even if it took a minute, returning to the previous task, you will have to remember something, dive again, and it takes time. We can say that this is an analogue of context switching.
What to do about it? Reduce the number of switching between tasks, negotiate with colleagues and management about changing some procedures in order to less often be distracted from tasks performed. Turn off all sorts of notifications, check mail on a schedule or at least less.
The next objective factor is when you have to deal with completely unknown things in your work. There is a natural rejection: “Well, the story is not completely clear to me. I need to know this, this and this. ” And the task, most likely, involves a creative approach - that you think out some things yourself, and not push the task. As in physics lessons you can sometimes hear from the teacher: all that is is given. That is, build the model yourself and decide what you need and what not. These are wonderful tasks, do not be afraid of them, you can think up the conditions yourself from general considerations and correct the situation.
And now that is almost impossible to fix.
- In large companies, product managers are usually not those who directly write code and come up with applications, so a stream of constantly changing requirements may come to you. You need to be able to talk with such people. The most common mistake is approximately the following: the person who sets the task assumes that he has made only a small change and that the terms will not change. “Just think, somewhere here next to a small site a small online store has grown. Full of the same online stores. Surely there is something ready. To fasten - half an hour of work. " It is very important that all changes are made in dialogue mode. So that the culture in the company implies that all participants sit down and acknowledge that the introduction of changes is likely to lead to a time shift.
- It happens that you have a very tough deadline and you just need to be in time for such a date. This means that you need to re-prioritize tasks. The objective problem of how to deal with it is more or less clear, but this is one of the most common and difficult stressful situations in which you just need to learn how to live.
About running away
Finally, let's get back to running away: when we don’t like something, and we try to avoid it. There are different cases. For example: "I do not want to develop a user interface, I want to do a backend." Such a runaway is permissible if a person has special abilities in system programming, if he wants to pump like devops, etc. Many companies have a small number of people engaged in either tasks in the field of system programming, or automating the calculation, release engineering, etc. But such tasks are not very many. Moreover, such a runaway is fraught with sitting in a "dusty corner", because in most companies the main value is to make a product, that is, to satisfy the user. If you do not want to engage in a user interface, you are running away from the product, that is, you start doing side things. This in a way reduces your value to the company.The next runaway option: “Too much control, too much pressure, I don’t want that. I want to work from home. ” There are many teams that work remotely. It seems that working this way is more convenient, more efficient and more comfortable. But you need to understand that if you are comfortable, it is not at all a fact that you are as productive as possible. If there is no control, then most likely there is no effectiveness. If the idea of remote work occurred to you, then I would highly recommend talking to the leader. Maybe you can find some more effective ways to interact.
Row measurement
Programmers terribly dislike control. Despite the fact that it is important that there will still be control, programmers do not really like this. And the programmer’s worst dream is if they begin to measure its performance in the number of lines of code. But some things, oddly enough, can be measured in lines of code! For example, test coverage, how much coverage increases over time for different teams, which team is great, and which is not very good. Or, before some big release, you can measure the speed of introducing new lines of code into the repository in order to assess whether most of the changes really concern bug fixing, or still the team still commits new features. In the latter case, it is more likely that the release would be wise to slightly move, if possible, of course.
Self learning
Even when working with shareware technologies, there are a lot of things that you can pump. For example, you are working with a MySQL database. Learn how it works internally, what is its architecture, how to optimize queries, how to make your circuit efficient on a lot of data? All of the above will be enough for a year of self-study, if not two. And this will become a very useful skill for you, because you will learn how to create applications of a completely different level.
Often, when a programmer is just starting his career, he says: “Oh, damn it, programming patterns! I will apply such and such patterns. I’ll write object-oriented code, which through my ORM layer will automatically turn into SQL, my ORM tool will automatically work with all data storage. ” Or, “Damn, why do we write in this language? Look, there’s another cool language around the corner. ” Or here is a quote from Habr: “I love Python the way it is - smart, concise, has a lot of useful things out of the box. For example, you can find out if a number is a polymorph in just one line. " Many languages, patterns, ORMs are not the most important, and I would advise you to learn other things.
To begin with, how money is made in your company. This will immediately give you an understanding of what is important for the company and what is not - at least at a general level. This will help to relate the values of the company to their own.
Further study the standards and approaches adopted by your company. For example, how to work with errors. The code should be written so that in case of an error it was possible to pick up all the necessary information and find the reason. But sometimes the code is written in such a way that it is generally not clear what happened. You know that there was a problem, and in what - it is not clear. Sometimes the logs are not collected at all, no one looks at them. In any company, a certain style of working with errors is developed. You need to study it and match it.
Learn to communicate - online and in meetings. Sometimes we think that online we can afford some other communication style - we don’t need to do that. Learn to be as useful as possible at meetings, and direct meetings in a constructive way.
The next very important skill is to learn how to quickly make a pilot version. When we undertake development, a perfectionist sometimes works in us: “It’s better to spend more time, but I’ll do everything cool.” In fact, it is important to make the pilot as fast as possible, even with crutches, then you can always redo them. But you will spend a lot of time creating a pilot, and then it turns out that he is not needed - it will be very disappointing.
Learn not new programming languages, but the infrastructure associated with your work. I do not urge you to become system administrators, but you can become a system administrator at least localhost - it will open up a lot of opportunities for you.
If you work with a database, there are a lot of directions here - find out how it works, how to configure it, read the manual for the system administrator. Any such dive will give you an understanding of how the database is organized, how to prepare it.
And finally, the most important thing: wherever and on whatever device your program works, there will always be performance problems. It is advisable to be able to figure out what affects the performance and how you can speed up the application.
New technologies
We want to study them, this is our need, we want to implement them in our products. But one thing is when we make an application for ourselves, another thing is when we offer some new technologies in a team. A lot of conflicts arise precisely because we hoped to use some kind of technology, and for some reason we were not allowed to introduce it, so we need to rewrite something, redo something. So, in order to avoid such conflicts, I recommend just looking at the new technology from this perspective: any change has a certain cost and certain risks - this is how life works. When replacing one technology with another or when choosing one technology from several, there is also a risk. These risks are very simple: increased complexity, closedness or openness of technology with all the ensuing consequences like training,
There is also the concept of quality. Technology can be very cool, but can be very dependent on maintenance. If this is one person, then everything depends on his personal qualities. For example, how quickly it will respond to bug reports. Even such things must be considered when choosing a technology. Finally, different dependencies are important when one technology depends on the availability or availability of another technology or product. The more complex the system, the greater the likelihood of failures. The more dependencies, the worse.
Now the financial question: is the cost of transition and the cost of support. You wrote in one language, offer to switch to another. As a rule, one simply cannot change the language, there is a certain machine, it is built in somewhere. And the product or service where it is built may work well for one community simply because it is larger. Or due to the fact that many large companies used it at random to the production, and all identified bugs have already been fixed. In the server side area, support is almost half the work that a large organization does. Therefore, the cost of support is no less important than the cost of development.
If you offer any new technology, then you need to enlist the support of a sufficient number of colleagues. In large companies, there is a rule: “We develop in different languages, but only those languages in which at least a certain number of people develop” fall into the standard set. Why is such a restriction imposed? It often happens that an employee initiates a migration to another language, starts to drag everyone, and in the middle of development, he suddenly loses interest and leaves. The project is in a completely collapsed state, because the main enthusiast has left, and other programmers speak this language still poorly.
There is such a thing as “ technical duty". If you are focused on the fastest release of the product, then your technical debt is growing. It is very important to understand: if you choose a solution between a crutch, the right one and a good one, then a crutch solution will increase your technical debt. In this case, put the task in the backlog. When you will be more free in terms of features, get it, do refactoring. If, from the very beginning, you try to do everything well and correctly, then perhaps your product will no longer be needed by the time it is completed.
What to read
I recommend reading, first of all, the blogs of programmers and developers. And as soon as possible to reach out to people who can become your mentors. As long as you have the opportunity and desire to read, read more. Then life will be such that, most likely, you will have neither time nor desire. Therefore, the more you read now, the better. As for books, there are a great many of them ( 1 , 2 , 3 , 4 ). Now offhand I can identify five books:
- "Introduction to Database Theory." Posted by Date. A lot of programmers work with SQL, but they don’t know some fundamental things.
- "The practice of programming." The authors are Pike and Kernigan. There are many examples in C, but it is quite simple. And if you did not have a computer science course, then this book will help fill in the gaps. A very good and very simple book.
- "Mythical man-month." Very good book. It is outdated, in fact, but, nevertheless, a lot of things are still relevant to this day.
- "From good to great." Posted by Collins. The book is about what good companies are, what great companies are, how they differ. A very interesting and subjective vision based on a consistent interpretation of real experimental data.
- "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 person who makes a trip on a motorcycle, repairs it himself and writes a lot about how he does it, how it goes over, which is important in caring for a motorcycle. All the values that a person scrupulously writes out can be transferred to any technique, and to the relation to software, and to the role of a system administrator, and to the role of QA.
I wish all students to build their future work in such a way that you are as comfortable as possible, and that you effectively and quickly join the real processes at your future work place.