Главная » Хабрахабр » Исповедь фуллстека: профессия, религия, мечты

Исповедь фуллстека: профессия, религия, мечты

Здравствуйте, меня зовут Павел и я фулстек в Mad Devs *аплодисменты*.

Я лишь хочу сказать, что материалов о том, почему фулстек хорошо и почему фулстек плохо, достаточно. На фоне большого количества статей и материалов о том, что фулстеки не нужны, фулстеки не существуют, фулстеки плохо, сложилось мнение о том, какими преимуществами обладает фулстек над узкими специалистами, и почему фулстеки нужны.
Хотел в начале статьи оставить список ссылок на другие статьи про фулстеков, но их что-то слишком много оказалось, поэтому извините. И каждая из них правдива минимум на 50%.
Тут наверное личные эмоции и мысли, не претендующие на последнюю инстанцию.

И весь этот период я именовал себя в резюме, на собеседованиях и в прочих местах: Backend developer со знанием и умением во Frontend и DevOps. Как я уже говорил, меня зовут Павел, скоро будет 7 лет, как я получаю деньги за программирование. Поэтому гордо добавлял эти две сферы в своё описание. Так или иначе в профессиональной карьере чаще работал как бекендер на проектах, но никогда не боялся, ни фронта, ни опс. Всё в сравнении познаётся, как известно. Правда с приходом в компанию Mad Devs и, поработав на одном из проектов с командой MadOps нашей, убрал из своего описания DevOps, потому что теперь я считаю, что совершенно в нём не разбираюсь. Главное, не встретить бекендера, который заставит убрать бекенд из резюме, иначе вообще ничего не останется. Надеюсь когда-нибудь поработать с такими же фронтенд-специалистами, которые «уговорят» меня убрать приписку «фронтенд».

И знаете, я с ними согласен.
Последние несколько месяцев работаю над проектом Peklo Tool, в котором использую Ruby на бекенде, VueJS на фронте, и Go для реализации текстового генератора. Самые частые аргументы специалистов, которые пишут и считают, что фулстек плохо, звучат так: Нет погружения ни в одну из сфер, Нельзя быть Senior Fullstack Developer, узкие специалисты высокого класса зарабатывают больше, чем сильные фулстеки и т.д.

И я чувствую проблемы:

  • чувствую, что вот этот код на Go можно написать лучше, и он будет работать быстрее или использовать меньше ресурсов системы;
  • чувствую, что мой webpack конфиг можно настроить гораздо лучше, в нём сейчас много мусора;
  • чувствую, что эту вёрстку можно сделать используя современные фичи CSS, SCSS, или взять PostCSS или другой экстенш;
  • чувствую, что код на рельсах можно оптимизировать, чтобы меньше запросов в БД производилось, например;
  • чувствую, что индексы нужно по-человечески в базе настроить;
  • чувствую, что вот этот Dockerfile нужно переписать, чтобы слоёв меньше было (или больше);
  • и так далее, так далее, так далее...

Более того, я очень хочу это всё сделать. Я всё это чувствую. Я только отниму время у разработки, — читай проблема: Нет полного погружения.
И я не совру, ведь проекту, на котором я сейчас работаю, нужны фичи. И, когда появляется свободная минутка, частично решаю хотя бы одну из этих проблем.
Вы спросите меня: а почему сразу в этом месте не заиспользуешь штуку N, чтобы проблем таких не было?
А я отвечу: я не знаю штуку N, настолько хорошо, чтобы быстро её применить в проекте в определённом кейсе. Тулза молодая, разработка ведётся чуть больше года, но в прод она вышла полноценно пару месяцев назад только. PekloTool — это профессиональная тулза для генерации кампаний контекстной рекламы. Очень просто, потому что я фулстек. В итоге, сейчас мы делаем все полезные для подобного продукта фичи.
Откуда я знаю, что нужны фичи и что фичи полезные будут? Я вижу цели проекта, вижу как он работает, вижу его косяки не только технические, о которых писал выше, а косяки, которые пользователям будут видны. Я вижу проект целиком.

Фулстек — это тот, кто участвует в развитии проекта. И тут мы подходим к главной мысли этой статьи: я считаю, что современный фулстек должен быть не просто кодером, который умеет в бекенд, фронтенд или ещё что-то. фулстек должен обладать пониманием предметной области проекта, UX / UI знаниями и даже немного маркетингом. Кроме компетенций по бекенду, фронтенду и т.д. Фулстек должен быть на короткой ноге с «заказчиком» проекта. Фулстек должен знать, каким образом проект выполняет свою основную задачу: будь то зарабатывание денег или спасение мира. «Заказчик» должен видеть в фулстеке того специалиста, с которым можно посоветоваться по всем вопросам по поводу проекта. У любого проекта есть «заказчик», если аутсорс компания, это заказчик, в продуктовой компании — это стейкхолдер или продакт.

