April 1, 2019 at 00:19Full Stack Confession: Profession, Religion, Dreams
Hello, my name is Pavel and I am full-stack at Mad Devs * applause *.
Against the background of a large number of articles and materials about the fact that full stacks are not needed , full stacks do not exist , full stacks are bad , there is an opinion about what advantages a full stack has over specialized specialists , and why full stacks are needed .
I wanted to leave a list of links to other articles about full stacks at the beginning of the article, but there were too many of them, so I'm sorry. I just want to say that there is enough material about why a full stack is good and why a full stack is bad. And each of them is at least 50% true.
There are probably personal emotions and thoughts that do not claim to be the last resort.
As I said, my name is Pavel, it will soon be 7 years since I get money for programming. And all this period I called myself in the resume, at interviews and in other places: Backend developer with knowledge and skills in Frontend and DevOps. One way or another, in his professional career he often worked as a back-end on projects, but he was never afraid of either the front or the ops. Therefore, he proudly added these two areas to his description. True, with the arrival of Mad Devs, and having worked on one of the projects with our MadOps team, I removed DevOps from my description, because now I believe that I do not understand it at all. Everything in comparison is known, as you know. I hope to someday work with the same front-end specialists who will "persuade" me to remove the front-end postscript. The main thing is not to meet a backender, which will force you to remove the backend from the resume, otherwise there will be nothing left.
The most frequent arguments of experts who write and believe that a full stack is bad sound like this: No immersion in any of the areas ,You can’t be Senior Fullstack Developer , high-class narrow specialists earn more than strong full stacks , etc. And you know, I agree with them.
Over the past few months, I’ve been working on the Peklo Tool project, which uses Ruby on the backend, VueJS on the front, and Go to implement a text generator.
And I feel the problems:
I can feel it all. Moreover, I really want to do it all. And, when a free minute appears, I partially solve at least one of these problems.
You ask me: why don’t you use thing N in this place right away so that there are no such problems?
And I’ll answer: I don’t know the thing N, so good as to quickly apply it in a project in a specific case. I just take the time from development - read the problem: There is no complete immersion .
And I'm not lying, because the project I'm working on needs features. PekloTool is a professional tool for generating contextual advertising campaigns. The tool is young, development has been underway for a little over a year, but it went into full production only a couple of months ago. As a result, now we are doing all the features useful for such a product.
How do I know that features are needed and that features will be useful? Very simple because I'm full stack . I see the whole project. I see the goals of the project, I see how it works, I see its jambs, not only the technical ones that I wrote about above, but the jambs that users will see.
And here we come to the main point of this article: I believe that a modern full stack should not be just an encoder that can do backends, front-end, or something else. Fullstack is someone who is involved in the development of a project. In addition to backend, frontend, etc. competencies full stack should have an understanding of the subject area of the project, UX / UI knowledge and even a little marketing. Fulstack must know how the project fulfills its main task: whether it is making money or saving the world. Fulstack should be on a short leg with the "customer" of the project. Any project has a “customer”, if an outsourcing company, it is a customer, in a product company it is a stakeholder or product. The “customer” should see in the full stack that specialist with whom you can consult on all issues regarding the project.
In the handbook of the newcomer Mad Devs (the same document that you are given to read on the first day of the company) there is an item called: “Customer Affinity” ( Eng. - “Customer proximity”). I described the essence of the term in the previous paragraph. A full stack should always put on a customer’s hat, the ideal option is when the “customer” makes sprint tasks together with a full stack. That is, a full stack understands the history of the appearance of each task, and not just solves the tasks that it was given. I believe that if a person simply does tasks and his work ends there, even if he does a backend, frontend, mobile phone, etc., this is not a full stack. This is just a back-end that can do front-end, or vice versa.
So I write all this, and the reader may have two thoughts:
There is another side of the coin that I want to describe. It's sad. The problem with full stacks is that they are overloaded. It is obvious. As a rule, we do very voluminous tasks, complex features. We still have communication with the customer to come up with features and tasks that I wrote about above. Plus, when you see the whole project from a technical point of view, you often work on infrastructure, architecture and other things. The more information, the more ideas, and the more ideas, the greater the chance that they will come true. As a result, you often think: maybe a NoSQL database, or maybe GraphQL, or maybe something else. Here employment also appears by itself. I'm not talking about the fact that I immediately run to transfer everything to the conditional GraphQL, but you sometimes accept some smaller ideas yourself and implement them. In short, very busy.
Do you want what? I would like to try a new library, study the Gitlab CI config more, smoke something interesting and relatively new for myself at the front, for example, Logux. But there is no time, you are responsible for the project. I will not say that this sadness , just sad sadness. In contrast to this, I get a big buzz: from when I see positive user reviews; when they joyfully write about a feature because of which you did not sleep for a couple of days; when the number of users grows.
In conclusion, I express the idea that narrow and broad specialists have their own advantages for the project, their career, environment, and disadvantages. In my opinion, I will describe specific professional advantages and disadvantages in one of the following materials, unless of course this is warmly received.
I am glad that I am full-stack, because this is the work that I like, which I do not mind doing the weekend, and which I do with pleasure.
Against the background of a large number of articles and materials about the fact that full stacks are not needed , full stacks do not exist , full stacks are bad , there is an opinion about what advantages a full stack has over specialized specialists , and why full stacks are needed .
I wanted to leave a list of links to other articles about full stacks at the beginning of the article, but there were too many of them, so I'm sorry. I just want to say that there is enough material about why a full stack is good and why a full stack is bad. And each of them is at least 50% true.
There are probably personal emotions and thoughts that do not claim to be the last resort.
As I said, my name is Pavel, it will soon be 7 years since I get money for programming. And all this period I called myself in the resume, at interviews and in other places: Backend developer with knowledge and skills in Frontend and DevOps. One way or another, in his professional career he often worked as a back-end on projects, but he was never afraid of either the front or the ops. Therefore, he proudly added these two areas to his description. True, with the arrival of Mad Devs, and having worked on one of the projects with our MadOps team, I removed DevOps from my description, because now I believe that I do not understand it at all. Everything in comparison is known, as you know. I hope to someday work with the same front-end specialists who will "persuade" me to remove the front-end postscript. The main thing is not to meet a backender, which will force you to remove the backend from the resume, otherwise there will be nothing left.
The most frequent arguments of experts who write and believe that a full stack is bad sound like this: No immersion in any of the areas ,You can’t be Senior Fullstack Developer , high-class narrow specialists earn more than strong full stacks , etc. And you know, I agree with them.
Over the past few months, I’ve been working on the Peklo Tool project, which uses Ruby on the backend, VueJS on the front, and Go to implement a text generator.
And I feel the problems:
- I feel that this code on Go can be written better, and it will work faster or use less system resources;
- I feel that my webpack config can be configured much better, there is a lot of garbage in it now;
- I feel that this layout can be done using modern CSS, SCSS features, or take PostCSS or other extens;
- I feel that the code on the rails can be optimized so that fewer queries in the database are made, for example;
- I feel that indexes need to be configured humanly in the database;
- I feel that this Dockerfile needs to be rewritten so that there are fewer (or more) layers;
- and so on, so on, so on ...
I can feel it all. Moreover, I really want to do it all. And, when a free minute appears, I partially solve at least one of these problems.
You ask me: why don’t you use thing N in this place right away so that there are no such problems?
And I’ll answer: I don’t know the thing N, so good as to quickly apply it in a project in a specific case. I just take the time from development - read the problem: There is no complete immersion .
And I'm not lying, because the project I'm working on needs features. PekloTool is a professional tool for generating contextual advertising campaigns. The tool is young, development has been underway for a little over a year, but it went into full production only a couple of months ago. As a result, now we are doing all the features useful for such a product.
How do I know that features are needed and that features will be useful? Very simple because I'm full stack . I see the whole project. I see the goals of the project, I see how it works, I see its jambs, not only the technical ones that I wrote about above, but the jambs that users will see.
And here we come to the main point of this article: I believe that a modern full stack should not be just an encoder that can do backends, front-end, or something else. Fullstack is someone who is involved in the development of a project. In addition to backend, frontend, etc. competencies full stack should have an understanding of the subject area of the project, UX / UI knowledge and even a little marketing. Fulstack must know how the project fulfills its main task: whether it is making money or saving the world. Fulstack should be on a short leg with the "customer" of the project. Any project has a “customer”, if an outsourcing company, it is a customer, in a product company it is a stakeholder or product. The “customer” should see in the full stack that specialist with whom you can consult on all issues regarding the project.
In the handbook of the newcomer Mad Devs (the same document that you are given to read on the first day of the company) there is an item called: “Customer Affinity” ( Eng. - “Customer proximity”). I described the essence of the term in the previous paragraph. A full stack should always put on a customer’s hat, the ideal option is when the “customer” makes sprint tasks together with a full stack. That is, a full stack understands the history of the appearance of each task, and not just solves the tasks that it was given. I believe that if a person simply does tasks and his work ends there, even if he does a backend, frontend, mobile phone, etc., this is not a full stack. This is just a back-end that can do front-end, or vice versa.
So I write all this, and the reader may have two thoughts:
- what nonsense . Here to each his own. If you think so, most likely you are a narrow specialist, then your opinion is clear. But, if you are full-stack, I will “make you happy”. You lose a huge layer of useful activities that will benefit your project, and also lose the opportunity to acquire important competencies that can determine the further development of your career;
- Is this what a full stack should look like on a product owner? Yes you are right. Except for a couple of points: the product-oouner is often the team lead of the entire project. I will not attribute leadership qualities to a full stack. This is about something else. Well, the product-oouner should be able to calculate the cost of developing a project, a full stack is not required to think about finances that relate to development. From his position, there is already money for development. He, of course, can offer options to reduce the cost of development, but only in percentage or qualitative terms, not in quantitative terms. Maybe a couple of points I’m missing some that the product should be able to, but I can, I'm full stack.
There is another side of the coin that I want to describe. It's sad. The problem with full stacks is that they are overloaded. It is obvious. As a rule, we do very voluminous tasks, complex features. We still have communication with the customer to come up with features and tasks that I wrote about above. Plus, when you see the whole project from a technical point of view, you often work on infrastructure, architecture and other things. The more information, the more ideas, and the more ideas, the greater the chance that they will come true. As a result, you often think: maybe a NoSQL database, or maybe GraphQL, or maybe something else. Here employment also appears by itself. I'm not talking about the fact that I immediately run to transfer everything to the conditional GraphQL, but you sometimes accept some smaller ideas yourself and implement them. In short, very busy.
Do you want what? I would like to try a new library, study the Gitlab CI config more, smoke something interesting and relatively new for myself at the front, for example, Logux. But there is no time, you are responsible for the project. I will not say that this sadness , just sad sadness. In contrast to this, I get a big buzz: from when I see positive user reviews; when they joyfully write about a feature because of which you did not sleep for a couple of days; when the number of users grows.
In conclusion, I express the idea that narrow and broad specialists have their own advantages for the project, their career, environment, and disadvantages. In my opinion, I will describe specific professional advantages and disadvantages in one of the following materials, unless of course this is warmly received.
I am glad that I am full-stack, because this is the work that I like, which I do not mind doing the weekend, and which I do with pleasure.