From frontend to backend

Transitions within departments are sometimes treated differently. Someone is just more accustomed to see any career changes within one company through the prism of job growth. Someone does not consider it possible to change the scope of activities, even if it is adjacent to the current one. Still others, in principle, are confident that moving from department to department means that a person takes the position “neither fish nor fowl”, and is unlikely to achieve anything significant.

At the same time, some employers in every possible way welcome this and consider it to be something like a fuse against burning out - the person will change the focus of attention, change the department or department, but will not change the work as a whole.

My name is Kostya, and I have been working at QIWI for almost 4 years. Today I will tell you how successfully moved from frontend-development to the backend.

Frontend

In QIWI, since the end of 2014, I started working as an iOS application developer, and, in principle, I have been developing a QIWI wallet for a couple of years. At the same time, I cannot say that it was boring - the tasks were quite different and within the framework of one application: we were engaged in integrating the wallet with our other services, fixing bugs, and drawing up animations. In addition, there was an interesting experience in creating an application for the Apple Watch. Then he expanded the focus a bit and also worked on the iOS application for Conscience.

And then about that time I started to move slowly to the back. In terms of flexible methodology, this is even convenient - I switched, in the first sprint I could do some tasks on the backend, and in the second I could integrate the API, which I wrote.

But in the backend at that time there were too few developers and too hefty backlog, so in the end I still switched to the backend completely. What I am doing now is the classic tasks of the backender - I am writing code in our microservices, fixing bugs, doing refactoring, comprehending Kotlin. There is an opportunity to work on a fresh product of the company - QIWI Investor.

By the way, I can’t say that in these two years it has somehow turned out to be numb in the front, I was clearly aware that there, too, was there, where to develop. For example, I see what is happening now in the mobile development team, and I understand that, if I stayed there, I would continue to grow further with the guys.

So there was a win-win situation - I wanted to help the team and the product (the advantage in development was not much in the direction of the back-tenders) and gain new knowledge. The Timlids understood everything and let me go without any complaints, the product too.

In addition, I just wanted to diversify knowledge in order not to become attached to one platform (I don’t like Android a bit, but Apple still gives up). Well, there was a desire, in which case, to be able to take and make an application for oneself (both the front and the back), if some cool idea suddenly appears. While that's not useful, really.

Backend

Of course, the very first problem that you encounter in this transition is gaps in the hardware. In my case these were some subtleties of working with databases, but both the ability to learn and the team helped here - the guys are responsive and always ready to help and explain something in detail. In QIWI, in principle, with training at all stages, everything is good, whether you are at least a junior at the very beginning of work, at least decide so and change the sphere a couple of years later.

Nobody was annoyed that at first I obviously didn’t work so efficiently, because I had to enter a lot of things (but in the long run, the team still won).

Of course, even before that, I had a little experience in various fields - mobile games and the web, but all of these were, rather, attempts to find something of my own, rather than just stuffing practical serious experience.

Impressions of the back end after the frontend

No work with UI. At all. Previously, you had to kill time to fix bugs in the UI, now - no. The disadvantages of this situation are that the end user does not see the results of my work specifically, as was the case with the front. I tried to determine what is more difficult - backing or front, and I realized that (personally for me) it was always harder to work with multithreading and network stack. And here it is not so important - you are behind the front or behind. At the front, I just ran into such tasks for the first time, without preparation, and at the back end I already had some kind of experience.

You can gain experience and do something cool in any area, if there is a desire and perseverance, here the practices converge - to do something (and do it well), and to make it work reliably and easily maintained. Moreover, the presence or absence of experience in the front is not so critical for the backend. If the developer takes into account all the little things, he thinks out the corner cases himself and generally understands how they will use his API, then he will do everything as it should without front knowledge.

It is easier for me to detect possible problems just because I know the features of the implementation of our mobile applications. But this is not some kind of superpower - it is a set of knowledge that one way or another is cluttered with any backender, which often works with fronts.

What is the result

Backend-development was another good experience for me - I learned how to write code and conduct reviews, think over architecture. This is really interesting.

But at the same time, having tried that front live, that back, I will not say that if something happens, I would immediately choose a backend at the very beginning of my career. It is still important for me to see and understand how users perceive my product. With the backend, this is all pretty ghostly.

Most likely, choosing the sphere now, I would go to game dev or web frontend. The web is still a good platform for launching new products, and at the same time it has ceased to be creepy and difficult to understand. All these tutorials from spaghetti code and callback-hell were left far behind, fortunately.