One day remote front-end

I recently became a team leader on one of our company's projects.

Today I want to talk about the inner kitchen of Maxillect and our team on the example of one of my working days, for example, yesterday.

image

If your project does not “burn”, then the days of the front-end are similar to each other. We do not “put out the fires”, but do our work day by day, and try to do it efficiently. Yesterday was no exception. But in my opinion, this is the criterion of our success - we are calm when calmly on production.

11:00 GMT + 5


My work day traditionally starts at 11. I live according to Yekaterinburg time. As an ordinary developer, I started working from 9-10 in the morning, but when I became a team leader, I adjusted to my Moscow colleagues. Many questions in the team arise at the end of the working day according to Moscow time. I had to shift my schedule to the team. It turned out to be even more convenient: my girlfriend’s working day now ends at the same time.

Usually the beginning of the day is calm, at this time I can effectively plan the working day. The team does not have a common start time for everyone, it is important to simply discuss the schedule in advance. Someone gets in touch at 9 in the morning, and someone at 10 in the Moscow time zone. Therefore, my first working hour of half the team is not there yet, and I can afford to spend this time with a laptop on a stationary bike.

image

In this mode, the simplest tasks are well solved, so I give this time to the formation of the “picture of the day”: I check the mail, see what has accumulated from the changes, which invitations to the meetings have arrived.

Every day I check what is happening on the task board. Not all developers write in the comments or say on the daily why the task is being knocked out of the schedule. It’s better to notice such things in the morning, so that during the day to raise a question in tête-à-tête calling.

11:30


After a half-hour “trip” I move to a convenient workplace with a large monitor. Perhaps this is the most convenient place for me in this world. Honestly, I can now see how some colleagues, unexpectedly switching to remote work because of the isolation regime, are sitting in the kitchen in ordinary chairs. I can’t imagine how you can work for so long. Before going to the udalenka in mid-2019, I worried about my comfort in advance - I bought a comfortable table and chair. By the way, the table can switch between two positions. At the touch of a button, he goes up and I can work a little while standing.

image

12:45


Timlid's work involves a lot of communication, but in the morning you can manage to do tasks that require deep immersion. And at 12:45 local time the first general team daily rally begins. The purpose of the rally is to exchange the status of current tasks. Often, business comes to these meetings to talk about immediate plans.

I noticed that the forced universal transition to remote work on our team had a rather positive effect.

Firstly, the business has slightly changed the processes, resuming regular calls. Previously, many issues were resolved by colleagues in the office (offline), and the remote part of the team could not attend them. Now everything happens online. And I can participate in their brainstorms and discussions. To the business I see the team look. It is great and inspiring.

Secondly, people who worked in the office can now sometimes be hit after the end of their working day, and they will answer. Before that, they went offline.

Of course, there are individuals who find it difficult to navigate in the new conditions. Their pace has fallen. But most of the team we have long been at a distance, so for them, formally, nothing has changed.

Usually, a daily rally falls within 15 minutes, after which we switch back to work.

2 p.m.


At 14:00 local time, already in-team communication begins. We discuss who did what and what problems they encountered. Here, too, yesterday, as always, we met in 15 minutes.

The rest of the day is the solution of tasks and one-on-one discussion of what needs to be worked out jointly. For these internal communications, we use Slack, which has all the necessary functions. All notifications come to it. The Calendar is rarely used, where invitations to call from business are received. Having become a team leader, I gradually drag communication with business onto myself. Earlier on the project, it was a common practice that the business itself communicated directly with the developer, if he saw that some tasks were stuck. Now we are planning to move away from this practice. This approach is more useful both for business and for the developers themselves, as they are less distracting. They can focus on problem solving.

16:00


Yesterday, I managed to arrange several continuous coding sessions for an hour and a half. Due to the abundance of issues that have to be addressed in the role of team lead, this is not always the case. As an ordinary developer, I shared the second half of the day with the help of a “tomato” timer, and in fifteen-minute breaks I could go away - to lie down or vice versa to do something active. But now too often questions arise for me, in breaks I still have to sit back. So tomato timers are now a thing of the past, as are quiet periods of more than 1.5 hours.

I still plan to try timers in the future when everything settles down in a new status. The first time after switching to team leaders it seemed to me that being a simple programmer was much easier, but now I began to find interesting pieces in my work, and most importantly, I began to understand how to structure it. Before that, I already tried to be a team leader in another company. But the deadlines were always there, and due to constant processing, I quickly burned out, having no time to understand how to build my own processes. There I left everything in the world, even studying at Stratoplan. Now the situation is radically different - I had a desire to return to abandoned classes and finish what I started.

Until I built my own processes, so when I want to sit down for fun, experiment, checking some solution outside the scope of the project, I spend time on the weekend. During these periods no one hurries or distracts me. This is how technological improvements for the project are born. And the results of such experiments help show the business what the actual advantage is. For us, such improvements more than pay off, since we spend much less nerves on support, do not drop production once again.

If the tasks that I did on the weekend relate to the project, I track them just on Monday, and I relax a bit at lunch. True, there were no such tasks this weekend.

19:30


I can also afford to spend the last half hour of a working day on a stationary bike. At this point, I already feel tired both with me and the team, so it is better to give preference to simple tasks that pedals are not a hindrance.

Yesterday at exactly 20:00 local time I turned off the computer and went about my business. Almost every day ends exactly like that. Tasks rarely go beyond the boundaries of working time, only if there are some truly critical tasks that interfere with someone, for example, testers with a different schedule.

In the opposite direction, this also works. On our project, rummages are extremely rare. Therefore, sometimes you can finish the working day earlier (or leave in the middle of the day), compensating for this time on another day. It is enough to write to the team that I am AFK, say, for 1 hour. All this will be seen later in the timeshare report, which each fills for himself - in this we trust each other.

In general, Monday, which I do not like folklore, is always quite calm. After the weekend, we have a modern stack that helps to get into work - I like working with the latest tools, trying different new things, so it's very interesting to program. In fact, along with changing the stack on the project, a hobby migrated to the main job.

The specific schedule largely depends on the features of the current release. We publish the results of our work in production about once every two weeks. It happens that large indivisible tasks fall into the release and then this period increases. But in general, business is for releasing releases more often.

Depending on the frequency of releases, all mandatory procedural measures are assigned.
Firstly, once in a couple of weeks we plan one of the next releases - we discuss tasks about 3 releases ahead. Unlike daily phone calls, planning can take up to an hour, taking away a significant portion of the work time. Not so long ago, we moved from rewriting the project to a new framework (we switched from Angular to React) to the gradual introduction of new features. And the next few months we will have to implement a lot of interesting functionality, so it became “hot" in the planning.
Secondly, after each release a retrospective is held. Regardless of how we went into production - good or bad - we discuss the details.

Thirdly, there are brainstorms with business when we come up with interesting functionality that can be offered to business (which we ourselves would be interested to implement). By the way, unlike many other dialers, brainstorms are held in video format.

All these events completely eliminate the feeling of uniformity in work - each week is built in its own way, the evolution of the project and its prospects are visible. Although our planning horizon is not so great, I know that there is still a lot of interesting things ahead, and it will be possible to start implementing this tomorrow morning.

PS We publish our articles on several sites of the Runet. Subscribe to our pages in VK , FB , Instagram or Telegram channelto learn about all of our publications and other Maxilect news.

All Articles