Why does a senior developer teach students

    We at Veeam have an educational project with a laconic name Veeam Academy . He is dedicated to the practice of developing in C #. If you do not go into details, then its essence is as follows: we take undergraduate students and in three months bring their purely theoretical institute knowledge into line with the surrounding reality. This is done both with the help of lectures, where they reveal the practical meaning of the boring theory, which they managed to give in the university, and with the help of a common project, which they have been developing throughout their studies.



    On the way to the first launch of the Academy, we were faced with many interesting problems, both purely organizational and legal. (If someone did not know, training is a licensed activity, so you shouldn’t just start teaching someone something, even if you really want to, so as not to increase the interest of the regulatory authorities.)


    But where do students get those very practical skills, you ask? The answer lies in our developers, who, on a completely voluntary basis, act as consultants, do a code review for the guys and just share their experience. Moreover, only senior developers participate in this activity. It was with them (after already 3 graduations from the academy) we decided to talk to find out:


    • Why do they spend their valuable time on students?
    • How does it feel to be a novice mentor?
    • How / why / why live with legacy code?
    • What is missing in modern education?
    • Why do people go into the development of boxed products?

    We did a small series of video interviews Dud-Style, and here there will be a small text extract from the most interesting answers. Two full interviews are now published (they are in the article), but three more will be posted soon.


    Characters:


    Alexander Baranov - Head of Solution Development, Veeam Backup & Replication.
    Artyom Grigoriev - Experienced Developer.
    Dmitry Babushkin - Senior Developer.
    Kirill Lukyanov - Head of development in the direction of Hyper-V, Project leader in a simple way.
    Philip Guzeev - Experienced Developer.


    How was the idea of ​​Veeam Academy born?


    Alexander - The idea was a joint one. In the course of numerous interviews there was an understanding of what the candidates lacked. Many junas come to us (junior developer). As a rule, these are people who have recently graduated from the institute, with experience of about 1 year or without it. As a rule, they lack practice. So, something must be done to ensure that this deficit, if not completely eliminated, then at least eliminate the main gaps. We began to think how to fit our existing experience into compressed two or three month courses - this was the beginning.


    Courses on algorithms and data structures that should be read in mathematical faculties are not bad in themselves. The problem is that often they are separated from practical application in the development, so they are not very well absorbed. We are trying to structure this knowledge a little and let us feel in practice how it works. And not just “how the technology works”, but how the process works as a whole: how the team works, how tasks are distributed, how to synchronize team members, etc.


    How did you get to the Academy?


    Artem - They offered to participate in the Academy as a reviewer, I thought: “Why not?”, At the same time I will refresh my knowledge and get experience in performances. This was my first experience almost from university, so I was very worried.


    On the other hand, the Academy is an opportunity to hire more employees, and in any case it is an interesting experience and an opportunity to understand what it is like to transfer knowledge.


    Philip - Immediately agreed, as suggested. It is always interesting to see what kind of thinking people have, to notice something new for themselves. And it is always helpful to share your knowledge.


    Kirill - When the project was launched, it was just a thought to involve developers in the process. This was the point, because We are constantly confronted with specific technical tasks in practice and know quite a few aspects that we are ready to share. I received an offer, I spontaneously agreed, and when I had already begun to approach this more thoughtfully, then goals and a desire to achieve them appeared.



    What did you do at the Academy?


    Dmitry - Prepared questions for online testing, was engaged in the selection and interview of students, and also acted as a mentor for some students.


    Alexander - I did what I first thought and planned, what we should do and tell - and what we [the candidates] lack, and that it would be interesting for people who come to this Academy.


    Philip - At the Academy I was and is as a mentor - a person who reviews the students' code and guides them on the right path, giving all sorts of advice.


    Do you regret the time spent?


    Dmitry - No, of course. I helped recruit three talented guys, even to neighboring departments, but ultimately we have one big team, a family, if you want. The more people in the neighboring department, the less they will throw off their tasks on us =)


    Kirill - I thought - this is a good chance to improve my skills of the same sociability and public speaking. We all know that this is a terrible topic for many developers, so I overcame my fears.
    In the end, I hired two students who work successfully.


    Why did you become a mentor?


    Dmitry - I like to develop in various directions, and it was a great occasion to prove myself in everything. At the time of violent youth slipped thoughts to go to the pedagogical, but did not work out, although some experience remained.


    Philip - Nothing happens just like that. For example, people come to the Academy for a reason, and, for example, to take some place in the team later. And the role of mentoring, including the selection of a valid person in the team.


    What is missing for modern students?


    Dmitry - There are a lot of talented guys who are well-informed, but, unfortunately, just slow. They have not yet had any practical experience, their brains have not been rebuilt for programming. They can not quickly find any solutions, they need to sit quietly and think in a comfortable atmosphere. This is not a problem when you solve some academic tasks at home, but when they join the work process, such people may simply not pull.


    Kirill - If we mean big subjects, then the main failures in knowledge after universities are multi-threaded programming. Probably the most disastrous area, judging by the analysis of our test tasks.


    But I think this is a consequence of the lack of practice. There are enough theories around, but in universities, as a rule, they give it very one-sidedly. For example, in C #, take task, async calls, and parse them. This mechanism is convenient, but does not allow to look under the hood. The student himself must go and begin to understand, but almost no one does. Curiosity is a good thing, but often it is simply not enough time for it.



    What is so interesting about the student code review?


    Artyom - In principle, it is in itself interesting to look at the code of other people. We don’t use a lot of innovations in the working process, so I even made something interesting for myself with respect to relatively new technologies.


    Students wrote on the seventh Sharpe, in the seventeenth studio, respectively, there were some moments that I had not yet encountered in practice. For example async / await.


    A code review is, let's say, the practice of writing good code. When you write yourself, you involuntarily think: “Well, then you can forget about it, better here, worse here, then redo it, etc.”. And when you watch someone else's code, you have no limitation that you need to fix 10 bugs before lunch. And you can calmly grasp where it’s bad, where you can do better, and where you can completely do it. It helps to look at the process of writing code from the side, and in the future it is easier to solve problems a la how to make a call scheme, the responsibility of classes, etc.



    What do you expect from a student at the interview?


    Dmitry - I want to see his approach. People come, they say that they read, for example, Richter. I did not read Richter, but when you start talking to them, it becomes obvious that they found the answer to some of their own questions and everything — that is, they did not read it [thoughtfully]. They flipped through the book, but they are not interested in what he is writing about, it is not interesting how the .Net Framework is arranged inside. This is a valid approach if you are an accomplished specialist. But if you saw C # in the first year and started to dismiss some implementation details, how everything works under the hood, this is a guarantee that you will begin to step on a rake. And if at this point you get into the team project, it will inevitably affect your result. Everyone will scold you, your motivation will fall and the question of further work will arise.


    There is also an aspect of having free time. Even if his [student's] eyes are burning, but he will spend two hours on the way to the Academy, plus he has a part-time job, plus life problems and a hungry cat at home, it becomes clear that he does not have free time and he will just burn like a match for three months of study.


    Is it difficult to learn how to write code “correctly and how do we need”?


    Phillip - You can't say “you're doing the right thing — or the wrong thing.” There is no such thing. You make supported code or you make unsupported code. Let's say you have a task in 5 hours on the hackathon to jot down some project. And, naturally, you will not think about some beauty of architecture and beauty of code. “Nalapa” to work - and rightly so. On the other hand, if you work in an enterprise [large company - ed.], Then you have allocated time for tasks and specific code requirements, and this is what we are striving for and what we are looking for.


    Alexander - There are two situations here. If a person has already done something similar in another grocery company, then it will flow relatively easily. The market is standardizing processes.
    Another thing, when you already have experience, but you did a few other things. Then the question arises, “How do you want to develop further?” If your goal is to work in a large company, move to another country, then you will have to endure the breaking up period. It's like a private car after public transport (or vice versa): at first it hurts and it is sad, but then it becomes very comfortable and convenient.


    Dmitry - In fact, if a person has a minimum skill level, it is not necessary to “break” it. But when experienced programmers come, they already have their own set of practices, their own code style, which may differ from ours - and the conversation begins “Why do you forbid me to use vars? I have such a good code, not a single type is visible, and everything is as it should be in functional programming. ” Here with such people it is already more difficult.
    And if this is a student, even the last year, with a dozen projects on the githaba - he just did not have time to acquire some evil practices. Well, working with completely “clean” people is a pleasure.


    Students can pleasantly surprise?


    Artem - Let's just say, sometimes there were situations that you open a code, and there are constructions everywhere that you have never seen before. I had to sit down with them, and figure out how to use them correctly. It happened that I myself did not understand right the first time.



    Was Veeam Academy helpful to you personally?


    Dmitry - Yes, of course. As usual - when you tell someone how to do it, first, you understand how to do it. Secondly, you systematize your own knowledge and even in the course of lectures you find answers to some questions that have tormented you for a long time. So sharing your knowledge with someone else is a great way to develop yourself.


    Alexander - First of all, it became clear what people expect, including from the place of future work. When you as a manager are in the process, you are more likely to get involved in business development. And where the situation is more informal, such as in the academy, it becomes clear what motivates people, what they want and what their interests are.


    You learn, among other things, a lot of new things about yourself, and this is the most important thing.


    For example, you understand that many things should be simplified. When you work for a long time in one area, the eye becomes blurred, and things that are obvious to you become completely incomprehensible to other people, especially beginners.


    Phillip - When you constantly boil in the environment of a certain level of developers, you begin to speak in a language that only you can understand. And when a person comes, just entering this environment, you start explaining everything with some simpler words, you learn to communicate information in a more structured way.


    Working with students, you also learn patience, some kind of compassion and understanding =) But then you start to see some things that you knew, but forgot. You have to delve deeper into technology in order to better convey to people the meaning of what is happening. Rather, the meaning of why it is better to do like this, but it is better not to do so.



    Is Enterprise development always about legacy?


    Cyril - Absolutely correct statement. When the project is written 10 years and is constantly evolving, a certain percentage of the code will be in it.


    Another question is how different companies can approach this.


    While the module is working, we try not to go into it. It is debugged 5 years ago and more than one release works stably. Another question is when you get the code in which you constantly need to change something. In this case, we are not forbidden and gradually improve it: to refactor, etc. 10 years ago there was a different standard of language, other lexical constructions. No one bothers to take, refactor and translate into new designs.


    Gradually, the code is rejuvenated, but this is all in the hands of the developer. You can score a bolt, solve the current problem and, perhaps, for the company this will be enough, because The ultimate goal in the form of a working product will be achieved. Well, what's inside ... There are a lot of stories on the Internet, especially about the dawn of gamedev, there when only classes in C ++ appeared ... you open the code - there are classes, in each there is a bunch of interruptions. It is clear that now it would be called quite a specific word.


    But in general, with Legacy code, one must be able to live. He should not be afraid.


    Dmitry - Legacy code, of course, is present and, of course, you have to somehow live with it. But you live with him not out of despair, but because it makes no sense to touch him. Most often, legacy code is some kind of debugged components, even if they are written on some .Net 2.0. They have been working for years, there is no new functionality to add to them - and why touch them if they work and work normally ?


    There are situations when you see a bug in the old code, past several releases, but suddenly fired. It is then that you begin to rewrite the old code, perhaps you cover it with unit tests so as not to break anything. Or just endlessly trust testers. Those. you just pick up a good time, naturally, not for release - but all sorts of beta are invented for this purpose.


    As for the Academy, this project also allows us to keep up with the times. New guys are coming, they are actively following the latest developments in the C #, .Net world, etc. They like some new constructions, “syntactic sugar” from the latest versions. And, in fact, through their timblids they force [advance] these constructions into the project. Yes, it may cause resistance, people may not accept it right away, but this is all temporary and, if a really useful feature came in the new framework, it will go into the process.


    Philip - We have to deal with what was written 10 years ago. From this you will not escape. Naturally, we strive to update our stack, but we have 180 projects in development, several million lines of code have been written during this time, and it is very difficult to just take and jump over it. It is necessary to understand and somehow take it.


    Alexander - Once I read the presentation of Mercedes Benz about why they are so conservative and introduce technologies with a certain lag. The answer is simple: everything that does not benefit the client goes “in a bucket”. Enterprise development follows the same principle. The first “victims” of the new technology should be analysts, developers, a test lab or anyone, but not a client. Any technology before appearing in the product should be run-in. From the outside, it looks like legacy, but from the inside it is not. Simply, everything modern we must first test "on cats" and only then apply in life.


    Artyom - Yes and No. Our product is 10 years old, so we have a lot of legacy, but this does not mean that we are blindly dragging old components and are not doing anything with them. It happens that we completely rewrite.



    Then how is the introduction of new features?


    Alexander - First of all, explain what problem you are solving. If you brought the draft lunar rover - this is certainly great, but explain what it is for. If you can explain why it will be useful to us, then, of course, we will implement it.


    Cyril - First you need to make out what it is - because it may have consequences. If we introduce some kind of new library, then not only developers will be involved. The testing department is turned on, which will need to retest all the logic that was based on the old working code, and now we have changed everything.


    Therefore, the introduction of something new in production development is often associated with large overheads. And if the gain from the introduction exceeds these costs, then, as a rule, the decision is made about the implementation. And if on the contrary, why? Do not shoot yourself in the foot.


    How to deal with the fervor of the June and their desire to improve everything?


    Dmitry - They still do not solve any serious, complex tasks due to a lack of competence. Young age (in terms of the developer) is a great opportunity to fill your own bumps, especially if you do not believe your older comrades. If the price of a question is two days, for which he realizes that his “ingenious” idea does not take off, and he will no longer deal with this garbage, then it is better to give him the opportunity to step on this rake personally. It’s much worse to forbid him to do this, and for months he will think that “a nasty timlid forbade me to gash a cool thing.”


    Kirill - Everything that is given in the Academy allows students, first, to look at the stack of modern technologies. Secondly, we are trying to use everything that we give to the maximum.
    Our product is not young, but when a new feature is written, it is created from scratch, and the use of new technologies carries fewer risks. So let them apply.


    Artem - New features are good to use in new areas. Our project is not so monolithic that it solves only one task, that's all. It has many functions, and there is always a place where to apply the new.


    When a new person arrives, he is given first training tasks, then small ones. In any case, he first needs to get acquainted with the project, because it is huge. It seems already for a million lines of code, but I can lie. In any case, to look around for a week, and even for a month he could not do it. But when he begins to understand, we can experiment with why not.


    How can junior be with legacy?


    Phillip - First, you can’t say that these things are completely outdated. There are all kinds of straightforward know-how, ok, we work in many ways without them. But in any case, people will learn from us the right approach to code organization and design. This is not going anywhere.
    We will also teach you how to work with legacy. This is also a very important skill. You can not think that you will come and begin to design the best system in the world. Not. Most often, when you enter an enterprise, you end up on a finished product. You will either lead it [to work with the existing code - ed.], Or develop the [new components - ed.].


    Dmitry - And nobody will let him in there. Developers always have a huge backlog [task list, including deferred ones - ed.], Analysts are constantly throwing in new features, and young talents are better off writing new code. Naturally, it will have to somehow integrate with the old code, but it is so thin layer in the work that it does not have time to cause some kind of disgust.


    Therefore, let them use lambda functions, let them use patterns. If only they understand which ones should be used, which are not, and which ones should be kept away from.



    So, maybe it's better to start in a startup?


    Alexander- Enterprise solutions are designed for long-term operation in enterprises employing thousands of people. This means that the application must be reliable, consistent with current trends and be compatible with the architectures present in the market, right down to the scale of the countries. The development of box software in one degree or another allows you to familiarize yourself with all these technologies and understand what is “architecturally good” and what is “not bad”. This is done based on the experience of companies operating in the enterprise [-sector]. To enter this sector, it takes a long time for a company to prove to the world that it makes products that meet these requirements. For example, Veeam has been doing this for about 5 years, from SMB [small & medium businesses - ed.] To Enterprise. When you come to the enterprise [-development], you can be sure that you are going to the organization, which proved its adequacy to the market. So, it uses adequate technology, adequate methods and quality standards.


    Therefore, it is very easy to choose. As a rule, successful startups make people from enterprise. There is such a feature: speaking as a guarantor of quality and stability, the enterprise is “agile” like a barge. And the market is moving somewhat faster, and when lag appears between them, start-ups fill this niche. And they appear not from scratch, but based on the experience of former employees of this very enterprise, who were able to see this niche. From here my recommendation: at least 5 years to work in a large (better international) organization, to gain experience and knowledge, and afterwards to understand how to develop further. Or go to a startup to promote new ideas and technologies, or to continue to grow a career.


    This is a question of efficiency. Anyway, you have to fill yourself with a set of standard cones on the forehead. You will either stuff them yourself, or in a shorter period of time you will learn about them from more experienced comrades. It is never harmful to invent a bicycle, but how to do better, you have to decide yourself.


    Kirill - It depends on the person. There are people who like to take all the newest things, put some solution out of the bricks that will suit both him and the customer.
    Food Company [i.e. developing its own product - ed.] at the entrance will look like a startup. The person does not know the problem area, and everything is new for him.


    What are the advantages of product companies? Usually they are big enough, they have products that bring a stable income. That is probably a stable salary - a good sign. The second point: in food companies, people work longer on one project, and they have a deeper expertise in this area. Here the advantage is communication with experienced colleagues.


    There is an opinion that it is necessary to change work every 2-3 years. Yes, as part of working on one feature during this time, you will study it thoroughly. But, for example, in Veeam, even within one team there is a very large stack of technologies, and if you are tired of working on one thing, you can always switch to something else. There is a practice of switching to another team - i.e. the employee will remain in the company, but his tasks will change so that the burnout does not occur and we do not lose valuable personnel.


    Dmitry - A startup is unlikely to get the amount of knowledge and experience that has been accumulated over the years of development. Typically, start-ups are collected from the same young and hot, who blindly cling to everything new. But every startup has very big chances to go bankrupt, and large enterprise solutions have been on the market for decades and have proven that their approaches are justified.


    In no case do I want to belittle the approach of startups, I just need to understand that he is very risky, and there is a survivor error. Yes, Amazon was a startup, Facebook was a startup, but that does not mean that your startup will also survive and become a billion-dollar business.
    But in general, I have never compared two such extremes as start-ups and enterprise. I often think of areas of development that may like or not.


    Artem - You can go and write “stylishly, fashionably, youth” saytik, but this is either alone or with a small team. In a large team, you can always look at a good old code and a good new code. You can also look at both the bad old code and the bad new one. That is, there are always many people around who can prompt, notice some error in the code, suggest how to make the code supported, so that after two years it would not be painfully painful to fix bugs in it. And more than the very communication with other developers, which is also a very valuable skill.


    On the other hand, in the startup experience is more extensive, or something. You will have to develop the whole architecture from scratch, think through the interaction of components, choose technologies, etc. In established projects, you can only see how it works. This approach from different sides. Startups go through bugs and crutches, but only if there are no people there who know how to do it right.


    Is there life after enterprise?


    Kirill - In food companies, everything is slowly changing, it is true. But, having got used to this, one might say, “heavy scientific design”, you will continue to write.


    Artem - Life is. I develop some small projects purely for myself and can apply some approaches from large products. Some people seem too cumbersome to me, and I have to write “bikes”. It depends on the person. If he just goes to work to write code for 8 hours, and outside of it programming doesn’t interest him, then he doesn’t need all this experimentation. And if a person is an enthusiast, he will not have any problems.


    Alexander - As I said, most startups come out of the enterprise. Of course, there are successful projects that have emerged from a brilliant idea, but statistics are implacable. We also had examples when former employees based their projects around implementation solutions, consulting, etc.


    Dmitry - Yes, but I would say - in parallel. What I lack at work, I compensate for home projects.



    Who exactly does not need to go into the development of box software?


    Artem - Just do not go to those who like to rewrite half of the product in the middle of the development cycle. Our development is gradual, evolutionary. And if you always want to try something new, then such people are needed, but in very limited quantities.


    You just need to align your desires with what is needed for the common cause. Do you have an idea - it's great, but you do not know the big picture. First you need to discuss it with colleagues, with analysts, to understand what the benefits of implementation will be. If the benefits are sufficient, you will always be allowed to start the implementation. And if you just came up with something that would postpone the release for six months, of course, no one will give you everything to give up and start “sawing” [writing code - ed.]. After all, customers pay money for a running product, not for developer experiments. So the assessment of their actions, too, must learn.


    Tabs or spaces?


    Artem - Of course, gaps. It is more convenient with them.


    Dmitry - Of course, tabs that are converted into spaces.


    Alexander - Four spaces. Historically, tabs in different editors have been shown differently, and the text can float. About 15 years ago, in some guide, I saw a piece of advice that, supposedly, change the settings of the Studio [Microsoft Visual Studio - Ed.] So that instead of tabs four spaces were put, well, somehow it was deposited in my head since then.


    Philip - Tabs, of course.


    Cyril - Holivar, yes, but I prefer spaces. I consider myself not only a high-level developer, and when you write a low-level code, you often don’t put up any Studio for yourself, but you write banally in a notebook. And when there is a tab, and there are spaces, then there are all kinds of jambs with alignment of the code, so what is it for.


    Instead of credits to music
    If you have a friend in mind who you want to send to us, or it is just interesting to take the entrance test, then we are now recruiting for the spring course .


    Also popular now: