What Lida is silent about: the beginning of a developer's career. Principles or how to become Middl'om

Hello! Programming is not an easy subject, and industrial software development is very complex. In our IT industry, it is not so rare to hear questions from junior colleagues in the series “how can I develop?”, “What do I need to do to become a high-level professional and as quickly as possible?”, “What to do if it doesn’t develop, but There are no interesting projects? ”,“ What should the middle one know? ”. If you have from 0 to 3 years of experience in IT, you are an aspiring specialist (or are just going to become one) and set yourself similar goals for professional and career growth, looking for the right ways, how to achieve these goals - this post is good for you complain under cat. It may also be of interest to team leaders and managers, in general, to all those involved in the training and development of specialists.

For starters, let me introduce myself. My name is Anatoly and if I omit posts and ranks, then first of all I am a Developer, because in the broad sense of the word I have been engaged in the development, research and management of developers. My experience in the industry 10+ years. It is quite diverse and extends from financial systems and web sites to products, algorithms and machine learning systems. The main thing, however, it seems to me, is that I myself was on the site of the targeted readers of this article and subsequently began to engage in various aspects in the development of young programmers. At the moment, more than 2 dozen junior developers and interns have already passed through me. Therefore, I think that I have something to talk about. A large number of materials on the subject under discussion, which can be found, are devoted either to purely technical topics or, for example, to almost blindly following Scrum. (such as “if you don’t know what to do, try to work on scrum and everything will hurt” :)) It would not seem like the realities and statistics of individual teams and specialists, these are not all things that make up the practice and culture of software development. Therefore, thinking about what to write about, I decided that I would not repeat this information, but rather try to focus on topics that I don’t write or speak about so much. Go!

Yes, as a disclaimer , I would like to say that the described is my personal opinion, confirmed by experience and theoretical knowledge, which were tested on this experience. It may not correspond to the reality in which you find yourself, so let me give you the first piece of advice right away: first of all, in any difficult situations, it is worth analyzing its construction, before applying any known practices and patterns like “if then. " Details are very important. Now - let's go! :)

1. Wide vs Narrow Specialization

Often, people who just want to learn how to programm ask themselves which technology to choose for studying, and generally, in which PL, roughly speaking, “it is better to write code”. People who get their first job think about whether their current technology will be promising and in demand in a couple of years and more. (some do not think at all, but this is often not good) “ Better ” and “more promising ” here are very subjective concepts, defined at the level of sensations and possible benefits for a future career. Quickly enough for IT beginners it can become clear that many projects are being done on a fairly large number of technologies, and it's impossible to know everything. So is it necessary to chase after all the hares?

For example, in the first year of work I received a valuable remark from my team leader that it was necessary to focus on one area, because the specialist is either a specialist or, roughly speaking, not an expert in anything. To know something at a high enough level, it is necessary to deal with it constantly and to delve deeply into the details - it's true and hard to argue with that. And indeed, practice confirms this: the majority of specialists known to me (who can be considered as such) are narrow specialists. Some of them simply brilliantly know their Subject and therefore solve problems of unprecedented steepness within it. At this point one could say “OK, then the principle is correct - everything fits”, if not for a few BUT. The fact is that the range of projects where such narrow specialists will be in demand is much narrower than, of course, more wide-ranging specialists. More than once I have met projects, participation in which would be simply impossible without the availability of broad knowledge of several technologies at once. People who possessed this knowledge discovered new, sometimes inaccessible doors. And participation in an excellent, unique project is a very serious and useful career test that can bring you a lot of valuable experience and other benefits. The second BUT is that the world of technology is constantly changing and strictly limiting oneself to knowledge of one or two technologies or PL, one can naturally begin to lose a competitive advantage and become a less demanded specialist.

So, briefly, you can say this: do not be afraid to try the technologies that you like! Perhaps you will not become an expert in 3 programming languages ​​at once, or in 5 frameworks, but knowledge of their fundamentals and internal structure is a serious competitive advantage if, all other things being equal, you get a job that requires a strong knowledge of 1 technology and base several others. The main thing here is measure and restriction. It is important to clearly define priorities, to study what technology you spend most of your time, and what time remaining to study.

2. Functional area

