Hello!
Programming
- This is a difficult subject, and
industrial software development
- very complicated. In our IT industry, it's not uncommon to hear questions from younger colleagues in the series "how do I progress?", "What should I do to become a high-level professional and as soon as possible?", "What to do if you can not develop and There are no interesting projects? "," what should the middle know? ". If you have 0 to 3 years experience in IT, you are a beginner specialist (or just going to become one) and set yourself similar goals for professional and career growth, looking for the right ways to achieve these goals - this post is for you, good complain under cat. Perhaps, it will also be interesting for timlids and managers, in general, all those who are engaged in training and development of specialists.
 
To begin with, let me introduce myself. My name is Anatoly and if I omit posts and ranks, first of all I'm a Developer, because in the broadest sense of the word my whole career was engaged in the development, research and management of developers. My experience in the industry is 10+ years. It is quite diverse and extends from financial systems and web sites, to products, algorithms and machine learning systems. The main, however, it seems to me, is that I myself was on the site of the target readers of this article and subsequently began to engage in various aspects of the development of young programmers. To date, I have already passed through a total of more than 2 dozen junior developers and trainees. Therefore, I believe that I have something to tell. A large number of materials on the discussed issue that can be met are devoted either to purely technical topics, or, for example, to the almost blind adherence to Scrum. (like - "if you do not know what to do, try to work on scrum'u and everything will be overwhelmed" :)) However it would seem from the realities and statistics of individual teams and specialists, this is not all of the things that make up the practice and culture of software development. Therefore, thinking about what to write, I decided that I will not repeat this information, but rather try to focus on topics that are not much written or spoken about. Go!
 
Yes, as
of the dislamer
, I would like to say that this is my personal opinion, confirmed by experience and theoretical knowledge, which were tested in this experiment. It may not correspond to the reality in which you find yourself, so let me give you the first piece of advice at once: first of all, in any difficult situation, it is worth analyzing its design, before applying any practices and patterns known to you "if, then. " Details are very important. Now - let's go! :)
 

1. Wide vs Narrow specialization

 
Often people who just want to learn how to program are wondering what technology to choose for learning, and indeed in what YP, roughly speaking, is "better to write code." People who take their first job think about whether their current technology will be promising and in demand in a couple of years and beyond. (some do not think at all, but this is often not good) "
Better than
"And"
more promising
"Here - these are very subjective concepts, defined at the level of sensations and possible benefits for a further career. Fast enough for newcomers to IT can become clear that many projects are made on a fairly large number of technologies, and it's impossible to know everything. So should you chase after all the hares?
 
For example, in the first year of work, I received a valuable observation from my timlide that it is necessary to focus on one area, because the specialist is either an expert or, roughly speaking, not a specialist in anything. To know something at a sufficiently high level, it is necessary to engage in this constantly and deeply to delve into the details - it is true and it is difficult to argue with this. Indeed, practice confirms this: most of the experts known to me (who can be considered such) are narrow specialists. Some of them just brilliantly know their subject and therefore solve the tasks of unprecedented steepness. At this point you could say "OK, then the principle is correct - everything converges", if not for a few BUT. The fact is that
range of projects
, where such narrow specialists will be in demand substantially already, than, it is clear, from specialists of a broader profile. More than once I met projects, participation in which would be simply impossible without the presence of broad knowledge in 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, which 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 itself to knowing one or two technologies or JA, we can naturally begin to lose the competitive advantage and become a less demanded specialist.
 
In short, 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 frames, but knowing their fundamentals and internal device is a serious competitive advantage if, other things equal, you get to a job where you need a strong knowledge of 1 technology and basic of several others. The main thing here is a measure and a restriction. It is important to clearly prioritize which technology you spend most of your time studying what remains.
 

2. Functional area

 
From specialization in programming languages ​​and development technologies, we smoothly pass to the next important thing -
functional region
. To give an example is easy from a life: as doctors have stomatologists, and there are cardiologists, and among developers there is a specialization, and speech here at all not only about the above-mentioned technologies or programming languages. Developers specialize in different ways: someone deals with user interfaces, someone processes data on clusters, someone recognizes images, and someone writes logic for a game bot. Examples of a lot.
 
