Здравствуйте, меня зовут Павел и я фулстек в Mad Devs *аплодисменты*.
На фоне большого количества статей и материалов о том, что фулстеки не нужны, фулстеки не существуют, фулстеки плохо, сложилось мнение о том, какими преимуществами обладает фулстек над узкими специалистами, и почему фулстеки нужны.
Хотел в начале статьи оставить список ссылок на другие статьи про фулстеков, но их что-то слишком много оказалось, поэтому извините. Я лишь хочу сказать, что материалов о том, почему фулстек хорошо и почему фулстек плохо, достаточно. И каждая из них правдива минимум на 50%.
Тут наверное личные эмоции и мысли, не претендующие на последнюю инстанцию.
Как я уже говорил, меня зовут Павел, скоро будет 7 лет, как я получаю деньги за программирование. И весь этот период я именовал себя в резюме, на собеседованиях и в прочих местах: Backend developer со знанием и умением во Frontend и DevOps. Так или иначе в профессиональной карьере чаще работал как бекендер на проектах, но никогда не боялся, ни фронта, ни опс. Поэтому гордо добавлял эти две сферы в своё описание. Правда с приходом в компанию Mad Devs и, поработав на одном из проектов с командой MadOps нашей, убрал из своего описания DevOps, потому что теперь я считаю, что совершенно в нём не разбираюсь. Всё в сравнении познаётся, как известно. Надеюсь когда-нибудь поработать с такими же фронтенд-специалистами, которые «уговорят» меня убрать приписку «фронтенд». Главное, не встретить бекендера, который заставит убрать бекенд из резюме, иначе вообще ничего не останется.
Самые частые аргументы специалистов, которые пишут и считают, что фулстек плохо, звучат так: Нет погружения ни в одну из сфер, Нельзя быть Senior Fullstack Developer, узкие специалисты высокого класса зарабатывают больше, чем сильные фулстеки и т.д. И знаете, я с ними согласен.
Последние несколько месяцев работаю над проектом Peklo Tool, в котором использую Ruby на бекенде, VueJS на фронте, и Go для реализации текстового генератора.
И я чувствую проблемы:
Я всё это чувствую. Более того, я очень хочу это всё сделать. И, когда появляется свободная минутка, частично решаю хотя бы одну из этих проблем.
Вы спросите меня: а почему сразу в этом месте не заиспользуешь штуку N, чтобы проблем таких не было?
А я отвечу: я не знаю штуку N, настолько хорошо, чтобы быстро её применить в проекте в определённом кейсе. Я только отниму время у разработки, — читай проблема: Нет полного погружения.
И я не совру, ведь проекту, на котором я сейчас работаю, нужны фичи. PekloTool — это профессиональная тулза для генерации кампаний контекстной рекламы. Тулза молодая, разработка ведётся чуть больше года, но в прод она вышла полноценно пару месяцев назад только. В итоге, сейчас мы делаем все полезные для подобного продукта фичи.
Откуда я знаю, что нужны фичи и что фичи полезные будут? Очень просто, потому что я фулстек. Я вижу проект целиком. Я вижу цели проекта, вижу как он работает, вижу его косяки не только технические, о которых писал выше, а косяки, которые пользователям будут видны.
И тут мы подходим к главной мысли этой статьи: я считаю, что современный фулстек должен быть не просто кодером, который умеет в бекенд, фронтенд или ещё что-то. Фулстек — это тот, кто участвует в развитии проекта. Кроме компетенций по бекенду, фронтенду и т.д. фулстек должен обладать пониманием предметной области проекта, UX / UI знаниями и даже немного маркетингом. Фулстек должен знать, каким образом проект выполняет свою основную задачу: будь то зарабатывание денег или спасение мира. Фулстек должен быть на короткой ноге с «заказчиком» проекта. У любого проекта есть «заказчик», если аутсорс компания, это заказчик, в продуктовой компании — это стейкхолдер или продакт. «Заказчик» должен видеть в фулстеке того специалиста, с которым можно посоветоваться по всем вопросам по поводу проекта.
В хендбуке новичка Mad Devs (тот самый документ, который тебе дают почитать в первый день работы компании) есть пункт под названием: «Customer Affinity» (англ. — «Клиентская близость»). Суть термина я описал в предыдущем абзаце. Фулстек всегда должен надевать на себя шапку заказчика, идеальный вариант — это когда «заказчик» составляет задачи на спринт вместе с фулстеком. То есть фулстек понимает историю появления каждого таска, а не просто решает задачи, которые ему поставили. Я считаю, что если человек просто делает таски и его работа на этом заканчивается, даже если он делает бекенд, фронтенд, мобилку и т.д., это не фулстек. Это просто бекендер, который умеет во фронтенд, или наоборот.
Вот я всё это пишу, и у читателя могут возникнуть две мысли:
Есть ещё одна сторона медали, которую хочется описать. Это грусть. Проблема фулстеков ещё и в том, что они перегружены. Это очевидно. Как правило, мы делаем очень объёмные задачи, комплексные фичи. У нас есть ещё общение с заказчиком, чтобы придумывать фичи и задачи, о которых я писал выше. Плюс, когда ты видишь проект целиком с технической точки зрения, ты чаще работаешь над инфраструктурой, архитектурой и прочими вещами. Чем больше информации, тем больше идей, а чем больше идей, тем больше шанс, что они воплотятся в жизнь. В итоге, ты чаще задумываешься: а может NoSQL БД, а может GraphQL, а может ещё что-нибудь. Вот тут занятость и появляется сама собой. Я не говорю о том, что сразу бегу всё переносить на условный GraphQL, но некоторые идеи поменьше ты иногда сам принимаешь, и воплощаешь в жизнь. Короче, занят очень.
А хочется что? Хочется новую библиотеку попробовать, больше изучить конфиг Gitlab CI, покурить что-нибудь интересное и относительно новое для себя на фронте, например, Logux. А времени нет, ты ответственный за проект. Я не скажу, что эта грусть, прямо грустная грусть. В противовес этому я получаю большой кайф: от того, когда вижу положительные отзывы пользователей; когда они радостно пишут о фиче, из-за которой ты не спал пару дней; когда растёт количество пользователей.
В заключении выражу мысль о том, что у узких и широких специалистов есть свои, как преимущества для проекта, их карьеры, окружения, так и недостатки. Конкретные профессиональные, по моему мнению, преимущества и недостатки опишу в одном из следующих материалов, если конечно этот будет встречен тепло.
Я рад тому, что я фулстек, потому что это та работа, которая мне нравится, которую я не прочь поделать в выходные, и которой занимаюсь с удовольствием.
На фоне большого количества статей и материалов о том, что фулстеки не нужны, фулстеки не существуют, фулстеки плохо, сложилось мнение о том, какими преимуществами обладает фулстек над узкими специалистами, и почему фулстеки нужны.
Хотел в начале статьи оставить список ссылок на другие статьи про фулстеков, но их что-то слишком много оказалось, поэтому извините. Я лишь хочу сказать, что материалов о том, почему фулстек хорошо и почему фулстек плохо, достаточно. И каждая из них правдива минимум на 50%.
Тут наверное личные эмоции и мысли, не претендующие на последнюю инстанцию.
Как я уже говорил, меня зовут Павел, скоро будет 7 лет, как я получаю деньги за программирование. И весь этот период я именовал себя в резюме, на собеседованиях и в прочих местах: Backend developer со знанием и умением во Frontend и DevOps. Так или иначе в профессиональной карьере чаще работал как бекендер на проектах, но никогда не боялся, ни фронта, ни опс. Поэтому гордо добавлял эти две сферы в своё описание. Правда с приходом в компанию Mad Devs и, поработав на одном из проектов с командой MadOps нашей, убрал из своего описания DevOps, потому что теперь я считаю, что совершенно в нём не разбираюсь. Всё в сравнении познаётся, как известно. Надеюсь когда-нибудь поработать с такими же фронтенд-специалистами, которые «уговорят» меня убрать приписку «фронтенд». Главное, не встретить бекендера, который заставит убрать бекенд из резюме, иначе вообще ничего не останется.
Самые частые аргументы специалистов, которые пишут и считают, что фулстек плохо, звучат так: Нет погружения ни в одну из сфер, Нельзя быть Senior Fullstack Developer, узкие специалисты высокого класса зарабатывают больше, чем сильные фулстеки и т.д. И знаете, я с ними согласен.
Последние несколько месяцев работаю над проектом Peklo Tool, в котором использую Ruby на бекенде, VueJS на фронте, и Go для реализации текстового генератора.
И я чувствую проблемы:
- чувствую, что вот этот код на Go можно написать лучше, и он будет работать быстрее или использовать меньше ресурсов системы;
- чувствую, что мой webpack конфиг можно настроить гораздо лучше, в нём сейчас много мусора;
- чувствую, что эту вёрстку можно сделать используя современные фичи CSS, SCSS, или взять PostCSS или другой экстенш;
- чувствую, что код на рельсах можно оптимизировать, чтобы меньше запросов в БД производилось, например;
- чувствую, что индексы нужно по-человечески в базе настроить;
- чувствую, что вот этот Dockerfile нужно переписать, чтобы слоёв меньше было (или больше);
- и так далее, так далее, так далее...
Я всё это чувствую. Более того, я очень хочу это всё сделать. И, когда появляется свободная минутка, частично решаю хотя бы одну из этих проблем.
Вы спросите меня: а почему сразу в этом месте не заиспользуешь штуку N, чтобы проблем таких не было?
А я отвечу: я не знаю штуку N, настолько хорошо, чтобы быстро её применить в проекте в определённом кейсе. Я только отниму время у разработки, — читай проблема: Нет полного погружения.
И я не совру, ведь проекту, на котором я сейчас работаю, нужны фичи. PekloTool — это профессиональная тулза для генерации кампаний контекстной рекламы. Тулза молодая, разработка ведётся чуть больше года, но в прод она вышла полноценно пару месяцев назад только. В итоге, сейчас мы делаем все полезные для подобного продукта фичи.
Откуда я знаю, что нужны фичи и что фичи полезные будут? Очень просто, потому что я фулстек. Я вижу проект целиком. Я вижу цели проекта, вижу как он работает, вижу его косяки не только технические, о которых писал выше, а косяки, которые пользователям будут видны.
И тут мы подходим к главной мысли этой статьи: я считаю, что современный фулстек должен быть не просто кодером, который умеет в бекенд, фронтенд или ещё что-то. Фулстек — это тот, кто участвует в развитии проекта. Кроме компетенций по бекенду, фронтенду и т.д. фулстек должен обладать пониманием предметной области проекта, UX / UI знаниями и даже немного маркетингом. Фулстек должен знать, каким образом проект выполняет свою основную задачу: будь то зарабатывание денег или спасение мира. Фулстек должен быть на короткой ноге с «заказчиком» проекта. У любого проекта есть «заказчик», если аутсорс компания, это заказчик, в продуктовой компании — это стейкхолдер или продакт. «Заказчик» должен видеть в фулстеке того специалиста, с которым можно посоветоваться по всем вопросам по поводу проекта.
В хендбуке новичка Mad Devs (тот самый документ, который тебе дают почитать в первый день работы компании) есть пункт под названием: «Customer Affinity» (англ. — «Клиентская близость»). Суть термина я описал в предыдущем абзаце. Фулстек всегда должен надевать на себя шапку заказчика, идеальный вариант — это когда «заказчик» составляет задачи на спринт вместе с фулстеком. То есть фулстек понимает историю появления каждого таска, а не просто решает задачи, которые ему поставили. Я считаю, что если человек просто делает таски и его работа на этом заканчивается, даже если он делает бекенд, фронтенд, мобилку и т.д., это не фулстек. Это просто бекендер, который умеет во фронтенд, или наоборот.
Вот я всё это пишу, и у читателя могут возникнуть две мысли:
- какой бред. Тут каждому своё. Если вы так думаете, скорее всего вы узкий специалист, тогда ваше мнение понятно. Но, если вы фулстек, я вас «обрадую». Вы теряете огромный пласт полезной деятельности, которая принесёт пользу вашему проекту, а также теряете возможность приобретения важных компетенций, которые могут определить дальнейшее развитие вашей карьеры;
- это что фулстек на продакт-оунера должен быть похож? Да вы правы. За исключением пары моментов: продакт-оунер часто бывает и тимлидом всей команды проекта. Лидерские качества я приписывать фулстеку не буду. Это про другое. Ну и продакт-оунер должен уметь считать стоимость разработки проекта, фулстек не обязан думать о финансах, которые относятся к разработке. С его позиции деньги на разработку уже есть. Он, конечно, может предлагать варианты по удешевлению разработки, но только в процентом или качественном выражении, не в количественном. Может быть ещё пару моментов я каких-то упускаю, что должен уметь продакт, но мне можно, я ж фулстек.
Есть ещё одна сторона медали, которую хочется описать. Это грусть. Проблема фулстеков ещё и в том, что они перегружены. Это очевидно. Как правило, мы делаем очень объёмные задачи, комплексные фичи. У нас есть ещё общение с заказчиком, чтобы придумывать фичи и задачи, о которых я писал выше. Плюс, когда ты видишь проект целиком с технической точки зрения, ты чаще работаешь над инфраструктурой, архитектурой и прочими вещами. Чем больше информации, тем больше идей, а чем больше идей, тем больше шанс, что они воплотятся в жизнь. В итоге, ты чаще задумываешься: а может NoSQL БД, а может GraphQL, а может ещё что-нибудь. Вот тут занятость и появляется сама собой. Я не говорю о том, что сразу бегу всё переносить на условный GraphQL, но некоторые идеи поменьше ты иногда сам принимаешь, и воплощаешь в жизнь. Короче, занят очень.
А хочется что? Хочется новую библиотеку попробовать, больше изучить конфиг Gitlab CI, покурить что-нибудь интересное и относительно новое для себя на фронте, например, Logux. А времени нет, ты ответственный за проект. Я не скажу, что эта грусть, прямо грустная грусть. В противовес этому я получаю большой кайф: от того, когда вижу положительные отзывы пользователей; когда они радостно пишут о фиче, из-за которой ты не спал пару дней; когда растёт количество пользователей.
В заключении выражу мысль о том, что у узких и широких специалистов есть свои, как преимущества для проекта, их карьеры, окружения, так и недостатки. Конкретные профессиональные, по моему мнению, преимущества и недостатки опишу в одном из следующих материалов, если конечно этот будет встречен тепло.
Я рад тому, что я фулстек, потому что это та работа, которая мне нравится, которую я не прочь поделать в выходные, и которой занимаюсь с удовольствием.
