Fullstack - why is it cool, or how to get pleasure from work

Recently, serious battles broke out on Habré in the comments to the Fulsteki article - these are eternal midla. Do not go on this path if you do not want to suffer

I will try to express my point of view that fullstek is really cool and why it’s good to follow this path.

Perhaps someone the text below will help to take this path, and perhaps vice versa, will save immature minds from it. In general, welcome under cat.

** AHTUNG! All of the following is not the absolute ultimate truth and is my subjective vision (of this world).

First, let's define the terms that will be discussed below to be in the same information field, because The concept of fullstack is different for everyone (exactly like the division into Junior / Middle / Senior and other tables of ranks).
')
The most common opinion is that fullstack is a developer who can work on one project with one's own strength, from back to front.

Some of you may say, “Well, in my team, the middle ones can”, which (to put it mildly) is incorrect in most cases. If the developer of the front can fix / add something in the back code, dig deeper into database queries, this is not a full-stack yet.
After all, the development of the project is not only the code of the back-up and the front, it is also the construction / configuration / support of the infrastructure for the resulting product. It is not enough to write code, it still needs to be made to work on the object. And the object can be a 5-dollar VPS with LAMP in default, and cloud networks like AWS / Azure, or even its own infrastructure where real hardware lives, from servers / workstations to routers.

Therefore, it will not be all about fullstack-dev, but rather about fullstack-in general. Which can pull in one person the project from the negotiation stage to the stage of signing the act of the work performed.

I will not bend my fingers, listing what should and what should not know a fullstack specialist, because This is an extremely vague list. In the end, someone manages to donate and promote "projects of one tool", say Java with NoSQL, but today we will not talk about this.

So, how to become a fullstack developer, do you need to become a fullstack or is it better to move in the direction of something one?

Let's briefly go over the plusminuses lying on the surface.

Minuses

Probably the most obvious disadvantage - accept as a fact that you will always ( always ) give in to highly specialized developers in everything - from mastering the most advanced tools and technologies to code quality. If you are ambitious, want to always be at the forefront of progress, want to bend your fingers and look at the rest, like shit - fullstack is not your way.

Finding a job for fullstack is much easier than for a single technology developer. But finding a high paying job is still more difficult. Paradox, yes? However, in the overwhelming majority of cases, this is the case (if of course we want to use a full-stack as a full-stack, and not as a “Java programmer”). Where there is a lot of pay from the first days / months of work, you usually don’t need “both the reaper and the reaper, and the igrets on the dude” - they require one more well-oiled gear into a common mechanism that will do exactly one task and do it well, as said timlid . There are exceptions, of course, but not as many as we would like.

Work in one helmet implies finite resources. Those. you can not implement a truly large software product. Even if there is enough knowledge, not enough time. You will not be able to release a killer game (small indie developments are good, but it’s not about them), the operating system or Mega-Office-XXL. Often, people will burn out if they have charged themselves with a very large project without calculating their strength. If you like to make games, or participate in large projects (usually international), well, or to get a good salary immediately after the university (2-3 years of active work) in one area - you are not here either.

You have to learn all the time. Constantly. Lot. Different. If you recall the years of study with shudder, conferences and webinars make you dislike if you are not ready to spend hours reading megatons of informational garbage, looking for bits of useful information in it, if you are annoyed by technologies that you have to manage , regardless of desires and preferences - You do not need the fullstack path. It is necessary to understand (and accept) that a certain Zen is needed here. You just have to be dragged from what is happening, which is far from everyone.

Never forget that a person is, in fact, a single-task animal, but you will have to constantly emulate multitasking modes (different languages, different development environments, different approaches, and the “write code” and “deploy infrastructure” concepts themselves are different). Believe me, at first it is very difficult and leads to low speed and a lot of errors.