Perhaps in the first 2 years of work, or even more, you will not be bothered by the issue of specialization, since the entrance to the projects and technologies that you will get to will take significant time, and this issue will simply not be relevant in a natural way. However, starting from a certain moment, you will feel the ease in solving more and more complex problems in some area, and the result will be determined in many ways not by the degree of detail, for example, you know the standard library of the IP with which you work, or as a virtuoso you own the advanced syntax of this YAP, and your experience in a specific functional area. Computer graphics, computer linguistics, financial programming are all specific areas, for studying and gaining practical experience in which months and years pass. 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 turn out!
 
3. Mentors and self-study
 
There are no two completely identical projects. There are no identical commands. Sometimes there is no single right decision, whether it's a global solution for the architecture of a large part of the system or a local solution for storing files in the repository. Before the beginning experts there are many questions and doubts. Questions that, due to lack of experience, can immediately not be answered. You got the ready code and it does not work at all, although other colleagues are fine; the procedure for installing the service in 1 case out of 6 ends with an error - and at least kill, but it's unclear why; you can not configure the network part of the service, although you do everything according to the instructions and re-read it 7 times already. Such situations for developers, testers and administrators occur all the time. The degree of complexity of problems can vary from the level "probably, it is necessary to dig somewhere there" to "where to dig - it is completely not clear". The first advice, which is well known and given by experienced specialists (and, for sure, you already heard from them) is that you need to learn how to independently understand the problems when you get stuck in them. As a rule, it is necessary to concentrate on the causal relationship and learn how to formulate the right questions about the problem. First of all - to yourself, secondly - to Google. It's not just "everything does not work", even if you are sure of it, try to return "to the beginning" in order 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 it. Further, the following simple advice: only after you have made several unsuccessful attempts and conducted an analysis of the problem yourself, having spent a significant amount of time (usually measured in hours, sometimes in days) - contact your senior colleagues. So you will not spend their valuable time on the solution of the nonsense question, which you yourself could easily solve by applying more perseverance. Thus, you demonstrate that you have developed the right approach to solving problems. Many problems seem at first glance complicated and incomprehensible, are solved by Google in the literal sense in 5 minutes.
 
But speaking 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 development technologies and examples of their use in a fairly intensive mode. And again: it's easy to say, but in fact training materials dofig and more, not all of them are understandable, they are not all relevant, they do not cover all the problems that the project will have to solve in practice. And here you can help
Wednesday
. To be in the team of "experts" who not only have a high level of knowledge, but are also ready to share this knowledge with skill - this is the best that can be at the start of a career. Yes, everything is right, you must first focus on self-study, but anyway, you will have a natural speed ceiling. Overcome it and help competent
mentors
. However, before contacting them, ask yourself the question: have you been stuck and you can not move forward on your own in solving the problem even by one step?
 
Total: look for a job where there are people who know the subject and who are interested in making you know him better! This will allow you to significantly increase the level of your expertise in a fairly short period of time. 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. There is no silver bullet
 
Work in the IT industry is a constant dialogue, a dispute, sometimes a fight of opinions, and sometimes a war of principles. Believe me, you will meet many 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 and you yourself!
 
Is it possible or impossible to make a task within the specified period? Which is better: technology A or technology B for task B? On what methodology is it worth developing a project and organizing the work process? Is the code good enough and it's time to stop polishing it, or does it still need refactoring? Do you have the option to extend the system from the very beginning, even if the extension is not expected, and you do not see the whole picture from your level of junior developer? How to properly assess the quality of the product and what role in this process the developers? And a dozen or two different similar questions.
 
Frequently, these and many other issues can not be unambiguously resolved in a particular situation. I would like to have it, but sometimes it simply can not be seen objectively, because the level of uncertainty on the project can be quite high. In a sense, this is in the context of one unspoken culture widely accepted in programming: the constant search and suggestion of better solutions with the help of more advanced technologies. We constantly instinctively force ourselves to make decisions based on incomplete data.
 
And here programming in its microcosm and the development of IT projects already on a large scale cease to be any exact disciplines and begin to be art. Art is built on principles and approaches, it is determined by them.
 
Completing the next project or a more massive task, look back and analyze: which
Principles
helped this task or this project to come to success (or vice versa - to get drunk)? Was it the question of what programming language was chosen and how it miraculously came up, or maybe the level of interaction with your customer or partner was so good that you could deal with the task most of the time without wasting time on communication costs? Constantly analyze, look for new principles and consult with mentors, how to discern and define these principles.
 
5. About big and small companies, about IT and not IT
 
