On June 15, a live broadcast was held in our instagram account with Ilya, the front-end development manager at Yandex.Money. We post the broadcast record and decryption.

ITKarma picture" true div>

My name is Ilya, I work for Yandex.Money and I manage the frontend. Before that, he was a backend developer, wrote in C #, and about 5 years ago he moved to the frontend. I’ve been managing it a little over a year. This is the way of development. I am still actively participating in the Burning Lead - this is a community for leading developers, team leaders, people who in one way or another intersect with management tasks; I hope the community guys listen to the stream.

About Node.js and its use

First I’ll say how we got it and why we use it. Historically, in Money we have a full-fledged Java backend in which Java developers work with databases, with the main business logic. Front-end tenders do not work with business logic, we prepare for ourselves the necessary data format and send it to the front-end, and there we already draw them on some framework. Initially, we had an Xscript server, which the guys at Yandex made back in the 2000s - this is our legacy. Part of the logic - server rendering - we wrote in XML, XSL/XML transformations. This went on for a very long time. Then, when we realized that it was hard to find developers on XSL/XML, we began to choose a new server, which could be written on the backend and then used on the frontend. It turned out that there is a whole platform Node.js.

Then Node.js was a very young platform, version 0.10, probably. It was decided to use it for several reasons: the Javascript language was gaining popularity, there were many developers; in addition, server and client logic could be written by one developer without superspecific knowledge. We do not regret our choice: the platform is still actively developing, optimizing, becoming faster, receiving useful features, and has an active community.

Let's talk about frontend architecture and what we would like to achieve in Yandex.Money architecture as a whole. Since we use Node.js, for a long time we have been using Express as the basis of the server framework. He copes well with his task - he processes the user's requests and gives answers, nothing more is needed from him. A lot of plugins have been written for him. There are SSRs for React applications, for example; since the main stack on the client is React, the SSR is not a problem to fasten. There are many implementations; you don’t even have to write code: you deploy from NPM, he does everything himself.

As for architecture, we have been living on Express for about 4-5 years, and some problems arise because of this. We have quite a few developers - there are about 50 people in the department - and we need to write code that is understandable to everyone; developers can change interests, move from team to team, and we need the code to be approximately the same, so that the developer in the new team does not spend a month acclimatizing to the new code. Express is a rather low-level framework, and it’s rather difficult to live with it: each team uses its own vision of how to write request handlers or business logic, go to the backend. The first attempt to set up the server architecture was made when we did ProcessFlow. I made reports on this topic - I told how, on the basis of IDEF0, you can build a system that will allow you to organize business logic, set the rules for writing it, make support, visualize the relationships between entities. The attempt was quite successful: in some places we had serious problems with understanding the code, and ProcessFlow helped solve them. It works now, and it suits us perfectly.

Now we are moving to NestJS.This is a fairly modern server framework that allows you to write controllers in the Model-View-Controller paradigm, organize business logic; his philosophy came from Angular. Its strong point is the rules, they already at the level of the framework determine the spelling of controllers and business logic. An uncontrolled environment can be disastrous when you are many and everyone writes differently; it is better to have a set of rules that you can always refer to - this is the path we choose. My colleague Andrei Melekhov, the lead podcast of devSchacht, actively talks about NestJS; He now describes the process of moving to NestJS, discusses problems.

We are committed to moving all applications to NestJS. We also think over more strict architectural rules in order to reduce the entropy between different applications in the company more strongly, and we split applications according to the microservice approach. Previously, we had a monolith, and everything was fine before our team grew and the developers began to interfere with each other - in terms of releases, in functionality - and, in addition, the monolith was going for a long time. We decided to split into microservices. Now we see that microservices in the front-end are hard: on the page you need to display several domain areas, despite the fact that each microservice should serve only one area. We see that microservices are turning into mini-monoliths, and now we are looking towards the micro-frontend, which will allow us to adequately organize the frontend without crossing the subject areas.

About the client part