From specialization in programming languages ​​and development technologies, we smoothly move on to the next important thing - the functional area . It is easy to give an example from life: as doctors have dentists, but there are cardiologists, there is a specialty among developers, and the discussion here is not only about the aforementioned technologies or programming languages. Developers specialize in different ways: someone deals with user interfaces, someone processes data in clusters, someone recognizes images, and someone writes logic for a game bot. A lot of examples.

Perhaps in the first 2 years of work or even more, you will not be bothered by the issue of specialization, since the entry into projects and technologies for which you will be taken will take considerable time, and this question will simply not be relevant to the natural way. However, starting from a certain point, you will feel the ease in solving more and more complex tasks in a certain area, and the result will be determined in many respects no longer by the degree of how detailed, for example, you know the standard library of the PLs with which you work, or how masterfully you own the advanced syntax of this PL, and your experience in a specific functional area. Computer graphics, computational linguistics, financial programming are all specific areas for the study and acquisition of practical experience in which months and years are spent. If you set a goal to become a high-level specialist, find the area that you really like. And if you really like it - develop and work in it with pleasure, and everything will work out!

3. Mentors and self-study

There are no two completely identical projects. There are no identical commands. Sometimes there is no one correct solution, be it a global decision on the architecture of a large part of the system or a local decision on how to store files in the repository. Before the novice specialist gets a lot of questions and doubts. Questions to which, due to lack of experience, may not immediately be answered. You have received ready-made code and it does not work at all, although other colleagues are fine; The service installation procedure in 1 case out of 6 ends with an error - and at least kill yourself, but it is not clear why; You cannot configure the network part of the service, although you do everything according to the instructions and have read it 7 times already. Such situations for developers, testers and admins occur constantly. The degree of complexity of the problems can vary from the level of "probably, you need to dig somewhere there" to "where to dig - it is not at all clear." The first advice, which is well known and given by experienced specialists (and, surely, you have already heard it from them) is that you need to learn to understand the problems as much as possible when you get into them. As a rule, it is necessary to concentrate on causality and learn to formulate the right questions about the problem. In the first place - to himself, and secondly - to Google. It’s not just “everything doesn’t work”, even if you are sure of it, try going back to the beginning to find the real cause of the problem. And, most likely, you are not the only one with a similar problem, just google and see for yourself. Further, the following simple advice: only after you have made several unsuccessful attempts and analyzed the problem yourself, spending significant time (usually measured in hours, sometimes in days) - contact your senior colleagues. So you will not spend their valuable time solving a foolish question that you yourself could easily have solved by applying a great deal of perseverance. In this way, you will demonstrate that you have developed the right approach to solving problems. Many problems that seem at first glance complex and incomprehensible, are solved by Google in the literal sense in 5 minutes.

But to speak is easy, but in fact, insufficient knowledge of development technologies and lack of practical experience will be a very painful factor. Therefore, the correct task number 1 - is the study of technology development and examples of their use in a fairly intensive mode. And again: it is easy to say, but in fact teaching materials dofig and more, not all of them are understandable, not all of them are relevant, not all of them cover the problems that will have to be solved on the project in practice. And this is where the environment can help. Being in the team of “experts” who not only have a high level of knowledge, but are also willing to share this knowledge skillfully - this is the best thing that can be at the start of a career. Yes, everything is correct, you should first of all focus on self-study, but one way or another, you will have a natural speed ceiling. To overcome it and help competent mentors . However, before you turn to them, ask yourself the question: are you stuck exactly and cannot move forward on your own in solving the problem at least a step?

Total: look for a job, where there are people who know the Subject and are interested in seeing you know it better too! This will allow in a fairly short time to significantly improve the level of your expertise. Avoid places where you are not ready to share knowledge. 4 years of work in such a place will be equal to two (and less) in another.

4. No silver bullet

Work in the IT industry is a constant dialogue, a dispute, sometimes a struggle of opinions, and sometimes a war of principles. Believe me, you will meet quite a few people who will convince you that they and only they have the most correct decision or opinion, supporting or not supporting it with facts. Sometimes this feeling will burst you too!

Is it possible or impossible to complete the task within the specified time? Which is better: technology A or technology B for task C? What methodology should develop the project and organize the process of work? Is the written code good enough and is it time to stop polishing it or does it still need refactoring? Is it possible to lay the possibility of expanding the system from the very beginning, even if the expansion is not expected, and you don’t see the whole picture from your junior developer ’level? How to properly evaluate the quality of the product and what role in this process among developers? And a dozen or two other similar questions.