Many young professionals want to work in companies they heard about, the products or products they used. In some Apple, Google or Microsoft (recently a good term appeared - "Guyandbook") or their Russian counterparts (as far as possible). Starting a career in a large company is a very, very valuable experience. (Especially you understand this for the 11th year of this experience :)) To see how a large company works from within, 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 a sensible team at the start of a career. However, there are always BUT.
 
The first BUT is that the "big IT company" is quite different from just a "big company" (especially in the Russian realities). If you have the 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 need to understand the possible consequences. And the worst-case consequences will be as follows: if the IT company closes or you want to leave it - you leave with knowledge and principles. If you want to leave not from an IT company to an IT company, then for a number of reasons this will make it more difficult. This may be the absence of the necessary and relevant experience, the specificity of the projects and the pickiness of the recruiters and hiring colleagues to your past jobs (remember the firm Pearson Hardman from the famous series that hired only from Harvard.) Such stories are not uncommon in reality. from food companies ", etc.). In companies where IT is not the main type of business, everything in the literal sense 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 the right principles, which then will help you make decisions and produce something very qualitative and complex at the output in fairly complex projects. If you produce something qualitative and useful - this is your goal, consider this.
 
6. Food and outsourcing companies
 
One of my most favorite topics, as I worked both in the first and second. Continuing the topic of captiousness, there is a certain opinion in the industry that it's not only more prestigious, but also monetary, to work in food IT companies, and this is accompanied by a set of the most interesting projects that can be found. 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 food companies is that a person, when coming there, actually has the opportunity to choose a project /product or sphere of activity, with all the consequences (for example, the opportunity 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 and the way you want, but it's your product. You greatly influence his success, at least at his level.
 
In outsourcing companies, the employee as a rule does not have such a choice, and moreover, periodically forced to sit because of this in a certain sense on needles. Integrators and outsourcers are engaged in those projects for which money is paid here and now. Not all such projects will be of interest to a certain class of programmers. For an employee of an outsourcing company, there is always the risk of being on an absolutely uninteresting and stagnant project, while, often, the only way to change the project will be to leave the company.
 
The main disadvantage of the food companies is the large amounts of legacy code and less focus on the development processes (with a greater focus on the directness of the hands and gyruses), with higher technical risks. The second not weak minus - failure of one project can put an end to the whole company. See the statistics of closed startups for the last 5 years and see this. This is not all the pros and cons, but the rest, I'm afraid, lies far beyond the scope of this article.
 
7. The quality of the vs is
 
Let's return to the difficult subject of programming. It is extremely important at the initial stage of a career to understand an important principle: the correctness of the code should always be above all else. On the other hand, any software is created with errors. The fact that they turned out to be principled may well affect the future fate of the project or product. Anyway, commercial programming is a business and without profit it can not exist. You necessarily and more than once there will be situations where the quality of the code (and sometimes the functionality itself) is sacrificed to release the release faster. Sometimes, it significantly demotivates the team, especially if the motives of such decisions are not explained. Perhaps it will in many ways demotivate you. I know of projects where the terms are constantly burning, and releases are constantly rolled out with loss in the internal (code) or external (functional) quality. On them, people worked on weekends from weeks to several months. What happened next? In the worst case, for the company - losses. In the worst case, for employees - the loss of health. Therefore, being in a situation where the quality is constantly sacrificed, it is worth evaluating 2 things: a) the duration of this b) the consequences (and they can be positive and negative). On the other hand, there are other examples: a fast system release might not be very high-quality, but it was very timely. The system was far from ideal, but the basic basic functionality in it worked well. As a result, its shortcomings were corrected during the next two releases, and the users of the system were so enthusiastic that the project invested twice as much resources, worked on it without fights, and made a very rich and steep functional that brought business great benefits . From the point of view of the ultimate goal, this is success.
 
Total: sometimes it is worth sacrificing some indicator (quality indicator or some other) now to open up some opportunities for the project in the future. If you are constantly sacrificing something and do not see that you get good results from this globally (and in the weak sense - locally, subjectively for you) - it is worthwhile to think about changing the project.
 
8. Programs are made for people
 
Software systems are very complex. Their complexity is sometimes compared to the complexity of a modern aircraft, saying that there are fewer elements in it than in any popular operating system. Over any more or less large-scale project, a team of tens or even hundreds of people can work. Each of them makes a piece of this software, sometimes without having a clue about the internal arrangement of the rest of its parts, and possibly how the user will use them. This is reality. It's impossible to know everything. In all corners of the system, it is simply physically impossible to look, there are so many of them. Sometimes this leads to an excessive focus on low-level technical tasks and care in such jungle, where the original goal is completely forgotten. And the original purpose of the software is to help the user to solve his tasks. This is important to remember always.
 