And finally, there is always the risk of remaining hostage to the situation and stop developing if the place of work does not imply any career ladders. And many thousands of potentially excellent workers are sadly sitting in small desktops, doing nothing at all what they wanted 10 years ago. Yes, they can do it in Windows Server, in * nix, they can also in Java and Python, they support some handicraft in C #, the “corporate portal” in PHP + JS has been written a long time ago, but there are no more tasks, the office has everything debugged, everything is working.
And it is worth to move abroad in 35-40 years, as the conservatism embedded in humans is included, multiplied by this cozy swamp, which ultimately leads to such a “suitcase without a handle”. And breaking this vicious circle every year becomes more difficult. Be wary of such a state, for a beard and a sweater grow even faster than that of narrow specialists who have been writing for 10 years on the same thing.

Perhaps enough for today horror, let's talk about the pros

You can do everything. Well, or almost. From the corporate site to the mobile application. After all, you are not limited to 1-2 technologies. You can even build your own micro-empire on a single intranet.

If you have been working fullstack for a long time (and most importantly - successfully), you can easily lead the development team. Become an Architect. Those who stand at the origins of any major project.

If you are a sullen introvert, love cars and do not love people - earn money on remote. Leisurely leading several projects, you can earn good money without spending nerves on communicating with the team.

If you like to communicate with people, you have a suspended (or trained) language (or you are just a cunning introvert with will power) - you can earn more money by penetrating the customer’s soul.

It should be understood that you will never be left without work at all. If you are the right fullstack, then you should pull on the middle of any technology. And even on the "signora of an average hand" (this is when a Google team is not taken from the street, but in a more or less serious project it is easy).

And finally, some simple and obvious (alas, not all and not always) tips. I will deliberately focus on the code base, and not on the infrastructure, so as not to bore readers.

Council first. Do not let your pride prevail over you . It is very important. Take for granted that there are people who are doing something better than you. Learn from them if possible. The approach “you are all shit, but I am a whole fullstack, I can do everything” is wrong at the root, and often beats not only on vanity, but also on the wallet. If you love yourself and money - follow this advice.

Council of the second. Once or twice in a few years it would be nice to work in a team of narrow specialists. This greatly raises the skill, because technology does not stand on the spot at all, but rush with the speed of a locomotive, and narrow specialists try to be in trend. If there is such an opportunity - do not miss it, learn a lot, find a lot of bottlenecks in your old projects and do not allow them in new ones.

Council of the third. Do not aspire to study ALL. First, it is simply impossible, and secondly, it is not necessary. Use well-studied technologies in your projects, those in which you are truly a “signor”. New PLs need to be studied (at least for general development), but they should be applied in real projects only after they become clear to you. As directly languages ​​and as with what quality they can be used, what benefit can we derive from the transition from, say, Java to Kotlin or Scala. If you do not understand the benefits, then either the language has not yet matured, or (most likely) you yourself. Approach "give two weeks to read specs and I will write on this shit" - a bad approach.

Council of the fourth. If you look at the code of your development 1-3 years ago and you do not want to fix it, most likely you have a crisis, like the developer (or the ideal code in all respects, which does not happen). Try advice # 2.

Council of the fifth. From the very beginning of your journey, work on a client base. Cultivate your credibility. You and your design should know. In this case, it does not matter whether you work in an enterprise or freelance on a remote site. If you do not have difficulty communicating with people, be sure to take the time to communicate with the customer. And doubly necessary - to communicate directly with those who have to work with your product. So you can think much better about the architecture of the future project.

Council of the seventh. Match the tools and tasks. Do not shoot from a cannon on the sparrows. No need to deploy local infrastructure with blackjack and girls with low social responsibility for a one-page "corporate website", simply because. that you can customize it. And dragging 5Mb JS frameworks to this site is also not necessary (just because you can).

There is no need to drag from the back to the front what the place is exactly on the back. On the contrary, too, do not. Remember, if you suddenly have too many crutches on a project, whose TK has not been changed 100,500 times during development, it means that you have poorly designed the architecture. If possible, correct it; if not, be sure to consider this in the following tasks.

Council of the eighth. Set your priorities correctly. Remember that your task is to make the product, first of all, convenient and as reliable as possible. Even if you have a hypertrophied sense of beauty, beauty should be brought last.

Phew Perhaps this is enough for a start.

Thank you all for your attention.

Oh yeah, I almost forgot ... Let the srach begin!