Under frequent, these and many other issues it is impossible to give an unambiguous solution in a particular situation. I would like to have it, but sometimes it is simply not visible objectively, because the level of uncertainty on a project can be quite high. In a sense, this goes against a single unspoken culture widely adopted in programming: the constant search for and the supply of better solutions with the help of more advanced technologies. We constantly instinctively force ourselves to make decisions based on incomplete data.

And it is here that programming in its microcosm and the development of IT projects on a large scale cease to be any number of exact disciplines and begin to be an art. Art is based on principles and approaches, it is determined by them.

When completing the next project or a less massive task, look back and analyze: what principles helped this task or this project to come to success (or vice versa - to zafeilitsya)? Was it a matter of what programming language was chosen and how it came up wonderfully, or maybe the level of interaction with your customer or partner was so good that you could do the task most of the time without wasting time on communication costs? Constantly analyze, look for new principles and consult with mentors how to see and define these principles.

5. About large and small companies, about IT and not IT

Many young professionals want to work in the companies about which they heard, the products or products they used. In some Epplah, Google or Microsoft (a good term recently appeared - “Guyandbuk”) or their Russian counterparts (as far as possible). Starting a career in a big company is a very, very valuable experience. (You especially understand this on the 11th year of this very experience :)) See how a large company works from the inside, and how processes are organized in it - believe me, it's worth it. Probably, it is difficult for me to imagine something better than a set of a large IT company and an intelligent team at the start of a career. However, there is always a BUT.

The first BUT is that a “large IT company” is quite different from just a “large company” (especially in Russian realities). If you have a choice, go to a small or medium-sized IT company or go to a large non-IT company (for example, a bank or some other financial or trading company), you should understand the possible consequences. And the worst-case consequences will be the following: if the IT company closes or you want to leave it, you leave with knowledge and principles. If you want to leave a non-IT company for an IT company, then for several reasons this will be more difficult. This may be the lack of necessary and relevant experience, and the specificity of projects and the pickyness of recruiters and hiring colleagues to your past jobs (remember the company Pearson Hardman from the famous TV series, which hired only from Harvard. Such stories are not uncommon in reality. Type "hire only from product companies ", etc.). In companies where IT is not the main type of business, everything literally revolves around this business. The result is very important, the process of achieving it is much less important. But it is the right process that lays down the right principles, which then will help you to make decisions and produce something very high-quality and complex at the exit in quite complex projects. If you produce something qualitative and useful - this is your goal, consider this.

6. Grocery and outsourcing companies

One of my favorite themes since I worked both first and second. Continuing the topic of pickyness, there is a definite opinion in the industry that working in grocery IT companies is not only more prestigious, but also monetary, and a set of the most interesting projects that can only be found is attached to this. Work in outsourcing on projects under the order, according to some experts, is a class below. Is it true or not?

I will answer: no. Not so simple.

The main advantage of product companies is that when a person comes there, he actually has the opportunity to choose a project / product or field of activity, with all the consequences (for example, the ability to work on truly unique and complex tasks). One of the main consequences: you will develop YOUR product, making it better every day. It will not always be easy to go the way you want, but this is your product. You largely influence his success, at least at your level.

In outsourcing companies, however, an employee usually does not have such a choice, and moreover, from time to time he is forced to sit on pins and needles in a certain sense because of this. Integrators and outsourcers are engaged in those projects for which they pay money here and now. Not all such projects will be of interest to a certain class of programmers. , , , .
— legacy ( ), . — . 5 . , , , .

7. vs

. : . , . , , . , – . , ( ) , . , , , . , . , , () () . . ? – . – . , , 2 : ) ) ( ). : , . , . , , , , , . – .

: - ( - ) , - . - , ( — , ) – .

8.

. , , - . - , . , , , . . . , . , . — . .

— , , , , . , , , , ( ), : , — , , .
? , ? .

, ? : , , , , , , , .

9.

(, ) , backend . (, Web , ). - . , ? , . , . , — . — . , . : , , . . , . , , . . , : , , UX/UI — , , , , .

10.

: . . - : , .

, , . : 1.5-2 . , , , , . . , 1-2 , - . — 4 , ? : , B. , . , , . , . , , — , , . , , , , .

: 1-3 , , . : skills 3 — 1. , — 2. — 3. , , , , 4 , , .

Conclusion

— , , . , . , , — . . , , ! , : ) hard skills ) c ) . , !

PS: . , , , .