Orientation on the user
- the most important quality of the programmer, tester, manager, all who create programs. If you do not pay enough attention to this issue, the functionality of your software will contain a lot of user-visible flaws creating inconvenience in use, so that your user will not be happy until the end (if not disappointed), and later you yourself: see the result of their work and the benefits that it brings - this, in fact, is one of the main motivational components of work in IT.
 
Will an unlucky user use your product or remove it on the first day of installation? Will he praise you for what you have implemented or will he complain to your manager about the quality? It depends largely on you.
 
What is this all about, you ask? I will formulate simply: be a user of your own product, put yourself in his user's place, start thinking like him, and perhaps you will find a way to make the product better, already as a developer.
 
9. About interfaces
 
The larger (perhaps even larger) part of the programmers who develop logic and the backend considers the tasks of programming the user interface to be not very interesting. This de facto is considered non-prestigious (although, if we take the Web of recent times, then there were positive changes in this principle). Allegedly for this and programming, you do not need to be able to. What is there, rivetting rivets? Once, again, and ready. Either way, there is a certain rational grain in this. Development of libraries of algorithms and development of interfaces, of course - these are different types of activities. But the interface is
person application
. Not having this Person in good enough quality, the happiness of the user will not be easy. I have even more interesting news for you: they not only do not want to do this, but very few people really know how, really. Because directly programming, the problem is not limited. A sufficient number of people know how to code interface interfaces to a certain extent, they do not do so much on a permanent professional basis. Much less people can explain why the interface or use scenario A seems to them more successful than scenario B. Already very few people are able to design a quality interface from scratch and scenarios of its use. So, good news: if you have found the ability to understand which interface is better, or even to offer successful UX /UI solutions - you can become a very competitive specialist, you will discover a new interesting area of ​​tasks, although, in a certain case, you will have to depart a little from the programming itself.
 
10. About change of a place of work
 
Known and inexorable statistics: a huge number of people leave their first job already in the second or third year. And you will also be among them with high probability. This happens for different reasons: from a small salary, to the lack of interesting tasks and other things.
 
The first reason, related to money, is very common. The canonical example is arranged like this: junu comes with an offer with a ZP of 1.5-2 times higher. Such a coefficient, of course, at the start of a career is possible, and it seems just a huge increase, it will be difficult to resist such a proposal. This is where the main error can be hidden. People are moving to a new place of work, which they too are likely to leave in 1-2 years, most likely not because of financial issues. Total - you have 4 years of experience, but have you done a lot of finished projects or at least major releases? Why it is at the start of a career that may not be the best solution is quite understandable: a person who does not learn to do well tasks A switches to doing tasks B. Whether it's another project, another subject area or technology. Switching, as is well known in programming, contains overhead. However, not always such a switch is negative. Perhaps the main positive thing that can wait for you here is the opportunity to participate in a more steep project with a steeper team, hitting it, your professional growth will go much faster. You should feel that you are moving with a noticeable margin, then, most likely, you will not be mistaken.
 
Total: before you change jobs in the first 1-3 years, think about the real reasons that you are urged to do it. Again, an intensive study of technology and an increase in skills in the first 3 years of experience is the number one task. Completed tasks and projects, quality is the task number 2. Financial growth is number 3. If you put finance first, then maybe in the future you will find with astonishment that for 4 years in the industry you have only learned to solve tasks from a strictly limited circle on your project and do not know and half of what you might need when you are in another company where you would like to work.
 
Conclusion
 
The beginning of a career is the time when it's worth working on your
technical skills
and learn
the rate of work
, which is sufficient for design work in real conditions. This is the time when it is necessary to develop self-discipline. For him you can understand for yourself what you like best to do, and what - do not like it at all. For him, you can also commit a large number of errors and a considerable number of victories. And the first and second, with proper analysis of flights and the making of correct conclusions at this stage of the career is a Victory, it is important to work out exactly this attitude and not give up! In the end, by the fourth year of experience, you will come up with a better outcome: a) with a good set of hard skills b) c real project experience c) with understanding of many problems and solutions. This is an excellent help to develop further!
 
P.S. The author will be happy to criticize and comment on the article in the comments and HP. Especially if you liked the article and its subjects, then write about what related topics you would like to read in the next articles.