Здесь уже написано множество статей о том, кто такой Fullstack, в чем его плюсы и минусы, в каких проектах есть смысл нанимать таких разработчиков, а где — нет. Я буду исходить из мысли, что вы понимаете, что такое Fullstack и с чем его едят.
Мысль, которую я хотел бы выразить заключается в следующем — «Почему, даже большие аутсорсинговые и продуктовые компании, хотят нанимать Fullstack и/или развивать своих сотрудников в этом направлении?».
Вопрос, в контексте статьи, интересный, но отвечать на него я не хочу, я хочу лишь порассуждать на эту тему.
Возьмем управляющего большой компании, скажем, больше 500 человек, который получил следующую сводку от руководства: «Нам необходимо набрать 20 разработчиков для наших будущих продуктов/заказов».
Руководство не волнует, будут ли это BE или FE или Fullstack — им нужно сдать в срок заказ или выпустить продукт. Управляющий, начитавшийся многих статей о Fullstack, думает: «Вот же оно — Решение!» и начинает набирать Fullstack, исходя из мысли, что можно набрать 15 таких разработчиков и закрыть все вакансии да еще и денег сэкономить, ведь зарплаты таких разработчиков редко превышают зарплаты более узкоспециализированных разработчиков.
Но, спустя какое-то время, начинаются проблемы, не через месяц, так через год. Оказывается, что продукт/приложение оказывается не способным выдержать нагрузку или добавление новых фич стало трудоемким и неэффективным.
Это случается не всегда и не со всеми, но случается все чаще. Почему так? Потому что, первое, что необходимо сделать после утверждения MVP(минимального рабочего продукта) — это убедиться, что все стало на свои места и дальнейшее развития продукта пойдет максимально прогнозируемо с минимально возможным количество ошибок. И, как правило, спрогнозировать дальнейший путь приложения/продукта, может лишь квалифицированный специалист.
Я ни в коем случае не против Fullstack, как явления, потому как эффективность таких разработчиков доказана в определенных случаях, но меня сильно беспокоит появившиеся тенденции к развитию текущих узких специалистов в Fullstack для любых продуктов, в независимости от того нужно это или нет.
Это один из древнейших споров: «Широкий профиль из узкий?».
Все мы прекрасно знаем, что сейчас, нанять толкового специалиста — большой труд и иногда, непосильная задача.
Судя по личному опыту проведения более сотни интервью, в основном с ребятами из ЕС и СНГ, часто приходиться идти на уступки руководству и нанимать хотя бы немного дотягивающего по уровню специалиста в огнем в глазах, в надежде, что он еще принесет пользу и станет «Rock Star». Все чаще видишь «Senior Dev / Senior Fullstack Dev», с миллиардом лет опыта, который не можешь решить FizzBuzz, посчитать сумму чисел Фибоначчи или написать пример рекурсии.
Сейчас сложно быть в топе, хотя бы в одном направлении, будь-то FE в Web, Android, iOs, разработке игр или же BE в
той же разработке игр, Data Science, Big Query, DB analyst, и т.д. Чтобы быть реально полезным, надо, чтобы не только «котелок варил», но и знать все тренды и иметь багаж практического опыта, а этого можно достигнуть, лишь изучая что-то новое ежедневно.
Я согласен с тем, что любой разработчик должен знать основы программирования, иметь алгоритмическую подготовку, знать и понимать различие паттернов и понимать, в общих чертах, как работает и FE и BE. Но, по-прежнему считаю, что толковый специалист их конкретной области, сделает все быстрее и лучше, чем специалист широкого профиля.
Да и, задумайтесь сами, с кем бы вы хотели работать и обучаться — с Fullstack или умудренным сединами, FE, BE, GameDev, DevOps гуру?
P.S. Есть определенное количество одаренных ребят, способных работать и поспевать во всем, что делают, будь-то FE, BE и т.п. Но их еще меньше, чем толковых узких специалистов, и закрыть все необходимые вакансии и потребности на рынке они, увы, не смогут. Я только рад, если человек сменил род деятельности и перешел в другую область, но, он по-прежнему, будет занят в одной области, а не в десятке областей.
Комментарии (149)
Finom
28.08.2016 19:50-10По своему опыту, могу сказать, что те, кто себя иенуют фул-стек разработчиками, не имеют никакого представления о современных практиках разработки фронт-енда. Максимум, что они могут — это поработать со стилями и сделать что-то небольшое с помощью jQuery. В этом нет ничего плохого, просто при найме нужно учитывать эти реалии.
Finom
28.08.2016 19:53-11И да, пардон за рекламу, именно для заполнения пропасти между говнокодером-jQuery-стом и взрослым разработчиком с современным тулчейном, я работаю над второй версией фреймворка Matreshka.js.
serf
28.08.2016 21:42+2Вышеназванное ничего общего с фуллстек не имеет. Судя по моему опыту, настоящих фуллстек инжереров очень очень мало, они такими стали не по приказу начальства, а по своей инициативе и ввиду возможно своей любознательности и задротства.
jsfun
29.08.2016 00:47+1И этих ребят я обожаю, потому что они действительно круты, но меня угнетает тенденция к тому, что сейчас работодатели хотят, чтобы все ими стали, а я, например, пока не готов писать коммерческие приложения, как BE, поскольку еще изучаю этот вопрос, а хочу дальше делать то, что умею. Как только рынок уйдет в FullStack, любой адекватный человек обязан будет подтянуться в этой области, чтобы быть востребованным, но пока это не так — я буду придерживаться своего мнения.
serf
29.08.2016 01:03+2Всему рынку будет очень сложно уйти в фуллстек, это слишком сложно. Если на уровне одного веб фреймворка и одного серверсайд фреймворка, то возможно, но это будет как выглядеть как мартышкин труд. В фуллстек уровня «инструмент подбирается исходя из задач» не уйдет. Лично я все время пилить фуллстек не смог бы, это заметно утомляет, стараюсь фокусировать на том что больше нравится и пока что баланс поддерживать удается. Разбавлять серверсайд занятость вебом и наоборот в целом полезно для повышений общего уровня техн. эрудиции.
Работодателей можно понять, фуллстек люди обычно в целом быстрее выполняют комплексные задачи и с качеством приемлемым для большинства проектов (а иногда качество бывает даже лучше чем делают выделенные специалисты, особенно в плане стыковки слоев тк вся картина изначально видна целоком). Я думаю фуллстек люди нужны, но которые сами такими стали, не по принуждению или чей-то необходимости, так что тенденция с работодателями мне такая тоже не нравится.
serf
29.08.2016 01:08Кстати это в Германии такой рынок?
jsfun
29.08.2016 01:58+1Нет, к сожалению, повсеместно. Повторюсь, я не против Fullstack, просто на практике выходит, что средний фуллстек хуже специалиста. Для любителей придираться к словам, средний значит, что из 100 кандидатов узкого профиля выше шанс того, что попадется толковые, чем у Fullstack.
VadimChin
29.08.2016 12:54Как и писали выше — решает бизнес. Для стартапа, как вариант, запилить работающее что-то силами фуллстека, потом уже набрать по отдельности людей. Опять же, фулстек это не робот, у которого все скиллы распределены ровно по 50%, у кого-то может быть бекенд продвинут, у кого-то — фронт. Если пилишь для внутренней кухни — ну переживут некоторое время без модных реактов и наоборот.
Я думаю, все-таки, суть таких предложений не в том, чтобы человек был гуру по всем вопросам, а в том, чтобы мог выкатить работающий полностью продукт, чтобы его можно было пощупать и попинать (продукт имеется в виду:) ).
imikh
30.08.2016 11:37+1История стара как мир. Те, кто давно в области, не хотят меняться под изменяющиеся потребности реальности. Ничего страшного, всё будет как всегда. На их место придут молодые.
APXEOLOG
28.08.2016 20:04+3Специализация появилась не просто так, и именно благодаря специализации мы имеем такие технологии, о которых еще век назад даже фантасты не могли мечтать. Специалист всегда предпочтительнее неспециалиста в своей области. Единственное применение fullstack-разработчика я вижу в небольших проектах, где пары «на-все-руки-мастер» будет достаточно для создания продукта
atc
28.08.2016 20:13+1А почему fullstack разработчик не может быть специалистом? Чаще всего не смотря на свою fullstack-ость он будет разрабатывать не более одного компонента системы в единицу времени, что вполне позволяет ему совершенствовать навыки как во frontend так и в backend стеках.
В таком случае разработчик выступает не в роли «на-все-руки-мастер», а в качестве бекендера с хорошим знанием фронтенда и наоборот.APXEOLOG
28.08.2016 20:17+1Ну, если принять что за единицу времени два программиста получают одинаковое кол-во опыта/знаний, и предположить что опыт/знания в каждой области бесконечны, тогда очевидно, что профильный специалист будет иметь больше знаний/опыта чем fullstack, если рассматривать их именно в контексте разработки одного компонента системы.
atc
28.08.2016 20:29-1Такое можно было бы сказать о фундаментальных областях, таких как алгоритмы\проектирование, но никак не о том или ином стеке. В пример можно взять тот же frontend стек, технологии и подходы там сменяются достаточно быстро (от 6 мес. до года), что вполне позволяет не отставать от узких специалистов, если знаешь основы и периодически работаешь в этой области.
APXEOLOG
28.08.2016 20:39+1Но ведь и в каждой технологии/фреймворке существует много тонкостей. Можно копипастить примеры из документации, а можно знать где подводные камни и как их обойти.
atc
28.08.2016 20:55На эти тонкости натыкаются все, как узкие специалисты, как и фуллстек, и тем и тем приходится копаться в issue\гуглить\просматривать сообщества и блоги по используемой платформе. Фуллстеку это немного сложнее (из-за объемов информации), тут вы правы.
Сам почти год назад переключился c BE на FE стек, адаптация заняла примерно 1-2 месяца, каких-то особых проблем не почувствовал. Сложности ожидаемо были не с тем, чтобы изучить очередной фреймворк\сборщик\транспайлер, а с фундаментальными вещами, такими как проектирование приложений.APXEOLOG
28.08.2016 21:22+2Возможно вы правы, мне сложно грамотно оценивать подобные вещи. У меня было несколько проектов, где я выступал в качестве fullstack-разработчика, и тем не менее я не отношу себя к этой категории. Одно дело «сделать когда надо», другое дело «чувствовать себя как рыба в воде».
serf
28.08.2016 21:49+3Специалисты «по фреймворкам» это очень ограниченный люди, я бы лучше взял в команду в общем плане толкового человека чем некого эксперта одного фреймворка. Фреймворки умирают и рождаются, и при этом желательно чтобы опыт оставался с тобой.
Ну, если принять что за единицу времени два программиста получают одинаковое кол-во опыта/знаний
Это не так, далеко не так. Люди обычно разно мотивированы, и кроме этого некоторые вообще случайные люди в своей професиии.
foxmuldercp
30.08.2016 12:16-1Фреймворки приходят и уходят, а основной их язык как был так и есть. Что C#, что Java, что JavaScript, что Python с Ruby.
Мне наглядно хватило кардинальных изменений Asp.Net MVC -> Asp.Net Core. Ну и классики мира питонов при обновлении версии 2.х на 3.х, и Perl 6 :)
При этом лично мне кажется, что по сравнению с ними в Ruby + Rails на котором я сейчас остановился, все тихо и спокойно, не считая RoR5 с ActiveCable и другими весьма серьезными изменениями 5й версии.
sentyaev
30.08.2016 15:51Мне наглядно хватило кардинальных изменений Asp.Net MVC -> Asp.Net Core
Это конечно боль, но двигаются они в правильном направлении.
indestructable
28.08.2016 22:39-1Это было бы так, отличайся они принципиально. Фронтенд фреймворки построены на нескольких базовых идеях, и разобравшись с четырьмя из них, с пятым разберешься с ходу.
DrPass
28.08.2016 20:54+1> Ну, если принять что за единицу времени два программиста получают одинаковое кол-во опыта/знаний,
> и предположить что опыт/знания в каждой области бесконечны
Если бы к квалификации программистов применялись математические законы, то да. Но дело в том, что
а) два программиста никогда не получают одинаковое количество опыта/знаний за единицу времени
б) опыт и знания в каждой области всегда конечны и практически всегда различны.
Поэтому каждый специалист индивидуален, и на практике корреляции между опытом программиста в каком-то одном конкретном инструментарии и широтой его знаний других инструментов/технологий как бы и не прослеживается.APXEOLOG
28.08.2016 21:19Я согласен, программисты бывают разные. Есть Fullstack-разработчики которые в каждой сфере знают больше чем профильный программист. С другой стороны я уверен, что всегда можно найти профильного программиста, который знает больше чем Fullstack в конкретной сфере.
Cryvage
29.08.2016 05:25Тут стоит учитывать классическое соотношение 20/80. Грубо говоря, можно получить 100% знаний в одной области, сконцентрировавшись на ней. А можно, за примерно такое же время, получить по 80% знаний в пяти областях. Это конечно очень грубый расчет, но общая идея вполне верная, как по мне. Что же касается задач и предъявляемых ими требований, то далеко не всегда нужен специалист, знающий абсолютно все тонкости. Применительно к web, чаще всего, нужен «просто сайт», который будет «просто работать».
Ну а популярность фуллстеков у менеджеров вполне понятна. Им гораздо проще так управлять, когда все юниты примерно равнозначны и взаимозаменяемы. И распределять нагрузку легче, и в отпуск человека можно отпустить, когда тот попросится, и фактор грузовика не страшен. А уж если менеджеру еще и ставят задачу в виде «Нам необходимо набрать 20 разработчиков для наших будущих продуктов/заказов», то тут вообще очевидно почему он начинает набирать фуллстек. Он просто не знает какие продукты, и уж тем более заказы, ждут его в будущем, и набирает максимально универсальных разработчиков, которых он потом хоть как-то но приткнет на проект. Такой вот у него получается паттерн «Стратегия».
Einherjar
29.08.2016 10:59+1Ну, если принять что за единицу времени два программиста получают одинаковое кол-во опыта/знаний, и предположить что опыт/знания в каждой области бесконечны
В пределе специалист широкого профиля знает ничего обо всем, а специалист узкого знает все ни о чем.
Radiocity
29.08.2016 12:55Два программиста никогда не будут получать одинаковое количество опыта/знаний. Это связано как со способностью каждого отдельного индивидуума усваивать информацию, так и раздутой самооценкой, которая присуща многим разработчикам. И, Вам, как опытному специалисту должно быть об этом хорошо известно, так как сталкивались с подобным на практике при работе в коллективе.
Saffron
28.08.2016 21:08+2Что-то вы людей совсем уж за идиотов держите. Вся поверхность современного программирования, действительно, неохватная. Сотни платформ, тысячи языков программирования, сотни тысяч фреймворков. Но фуллстак — это не всё это вместе, а две-три платформы, столько же фреймворков и языков. Это можно выучить даже за время обучения в ВУЗе. А если в своё время поленился — потом само собой выйдет. Будет что-то тормозить, потекут абстракции — залезешь во внутренний слой стека, надо будет что-нибудь потестить — перейдёшь на внешний. И потом, свой собственный уровень стека за 5 лет ты изучишь досконально. А что потом? Программист, который перестаёт учиться, убивает программиста в себе. На мой взгляд, фулстек программист — это крайне естественное явление.
APXEOLOG
28.08.2016 21:17+1За те 5 лет, что Вы будете изучать 3 фреймворка, выйдут еще 33. Сколько времени нужно тратить, чтобы одинаково *глубоко* знать тонкости всех сфер? Вы думаете новые направления, такие как DevOps, например, появляются с потолка? Причина ведь в том, что кол-во и сложность решений постоянно растет и вам просто не хватит 24 часов в сутках, чтобы быть на острие лезвия в каждой сфере.
Saffron
28.08.2016 22:21+1Попробуйте выбирать те технологии, которые проживут минимум пять лет, в таком случае вместе с их развитием вы будете развиваться и сами. Нет никакой необходимости знать все 100500 яваскирпт фреймворков. Как вы метко заметили, они выходят каждый месяц. Попытки изучить их всех — вот настоящая трата времени, гораздо полезнее будет изучить низлежащий по стеку фреймворк.
DrPass
29.08.2016 00:14> За те 5 лет, что Вы будете изучать 3 фреймворка, выйдут еще 33.
> Сколько времени нужно тратить, чтобы одинаково *глубоко* знать тонкости всех сфер?
Ну так у узкопрофильного ведь будет та же проблема. Ему нужно будет или регулярно «расширять» профиль, осваивая очередную новую технологию в его сфере, или через некоторое время стать антикварным специалистом, как сейчас спецы на Коболе или там RPG. Обычно выбирают первое.Vjatcheslav3345
29.08.2016 10:47Обычные антиквары не бедствуют (нищего антиквара ещё не встречал) "кобол-антиквары" — тоже. Так что для "дедушек" от программирования — мужиков которым 50 и 50+ лет с семьей и внуками, это самая естественная ниша обитания, если не уходить в руководство (руководить — не каждому дано) а вот молодые "духи", те да… тем ещё можно метаться и менять курсы.
DrPass
29.08.2016 10:54Не бедствуют, но до этого ж ещё дожить надо :) И хорошо, если ниша такая денежная, как Кобол, который вертится вокруг дорогущих систем в управлении предприятием. Я видел антикваров, которые в 90-е засели на Sybase ASE, и там и остались. Вроде как сервер живой и сейчас, но… во-первых, сейчас малораспространённый, во-вторых, за него платят намного меньше, чем за Кобол. В третьих, активно вытесняется некогда младшим братом MS SQL. И рано или поздно ниша вообще схлопнется, если SAP что-то круто в политике его продвижения не поменяет.
А веб-разработка сейчас вообще находится где-то на середине кривой активного роста, ИМХО. Лидера в технологиях ещё нет, они постоянно меняются, активно развиваются. Поэтому сейчас вряд ли что-то долгоживущее в этой сфере можно найти, чтобы мусолить лет хотя бы десять.Vjatcheslav3345
29.08.2016 10:59Надо посмотреть, на чем пишется наибольшее количество долгоживущего кода в банковской сфере, инфраструктурных проектах стран и международных отрганизаций, коммерческих гигантских сайтов типа амазона и сделать выводы здесь в теме. Что то мне подсказывает, что через 30+, 50+ ява-антикавры будут ой как много зарабатывать… хватит внучкам на крузаки...
Vjatcheslav3345
29.08.2016 11:08+1Молодежь — учите Яву, С, С++…
И на пенсиях не пропадете!
Ява кормит,
"С" согреет!..
"С++" скучать не даст — мозги взорвёт!
А ещё он дом тебе построит...
deniskreshikhin
28.08.2016 20:10«Почему, даже большие аутсорсинговые и продуктовые компании, хотят нанимать Fullstack и/или развивать своих сотрудников в этом направлении?».
Компаниям нужно иметь много качественного человеческого ресурса (HR — human resources, если кто забыл). Это актив который стоит конкретных денег, и приносит конкретные деньги.
Чем этот ресурс более однообразен, тем лучше. Full-stack программистов легко перебрасывать с проекта на проект. Легко нанимать (их много), легко увольнять (легко найти замену). Его можно купить у партнеров, его можно продать партнерам.
Т.е. это вопрос денег, ничего личного.
jsfun
28.08.2016 20:16Да, но если качество страдает, вопрос денег стоит еще острее
deniskreshikhin
28.08.2016 20:28Видимо не достаточно страдает, что бы отказатсья от этой идеи.
Но вообще тут взаимное движение. Т.е. с одной стороны прогеров подгоняют под full-stack, с другой стороны языки и технологии тоже подгоняют под full-stack, ну и задачи само собой. В основном сейчас люди занимаются разного уровня интеграциями, а не разработкой там каких-то новых вещей.
Не считаю что это правильно, потому что как раз интеграцию-то можно автоматизировать. А вот разработку нового нельзя.
Но тут решают не программисты, а деньги
azsx
29.08.2016 02:37+4Но тут решают не программисты, а деньги
Золотые слова! Также могу покритиковать снизу — вверх, только толку то? Как данная ситуация видна со стороны.
Есть хозяин, которому деньги достались волшебным образом. Тупо надо кому-то деньги раздавать, чтобы «расцветали все цветы», вот некоторым ни с того ни с сего и дают миллиардные кредиты или отдают невероятные заказы. Хозяин (логично ведь) сразу заводит двух любовниц + жена, когда отдохнуть от суматохи надо и начинает каждый месяц ездить за границу. Хозяин нанимает высший менеджмент.
Чаще всего единственное достоинство этих высоких менеджеров — они вместе с хозяином играли в одной песочнице. Всё, больше достоинств нет, зато очень тянет поруководить. Они, прежде всего, заводят себе любовницу + жена, начинают часто ездить заграницу и нанимают более мелких менеджеров.
В IT отрасли наименование должностей не важно, его могут нанять на должность архитектора, руководителя проекта или технического директора. По идее – именно он должен знать несколько языков программирования, разбираться в различных фреймворках на их основе и благодаря своему практическому опыту разработки работающих приложений выбирать стратегию развития своей небольшой рабочей ячейки. При этом ячейка представляет собой весьма разнородных специалистов по качеству и разнообразию познаний. А также его обязанностью является улучшать мотивацию сотрудников своей ячейки, чтобы главный хозяин не жил как лох в дорогих отелях Лондона, а купил себе свой замок.
Но в реальности главной задачей мелкого менеджера является умение принимать критику сверху от более опытных друзей хозяина за всё подряд. На все крики, выговоры, несправедливые подколки мелкий менеджер должен всегда признавать правоту высшего менеджмента, а также указывать пальцем на конкретных программистов, которые виновны. Например, в том, что приложение не способно выдержать нагрузку.
В самом низу сидит всегда срывающий сроки программист. При трудоустройстве ему так или иначе намекнули, требуется full-stack. Когда он пришел на работу ему уточнили, что работать он будет на java (за нее же ни одного менеджера не уволили), пользоваться будет тем, тем и тем. Если, внезапно, начальник настолько туп, что даже не может почитать о модных фреймворках на хабре, то программисту разрешают выбрать свой фреймворк под задачу. Логично, что «full-stack» разработчик знает таких фреймоврков мало и выбирает не лучший, а наиболее знакомый вариант. Кстати платят программисту сначала только на еду хватает, а сеньору еще чтобы на жену и ребенка хватило. Ну и заграница раз — два в год. Без лобстеров…
Вывод поста — проблема на Вашей стороне! Только беда не в том, что нанимают универсалов, а в том, что управленцы на местах «ни украсть, ни покараулить»…
Arlekcangp
30.08.2016 11:381. Не пойму как можно пытаться нанимать человека который знает 2-3 платформы на туже или тем более меньшую зарплату чем узкого специалиста? Ему никто не мешает пойти работать также по узкой специализации за те же деньги и непариться с какими-то там фулстэками. А потом удивляются что не могут найти А спец такой ценен не тем что он много знаем а именно тем что устраняет вопросы взаимодействия. Включение одного-двух таких людей в команду должно решить проблемы отфутболивания проблем на другую сторону (при правильно поставленном процессе) Еще лучше если этот человек тим-лид.
Еще можно вспомнить что не вебом единым — есть смартфоны (и там все совершенно отлично от веба), есть встроенные системы, есть биг-дата и всякий хай-лоуд. Т е если например у меня есть опыт в java, но без андроида и при этом есть опыт в Objective C — это full-stack или нет? И вот все продолжают этот мэм жевать — фулл-стэк/не фулстэк. Есть определенный минимум который должен знать опытный разраб — алгоритмы, ООП (на любом языке), основы баз данных (и не надо говорить что он никогда не сталкнется — сейчас многие приложения содержат базу на клиенте) Дальше зависит от того что нужно работодателю — если он заявляет определенный набор технологий то должен и ожидать что под этот набор разработчика может и не найтись — значит нужно либо повышать зп либо разбивать ответственность. Второе чревато доп. рисками взаимодействия между этими людьми. Вариант человека который знает более одной платформы так или иначе должен оплачиваться лучше В противном случае он просто пойдет за туже зп работать на одну платформу. По поводу знает ли он все тонкости и фреймворки — это вообще нонсенс. Во первых узкие спецы их тоже на память не знают. Во вторых важнее именно конкретный опыт работы (в годах, часах, проектах и т д) И с некоторого опыта (от года до 5 на в зависимости от платформы) уже не должно быть разницы — дальше уже зависит от самого человека как он там работал — изучал что то новое каждый день или все 5 лет от забора до обеда.deniskreshikhin
30.08.2016 12:27+1В том и дело, что от full-stack программиста не требуется глубокого знания всего стека. Достаточно знаний которые позволяют решать типовые задачи. В общем это помогает получать вполне себе оплачиваемую работу людям с опытом разработки, но без глубоких знаний конкретных БД, фреймворков и технологий.
Например, человек со средними знаниями верстки на html4/css3 не может найти себе работу верстальщиков на 120к. Но если при этом он еще умеет немного программировать на backend, немного знает MySQL, и у него есть пусть и не сложные, но готовые качественные проекты в портфолио, то он может рассчитывать на почти такую же ЗП как если бы он был профи в чем-то одном.
Т.е. выбор стоит между иметь зарплату уровня middle developer и работать full-stack программистом, либо идти по узкому пути (например backend) и получать зарплату junior но в перспективе стать специалистом .
Другими словами:
junior frontend + junior backend => full-stack developer с зарплатой middle,
middle frontend + middle backend => full-stack developer с зарплатой senior.
С точки зрения хозяина, допустим у вас есть сервис и мобильное приложение для iOS. Сервис не особо сложный, но приносит реальный доход который позволяет вам вполне сводить де?бет с кре?дитом. Допустим сервис реализован со следующим стеком технологий — backend: MySQL + Node.js + Express, frontend: stylus/css3 + jade/html5 + angular, для мобильной платформы Objective-C + CocoaTouch. Один путь — нанять отдельно хорошего бекендера (MySQL + Node.js + Express), фронтендера(stylus/css3 + jade/html5 + angular) и мобильного разработчика (Objective-C + CocoaTouch), другой путь — нанять двух-трех full-stack программистов.
Почему выгоднее нанять full-stack?
Во-первых, количество задач может быть недостаточно для загрузки трех специализированных программистов. Задачи для фронтенда могут появляться каждый день (часто меняется дизайн), а вот для бекенда логика меняться может раз в месяц. В случае full-stack программистов это не проблема, можно перекидывать с бекенда на фронтенд и т.д…
Во-вторых, в среднем специалисты стоят дороже, а full-stack программисты чуток дешевле.
В-третьих, можно сэкономить на количестве программистов, вместо трех специалистов нанять двух full-stack.
В-четвертых, если кто-то из специалистов уйдет, то встанет вся контора. При этом поиск нового равноценного программиста может занять до полугода и больше. В случае с full-stack такой проблемы нет — работу ушедшего full-stack программиста могут выполнять другие full-stack программисты.
Что касается мобильной разработки, то если программист умеет программировать под iOs и использует Java на backend, то он вполне может быть full-stack программистоv в команде где есть какой-то сервер на java и есть клиентское приложение на iOs. Более того, многие компании возьмут такого программиста и переучиться под Android.
serf
28.08.2016 21:33Но, по-прежнему считаю, что толковый специалист их конкретной области, сделает все быстрее и лучше, чем специалист широкого профиля.
Фуллстек не тратит дополнительное времени на коммуникацию, тк работает один, он привык видеть всю картину и менее зависеть от прогресса коллег. Допустим если нужно сделать фичу быстро (первую версию, скажем пилот, а дальше если нормально пойдет вся команда подключится), то фуллстек в человекочасах сделает гораздо быстрее (раза в 2 минимум быстрее) и без особого ущерба качеству чем команда из ускоспециализированных специалистов.atc
28.08.2016 21:34Или вовсе сделает совсем не то, экономия на коммуникации она такая. Если это не research задача, то команда из нескольких человек намного быстрее найдет все подводные камни в тз.
serf
28.08.2016 21:38+1Человек которому доверяют работать индивидуально как правило заслужил такую репутацию, и как правило перед тем как приступить к задаче он задает все нужные вопросы по имеющися требованиям плюс интересуетя перспективой проекта чтобы предвидеть потенциально узкие места.
atc
28.08.2016 21:54Вопросы задают все, но правильные вопросы обычно появляются во время командного обсуждения или прямо во время выполнения задачи.
Получается два варианта:
1) фуллстек действует строго по тз, результат — «я его слепила из того что было»
2) фуллстек задает много уточняющх\корректирующих тз вопросов постановщику задачи, результат — отсутствие экономии времени
Как альтернатива этому — коллективное обсуждение, в процессе которого каждый разработчик сможет более глубоко взглянуть на свою часть задачи и задать более правильные вопросы еще до начала её выполнения.serf
28.08.2016 21:59Вы не поняли смысла, фуллстек товарищ способен и задает все нужные вопросы самостоятельно, не отвлекая узких специалистов, и обычно досточно задачть все вопросы на начальном этапе разработки фичи. Кроме этого в процессе выполнения он не отвлекает узких специалстов вопросами вида «а где там и как и откуда, какой там формат API и тд», а просто делает результат. Но если честно это не значит что фуллстек всегда будет так действовать (некоторые все же предпочитают фокусировать в бэкенде или фронте, ресерче, тимлидстве и тд), но в момент необходимости его навыки и способности могут быть очень полезны для команда/компании.
atc
28.08.2016 22:13+1Вполне понял, дело в том, что даже при командной работе совсем непросто выяснить ответы следующие вопросы:
— что мы делаем?
— для чего мы это делаем?
— а нужно ли это делать вообще?
— как это можно сделать иначе\лучше\быстрее?
Чаще всего ответов не знает даже сам постановщик задачи, но их можно найти, разговаривая с командой. Я веду к тому, что fullstack разработчик может экономить время или на максимально понятных\четких задачах (при грамотном постановщике) и на research задачах. Какие-то стратегически значимые решения доверять одному (пусть и достаточно опытному разработчику) я бы наверное не стал.serf
28.08.2016 22:19Речь ведь была о том чтобы запилить фичу, разумеется стратегические решения в одиночку не принимаются, хотя зависит от состава команды (иногда просто никто не хочет или не способен учавствовать в процесс принятий решений кроме одного-двух человек). Смысл фуллстека в моем понимании проявляется когда нужно сделать что-то быстро и без особого ущерба качеству, такое нужно не всегда если конечно это допустим не конвеерная разработка прототипов. Также в целом приятнее общаться с фуллстеком видя что он или уже знает о чем идет речь или схватывает все на лету, общая техническая эрудиция на высоком уровне.
PS предоплагает что когда фуллстек берется сделать что-то «быстро» и относительно качественно, то все вопросы (очень общие вопросы) указанные выше уже решены, дело перешло к конкретике.
wing_pin
29.08.2016 12:55Для этого есть agile и PM, который определяет направление развития, если только вы не разрабатываете по модели waterfall
indestructable
28.08.2016 23:05+7Посмотрим с другой стороны. "Специализация" в технологии часто означает то, что человек выучил что-то одно, и считает, что этого достаточно. Я знаю людей, которые за десять лет работы выучили как писать бизнес-логику на C# и MS SQL Server. Ни веба, ни десктопа, ни другой платформы они не знают. Являются ли они классными профи и убеленными сединами гуру? Нет, и более того, те люди довольно посредственные разработчики.
Большинство проектов не требуют глубинных знаний платформы. (И, кстати, шанс их получить у специалиста такой же, как и у фулл-стек разработчика. Платформа, которая требует постоянного вникания в свои тонкости, не выживает). Намного практически полезней для команды и успеха проекта навыки архитектуры и проектирования у разработчика, хотя бы в минимальном их виде.
Но хорошая архитектура — она в первую очередь для разработчиков, это ясный код, который легко использовать правильно, и сложно использовать неправильно. Для хорошего проектирования кода необходимо понимать специфику работы человека, который будет использовать твой код.
Но навыки проектирования (это именно навыки, не знания, теория тут не очень помогает) очень сложно получить, не побывав в роли пользователя своего же, или похожего, кода. Сложно извлечь урок проектирования и архитектуры из проекта, в котором ты можешь понять только часть. Сложно разработать хороший веб-апи, если ты никогда не использовал веб-апи.
Вот и получается бизнес-логика, которая требует целого слоя для адаптации к UI. Веб-апи, к которым нужно делать три запроса вместо одного. Постоянные обсуждения и переделки формата запросов и ответов (т.к. разрабатывают это разные люди, каждый из которых не понимает специфики другой части).
saboteur_kiev
28.08.2016 23:19+2«Оказывается, что продукт/приложение оказывается не способным выдержать нагрузку или добавление новых фич стало трудоемким и неэффективным.»
А какое отношение к этому имеет фуллстак разработчик?
Это проблема того, что в проекте нет нормального архитектора и тим лида, а не отдельных разработчиков.
jsfun
28.08.2016 23:42Согласен, но тут имелось ввиду, что шанс того, что приложение будет проблематичным, если в нем будет вместо 2 компетентных ФЕ и БЕ, 4 — Фуллстека.
Имеются ввиду среднестатистические разработчики. Конечно, всегда есть вероятность того, что Фуллстеки будут компетентнее, чем ФЕ или БЕ, но, опять же, тут скорее речь о статистике.
vics001
29.08.2016 00:24+1Как по мне проблема высосана из пальца, full-stack может быть человек, у которого есть огромный опыт, зп такого человека, если у него успешная карьера, соответственная, да еще может быть куча претензий к работе, которую он хочет делать. Как по мне, full-stack может называться полноценный архитектор, у которого есть знания и умения делать от и до, хотя он может уже не разбираться во всех нюансах технологий, но он может точно сказать, людей какой специализации стоит искать, а это самое главное.
А все эти full-stack меньше 3 лет опыта, это конечно, из разряда хочу знать всё. С другой стороны, если человек 5 лет назад писал на С++ совсем не факт, что его экспертиза на современном рынке сравним с теперешней, и чтобы влиться в современные технологии ему еще потребуется 2-3 месяца на раскачку.
zagayevskiy
29.08.2016 01:07Все чаще видишь «Senior Dev / Senior Fullstack Dev», с миллиардом лет опыта, который не можешь решить FizzBuzz, посчитать сумму чисел Фибоначчи или написать пример рекурсии.
Как это знакомо!
Только проблема, по-моему, глубже — таких «сеньоров» я часто вижу на собеседованиях на мобильных разработчиков.
sentyaev
29.08.2016 01:43По моему мнению, компании ищут fullstack разработчиков по одной довольно простой причине.
А именно, сейчас огромное количество языков, библиотек и фреймворков, и найти специалиста, который будет иметь знания в том, что использует компания, практически невозможно, а если мы говорим про аутсорс-компании, там еще хуже, никогда не знаешь что за проект тебе отдадут и насколько он легаси.
Кроме того, что нужно сделать фронтенд + бекенд + базу (которых сейчас тоже не мало), стало гораздо больше проектов где используется messaging, ML, bigdata и т.д.
И для каждой из технологий есть десятки вариантов.
Понятно, что нужно знать алгоритмы, паттерны и т.д., но это базовые знания, вы же не собираетесь для каждого проекта создавать заново все.
В итоге, проще взять человека, у которого есть знания во всех этих частях и который сможет достаточно быстро въехать в новые библиотеки и фреймворки.
С другой стороны, я считаю, что эту ситуацию создали сами разработчики, прыгая с одного стека технологий на другой, а бизнес соответственно просто подстроился.
В итоге мы получили ситуацию, когда разработчик не может вложится в изучении ограниченного стека и стать там профессионалом, т.к. в каждом проекте что-то свое.
Ну и конечно же я сейчас имею ввиду программирование как инженерную дисциплину, когда мы именно делаем продукты для бизнеса. В computer science думаю ситуация другая, но я с ней не знаком.jsfun
29.08.2016 02:03+1В итоге, проще взять человека, у которого есть знания во всех этих частях и который сможет достаточно быстро въехать в новые библиотеки и фреймворки.
А на практике — сложнее, потому что таких людей крайне мало. Вьезжать он будет быстрее, но, если у узкого специалиста есть шанс догнать тренды, то у фуллстека он гораздо ниже, потому что он просядет в какой-либо из дисциплин быстрее.sentyaev
29.08.2016 03:10догнать тренды
Так я именно об этом и говорю. Вместо решения задач бизнеса, мы гонимся за трендами, т.к. если этого не делать, то потом как искать новую работу…
Я работал, да и сейчас работаю, с проектами, которые живут более 10 лет, и все еще развиваются.
И со временем эти проекты превращаются в месиво из разных технологий, и добавляли их как раз для того, чтобы следовать трендам.
Понятно, что переписать это все не представляется возможным, слишком дорого для бизнеса, да и не объяснить.
Поэтому мы придумали… та-да… микросервисы))) А еще новые тулзы и фреймворки для этого.
Теперь, даже в рамках одного проекта можно получить несколько разных стеков технологий.
И учитывая это, можно ожидать что-то вроде any-stack разработчиков)jsfun
29.08.2016 04:27Я не про хипстерские вещи у которых свой потенциал, но реальных приложений, дай Боже, если с сотню наберется. Я про зарекомендовавшие себя технологии и, рано или поздно, любой продукт надо переписывать. А каша из технологий зачастую лишь там, где либо нет толкового лида, либо он настолько задерган, что у него нет ни сил ни времени со всеми спорить.
Тренды — это то куда сообщество движется и, конечно, надо понимать стоит ли конкретно Вам за ним следовать или нет, но Вы, как разработчик обязаны знать их и быть способным применить при необходимости. Согласны?
sentyaev
29.08.2016 05:27+1Просто «тренды» в программировании, больше похожи на тренды в моде, а мода, она постоянно меняется.
Я же всего лишь пытаюсь ответить на ваш вопрос
1. Программисты часто меняют работу (многие пишут про 2-3 года), из-за этого бизнес хочет средне-хорошего разработчика, чтобы не нужно было учить и можно было заменить.
2. Быстро меняются технологии, позавчера все уходили в веб, сегодня все для мобильных устройств и в облаках, завтра никто не знает что будет. Учитывая п.1 нужно чтобы работу могли подхватить те, кто есть.
3. Раньше все можно было сделать на бекэнде, потом начали писать логику на фронтенде, потом появились SPA, а теперь и мобильные, и планшеты, и телевизоры.
4. Программистов на рынке не хватает, а задач куча. Выпускать продукт все хотят как можно быстрее (программисы же еще и денег стоят, и немалых).
Я все это к тому, что желание компаний нанимать fullstack разработчиков это не проблема, а необходимость.
Кстати, тут у меня возник вопрос, что для вас этот «stack»?
Вот смотрите, я веб-разработчик, специализируюсь на технологиях от MS.
Основа — HTML5, CSS, Javascript/Typescript, C#, SQL.
Далее, я выбрал некоторые фреймворки которые помогают мне разрабатывать приложения быстрее, перечислять их нет смысла, т.к. их куча и с каждым годом становится все больше.
Это все и есть мой «стек» технологий.
Не могу же я быть веб-разработчиком и не уметь готовить фронтэнд?
vlad72
29.08.2016 04:05Требование фулстека связано с тем, что сейчас технологии находятся на некоемом перепутье — нет мейнстрима (как еще 10-20 лет назад), неизвестны перспективы их развития и т.д. Вот как только утрясется и Бигдата с ИИ скажут, что им надо, тогда и снимут такие требования в вакансиях…
dipsy
29.08.2016 09:48Вот уж где точно не утрясется, так это бигдата и ИИ. Но, конечно, с появлением AGI и ASI с вакансиями проблем вообще никаких не будет ни у кого…
claygod
29.08.2016 09:13+1Читал когда-то статью об учёных (не нашёл пруфа к сожалению), которые сейчас являются узкопрофильными (ну может быть не сильно узко). В статье подчёркивалось, что наука стала столь широка, что быть фуллстек учёным уже не получится. Последнее поколение учёных оркестров остановилось на поколении Ландау. Мне кажется, что с программистами и IT индустрией в целом ситуация та же.
jehy
29.08.2016 09:35+1По моим ощущениям, на том же хедхантере сейчас ситуация ровно обратная от той, что вы описываете — фуллстек стоит в полтора-два раза меньше, чем узкий специалист по одной из веток стека. Поэтому я одно время думал уходить от фуллстека… Но это слишком скучно. После некоторых поисков нашёл таки подходящего работодателя и страшно доволен жизнью.
Небольшая рекомендация — придумайте какие-нибудь более интересные и творческие задачки. Когда я вижу Фибоначчи на собеседовании в пятый раз за неделю, то первое желание — выбежать из помещения с восплем ужаса. Хотя если вы хотите заодно проверить стрессоустойчивость — это самое то!
akamensky
29.08.2016 09:48-1Мне кажется все хотят full-stack разработчиков так как (в 99% случаев) те кто «просто» разработчики знают только свою нишу и больше ничего.
Для разработки качественного продукта необходимы знания во всех областях, как работает браузер, как браузер общается с сервером, как работает сервер, что такое линукс и т.д.
Конечно без этих знаний можно что-то писать и даже получать результаты, но процесс будет настолько медленнее и выбранное решение не будет гарантированно лучшим.
Самое печальное это то, что я собеседовал full-stack разработчиков, которые не в курсе как работает HTTP протокол. Я уже не говорю про HTTPS и прочее. А если посмотреть на 90% вопросов на SO, там сплошная банальщина которая гуглится за 5 минут и запоминается на всю жизнь, и потом эти люди пишут в резюме full-stack developer.
DrPass
29.08.2016 10:11> Для разработки качественного продукта необходимы знания во всех областях, как работает браузер, как браузер общается с сервером,
> как работает сервер, что такое линукс и т.д.
Это же просто общие знания, которые полезно знать любому разработчику веб-приложений, неважно, фронт, бэк, фулл..., неважно даже на какой платформе.akamensky
29.08.2016 10:43Есть набор общих знаний, а есть более глубокие по каждой части. Например почему большое количество открытых соединений к серверу могут вызывать проблемы даже если они не создают нагрузку на CPU.
Можно знать как работает HTTP, а можно плюс к этому еще и знать OSI модель и понимать разницу между HTTP и TCP.
Вот интересное чтиво (англ.) по этому поводу.
deniskreshikhin
29.08.2016 12:35Странно, но вы описывая "правильного разработчика" как раз-таки описываете full-stack.
Для full-stack программиста как раз более важно знать технологические нюансы: знать стандарты интернета (http, ssl, pop/smtp etc), знать верстку и нюансы работы браузеров (html4/5, css3/4), знать javascript, какой-нибудь еще язык (python, ruby, php, тот же node.js), знать хотя бы одну БД с поддержкой SQL и хотя бы одну NoSQL, плюс хотя бы основы мобильной разработки. Все, full-stack готов.
Как раз-таки, обычный программист не обязан этого всего знать. Допустим, взять C++ программиста. Что бы стать спецом в C++ нужно прочитать с десяток книг (Мейерса, Саттера, Александреску, Страуструпа). Выучить хотя бы стандарт 98 года, который на 700 страницах. Потому что современный стандарт языка уже занимает 1400 страниц. Т.е. на это все уйдет 3-4 года минимум. Плюс в C++ важно понимать принципы ООП, основы рефакторинга и разработки через тестирование (Банда четерыех, Фаулер, Мартин, Кен Бек). Еще 1-2 года. Это уже не говоря что желательно так же разбираться в алгоритмах, если в университете вы не успели проштудировать многотомники Дональда Кнута, Альфреда Ахо и др. В этом случае еще стоит накинуть 2-3 года.
Итого что бы стать Senior'ом требуется от 4 до 9 лет. При этом слова HTTP, SQL, TCP и т.д. в процессе обучения могут в принципе ни разу даже и не встретится.
При этом специалисты C++ одни из самых оплачиваемых.
akamensky
29.08.2016 13:27Мы с Вами на самом деле об одном и том же. Я именно и говорю что full-stack набирают так как нужны люди с более обширными знаниями.
Разница только в том, что в моем понимании для полноценного full-stack не хватит просто знать одну БД и один фреймворк для фронтенда. Если рассуждать таким образом, то просто прочитав Getting Started для Node.js, MongoDB, Angular и т.д. и зная только лишь JS мы получим full-stack? Мне кажется, что для полноценного full-stack нужно более глубокое понимание технологий, а это приходит с опытом (ну или не приходит, по-разному бывает).deniskreshikhin
29.08.2016 14:20В том и дело, что опыт у людей в основном частный. Т.е. если full-stack разработчик проработает на каком-то конкретном языке с конкретной технологией (допустим 3 года на Ruby On Rails + Postgres), то скорее всего он уже будет искать следующую работу по названию "Senior Ruby On Rails", т.к. ему не придется переучиваться + за специализацию платят больше.
Т.е. то что full-stack программисты не сильно глубоко лезут в конкретные технологии это их преимущество, которое компаниям наоборот выгодно культивировать — перебрасывать с проекта на проект, давать разношерстные задачи, устраивать семинары, тренинги и т.д. Например для тех кто программирует на ООП языке нужно делать семинары по "функциональному программированию", а тех кто использует SQL подсовывать NoSQL, дескать для расширения кругозора. В этом случае опыт достаточный для перехода на следующую планку по ЗП никогда не будет достигнут, при этом разработчик будет всегда чувствовать себя нужным и восстребованным в компании специалистом.
nick_volynkin
29.08.2016 10:00-1MVP(минимального рабочего продукта)
Пришлось немного поугадывать, прежде чем нашёл расшифровку термина. Оказалось "minimum viable product".
indestructable
29.08.2016 10:56Есть два типа команд: один тип — это команды с четкой специализацией каждого человека, раньше их было много, сейчас они, наверное, только в энтерпрайзе; второй тип — это команды из аджайл, разработчики из таких команд обычно фулл-стек, сейчас в веб деве пре-энтерпрайз таких большинство. Это один из принципов аджайл — взаимозаменяемость разработчиков, поэтому разрабам дают отдельные фичи делать "с низу до верху", от базы до верстки.
Fen1kz
29.08.2016 12:19+3Нехило так засрали.
Оказывается, что продукт/приложение оказывается не способным выдержать нагрузку или добавление новых фич стало трудоемким и неэффективным.
Охренеть, то есть фуллстек теперь у вас автоматически означает — "неспособность написать масштабируемое приложение"?
jsfun
29.08.2016 12:59-1Ну почему Вы не читаете внимательно. Имелось ввиду среднестатистически. На 10 продуктов, написанных фуллстек и узкими спецами, шанс того, что у фуллстек все будет хуже- выше
gandjustas
29.08.2016 12:34Когда я начинал работать программистом, то считалось нормальным, что начинающий разработчик знает минимум 3 языка, а также один из диалектов SQL. Не обязательно имеет опыт в этом деле, но по крайней мере решит задачу за ограниченное время.
10 лет спустя люди, претендующие на максимальную зарплату, жалуются что им надо учить аж два с половиной языка — JS, php\java\c#\python, html и уметь писать хотя бы базовые запросы к базе, которые не уложат её на лопатки.
Fen1kz
29.08.2016 12:53А какие три языка надо было знать в то время, когда вы начинали работать программистом?
gandjustas
29.08.2016 18:53В универе обычно изучали pascal, часто delphi, иногда C или Java, на многих специальностях связанных с программированием также был JS или PHP.
Вот как раз PHP планку и понизил. Бум сайтов привет к тому, что в программисты пошли те, кто не имеет профильного образования и прочитал одну книжку "как сделать сайт на php и mysql за 24 часа".
sentyaev
29.08.2016 19:50Например в моем универе было так:
1. Основы программирования — pascal + delphi
2. ООП — c++
3. Функциональное — lisp
4. Логическое — prolog
5. Системное — С и Asm
6. Базы данных — тут почему-то был foxpro, но лекции были норм ибо читали без привязки к инструменту (БД).
7. Еще в некоторых предметах для программирования были Ada и Java.
Но суть в том, что нам не преподавали языки, был предмет (например ФП), а язык использовался только для решения задач, он был вторичен.
Но сейчас мы почемуто постоянно выбираем язык (куча же статей some VS some-new) и фреймворк, хотя по сути все одно и тоже.
NaN
29.08.2016 13:30+3Позволю себе процитировать Хайнлайна.
Человек должен уметь менять пеленки, спланировать вторжение, заколоть свинью, вести корабль, построить дом, написать сонет, подвести счета, возвести стену, снять мясо с костей, утешить умирающего, отдать приказ, выполнить приказ, действовать вместе и в одиночку, решать уравнения, анализировать новую проблему, разбросать навоз, запрограммировать компьютер, приготовить вкусное блюдо, биться и победить и умереть, если надо, с достоинством. Узкая специализация — удел насекомых.
sefus
29.08.2016 16:01+5Я не боюсь того, кто изучает 10 000 различных ударов. Я боюсь того, кто изучает один удар 10 000 раз.
Брюс Ли
knagaev
31.08.2016 12:39Очень хорошо.
Но что будет делать человек с одним натренированным ударом против беспилотника или того хуже стратегической ракеты?
Экстенсивный путь развития (один удар 10000 раз) не всегда подходит для прогресса.saboteur_kiev
31.08.2016 16:40А что будет делать человек с 1000 натренированными ударами, вооруженный ножом пистолетом, нунчаками и катаной против стратегической ракеты?
knagaev
31.08.2016 19:17Ничего.
Зато сможет сделать человек за пультом системы ПРО.
Об этом я и сказал, что если бы люди всегда тренировали только один удар, то мы сидели бы в пещерах и убивали зверей одним ударом.
Так что я поддерживаю Хайнлайна и NaN, узкая специализация — удел насекомых.saboteur_kiev
31.08.2016 21:59Я считаю, что вы слишком заморачиваетесь. Человек, который изучает 1 удар 10.000 раз, кроме этого еще может есть, пить, читать книжки, играть в шахматы. Не стоит думать, что он ну вообще ничего не умеет, и уже несколько раз поясняли, что узкая специализация не означает незнание базовых основ, а то и достаточно глубоких знаний всех смежных технологий.
knagaev
31.08.2016 22:15А Вы не считайте.
Если мы говорим об аллегории, то значит и не надо расширять её так, как Вам удобно.
Иначе, если человек знает _базовые_ основы, и имеет глубокие знания _всех_ смежных технологий, то очень смахивает на фулстек-разработчика.
sefus
01.09.2016 10:55Экстенсивный путь как раз направлен на увеличение количества разных ударов, а не качество одного конкретного. Прогресс в этом случае чистая случайность.
knagaev
01.09.2016 11:03+1Боюсь тут немного путаница в терминологии.
Убираем комбайном пшеницу.
Вместо одного комбайна запускаем десять таких же — экстенсивный путь.
Делаем новый, который работает как двадцать старых — интенсивный.
Или модернизируем старый (точим один удар) — экстенсивный путь.
Пробуем новые принципы (делаем разные удары), применяем более эффективный (на гравитонной тяге) — интенсивный путь.
Если точить только что-то одно, развитие будет только экстенсивное, за границы этого одного (которые всегда есть в реальной жизни) никогда не выйти.
Вернёмся к нашим баранам — пардон, разработчикам.
Гениальный узкоспециализированный джаваскриптолог может не знать, что нужно немного подкрутить на бэкэнде, и визуализация будет намного легче и быстрее.
А фулстекер сможет увидеть это.
Capici? :)sefus
01.09.2016 11:14Гениальный узкоспециализированный джаваскриптолог может не знать, что нужно немного подкрутить на бэкэнде, и визуализация будет намного легче и быстрее.
А фулстекер сможет увидеть это.
Дело в том, что фуллстекер может увидеть это, если случай достаточно тривиален. А может и не увидеть. И на поиск проблемы ему придется потратить дополнительное время, которое гениальный бекендер уже потратил когда становился таким. Можно изучить все сферы досконально, но жизнь коротка.
Если у вас вдруг возникнут проблемы со здоровьем вы пойдете к разным узкоспециализированным врачам или к одной бабушке, которая лечит все болезни?sentyaev
01.09.2016 12:25Дело в том, что фуллстекер может увидеть это, если случай достаточно тривиален.
Как раз наоборот, знания в разных областях помогают увидеть нетривиальные случаи.sefus
01.09.2016 13:06Интересно, как знание CSS поможет найти утечку памяти на бекенде?
sentyaev
01.09.2016 13:31Хм… а как знание SQL в этом поможет?
sefus
01.09.2016 13:49Никак. SQL бекендеру для других целей нужен.
sentyaev
01.09.2016 14:05Так и CSS нужен для других целей.
То, что в этой статье называют fullstack — это обычный Web Application Developer.
sefus
01.09.2016 14:15Для каких целей бекендеру CSS?
sentyaev
01.09.2016 14:21Давайте отправимся в прошлое, лет на 7-10 назад, когда html страницы генерились на backend.
Вы думаете тогда не нужно было знать html и css?sefus
01.09.2016 14:56Их и сейчас полезно знать, но помнить все тонкости верстки человеку, который ей не занимается, не обязательно. И тем более следить за всеми трендами не всегда есть время.
sentyaev
01.09.2016 15:14У вас есть полное право заниматься и изучать только то, что вы считаете нужным.
Я, в свою очередь, обращаю внимание на то, чего хотят мои заказчики. Если им нужен человек, который умеет и SPA сделать, и backend для него, при этом их устраивает результат моей работы и время затраченное на проект, а меня, в свою очередь, устраивает оплата, то я буду таким специалистом.
И, что немаловажно, мне интересно заниматься и фронтендом, и бэкендом, а еще я хочу знания в мобильной разработке улучшить.
knagaev
01.09.2016 12:53А вот енто называется демагогия.
Почему Вы сравниваете бабушку и врача?
Вообще когда у вас что-то болит, то вы идёте сначала к фулстекеру-терапевту, который вас направляет к узкоспециализированному (ну или сам лечит).
Диагносты, кстати, как показывает доктор Грегори, наш, Хаус, фулстекеры.
Если бы он занимался только, к примеру, почками, то дальше никак.
Ну и вообще врачи-специалисты вначале фулстекеры — их сначала учат всему организму (анатомия человека), а только потом специализируют.
И Ваше «может увидеть… а может и не увидеть» тоже из инструментария демагогии.
Потому что дальше надо оценивать вероятности, а лучше уровни доверительной вероятности, а ещё лучше полное распределение вероятностей.
Лучше я отвечу так
«Все может быть. Все может статься. Машина может поломаться. Девчонка может разлюбить.» ну и далее по тексту кто знает :)sefus
01.09.2016 13:05Почему Вы сравниваете бабушку и врача?
Под бабушкой я имел ввиду универсального врача на все болезни.
Ну и вообще врачи-специалисты вначале фулстекеры — их сначала учат всему организму (анатомия человека), а только потом специализируют.
И вы хотите, чтобы все были фуллстекерами, без этих узкоспециализированных по уделу насекомых врачей?knagaev
01.09.2016 13:09К сожалению, не умею читать между строк настолько хорошо, чтобы увидеть за бабушкой (даже без кавычек) универсального врача :)))))
А где Вы увидели, что я хочу, чтобы все были фуллстекерами?
Настроение статьи было несколько против фуллстекеров, плюс комментарий с цитатой Брюса Ли — вот я и бросил на другую чашу своё скромное мнение.
Могу ещё добавить цитату от Козьмы Пруткова «Специалист подобен флюсу: полнота его односторонняя».
deniskreshikhin
29.08.2016 16:11Хех, боюсь что если упорно растрачивать силы на все возможные языки и технология, то удастся выполнить только два пункта: "запрограммировать компьютер" и "умереть".
Cryvage
30.08.2016 00:39У господина Хайнлайна была насыщенная жизнь, и вероятно он умел делать все перечисленное, но в то же время, если опросить, скажем, тысячу людей, на тему «Кто такой Роберт Хайнлайн», как думаете, что большинство из них ответят? Я готов спорить, что самым популярным ответом будет «писатель». Не «лейтенант ВМФ США», и не «политик». Хотя и тому и другому он отдал не мало лет своей жизни. Но в итоге он сконцентрировался на писательстве и добился в этом настоящего успеха. Что это, если не узкая специализация? Просто многие неверно понимают этот термин. Узкий специалист это не тот, кто ничего не знает, кроме своей области. Это тот, кто знает в совершенстве свою область, неплохо ориентируется в смежных областях, а так же знает и умеет достаточно для обеспечения своей жизнедеятельности в различных условиях. Чем же это отличается от широкого специалиста? Да только некоторым размытием границы между своей областью и смежными областями.
С обеспечением жизнедеятельности, я думаю, понятно — мертвый специалист бесполезен, хоть узкий, хоть широкий. Большая часть перечисленного в цитате, как раз относится к навыкам выживания и преодоления различных жизненных ситуаций. Иначе бы я про это даже не упомянул, т.к. очевидно.DrPass
30.08.2016 00:44> Я готов спорить, что самым популярным ответом будет «писатель».
А я готов спорить, что самым популярным ответом будет «не знаю» :)
sbnur
29.08.2016 14:38+1Тенденция к fullstack демонстрирует, что труд программиста не конвейеролизуется — и это радует.
В стародавние времена (а может и сейчас) в Китае в фарфором производстве труд был настолько специализирован, работник рисовал всю жизнь только один завиток на кружечке, а следующий другой и так далее
Не хотелось бы быть таким специалистом
fukkit
29.08.2016 16:38+1Попытка сэкономить на главном инженере (тех.лиде) и ведущих инженерах (тим.лидах) путем размазывания ответственности за решения по системному анализу, архитектуре и организации работ между продвинутыми старшими инженерами (этот ваш «фулстэк», а на самом деле — разносторонне (нормально) образованный старший инженер) приводит к деградации общей эффективности команды.
Исключение — мелкоразработка (сайтики, ненужная шаровара, второстепенные утилиты), где весь этот бардак возможен благодаря низкой сложности разрабатываемых систем и общей безграмотности заказчика и беззубости контрактов.deniskreshikhin
29.08.2016 16:52А как же Valve? У них нет начальников в принципе, абсолютно горизонтальная компания. Тоже мелкоразработка?
fukkit
29.08.2016 16:55Не работал там, не могу сказать, каково им без начальников.
Какая-то уникальная организация труда?deniskreshikhin
29.08.2016 17:22+1Если кратко — новые разработчики сами решают чем заниматься — можно присоединится к существующему проекту, создать свой и набрать таким же образом команду. Можно бегать от одного проекта к другому. Переработки в офисе не приветсвуются.
Оценка успешности работы разработчиков происходит на основе опросов коллег. В соответствии с результатами опроса формируется зарплата.
Hierarchy is great for maintaining predictability and
repeatability. It simplifies planning and makes it easier to
control a large group of people from the top down, which
is why military organizations rely on it so heavily.
But when you’re an entertainment company that’
s spent the last decade going out of its way to recruit the most
intelligent, innovative, talented people on Earth, telling
them to sit at a desk and do what they’re told obliterates
99 percent of their value. We want innovators, and that
means maintaining an environment where they’ll flourish.
That’s why Valve is flat. It’s our shorthand way of saying
that we don’t have any management, and nobody “reports
to” anybody else. We do have a founder/president, but
even he isn’t your manager. This company is yours to
steer—toward opportunities and away from risks. You have
the power to green-light projects. You have the power to
ship products.
A flat structure removes every organizational barrier
between your work and the customer enjoying that work.
Every company will tell you that “the customer is boss,” but
here that statement has weight. There’s no red tape stop-
ping you from figuring out for yourself what our customers
want, and then giving it to them.http://www.valvesoftware.com/company/Valve_Handbook_LowRes.pdf
fukkit
29.08.2016 17:41При достаточном количестве денег компания может позволить себе некоторую краткосрочную неэфективность в надежде на какой-то больший эффект в перспективе. Но это скорее в плоскости венчурного инвестирования, планово убыточного поиска «выстреливающих» идей.
Оценка успешности работы разработчиков происходит на основе опросов коллег.
Для нормального бизнеса это бред. Или нам чего-то недоговаривают или эту оценку как-то не так используют.
deniskreshikhin
29.08.2016 17:48Хех, Valve уже 20 лет исполнилось. Прибыль год от года растет.
Aingis
29.08.2016 17:58Уверен, что там всё выглядит совсем не так, как выглядит со стороны. Наверняка, есть нюансы, которые нам не видны. Это как с «20% времени на свой проект». То ли есть, то ли нет, но точно известно, что эти «свободные 20%» всегда требовали согласования с руководством и не на что попало, а на конкретный проект. Наверняка и тут такая же согласованная свобода. Не верю, что там нет никакого контроля. Возможно, он имеет необычную форму, но как-то же они наверняка оценивают эффективность, хотя бы чтобы просто убедиться в своей правоте.
deniskreshikhin
29.08.2016 18:07Безусловно. Картинка всегда будет отличаться от того что на самом деле.
Но тут важно не то как у них внутри, а то какие они цели себе ставят. Т.е. если бы их цель была построить жесткую иерархичную систему, то зачем привлекать людей которые не будут в такой компании работать? Все-таки, если они хотят видеть себя горизонтальной компанией, то видимо это дает свои преимущества.
fukkit
29.08.2016 18:06Без факторного анализа роста прибыли сложно утверждать наличие его связи с анархией в управлении.
deniskreshikhin
29.08.2016 18:07Тем не менее, анархия и горизонтальная организация компании не мешает иметь прибыль сама по себе.
DrPass
29.08.2016 23:04+1На самом деле основной принцип эффективности Valve состоит в том, что они хорошо поработали 15 лет назад, и теперь сидят на широченной денежной трубе, которая качает сотни миллионов долларов буквально из воздуха. Причём им для этого нынче не нужно делать вообще ничего, ну, кроме периодического техобслуживания и апгрейда серверов. И клиенты, и поставщики к ним сами идут, в автоматическом режиме. В таких условиях можно придумывать любые способы организации труда, они все будут казаться эффективными :)
vvpoloskin
29.08.2016 18:05Наверно уместно сравнить программистов с админами (не офисными, например, у интеграторов, провайдеров) как с более зрелой специальностью (просто более старой). Админы прошли уже этот «Full Stack» на заре повсеместной информатизации и интернетизации. В ранних провайдерах админ был и монтажник, и биллингист, и сетевик, офисный админ. Сейчас такое осталось только в местечковых провайдерах или интеграторах-аутсорсерах по мелким кафе. В крупных организациях (>1k человек) все распределено и поделено. Придет время, в софтварных крупных конторах также все поделится на четкие зоны ответственности, появится ветвистая штатная структура, более четкая специализация и меньшие требования к новым кандидатам. Конечно в мелких конторах так и останутся необходимы люди-оркестры.
И да, наверно не стоит путать понятия «широкий кругозор в своей сфере» и «разработчиков Full Stack».
springimport
29.08.2016 18:41В идеале должна быть команда с fullstack-тимлидом и узконаправленными разработчиками, какой смысл всем все знать?
Saffron
29.08.2016 20:25Вы забываете про bus-фактор. fullstack-ов должно быть два, на случай если с тимлидом что-нибудь приключится.
Thor
30.08.2016 19:53+1Есть области, где фулстек дает вполне ощутимое конкурентное преимущество – фриланс. Малому бизнесу гораздо комфортнее общаться с одним человеком, чем с командой, т.к. очевидным образом не происходит размытия ответственности. Менеджер не сможет свалить все на разработчика, а разработчик на менеджера. Вся ответственность на фулстеке.
DrPass
31.08.2016 12:22> где фулстек дает вполне ощутимое конкурентное преимущество – фриланс
На фрилансе это, скажем так, существенно расширяет круг потенциальных клиентов. Т.к. клиенты, которым нужен проект «под ключ» сами не будут заниматься администрированием всего проекта, а будут либо искать мастера на все руки, либо обратятся к компании.
> гораздо комфортнее общаться с одним человеком, чем с командой, т.к. очевидным образом не происходит размытия ответственности.
Ну, клиенту в обоих случаях приходится общаться только с одним человеком, только в случае команды это будет менеджер/представитель.
> Менеджер не сможет свалить все на разработчика, а разработчик на менеджера.
… который, если перед клиентом не дай боже что-то заикнётся про криворуких разработчиков, по правилам ведения бизнеса в первый раз должен лишиться премии, во второй — вылететь с работы. Не имеет права менеджер обвинять в проблемах никаких других сотрудников своей компании. Хотя этим правилам, конечно, следуют не все.
heilage
Мне кажется, ваша боль не от фулстэка как такового, а от неадекватной самооценки кандидатов в каждом втором резюме. Так это и не у фулстэкеров встречается сплошь и рядом. А фулстэк на то и фулстэк, чтобы уметь поднять веб-продукт целиком и уметь смотреть на систему в целом. Да, это требует колоссального количества познаний. Но невозможного в этом я ничего не вижу.
jsfun
Я по-этому и написал, что есть толковые ребята, которые могут это сделать, но меня беспокоит то, что компании хотят, чтобы максимальное количество разработчиков были фулл-стэк.
heilage
Думаю вы правы, что это обыкновенное стремление снизить затраты за счет найма одного человека-оркестра вместо двоих, а то и троих :) И насчет развития узких специалистов до фулстэкеров — тоже объяснимо, если принять во внимание стремление к взаимозаменяемости людей в команде.
Trans00
Есть еще проблема у работника «надоело одно и тоже, хочу чего-то нового»=)
Temirkhan
Скорее всего я исхожу из сугубо-личных наблюдений, но я склонен полагать, что «индукция» — явление в наших кругах куда более редкое, чем «дедукция». Иначе backend или frontend developer'ов было бы больше, чем fullstack.
Mirn
полностью согласен, это стремление снизить затраты за счёт найма человека-оркестра очень заметно в менее денежной области: разработке и производстве электроники
примеров много:
1. Знакомый с богатым опытом работы хотел устроится на разраба прошивок двигателей в Дубну (цена бага миллионы и десятки миллионов рублей), пообещали до кризиса за 150тр, но после кризиса вместо этого взяли двух студентов на вырост за 30тр (до первого сожжёного мегаватника видать). будут год ескд изучать, а потом год отладочные платы — видать результаты им не нужны вообще.
2. Я сам держу три разных резюме (плисовод, микроконтроллерный си/с++, разработчик электроники) не получил ни одного предложения если выставить желаемую з/п более 100тр уже за пол года, ну да, за 60-80тр (для МКС) вылазят куча неадекватов, гос контор и прочих сомнительных мест с переработками, командировками и фин ответственностью за срывы сроков (работал там, спасибо не надо, редко платили выше 50% от обещанного из-за «сделать вчера» и штрафов).
3. Ко мне постоянно обращаются сомнительные «крутые конторы» в которых «все программисты уже на крузаках ездят», стартаперы, оборонка, все они просят что то разработать, все замолкают после просьбы о предоплате хотя-бы отладочных плат, и части моего времени (обычно это суммы не более 10тр из 200т и выше). А без предоплаты я даже паяльник в руки не возьму и IDE не запущу, точка.
4. У меня есть маленькое хобби по разработке и производству некоего гаджета, аналогично — никто из русских не покупает за 20 евро (ноют: дорого), в европе и не только как пирожки даже за 200 уходило, знай только по 500шт отгружай.
ну и так далее.
я долго могу рассказывать о фин несостоятельности заказчиков и ненужности разработчиков электроники.
По-моему и разработчики и результаты их работы у нас попросту не нужны и наш бизнес с ними слабо умеет работать.
Вот недавно работодатель на основном месте работы огорчил:
Извинился и сказал что не тянет наши разработки в плане маркетинга и увеличения объёма продаж, поэтому новых разработок больше не будет, нас увольняет с н.г. и оставляет за нами только авторские % от маржи с каждого изделия что тоже неплохо. Увеличив этот процент до 30 за что спасибо им, по сути они дают 100% свободного времени, за половину от текущей зарплаты. Жаль, изделия то очень хорошие (кроме себестоимости выше Китая) и мне за них не стыдно, я буду по ним ещё много статей писать. Более того наши изделия показывают стабильный рост продаж в полтора раза в год уже пять лет подряд несмотря на кризис и тд. Вот так вот вышло.
DrPass
У вас-то частный случай, связанный с проблемой иного плана — как найти работу инженеру при стагнации экономики и без эмиграции в другую страну.
DevOpsEngineer
Работы полно, проблема с зарплатой.
Mirn
извиняюсь. забыл добавить главное:
для пунктов 1-3 во всех этих случаях нужен не только фулстек разработчик от прошивок до платы, перечня компонентов и технологии,
а ещё чтоб он внедрил это в производство, а нередко и организовал закупку компонентов и оптимизировал себестоимость и обеспечил качество — инженер сопровождения и спец по тестирования/качеству. Для примера в нашей конторе в глубинке этим занимаются пятеро, и у всех з/п существенно выше чем они максимум могут заплатить за одного такого «оркестра».
asm0dey
Чтобы мне перестали звонить каждые пять минут мне приходится выставлять цифру в резюме больше 200к. Но народ, видимо, привлекает то что я и правда человек-оркестр.
gorodnev
Снижение затрат и есть причина появления потребности в таких специалистах. Зачастую компаниям нужны люди, которые будут эффективно закрывать тикеты вроде «Добавить сортировку по полю Х» или «Добавить новый REST-поинт для выгрузки из таблицы Y». Особых знаний и умений для реализации такой функциональности не нужно, а платить хочется как можно меньше. А ведь такой работы на проектах очень и очень много (по крайней мере, на стадии поддержки). А профессионалы, которые выходят за грань описанного крайне и крайне редки.
DrPass
Это тоже вполне ожидаемо, т.к. увеличивает взаимозаменяемость специалистов и устраняет одно звено коммуникации между разработкой FE и BE. Эффективнее, в общем.
> Да, это требует колоссального количества познаний
Да не колоссального на самом деле. Фуллстэки ведь тоже имеют специализацию. Кто-то один фреймворк хорошо знает, кто-то другой.
heilage
Не согласен. Знание фреймворков не кажется определяющей компетенцией для фулстэка. А вот понимание того, как всё работает — кажется, потому что при наличии такого понимания новый фреймворк изучается и встраивается в процесс за несколько дней, в худшем случае — за пару недель.
DrPass
> Не согласен. Знание фреймворков не кажется определяющей компетенцией для фулстэка
Вы абсолютно правы, определяющей компетенцией не является, но это как раз то, что требует «колоссального количества познаний». Базис из понимания, как всё работает, он во-первых, значительно меньше, во-вторых, относительно стабилен, и не требует постоянного обновления копилки знаний.
alexeyrom
Зато с такими компаниями легче конкурировать :)
Vjatcheslav3345
И такие люди предпочитают работать на себя а не на "добренького босссса".
heilage
Никак не связано. Фуллстэк это про технологию, а не про маркетинг.
DrPass
> И такие люди предпочитают работать на себя а не на «добренького босссса».
Это дело вкуса. Работая на себя, порой приходится куда чаще выходить из зоны комфорта, чем работая на какую-то уютную ИТ-компанию.
Temirkhan
О какой зоне комфорта может идти речь, если у тебя восемь рук?
saboteur_kiev
Зона комфорта — когда тебя устраивает распорядок дня, то, чем ты занимаешься и оплата.
Ничего из этого отдельно, но все вместе. Я вот отлично могу себе представить себя лет в 50-60 на средней зарплате, но в уютной фирме, в которой нет запары, на которую я пешком хожу, работаю с приятными людьми, по желанию работаю удаленно.