It consists of two large stacks. The first is a legacy stack using the BEM Naming methodology (certain names of CSS styles to avoid intersections), on the basis of which they created the framework in Yandex. We used it for a long time, since we use the Yandex technological stack. It’s cool, and in it the work with components is organized in much the same way as in modern frameworks: in the form of separately lying blocks that are convenient to maintain. However, it is already outdated, as it is based on GQL and does not meet modern requirements for UI; it is very difficult to make animations and applications on the client on it. We have been gradually switching to React for several years (the transition advances when the design or functionality changes: that is, all rewriting of business processes takes place on a new technology). It seemed quite mainstream to us - that is, there are a lot of developers on it. React - the main framework on the client, Redux is used as the state manager; with it we use Redux-Thunk for asynchronous actions and backend requests. Several projects used hooks.

Why not Angular?

When we selected the stack, Angular was approximately version 1.5. It seemed to us doubtful, and we chose a different solution. I have no complaints about the latest versions of Angular, but we don’t want to abandon React.

How I became a team leader, why I chose this path, what are the pros and cons

In fact, each company will have its own requirements for team leader or department head, but it seems to me that there is also a certain plan of what you need to know and do in order to develop in the direction of management. There is such a podcast - PodlodkaPodcast, they published such a plan (roadmap). Cool stuff; it says what you should read to develop the right softskills - you need to focus on them. Of course, a good team leader must have excellent hardskills: he is not just a formal team leader (say, 5 people), he must prove his leadership, he must teach his team, his people must be willing to learn how to program as he can. But softskill is also important: communication skills for communication within and outside the team, for upholding the opinions of the team, for finding compromises. Timlid has a lot of communications. In addition, you need to be able to show empathy: when communicating with developers, it is important to establish understanding at the level of feelings, understand the mood of each interlocutor, determine what he wants. This is not directly said, but it is very good when the team leader owns it. It’s great when the mentoring skill is also attached to hardskills: people will reach for such a team lead, he will be able to clearly formulate and set goals.

Everything happened for me according to this plan.I studied communication, helped children - even in those cases when I myself do not initially understand what the problem is, it is useful to sit down and deal with the problem together. People began to contact me more often; The management noticed this, and I was promoted to senior developer, and a year later to the lead. In our company, this is the developer who is directly responsible for the development and growth of the team. I prepared many different workshops on tests, load testing. In general, I looked at what topics in the department are currently “sick” and tried to do something useful for the team to improve the situation - with the help of workshops, speeches, just personal help; and when our leader left, he recommended me in his place.

When I became a team leader, the problems had just begun. You might think that everything should be fine at this place: the developers work, the lead commands, and that’s all - but this is not so. When I was a developer, I did an understandable task and rejoiced at my achievement - but as a leader, as it turned out, the tasks are often very blurry. Need to "improve something." For example, you need to speed up the code review time: a person comes in, looks at the code and presses a button, what can be improved here? The second important point that puts pressure on you is that the leader does not solve applied problems with his own hands. And here comes the “impostor syndrome”: it may seem like you're just wasting time while developers write code, and sometimes you feel useless. You need to understand and know your value: communication is also an important task. A good leader helps remove unnecessary communication barriers during the project; developers may not communicate because it’s uncomfortable for them, but the manager is obligated.

One of the advantages is the scale of work. When I was a developer, I thought in a separate project. The project could be big, of course, but in the role of team lead I think within the whole company: I have to make my whole department better, so that the whole company becomes better. From this scale, I enjoy working on projects.

About the processes of managing people in our department

