FullStek Confession: Profession, Religion, Dreams
Hello, my name is Pavel and I am fulstek in Mad Devs * applause *.
Against the background of a large number of articles and materials that fulsteks are not needed , fulsteks do not exist , fulsteks are bad , there is an opinion about what advantages fulstek has over narrow specialists and why fulsteks are needed .
At the beginning of the article I wanted to leave a list of links to other articles about fulsteks, but something turned out to be too much, so sorry. I just want to say that there is enough material on why fulstek is good and why fulstek is bad. And each of them is true at least 50%.
There are probably personal emotions and thoughts that do not pretend to be the last resort.
As I said, my name is Pavel, it will soon be 7 years old, as I get money for programming. And all this period I called myself in resumes, at interviews and in other places: Backend developer with knowledge and skills in Frontend and DevOps . One way or another, in a professional career, he more often worked as a backendant on projects, but he was never afraid, neither the front nor ops. Therefore proudly added these two spheres to his description. But with the arrival at Mad Devs and, having worked on one of the projects with our MadOps team, I removed DevOps from my description, because now I think that I don’t understand it at all. Everything in comparison is learned, as is well known. 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 the backend, 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 full stack is bad are: No immersion in any of the spheres , One cannot be a Senior Fullstack Developer , high-end narrow specialists earn more than strong full ones , etc. And you know, I agree with them.
I've been working on the Peklo Tool project for the last few months, where I use Ruby on the backend, VueJS on the front, and Go to implement a text generator.
And I feel the problems:
I 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 immediately use N in this place so that there are no such problems?
And I will answer: I do not know thing N, so well as to quickly apply it in the project in a certain case. I only take time to develop, - read the problem: There is no complete immersion .
And I'm not lying, because the project on which I am working now needs features. PekloTool is a professional tool for generating contextual advertising campaigns. Tulsa is young, development is underway for a little over a year, but it came out fully a couple of months ago only. As a result, now we are doing all the useful features for this product.
How do I know that features are needed and that features will be useful? Very simple, because I'm full . I see the whole project. I see the goals of the project, I see how it works, I see its jambs not only technical, about which I wrote above, but the jambs that users will see.
And here we come to the main idea of ​​this article: I believe that modern fulstek should not be just a coder who can do backend, frontend or something else. Fulstek is the one who participates in the development of the project. In addition to competences in backend, frontend, etc. Full-stack should have an understanding of the project domain, UX / UI knowledge, and even a little marketing. Fulstek needs to know how the project performs its main task: whether making money or saving the world. Fulstek should be on a short leg with the project’s “customer”. Any project has a “customer”, if an outsourcing company is a customer, in a grocery company it is a stakeholder or product. The “customer” must see in the full-stack that specialist who can be consulted on all questions about 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 Affinity"). The essence of the term I described in the previous paragraph. Fulstek should always wear a customer cap, the ideal option is when the “customer” makes up the tasks for the sprint along with the fulstek. That is, fulstek understands the history of the appearance of each task, and not just solves the tasks that have been set for it. I believe that if a person just does a task and his work ends there, even if he does a backend, front-end, mobile phone, etc., this is not full-stack. It's just a backender who can do the frontend, or vice versa.
Here I am writing all this, and the reader may have two thoughts:
There is another side of the coin that I want to describe. This is sadness . The problem of fulsteks 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 invent features and tasks, which I wrote about above. Plus, when you see a project entirely 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 about it: maybe NoSQL DB, or maybe GraphQL, or maybe something else. This is where employment appears by itself. I don’t say that at once I’ll run everything into a conventional GraphQL, but sometimes you take some smaller ideas and put them into practice. 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. And there is no time, you are responsible for the project. I will not say that this sadness , just sad sadness. In contrast, I get a big buzz: when I see positive feedback from users; when they happily write about a feature that prevented you from sleeping for a couple of days; when the number of users grows.
In conclusion, I would like to express the idea that narrow and broad specialists have their own, both advantages for the project, their careers, the environment, and disadvantages. Specific professional, in my opinion, the advantages and disadvantages will be described in one of the following materials, unless of course this is greeted warmly.
I am glad that I am full, because this is a job that I like, which I do not mind doing at the weekend, and which I do with pleasure.
Against the background of a large number of articles and materials that fulsteks are not needed , fulsteks do not exist , fulsteks are bad , there is an opinion about what advantages fulstek has over narrow specialists and why fulsteks are needed .
At the beginning of the article I wanted to leave a list of links to other articles about fulsteks, but something turned out to be too much, so sorry. I just want to say that there is enough material on why fulstek is good and why fulstek is bad. And each of them is true at least 50%.
There are probably personal emotions and thoughts that do not pretend to be the last resort.
As I said, my name is Pavel, it will soon be 7 years old, as I get money for programming. And all this period I called myself in resumes, at interviews and in other places: Backend developer with knowledge and skills in Frontend and DevOps . One way or another, in a professional career, he more often worked as a backendant on projects, but he was never afraid, neither the front nor ops. Therefore proudly added these two spheres to his description. But with the arrival at Mad Devs and, having worked on one of the projects with our MadOps team, I removed DevOps from my description, because now I think that I don’t understand it at all. Everything in comparison is learned, as is well known. 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 the backend, 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 full stack is bad are: No immersion in any of the spheres , One cannot be a Senior Fullstack Developer , high-end narrow specialists earn more than strong full ones , etc. And you know, I agree with them.
I've been working on the Peklo Tool project for the last few months, where I use Ruby on the backend, VueJS on the front, and Go to implement a text generator.
And I feel the problems:
- I feel that this Go code 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 another extension;
- I feel that the code on the rails can be optimized so that fewer queries to the database are made, for example;
- I feel that the indices need to be customized in the database;
- I feel that this Dockerfile needs to be rewritten so that there are fewer layers (or more);
- and so on, so on, so on ...
I 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 immediately use N in this place so that there are no such problems?
And I will answer: I do not know thing N, so well as to quickly apply it in the project in a certain case. I only take time to develop, - read the problem: There is no complete immersion .
And I'm not lying, because the project on which I am working now needs features. PekloTool is a professional tool for generating contextual advertising campaigns. Tulsa is young, development is underway for a little over a year, but it came out fully a couple of months ago only. As a result, now we are doing all the useful features for this product.
How do I know that features are needed and that features will be useful? Very simple, because I'm full . I see the whole project. I see the goals of the project, I see how it works, I see its jambs not only technical, about which I wrote above, but the jambs that users will see.
And here we come to the main idea of ​​this article: I believe that modern fulstek should not be just a coder who can do backend, frontend or something else. Fulstek is the one who participates in the development of the project. In addition to competences in backend, frontend, etc. Full-stack should have an understanding of the project domain, UX / UI knowledge, and even a little marketing. Fulstek needs to know how the project performs its main task: whether making money or saving the world. Fulstek should be on a short leg with the project’s “customer”. Any project has a “customer”, if an outsourcing company is a customer, in a grocery company it is a stakeholder or product. The “customer” must see in the full-stack that specialist who can be consulted on all questions about 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 Affinity"). The essence of the term I described in the previous paragraph. Fulstek should always wear a customer cap, the ideal option is when the “customer” makes up the tasks for the sprint along with the fulstek. That is, fulstek understands the history of the appearance of each task, and not just solves the tasks that have been set for it. I believe that if a person just does a task and his work ends there, even if he does a backend, front-end, mobile phone, etc., this is not full-stack. It's just a backender who can do the frontend, or vice versa.
Here I am writing 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, I will “delight you”. You lose a huge reservoir of useful activities that will benefit your project, as well as lose the opportunity to acquire important competencies that can determine the future development of your career;
- Is this what a full-product product should look like? Yes you are right. With the exception of a couple of points: the product-owner is often the team leader of the whole project team. I will not attribute the leadership qualities to a full-stack. This is about something else. Well, a product manager must be able to count the cost of developing a project, full stack is not obliged to think about the finances that are related to development. From his position, there is already money to develop. Of course, he can offer options to reduce the cost of development, but only in percentage or qualitative terms, not in quantitative terms. Maybe a couple more moments I’m missing something, that I should be able to make a product, but I can, I’ll be full.
There is another side of the coin that I want to describe. This is sadness . The problem of fulsteks 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 invent features and tasks, which I wrote about above. Plus, when you see a project entirely 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 about it: maybe NoSQL DB, or maybe GraphQL, or maybe something else. This is where employment appears by itself. I don’t say that at once I’ll run everything into a conventional GraphQL, but sometimes you take some smaller ideas and put them into practice. 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. And there is no time, you are responsible for the project. I will not say that this sadness , just sad sadness. In contrast, I get a big buzz: when I see positive feedback from users; when they happily write about a feature that prevented you from sleeping for a couple of days; when the number of users grows.
In conclusion, I would like to express the idea that narrow and broad specialists have their own, both advantages for the project, their careers, the environment, and disadvantages. Specific professional, in my opinion, the advantages and disadvantages will be described in one of the following materials, unless of course this is greeted warmly.
I am glad that I am full, because this is a job that I like, which I do not mind doing at the weekend, and which I do with pleasure.
Source: https://habr.com/ru/post/446040/
All Articles