Суть термина я описал в предыдущем абзаце. В хендбуке новичка Mad Devs (тот самый документ, который тебе дают почитать в первый день работы компании) есть пункт под названием: «Customer Affinity» (англ. — «Клиентская близость»). То есть фулстек понимает историю появления каждого таска, а не просто решает задачи, которые ему поставили. Фулстек всегда должен надевать на себя шапку заказчика, идеальный вариант — это когда «заказчик» составляет задачи на спринт вместе с фулстеком. Это просто бекендер, который умеет во фронтенд, или наоборот. Я считаю, что если человек просто делает таски и его работа на этом заканчивается, даже если он делает бекенд, фронтенд, мобилку и т.д., это не фулстек.

Вот я всё это пишу, и у читателя могут возникнуть две мысли:

  • какой бред. Тут каждому своё. Если вы так думаете, скорее всего вы узкий специалист, тогда ваше мнение понятно. Но, если вы фулстек, я вас «обрадую». Вы теряете огромный пласт полезной деятельности, которая принесёт пользу вашему проекту, а также теряете возможность приобретения важных компетенций, которые могут определить дальнейшее развитие вашей карьеры;
  • это что фулстек на продакт-оунера должен быть похож? Да вы правы. За исключением пары моментов: продакт-оунер часто бывает и тимлидом всей команды проекта. Лидерские качества я приписывать фулстеку не буду. Это про другое. Ну и продакт-оунер должен уметь считать стоимость разработки проекта, фулстек не обязан думать о финансах, которые относятся к разработке. С его позиции деньги на разработку уже есть. Он, конечно, может предлагать варианты по удешевлению разработки, но только в процентом или качественном выражении, не в количественном. Может быть ещё пару моментов я каких-то упускаю, что должен уметь продакт, но мне можно, я ж фулстек.

Это грусть. Есть ещё одна сторона медали, которую хочется описать. Это очевидно. Проблема фулстеков ещё и в том, что они перегружены. У нас есть ещё общение с заказчиком, чтобы придумывать фичи и задачи, о которых я писал выше. Как правило, мы делаем очень объёмные задачи, комплексные фичи. Чем больше информации, тем больше идей, а чем больше идей, тем больше шанс, что они воплотятся в жизнь. Плюс, когда ты видишь проект целиком с технической точки зрения, ты чаще работаешь над инфраструктурой, архитектурой и прочими вещами. Вот тут занятость и появляется сама собой. В итоге, ты чаще задумываешься: а может NoSQL БД, а может GraphQL, а может ещё что-нибудь. Короче, занят очень. Я не говорю о том, что сразу бегу всё переносить на условный GraphQL, но некоторые идеи поменьше ты иногда сам принимаешь, и воплощаешь в жизнь.

Хочется новую библиотеку попробовать, больше изучить конфиг Gitlab CI, покурить что-нибудь интересное и относительно новое для себя на фронте, например, Logux. А хочется что? Я не скажу, что эта грусть, прямо грустная грусть. А времени нет, ты ответственный за проект. В противовес этому я получаю большой кайф: от того, когда вижу положительные отзывы пользователей; когда они радостно пишут о фиче, из-за которой ты не спал пару дней; когда растёт количество пользователей.

Конкретные профессиональные, по моему мнению, преимущества и недостатки опишу в одном из следующих материалов, если конечно этот будет встречен тепло. В заключении выражу мысль о том, что у узких и широких специалистов есть свои, как преимущества для проекта, их карьеры, окружения, так и недостатки.

Я рад тому, что я фулстек, потому что это та работа, которая мне нравится, которую я не прочь поделать в выходные, и которой занимаюсь с удовольствием.


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

Слушаем SID-музыку через OPL3 на современных ПК

Кто-то может подумает, что это будет что-то ужасное, а оказывается если сделать простой маппер, то можно получить весьма хорошее звучание, как это сделали несколько разработчиков в программе LLSID ещё в далеком 2007 году. Наверное не все любители чиптюн музыки знают, ...

Пользователь в Docker

В новой статье он рассказывает, как создать пользователей в Docker. Андрей Копылов, наш технический директор, любит, активно использует и пропагандирует Docker. Правильная работа с ними, почему пользователей нельзя оставлять с root правами и, как решить задачу несовпадения идентификаторов в Dockerfile. Это кажется очень удобно, ведь ...