The development process involves the communication of developers among themselves, and we have several intersection points. The development task goes to one of the teams; Usually a team is Java developers, front-end developers, a manager, a product, and testers. Such a unit, sits somewhere separately. The existence of other teams for it does not have special significance in itself - but we need all the teams to write approximately uniform code. To do this, you need to communicate, and there are several approaches. Firstly, these are occasional meetings of the entire department; Now we are all going to zoom, but that, of course, is not it. At meetings we share news, the guys tell us what they do in their teams: what kind of projects they have, what will be in the future, what and how they do it. This helps to build an idea of ​​what is happening in the front-end: it is big, it just won’t come out to consider it. We also organize tech talks, different in scale: for the whole company or in our department, and technical techniques are presented there: for example, one of them told how hooks are used in React, how they affect the form, how the code looks for them, what are the pros and cons. These reports are interesting to listen to, and they help to spread knowledge throughout the company. There are processes directly in the development that allow us to communicate in such a way that we will not encounter misunderstanding on the code because of the techniques, components and libraries used - that is, we We try to mitigate the bad consequences of isolated decision making. This process, which we call Logic Review, allows us to find out the opinions of experts, leading developers, senior developers after we understand how to do a specific task - that is, compare our vision of project implementation with the vision of those who determine the further development of the entire department. It allows us to share knowledge, technology, and control the homogeneity and architecture of the stack. Of course, it’s impossible to catch up everywhere and avoid all problems with coding, but such a reconciliation before starting development reduces their number.

Is it possible to fool Review 360?

Let me remind you that Review 360 is when everyone (developers, testers, managers) with whom a person who needs to be worked with is interviewed “in a circle” using a questionnaire. I talked about this process on Burning Lead. If the team is small, as we usually do - people of 5-10 - then this process, in fact, is not needed: the team leader himself can communicate with each member of the team. Actually, he should communicate with each developer once every 1-2 weeks in order to understand what the developer wants, what his mood is, whether he is satisfied with the tasks, how he works, how his growth is going. But, when the team is large - for example, I now have more than 50 front-end - there will not be enough time for such personal communication. The team leader has other responsibilities and projects, he is obliged to develop the department, he cannot spend all his working time only on communication, which later will need to be analyzed as well. Therefore, you have to use less accurate approaches - for example, Review 360.

Is it possible to deceive him - I think it means that can developers agree among themselves and give themselves high marks? Probably they can, but you don’t agree with the manager and product owner: these people pursue somewhat different interests, and this will be easily calculated. That is - it is possible, but not for long. Over time, it will become clear that the developer is not doing his job. If the product owner says that the developer can’t do it, and other developers give him the highest marks, then we clearly understand that there is a problem: either the product owner is sharpening his teeth, or other developers do not notice anything (or they agreed).

In general, I think that 360 Review is a fairly objective thing, and we spend them with a certain period of time. We have not gained too much experience with them, but we are gradually moving forward and improving methods for calculating statistics and sets of questions.

Tell us about the dependency manager, composer and Laravel

I know that Laravel is a good PHP framework, and they write on it with us, but I hardly worked with these technologies myself.

Do you have a separation between layout and JS developers, or does the developer do everything?

We mean that the front-end is a person who writes JS calls to the back-end, transfers to the front-end and implements it. We do not write complex business logic and interactions with databases. But we can say that the front-end is full-stack, because it writes both on the client and on the server.

What do junior front-end developers need to know to work in the company?

Unfortunately, now we do not have open vacancies for June, but they do. We require knowledge of Javascript language theory. This may seem absurd, because JS theory in everyday tasks seems to be unnecessary; however, we know that a person who has studied theory knows how to work with information and perceive it. In addition, he has motivation: he sat down and figured out how the language works; when he encounters a problem or a difficult place, he knows how to look for the information that is necessary for the solution (you need to be able to even google).

Tell us about the architecture of the client side. Do you have a component library, and how is it rummaged? How many independent applications, are they all on the same stack?

I already talked a bit about architecture. We have a library of components, there are several of them. There is one that we get from Yandex so that the visual style is the same. There is a design system that says which grids, colors, typography (etc.) we use on the front-end - that is, this system completely dictates the location and color scheme. Finally, a library of common components between the applications that we use. We have more than 20 applications (26?), And in all it is used; sometimes we crawl quite strongly by version - we get different versions in different applications, because of which the visual part may suffer. This is one of the big problems with microservices with a shared library, but we are trying.

What is the size of your team?

