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

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

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

    Я рад тому, что я фулстек, потому что это та работа, которая мне нравится, которую я не прочь поделать в выходные, и которой занимаюсь с удовольствием.
    Share post
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 40

      +6

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

        0
        Есть еще вариант. В эпоху микро- и наносервисов часто возникает ситуация, когда фронт, бэк и овнер — одно лицо, потому что больше нет смысла. Я пришел во фуллстек из фронта. Создать простенький бэк для общения с остальными сервисами на основе современного фреймворка — не особая проблема, большая часть проекта — привычный мне фронт
          0
          Я работаю примерно в такой же парадигме, но вот называть себя фуллстек-программистом мне совсем не хочется, потому что де-факто 90+% времени работа идёт над фронтом. Могу ли я бек поковырять? Да конечно могу, но это не фуллстек. Фуллстек будет тогда, когда вы бизнес-критичный функционал будете реализовывать везде (и на фронте, и на беке), а задачи уровня «написать хендлеров express, чтоб у фронта был чистый единый бек, после которого оно уже расходится в разные стороны» — это по силам любому вменяемому программисту, не страдающего пуризмом в извращённой форме («если это не в браузере, то делать не буду»).
            0
            Так фишка именно в том, что бизнес-логика как раз и реализована на бэке, а на фронте только максимально удобный UI для неё. И как бы пафосно это не звучало, но хороший программист может писать код на любом человеческом языке программирования (не считая, может быть, марсианских чисто функциональных языков и диалектов брейнфака) и вынос кода с фронта на бэк должен быть если не тривиальной, то, по крайней мере, решаемой задачей. Подход с бизнес-логикой на фронте, когда для бэка остается роль тонкой прокладки для роутинга и синхронизации с другими сервисами, мне совершенно не нравится — получаются какие-то совершенно неповоротливые монстры. Вот и выходит где-то 60% работы на бэке, 35% на фронте и 5% DevOps (минимум для разворачивания собственного окружения и как черновик для прода)
              0
              Мне кажется, что вы просто моё «бизнес-критичный функционал» не так прочитали. Это как раз всё то, что продаёт продукт — вплоть до дизайна (если речь про сайты для широкой публики). Понятно, что без всего остального один только дизайн никому не нужен, но и очередной фейсбук никому не будет нужен, если с ним можно общаться только через JSON. И в этом смысле практически всегда будет и бизнес-критичный функционал на фронте, и на беке, и может быть и еще где-нибудь.

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

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

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


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


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

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

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


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

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

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

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

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

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

                  На нормальном ревью, коллеги должны отклонить такой запрос. Ведь даже, несмотря на знаменитое высказывание кнута о преждевременной оптимизации, допускать такое в коде — просто небрежность.
                    0
                    Про использование запросов в цикле — это, конечно, жесть. Речь всё-таки о менее тяжких преступлениях: о 3-4 запросах, которые идут по порядку, хотя можно было в один, об использовании ORM в тот момент, когда можно без неё обойтись, просто с ней быстрее и т.д.
                      +1
                      У меня есть один проект, где запросы в цикле работают год уже.
                      Да, там можно соптимизировать. Да, я знаю как.
                      Но оптимизация будет стоить не меньше дня разработки, а неоптимизированный код кушает всего два ядра из 56, потому будет еще работать долго. Просто вынесен на отдельные ядра и все.
                      Я все же придерживаюсь позиции, что лучше иметь начальные знания у всех разработчиков, чем глубокие, но 10х размер команды.
                      Как минимум пока проект не приносит миллион в год.
                      Понятно, что если у вас 50-500 человек сидит в офисе, то выгоднее для всего кроме прототипов узкая специализация. Но в малых командах не все так очевидно.
                        0
                        Но, если даже в команде 50 человек есть тимлид или ведущий разработчик, который является тем самым фулстеком, что может быть полезен в любой части системы, как минимум на уровне общения и принятия решений — это безусловно плюс.
                        Работал в такой команде. Был кайфово, что есть хотя бы, кто всё знает.
                +1
                5) фулстеки-одиночки задействованы на MVP. В одно лицо гораздо проще быстрее и дешевле сделать MVP. Да, БД будет не оптимизирована, вместо вёрстки бутстрап и прочие недостатки. НО без стендап митингов, согласований между командами, и прочего, MVP будет готов через неделю, а не месяц. А потом, если MVP «зайдёт» можно выделить фронтов с дизанеромам, беков с девопсами, аналитиков и запилить уже полноценный проект по этим вашим скрамам с аджайлами.
                  0
                  Здесь абсолютная верная мысль. Тут, конечно, появляется вопрос о том, как правильно делать MVP, но это другая тема.
                  0
                  Если честно, совсем не понял ваш четвёртый пункт. Вы имеете ввиду, что мы устраиваем себе оплачиваемый университет, изучая в нём предметную область, продакт-оунерство и т.д.?
                    0
                    Изучая в нем технологии бэка, фронта и девопс. Я лично очень за, да и работодателю обычно по боку, маржа все равно отличная, пусть лучше девелопер учится в день часика по три из восьми, чем будет недовольно эти же три часа сидеть в снэпчатиках.
                  +2
                  Соглашусь с ganqqwerty, и от себя добавлю, что в современном аджайлнутом мире фуллстеки — это просто способ удешевления разработки. Насколько оправданный — отдельная тема, но такая точка зрения у бизнеса есть. И выжимают из них по полной, так, что действительно получается и качество по всему стеку среднее, и времени и сил смотреть по сторонам (да и вглубь) — нету.
                  • UFO just landed and posted this here
                    +2
                    Работа в выходные оплачивается по ТК в двойном размере? Как относится семья к работе в выходные?
                      0
                      Мне кажется, это тема для отдельной статьи.Скажу вкратце:

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

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

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

                        +1

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

                          +1

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

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

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


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

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


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

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


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

                              +1
                              Думаю, если нравится фулстечить, нужно продолжать фулстечить. Я обещал не сравнивать узкие специализации и фулстек в этом материале. Но если обратиться к этой, здесь есть зависимость от личности ещё. Я не являюсь психологом, но точно знаю, что люди, которым нравится пытаться объять необъятное и те, которым нравится углубляться в одной сфере — это люди разного типа. И они кайфуют от разного.
                        0
                        ТС, я категорически с вами не согласен. Фулстек это просто термин обозначающий компетенции во фронте (мобайле) и беке, а не философия. Но за то что так доходчиво и развёрнуто поделились своим видением — жирный плюс.
                          0
                          Из таких специалистов получаются классные менеджеры, которые понимают, что нужно заказчику и понимают, что, как и кому делать. Ценнейшие люди на небольших и быстрых проектах, и знание многих ЯП, методологий, архитектурных принципов просто необходимы.
                          Рекомендую прокачивать скилл ораторского искусства и уверенности, это поможет и время высвободить, и ЗП увеличить
                            0
                            Спасибо за комментарий. Скилл ораторского искусства и уверенности прокачен. Выступаю примерно 50 раз в год.
                              0
                              Что можете посоветовать для прокачки данных скиллов?
                            0
                            Наиболее сложные вещи сейчас творятся вокруг API между фронтом и сервером. Фронту надо удобно и пачками таскать данные. Беку — делать это быстро. Фронту — просто, понятно, консистентно, менеджить стейт. Нужды фронта определяют дизайн API, а часто — вообще архитектуру всего бекенда.

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

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

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

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

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

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

                                И так же, прошу обратить ваше внимание на начало моего материала, где явно дал понять, что это личное мнение, не претендующее на последнюю инстанцию.
                                0
                                Однажды ты спросишь меня, что я люблю больше, frontend или backend. Я отвечу, что fullstack. Ты уйдешь, так и не узнав, что я еще и под android умею, и под ios немного.
                                  0
                                  Сейчас работаю в фуллстэке, хотя сам больше фронт. Компания небольшая, и я единственный кодер, от чего приходится делать всё и сразу. Один из типичных примеров фулстэка.
                                  Страшно за медленный рост в знаниях, из-за широкого спектра. Нет времени на ковыряние инструментов, надо писать говнокод, чтобы послезавтра зарелизиться.

                                  Как по мне, фуллстэки — те, кому нужно контролировать всё и вся. Да и людей, которые не умеют ни в один стэк, тоже встречал. Лучше выбрать одну сторону.
                                    0
                                    Да и людей, которые не умеют ни в один стэк, тоже встречал.

                                    А их работодатель знает, что они не умеют?

                                  Only users with full accounts can post comments. Log in, please.