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

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

Хотел в начале статьи оставить список ссылок на другие статьи про фулстеков, но их что-то слишком много оказалось, поэтому извините. Я лишь хочу сказать, что материалов о том, почему фулстек хорошо и почему фулстек плохо, достаточно. И каждая из них правдива минимум на 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. А времени нет, ты ответственный за проект. Я не скажу, что эта грусть, прямо грустная грусть. В противовес этому я получаю большой кайф: от того, когда вижу положительные отзывы пользователей; когда они радостно пишут о фиче, из-за которой ты не спал пару дней; когда растёт количество пользователей.

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

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

Комментарии (37)


  1. ganqqwerty
    01.04.2019 01:24
    +1

    Мне кажется, что если у вас в проекте есть фуллстеки, то тут вероятно что-то из нижеперечисленного:
    1) вы консалтинговая компания, которая быстренько прибегает (желательно по тендеру), говнокодит и убегает.
    2) вы разрабатываете что-то очень простенькое, где вопросы ядреных оптимизаций не стоят.
    3) ваши фуллстеки — это просто перегруженные работой бэки, взявшие на себя фронт, а тот, кто вас нанял, отлично экономит до поры. Либо они выгорят, либо они какие-то мутанты
    4) ваши фуллстеки — это девелоперы, которые отлично понимают разницу между собственными интересами и интересами тех, кто их нанял. Они честно работают положенные часы, тратя их на изучение всего что нужно для фуллстеченья. В итоге проект двигается очень медленно или становится кривым, но так как мы не умеем отслеживать продуктивностью программистов, такие ребята могут устроить себе этакий оплачиваемый университет за два-три года.


    1. eggstream
      01.04.2019 02:34

      Есть еще вариант. В эпоху микро- и наносервисов часто возникает ситуация, когда фронт, бэк и овнер — одно лицо, потому что больше нет смысла. Я пришел во фуллстек из фронта. Создать простенький бэк для общения с остальными сервисами на основе современного фреймворка — не особая проблема, большая часть проекта — привычный мне фронт


      1. JustDont
        01.04.2019 13:45

        Я работаю примерно в такой же парадигме, но вот называть себя фуллстек-программистом мне совсем не хочется, потому что де-факто 90+% времени работа идёт над фронтом. Могу ли я бек поковырять? Да конечно могу, но это не фуллстек. Фуллстек будет тогда, когда вы бизнес-критичный функционал будете реализовывать везде (и на фронте, и на беке), а задачи уровня «написать хендлеров express, чтоб у фронта был чистый единый бек, после которого оно уже расходится в разные стороны» — это по силам любому вменяемому программисту, не страдающего пуризмом в извращённой форме («если это не в браузере, то делать не буду»).


        1. eggstream
          01.04.2019 18:51

          Так фишка именно в том, что бизнес-логика как раз и реализована на бэке, а на фронте только максимально удобный UI для неё. И как бы пафосно это не звучало, но хороший программист может писать код на любом человеческом языке программирования (не считая, может быть, марсианских чисто функциональных языков и диалектов брейнфака) и вынос кода с фронта на бэк должен быть если не тривиальной, то, по крайней мере, решаемой задачей. Подход с бизнес-логикой на фронте, когда для бэка остается роль тонкой прокладки для роутинга и синхронизации с другими сервисами, мне совершенно не нравится — получаются какие-то совершенно неповоротливые монстры. Вот и выходит где-то 60% работы на бэке, 35% на фронте и 5% DevOps (минимум для разворачивания собственного окружения и как черновик для прода)


          1. JustDont
            01.04.2019 21:03

            Мне кажется, что вы просто моё «бизнес-критичный функционал» не так прочитали. Это как раз всё то, что продаёт продукт — вплоть до дизайна (если речь про сайты для широкой публики). Понятно, что без всего остального один только дизайн никому не нужен, но и очередной фейсбук никому не будет нужен, если с ним можно общаться только через JSON. И в этом смысле практически всегда будет и бизнес-критичный функционал на фронте, и на беке, и может быть и еще где-нибудь.

            ЗЫ: Я очень не люблю словосочетания «бизнес-логика», потому что под это что только не подписывают. Никогда не видели, как делающий кнопочки фронтэндщик рассуждает, что переключение стилей нажимаемых кнопок — это у него «бизнес-логика»? А я видел.


            1. eggstream
              02.04.2019 00:24

              Я много чего видел и слышал. И отнесение изменения состояния интерфейса к бизнес-логике, и обзывание роутинга на сервере фронтендом (или даже фронтендом бэкенда или бэкендом фронтенда), и то, как три строчки размытых хотелок называют ТЗ.
              Моё мнение, что любой сервис должен быть в первую очередь доступен и полностью работоспособен через API, во вторую — иметь доступ к этому API через максимально простой интерфейс, и только на третьем месте — свистелки, метеоризм и прочий реакт с вебпаком, как бы ни странно это звучало от человека, чьим основным хлебом очень долго был фронт.


              1. JustDont
                02.04.2019 01:37

                любой сервис должен быть

                Чрезмерные обобщения до добра вас никогда не доведут. Не любой.
                Широкому слою общепубличных вещей «простой интерфейс» к API вообще нафиг не сдался, и может спокойно полностью отсутствовать.
                Для вещей, где важна именно клиентская логика работы — да тот же гугльдокс — бекэнд будет в многие разы проще фронтэнда. Он конечно всё равно нужен, но соль совершенно не в нём.


    1. amakhrov
      01.04.2019 05:22

      2) вы разрабатываете что-то очень простенькое, где вопросы ядреных оптимизаций не стоят

      В большинстве приложений не стоят вопросы ядреных оптимизаций.
      И даже в оставшемся меньшинстве ядреные оптимизации нужны, как правило, только для небольшого подмножества задач.


      Так что ваш пункт 2 покрывает довольно-таки большой спектр работ )


      Либо стоит уточнить, что вы называете ядреными оптимизациями.


    1. arheops
      01.04.2019 07:34

      В обычной жизни СРАЗУ надо минимальная оптимизация или полное ее отсутствие.
      Переоптимизация — типичная ошибка джунов.


      1. ukko
        01.04.2019 08:42

        Насколько большие проекты вы разрабатываете? RPS?


        Я веду к тому, что совсем без оптимизации нельзя. Как минимум индексы должны быть проставлены корректно


        1. arheops
          01.04.2019 08:51

          Да 90% сайтов работает вообще без индексов. Или со стандартными индексами как Wordpress
          Если у вас наблюдаются тормоза в базе и вы не в курсе про индексы, то платится за 2-3 часа *DB expert и он вам ставит индексы.
          Более того, я постоянно вижу высоконагруженные системы, в которых не только индексов нет, но и на 128Gb RAM сервере mysql использует конфиг по умолчанию и выделяет себе 2гб. Ничего, работает все. Просто ставят быстрые SSD и куча процессоров.

          Оптимизация имеет смысл, когда у вас уже есть пользователи. На старте более важно, чтоб работало хоть как-то.

          Я разрабатываю разные проекты, у меня вторая специализация mysql. Но по факту эти оптимизации не везде нужны, мягко говоря. Современное железо нереально круто. Даже full-scan по таблице в 2млн выполняется секунды.


          1. ukko
            01.04.2019 09:26

            Ок, понял свою ошибку…

            Индексы — слишком надуманный пример.

            Пусть будет пример с циклом в цикле в котором идёт обращением к БД.

            На нормальном ревью, коллеги должны отклонить такой запрос. Ведь даже, несмотря на знаменитое высказывание кнута о преждевременной оптимизации, допускать такое в коде — просто небрежность.


            1. kalashnikovisme Автор
              01.04.2019 10:30

              Про использование запросов в цикле — это, конечно, жесть. Речь всё-таки о менее тяжких преступлениях: о 3-4 запросах, которые идут по порядку, хотя можно было в один, об использовании ORM в тот момент, когда можно без неё обойтись, просто с ней быстрее и т.д.


            1. arheops
              01.04.2019 10:40

              У меня есть один проект, где запросы в цикле работают год уже.
              Да, там можно соптимизировать. Да, я знаю как.
              Но оптимизация будет стоить не меньше дня разработки, а неоптимизированный код кушает всего два ядра из 56, потому будет еще работать долго. Просто вынесен на отдельные ядра и все.
              Я все же придерживаюсь позиции, что лучше иметь начальные знания у всех разработчиков, чем глубокие, но 10х размер команды.
              Как минимум пока проект не приносит миллион в год.
              Понятно, что если у вас 50-500 человек сидит в офисе, то выгоднее для всего кроме прототипов узкая специализация. Но в малых командах не все так очевидно.


              1. kalashnikovisme Автор
                01.04.2019 16:38

                Но, если даже в команде 50 человек есть тимлид или ведущий разработчик, который является тем самым фулстеком, что может быть полезен в любой части системы, как минимум на уровне общения и принятия решений — это безусловно плюс.
                Работал в такой команде. Был кайфово, что есть хотя бы, кто всё знает.


    1. titulusdesiderio
      01.04.2019 09:07

      5) фулстеки-одиночки задействованы на MVP. В одно лицо гораздо проще быстрее и дешевле сделать MVP. Да, БД будет не оптимизирована, вместо вёрстки бутстрап и прочие недостатки. НО без стендап митингов, согласований между командами, и прочего, MVP будет готов через неделю, а не месяц. А потом, если MVP «зайдёт» можно выделить фронтов с дизанеромам, беков с девопсами, аналитиков и запилить уже полноценный проект по этим вашим скрамам с аджайлами.


      1. kalashnikovisme Автор
        01.04.2019 10:33

        Здесь абсолютная верная мысль. Тут, конечно, появляется вопрос о том, как правильно делать MVP, но это другая тема.


    1. kalashnikovisme Автор
      01.04.2019 10:25

      Если честно, совсем не понял ваш четвёртый пункт. Вы имеете ввиду, что мы устраиваем себе оплачиваемый университет, изучая в нём предметную область, продакт-оунерство и т.д.?


      1. ganqqwerty
        01.04.2019 11:46

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


  1. YuryZakharov
    01.04.2019 02:34

    Соглашусь с ganqqwerty, и от себя добавлю, что в современном аджайлнутом мире фуллстеки — это просто способ удешевления разработки. Насколько оправданный — отдельная тема, но такая точка зрения у бизнеса есть. И выжимают из них по полной, так, что действительно получается и качество по всему стеку среднее, и времени и сил смотреть по сторонам (да и вглубь) — нету.


    1. eugene_bx
      01.04.2019 10:33

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


  1. ghrb
    01.04.2019 04:51

    Работа в выходные оплачивается по ТК в двойном размере? Как относится семья к работе в выходные?


    1. kalashnikovisme Автор
      01.04.2019 10:38

      Мне кажется, это тема для отдельной статьи.Скажу вкратце:

      * работаю в белую, но не по ТК
      * у нас с женой есть много совместных проектов (речь не про работу), так что проблем с общением и времяпрепровождением нет


      1. ghrb
        01.04.2019 11:56

        Я просто ещё про один признак перегрузки — работа в выходные, плюс очень удобная для работодателя — бесплатная.


        1. kalashnikovisme Автор
          01.04.2019 16:40

          Переработка небесплатная, конечно. Все часы логируются в соответствии с договором.

          Единственный недочёт перегрузки я описал в статье, других недочётов от перегрузки нет.


  1. DarkGenius
    01.04.2019 08:23

    Так что делать фуллстеку-то? Уходить в узкую область или продолжать развивать кругозор?


    1. Vlad_IT
      01.04.2019 09:56
      +1

      Надо взвешивать плюсы и минусы. ЗП у fullstack и узкого специалиста, плюс-минус равны, но узкому быстрее расти.
      Я ушел с fullstack разработки во frontend, и знания fullstack'а мне очень помогают понимать весь процесс разработки, легко читать серверный код, чтобы лучше понимать его поведение на мои запросы, иногда могу что-то дописать (но по этическим соображениям стараюсь этого не делать, если под это выделены люди). Я стал меньше уставать, т.к. из-за того, что я лучше знаю свою область, мне приходится меньше штудировать документацию, ловить баги. Учиться приходится столько же, т.к. материала для изучения все равно очень много даже в узких областях. Но думаю, в этом нет необходимости, можно спокойно сосредоточится только на том, что необходимо в работе.
      Надо понимать, что плюсов fullstack'а больше для работодателя, а не для вас лично. Нужно в первую очередь думать о себе, понимать, что нужно в вам, чтобы проще и эффективнее работать, также нужно выделять время на отдых и хобби, иначе если перегорите, потеряете очень много времени и сил на восстановление (если вообще восстановитесь).


      1. DarkGenius
        01.04.2019 10:00

        Ну а если интересен и бэк, и фронт, и хочется иметь широкий кругозор? Даже будучи фуллстеком хочется осваивать смежные стеки, но на все времени не хватит. Так же, если уже подсел на иглу фуллстека, слезть с нее непросто, поскольку в узкой специализации фуллстек скорее всего проиграет тем, кто давно является узким спецом.


        1. Vlad_IT
          01.04.2019 10:17

          Ну а если интересен и бэк, и фронт, и хочется иметь широкий кругозор?

          Можно просто сделать смещение в определенную сторону. Например, больше заниматься backend разработкой, а frontend по мелочи. Или заниматься frontend разработкой, а backend заменить на nodejs. Моя основная мысль, чтобы на работе использовать один стек, а дома в своих проектах можно заниматься чем хочется.


          Даже будучи фуллстеком хочется осваивать смежные стеки, но на все времени не хватит.

          Это сложная проблема. В жизни очень много чего интересного, чем мне хотелось бы заниматься, но времени и сил на все не хватает. Но нужно оценивать свои силы, чтобы потом не перегореть и не потерять интерес ко всему.


          Так же, если уже подсел на иглу фуллстека, слезть с нее непросто, поскольку в узкой специализации фуллстек скорее всего проиграет тем, кто давно является узким спецом.

          Я плавно переходил. Я не бросал fullstack разработку, просто сконцентрировал обучение на frontend, да и сейчас по мелочи пишу на питоне. Таким образом, у вас будет серьезный плюс над другими узкими разработчиками, например в frontend — вы будете понимать внутреннюю кухню бека, лучше понимать взаимодействие фронта и бека, легче будет общаться с backend'разработчиками, понимать их. Это отличный пункт в резюме.


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


          1. kalashnikovisme Автор
            01.04.2019 16:44

            Думаю, если нравится фулстечить, нужно продолжать фулстечить. Я обещал не сравнивать узкие специализации и фулстек в этом материале. Но если обратиться к этой, здесь есть зависимость от личности ещё. Я не являюсь психологом, но точно знаю, что люди, которым нравится пытаться объять необъятное и те, которым нравится углубляться в одной сфере — это люди разного типа. И они кайфуют от разного.


  1. titulusdesiderio
    01.04.2019 09:09

    ТС, я категорически с вами не согласен. Фулстек это просто термин обозначающий компетенции во фронте (мобайле) и беке, а не философия. Но за то что так доходчиво и развёрнуто поделились своим видением — жирный плюс.


  1. oldd
    01.04.2019 13:32

    Из таких специалистов получаются классные менеджеры, которые понимают, что нужно заказчику и понимают, что, как и кому делать. Ценнейшие люди на небольших и быстрых проектах, и знание многих ЯП, методологий, архитектурных принципов просто необходимы.
    Рекомендую прокачивать скилл ораторского искусства и уверенности, это поможет и время высвободить, и ЗП увеличить


    1. kalashnikovisme Автор
      01.04.2019 16:45

      Спасибо за комментарий. Скилл ораторского искусства и уверенности прокачен. Выступаю примерно 50 раз в год.


  1. jakobz
    01.04.2019 18:11

    Наиболее сложные вещи сейчас творятся вокруг API между фронтом и сервером. Фронту надо удобно и пачками таскать данные. Беку — делать это быстро. Фронту — просто, понятно, консистентно, менеджить стейт. Нужды фронта определяют дизайн API, а часто — вообще архитектуру всего бекенда.

    Когда бек и фронт делают архитектуру сами по себе, получается полный треш и угар, в стиле «вот вам REST-API как в книжке, GET /users?id=123, живите как хотите». И фронт начинает делать распределенные join-ы данных из нескольких микросервисов, а бек — чинить возникшие от этого проблемы с перформансом.

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

    Или фронтам приходится закрывать архитектурные дыры бека, вроде «покажите какой-нибудь спиннер там пока наши микро-сервисы синхронизируются через очередь», или «если сервис А лежит, а Б — нет, должно как-то там все работать».

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


  1. fenix163
    02.04.2019 02:57

    Соглашусь с titulusdesiderio и расширю ответ. Автор путает широту знаний и глубину. Если он знает только back, он backend'ер. Если front, то frontend'ер. Если он знает и то и то, то fullstack. Даже если он и то и то знает плохо, то это лишь означает, что он плохой fullstack. Это что касается широты. Что касается глубины — это стандартная градация junior, middle, senior. Автор пытается скрестить сеньора и тимлида, уровень знаний и уровень ответственности за отдел. Строго говоря это разные позиции. И заказчик (внутренний/внешний — не важно) в общем случае не может общаться с fullstack-разработчиком, потому что это обычный программист, пусть даже и сеньор, у которого не может быть функций управления отделом, управления загрузкой отдела и планирования. Максимум, что может быть это менторство. Автор описывает скорее неофициального тимлида, который стал таким из-за экономии на новом сотруднике или из-за того, что просто знал больше остальных сотрудников и захотел немного выделиться и больше участвовать в процессах управления. Но в целом fullstack != тому, кого описывает автор.


    1. kalashnikovisme Автор
      02.04.2019 03:02

      Мне кажется, вы прочитали материал невнимательно.

      В статье точно есть цитата, что фулстекам не хватает глубины. А также есть мысль, что я не приписываю фулстеку лидерские качества (тимлидинг соответственно, думаю, это очевидно).
      Ни о каких «отделах» в статье речи не идёт в принципе. Взаимодействия и отношения внутри отделов разработки — это отдельная тема. К этой статье отношения не имеет.

      Вы два раза в своём комментарии упомянули, что я якобы имел ввиду, что фулстек — это тимлид. Поэтому во второй раз попрошу вас внимательно перечитать и обратить внимание, что тимлидерских качеств я фулстеку не придавал, а наоборот обращал внимание, что это про другое.

      И так же, прошу обратить ваше внимание на начало моего материала, где явно дал понять, что это личное мнение, не претендующее на последнюю инстанцию.


  1. megahertz
    02.04.2019 08:32

    Однажды ты спросишь меня, что я люблю больше, frontend или backend. Я отвечу, что fullstack. Ты уйдешь, так и не узнав, что я еще и под android умею, и под ios немного.