I have two roles in the company: I manage a department of about 50 people and at the same time I am the product owner of our platform team, there are 8 people.

React Native or Flutter?

We had experiments with React Native, Flutter was then very new; we decided that we would choose React Native.

Yandex wants to launch its frame?

No, BEM is a very old framework, it is deprecated, we use React instead. Nobody wants to launch a new framework.
Question: only JS on the backend, or are there any legacy parts?
I told you that we have an Xscript server with XML/XSL. This is precisely our legacy, we are actively cutting it out and want to stop using it as soon as possible. Mostly - in 96% of cases - we use JS.

Redux-Thunk or Redux-Saga?

We are using Thunk. Saga had an approach; maybe then we just didn’t have any guys who understand it well enough, but we did not see any advantages over Thunk. There is already an approach with hooks, but so far Thunk is very actively used.

Are you setting Smart tasks within your company or team?

When we do projects, goals are set by Smart. That is, we must have a clear idea of ​​what we will do and where to come. For beginners, tasks are also set by Smart. But I can’t say that already in the development process there should always be clearly defined tasks: often when the guys in the team create tasks, they can be completely differently described, but for beginners everything is always described so that it is clear how to go and for what. That is, not all 100% of the tasks are set by Smart, but we are actively using this methodology.

As for microservices - module Federation Pack 5 has now been rolled out, is it possible to look in this direction?

Yes, but this is probably not a microservice, but a microfront? It will be necessary to analyze what can be pulled out of this; it’s just that microservice tasks on the front end are not very well solved.

What is the difference in managing 5, 10 and 50 people?

In the attention paid to the developers. When the developers are 5-10, I can talk with each of them, listen to problems, understand what they want and how they are developing. When there are 50, it is impossible; Of course, this worsens the feeling of the role of the leader, because it seems that I am separated from the developers, but nothing can be done about it. This is the main difference. In addition, 5-10 people is one team that works together, but 50 people cannot be one team; so many developers need to be divided into separate manageable groups, otherwise it will not work to keep focus.

Will there be a massive transition to NestJS?

It is hard to say. Maybe tomorrow there will be a new front-end framework that surpasses NestJS, and we will all switch to it. I think that now NestJS is well developed, but you need to proceed from the task. For many of the tasks that we solve at Node, we don’t need such a serious framework - for example, for lambda functions that someone will call; but when there’s a lot of logic at the front end, it seems like Nest would do better. It is well designed now, there is also a backend framework (although it was rather raw when we watched it). Nest is developing and, perhaps, will become more popular, but I don’t think that there will be a mass transition to it, as to Express.

What is the difference between interviews for June and Middle? What is evaluated in the second case?

When we interview the juna, we check the person’s motivation, basic knowledge of JS, look at communication and the desire to develop. Everything is more interesting with the middle: after all, the middle are people who write the bulk of the code for our projects; they have few meetings, they develop most of the time. We need to test his hardskills (tasks) well, find out how he argues, talk about architecture, ask how he organizes projects, consider his style of writing code. The middle itself already has formed expectations regarding the company - that is, from our side it is necessary to convey what we expect from it and what we can offer.

Is there any pain in your team that you would like to solve? What is the reason, and what could be the solution?

I would like to shift the focus to working with people so that the department pays more attention to developers.My focus is blurring now because there are too many people; my task is to somehow build communication (not necessarily only with my participation) so that the problems that the guys have and their desire to develop are not lost, and brought to their logical conclusion. Everything needs to be repaired and done better. Maybe you can create groups in which the guys in charge of these groups will communicate with the developers - more often than I can afford - and solve their problems, or escalate to me if necessary. I think it’s possible to fix the loss in communications: after all, when the head does not have enough focus on the developer - even because there are simply a lot of developers - this affects his growth. Each developer needs attention - as if we were sitting at the neighboring tables and working together. I already solve this problem, but it is not solved.

How do you build a process to manage so many people? How many leads? Is it hard to set goals?

Not easy. A lot of communication. Instead of official leads, in each team, the leader is the most experienced developer who works directly and communicates with people, conducts reviews, decomposes and cuts tasks. We communicate with each such leader, intersect in a review. There are even larger areas (B2B, B2C), and each area has a person who is responsible for it. He builds work in his direction, including work with people. I try to communicate with both senior developers and leading developers of the direction, as often as possible; we also have general meetings of senior developers, where we discuss news, problems of teams and processes, think what to do. I think that senior developers should feel like some kind of team with which they can make any mountains - make the processes as needed, instead of accepting the inconvenience.

Do 1 on 1? How often? Life hacks?

Actually, in our company the review is just called “1 on 1”. Now I conduct a review with all the senior developers once a month (this is less than recommended, it is better to do it once every couple of weeks). Often we have something to discuss. There are no special life hacks - in the literature it is described in sufficient detail about 1 on 1. It is important to let the developer talk - he should talk about 80% of the time; this is the essence: the task of the leader is to create a friendly and safe atmosphere for the review, so that the developer can tell him everything that bothers him. This is quite difficult and does not always work out, but it's cool if there is 1 on 1, and they have something to discuss. They are best done in an informal setting - for example, you can in the park. Creating a comfortable atmosphere can be different - it’s not only an office meeting room.

What vacancies do you have open?

Which direction? We have quite a lot in different directions. By the front end, we are looking for several middle-developers (in my opinion, 2), you can also senior.

What are the challenges that a manager faces?

It is difficult to talk about the complexity of tasks when you solve them. For example, giving up legacy is a daunting task. There is a business that wants to grow; there is you, the leader who wants Legacy to be gone. It is necessary to find a common language with business and to seek to include in the business plan the tasks of abandoning legacy, which is not trivial. This requires good communication skills, good focus - you need to constantly keep abreast of the hand; the business’s mission is to make money, he doesn’t like to give up working legacy systems.
The challenge is to come up with tasks to improve the work in the department. You need to analyze what problems developers are facing, do not forget to improve the dev-experience. Identifying problems is also non-trivial.

Looking at fronts on a remote site?

We prefer to work in the office, so we do not consider the remote. Naturally, now all the work is just on the remote - we also connect new employees to the remote, but with the condition of moving to the office after the end of the epidemic.

What should I do if the team leader is weak and clearly should not remain in position?

You need to use the feedback mechanism. This is a powerful and cool mechanism, but, of course, you need to do this carefully so that the person is not offended.You need to be able to show empathy, understand the feelings of a person, give feedback in the right direction. He can either accept or not accept it; if he became a team leader, he must be able to work on himself and accept feedback. It is important not just to sulk at him because he “falls short”, but to tell him constructively what, in your opinion, is doing poorly, and to find out his opinion. I myself am not a master of feedback, I have yet to learn how to do this, but I know the main rule: talk about action, not about personality. If you tell the leader what things are sinking in the team, maybe everything will be fixed.

And what's next?

June 30 at 20:00 in our Instagram account will be Vlad Vlad Rau - Senior Digital Analyst in London office of McKinsey Digital Labs. Now Vlad is engaged in product/data engineering. Before moving to London, she interned twice at Google in Dublin, and also studied at GSOM SPbU and IE Business School in Madrid.

You can ask her a question in the comments on this post .

What happened before

  1. Ilona Papava, Senior Software Engineer on Facebook - how to get an internship, get an offer and everything about working for the company
  2. Boris Yangel, Yandex ML Engineer - how not to join the ranks of dignified specialists if you are Data Scientist
  3. Alexander Kaloshin, CEO of LastBackend - how to launch a startup, enter the Chinese market and get 15 million investments.
  4. Natalya Teplukhina, Vue.js core team member, GoogleDevExpret - how to get an interview in GitLab, get into the development team Vue and become Staff-engineer.
  5. Ashot Hovhannisyan, CTO and founder of DeviceLock - who steals and makes money from your personal data.

ITKarma picture

ITKarma picture.