Введение
Прежде всего определимся с терминами. Есть много разных представлений о том, кто же такой full stack разработчик, кто-то даже вполне обоснованно считает, что такие разработчики — это миф, но в этой статье будет иметься в виду разработчик, который обладает знаниями и умениями, позволяющими с нуля написать некий софт и вывести его в продакшн. При этом софт может быть рассчитан на web платформу, мобильные приложения или десктопные. Идеальный full stack разработчик — это тот, кто владеет в какой-то мере всеми платформами и может разработать и установить на них свой софт. Но это действительно скорее миф.
Ну или хотя бы кого-то, кто не будет слишком сильно жаловаться, когда его попросят поработать вне его зоны комфорта.
Возможно, по заголовку кому-то покажется, что это жалобный пост, который говорит о том, как плохо живётся неквалифицированному школьнику, который похватал всего из разных статей в интернете. Нет, пост не жалобный, мы говорим про full stack, а не full slack, и в конце будет так же рассмотрен список плюсов. И мы будем рассматривать не школьника, а разработчика с опытом работы в пять и более лет. Просто посмотрим, какие минусы есть в таком развитии.
Минусы
В каждой отдельной области вы хуже, чем узкий специалист
Кажется довольно очевидным, но всё же поясню. Если вы потратили шесть лет на одну технологию, то с очевидностью ваши знания будут больше, чем у человека, который шесть лет занимался несколькими. У вас было больше проектов, вы больше занимались какими-то типичными решениями, больше читали и писали код.
Вам сложнее продвигаться глубже
Хороший full stack разработчик всегда сильно нагружен. И ваше время на познание нового распределяется между всеми технологиями, с которыми вы работаете. Естественно, что ваше развитие происходит медленнее, чем у программиста узкой специализации.
У вас больше вероятность перегрузки задачами
Если вы занимаетесь сразу несколькими проектами с нескольких сторон, то даже при хорошем тайм менеджменте часто будет случаться так, что все проекты требуют к себе повышенного внимания и времени. Придётся это решать или передачей части задач другим разработчикам, или распределением приоритетов, или тщательным планированием. Конечно, вероятность перегрузки есть у любого разработчика — как известно, в реальном мире любую задачу нужно делать “вчера”. Но у вас такие задачи могут внезапно появляться пачками.
Вас сложно заменить
Кому-то это может показаться плюсом — вас сложно уволить, вас любят и ценят. Но обратная сторона медали — невозможность передачи задач, звонки в любое время суток, проблемы с уходом в отпуск, сложности при попытке заняться чем-то другим.
У вас нет чёткой зоны ответственности
Если в кране нет воды — значит, виноват full stack! Какие бы проблемы не возникали, какие бы баги не вылезали — скорее всего, именно вам придётся ими заниматься, даже если проблема на самом деле должна быть в ведении другого разработчика. Просто ваша картина мира гораздо полнее, и вы быстрее сможете локализовать и исправить ошибку. К сожалению, этим часто злоупотребляют.
“О, дайте ему — он разберётся!”
В ситуации, когда необходимо разобраться с плохим или старым кодом, скорее всего задействуют именно вас. Особенно печально, когда работодатель хочет сэкономить, наняв одного разработчика на весь проект. А ты его открываешь и понимаешь, что проще это выкинуть и целиком переписать.
Вы не знаете всех наборов библиотек
Это довольно очевидно следует из первого пункта, но хочется упомянуть отдельно — хотя бы потому, что в вакансиях часто требуется опыт работы с конкретными библиотеками.
Вы не успеваете за всеми тенденциями
Опять же это следует из первого пункта. По непонятной мне причине, часто ищут разработчика, который в совершенстве умеет применить что-то, что вышло в релиз полгода назад. Увы, вы не можете одновременно знать и уметь применять ES6, рассказать об отличиях последней версии Symfony и о возможных проблемах миграции с Oracle на Tibero в текущий момент. Возможно, вы об этом читали, но попробовать просто не успели.
Вы не всегда пишете оптимальный код
Скорее всего, ваш код понятен, хорошо систематизирован и откомментирован. Но наверняка более квалифицированный специалист мог бы сделать его чуть лучше. Другой вопрос, что это обычно не критично. Действительно плохо, если каша из языков в голове заставляет вас применять подходы и решения, которые никак не годятся в текущем проекте. Ужасно видеть, как некоторые даже пишут функции, которые были бы созвучны привычным для них реализациям в другом языке.
Вы часто подглядываете в мануалы
Даже функции для работы со строками во всех языках выглядят по разному, что уж говорить о чём-то более сложном. Если вы часто переключаетесь между разными технологиями и языками, то скорее всего у вас непрерывно будет висеть мануал, в который вы подглядываете, что конечно несколько снижает скорость работы.
Вы можете начать завидовать зарплате узких специалистов
Если начать искать вакансии по самому вашему дорогому навыку, то можно огорчиться — специалисты с большим опытом работы могут получать за него весьма неплохие деньги. Скажем честно — у вас такого опыта работы с конкретной технологией нет. Но даже если вы углубитесь в эту технологию и получите необходимые знания — хотели бы вы дальше всю жизнь заниматься только этим? Например, администрированием СУБД Oracle?
Минусы в трудоустройстве
Отдельно хочется упомянуть сложности, которые случаются при смене работы.
Вас буду звать работать по случайным ключевым словам в резюме
HR не всматривается в то, что указанной технологией вы занимались на небольшом проекте три года назад. Он увидел слово, похожее на вакансию, которую надо закрыть, сделал стойку, и пытается вас туда пристроить любой ценой, не интересуясь вашими желаниями и текущими предпочтениями.
Full stack full stack’у рознь
Какой бы вы ни были широкий специалист, вряд ли вы найдёте место работы с точно таким же стеком технологий. Бывает, но крайне редко. Однако пересечения часто довольно большие, и ничто не мешает вам подтянуть недостающее и ещё больше расширить кругозор.
Вам не верят
Да, вот такая смешная и реальная проблема. Если вы указали в резюме слишком много всего, то вам просто не поверят и даже не будут пытаться проверять или спрашивать о том, на каком уровне вы что знаете. Поэтому, как ни смешно, лучший способ — безжалостно удалять из резюме все сведения, которые вы считаете неактульными для своего будущего. А ещё лучше — подгонять резюме под каждую вакансию.
Вам сложнее искать подходящую вакансию
Fullstack разработчиков ищут довольно редко, и не всегда работодатель с такой вакансией может конкурировать с вакансией узкой специализации по условиям. И возникает вопрос — какие использовать ключевые слова при поиске вакансии? Если вы, скажем, Java разработчик, то просто указали в поиске Java — и погнали кликать. Но full stack’у немного сложнее. Обычно проблема решается подпиской на несколько разных фильтров по словам, которые вам наиболее интересны — или просто выборкой по желаемому уровню зарплаты. Последнее не всегда срабатывает, поскольку к моему величайшему недоумению до сих пор висит огромное количество вакансий вообще без указаний зарплатной вилки. Видимо, HR боятся, что тогда каждый захочет описанный максимум? Странно. Если кто знает доводы в пользу такой стратегии рекрутинга — приведите, пожалуйста, в комментариях.
Плюсы
Теперь, наконец, о вкусном.
Вы можете выбирать, кем работать дальше
Вам гораздо проще сменить ориентацию (простите за двусмысленность), чем обычному разработчику. Вы видите многое в применении, можете разобраться и понять, что вас интересует. Да, вам придётся потратить время на углубление — но это будет потраченное с пользой время. Да, вам скорее всего придётся завести несколько пет проджектов, чтобы попробовать всё, что хочется. Но это опять же окупается сторицей.
Вы меньше выгораете
Если есть возможность периодически менять проекты, то вы гораздо меньше устаёте от применения одного и того же. Конечно, если вы не хардкорный фанат и не получаете удовольствие просто от того, что пишете всё, скажем, на vanilla C или asm.
Вам проще расти в тимлида или архитектора
Довольно очевидный плюс — чем больше вы разбираетесь в общей структуре, тем больше у вас шансов на рост в руководителя. Конечно, при наличии желания и коммуникативных навыков.
Вы можете отдебажить всё, что угодно
Очевидный плюс. Ваше системное мышление достигло уровня, на котором вы можете исправить что угодно и где угодно.
Работать веселее, интереснее и познавательнее
За один день вы можете получить много новых навыков и знаний в абсолютно разных вещах.
В одиночку вы можете создавать чудесные вещи на стыке разных технологий
Вы один можете сделать то, на что при стандартном подходе требуется 3-4 человека. Запрограммировать микроконтроллер для интернета вещей, который общается с веб сервером, пишет в базу данных, и данные с которого можно просматривать на веб сайте, в приложении или на мобильном устройстве? Легко! Вы один можете представить всю систему и реализовать её без согласований, недопониманий и проволочек.
Ваши решения работают быстрее и надёжнее
За счёт понимания взаимодействия различных систем, вы можете выбрать лучше пути для их комбинирования. Вы лучше понимаете каждый компонент и не боитесь его использовать. Как пример — возьмём “кляудные технологии” (мопед не мой, в публикациях проскакивало). В общем и целом, облако это чудесный способ решения огромного количества задач, в том числе задач масштабирования. К сожалению, всё чаще вижу, что облачные решения используются просто потому, что разработчик не умеет и боится решить свою задачу как-то ещё, а представляет это в виде дополнительного плюса. А многое можно сделать гораздо дешевле и лучше, если иметь хотя бы поверхностное понимание вопроса.
Вы можете пользоваться почти любыми исходниками
В мире, где решена уже практическая любая прикладная задача, тратить время на то, чтобы написать ещё один велосипед — просто преступление по отношению к длительности своей жизни. Теперь вы можете взять любой репозиторий на любом языке и воспользоваться им как отправной точкой для своего решения. Вы пролетите свежим бризом над граблями, которые до вас собрали тысячи других разработчиков.
Вы постигаете дзен
Теперь вы знаете, что нет языка разработки, которых лучше остальных. Вы знаете, что нет самой лучшей базы данных. Вы можете предположить, что какой-то инструмент подходит для ваших целей лучше… но вы вполне готовы использовать альтернативы, если на то есть какие-то основания, например, квалификация остальных разработчиков. Вы больше не пишете статей про синтетические тесты, созданные с тем, чтобы показать преимущества одной технологии над другой. Вы знаете, что прирост производительности в пять процентов скорее всего не стоит двух ваших человеко-месяцев. А освободившееся от холиваров время вы наконец можете потратить на что-то полезное. Например, чтобы наладить взаимоотношения с девушкой (для примера назовём её Катей). Вы теперь понимаете, что технологии бывают разные, что люди бывают разные, и нужно просто найти правильный способ связать всё воедино. Ты любишь мир, и мир любит тебя. Даже когда ты его используешь, чтобы выстрелить себе в ногу.
Здесь должна была быть картинка, на которой показано, как просветлённый программист в позе Лотоса медленно возносится над горами Тибета, а вокруг него танцуют, обнимаются и водят хоровод языки программирования и различные технологии в образе очаровательных девушек — но увы, такой картинки почему-то не нашёл. Пожалуйста, представьте это сами.
Комментарии (90)
ibKpoxa
03.03.2016 13:55+9А еще узкий специалист может проснуться и обнаружить, что он не нужен, т.к. его ниша устарела и пора было давно переучиваться на что-то другое, что не грозит fullstack разрабу.
evsan
03.03.2016 15:32+2Это какой-то исключительный случай, по-моему.
Устаревание ведь проходит не мгновенно. И вытесняющие технологии обычно изучать не так трудно, они похожи. По-моему, большинство Swing Java разработчиков вполне комфортно себя будут чувствовать, используя Vaadin. В крайнем случае применить полученные за годы работы со Swing знания в UX во front-end разработке на JS с каким-нибудь модным фреймворком, если серверное программирование "не его".
Единственная проблема — это поиск работы без коммерческого опыта в конкретной технологии, но и это решается.ibKpoxa
03.03.2016 17:15+1У меня пример из сферы DBA, знакомый 15 лет занимался базами Oracle, больше ничего толком не знает, и когда на предприятии решили перейти на postgresql, то наняли тех, кто разбирается в postgresql и после миграции он, ораклист, был уволен, т.к. не хотел переучиваться и решил, что найдет без проблем другое место. Но с другим местом довольно долго не срасталось, т.к. отказываются от оракла много где и достаточно хороших специалистов переизбыток, возможно что уже больше полугода ищет, после НГ не спрашивал еще.
PerlPower
03.03.2016 17:53-1Чует мое сердце, что среднему оракловщику платят больше чем DBA постгреса, так что возможно ваш знакомый таки прав.
jehy
03.03.2016 21:45+2Про то, что ораклоид долго ищет работу — это странно. У меня вот в резюме разработчика написано про сертификацию в качестве Oracle DBA — звонят постоянно и обещают горы золота. Может, у вашего знакомого что-то не так с резюме? Попробуйте показать его знакомому HR'у. Резюме, не знакомого.
cavin
03.03.2016 14:08+8Full-stack разработчики — мастхев для стартапов почти на любом этапе развития. Это в том числе касается пункта "Вас сложно заменить" — если есть несколько универсалов, они неплохо друг друга дополняют и заменяют.
jehy
03.03.2016 14:11Да, упустил как-то из виду этот хороший вариант решения проблемы замены. Правда, обычно универсалов довольно мало. Хотя не знаю ситуации со стартапами.
TrueMaker
08.03.2016 10:44Как ни странно, универсалов не мало в численном выражении, но очень мало в отношении количество вакансий на одного человека.
enleur
03.03.2016 15:39Для стартапов или маленьких команд полезны, но если есть пара фулстеков, то в конечном итоге все равно разделят между собой и станут заниматься чем-то одним.
cavin
05.03.2016 01:23+14 года стартапов говорят мне об обратном: один за всех и все за одного — теперь это лозунг универсалов в одной лодке
Fen1kz
03.03.2016 14:56+1А почему сложнее искать подходящую вакансию? Обычно так и пишут "full stack". На всякий можно ещё и "fullstack".
jehy
03.03.2016 15:01+5Уточню, возможно было не совсем понятно из статьи. Те, кто ищут fullstack в явном виде — часто хотят взять одного человека на три вакансии, и чтобы он ещё вечерами мусор выносил. Да и немного вакансий — сейчас по Москве на хедхантере к примеру только 8 штук.
Зачастую гораздо интереснее искать вакансии по каким-то другим конкретным ключевикам.
enleur
03.03.2016 15:37Плюсы как-то притянуты за уши
ikaktys
03.03.2016 15:46+1вот да, после 10+ лет опыта работы full stack в корпорации из этих плюсов есть только одно — тебя сложнее уволить и проще пихнуть в другой проект, все остальное — только "чуство глубокого удовлетворения" и плюсы для начальства, опять же только потому что тебя моугт пихнуть в любой проект, не особо интерсуясь мнением.
dougrinch
03.03.2016 18:45-1А объясните почему "тебя сложнее уволить". На мой взгляд как раз узкий специалист в гораздо большей степени незаменим. По аналогии с постройкой моста: да, он занимается лишь одной единственной опорой, а про другие части вообще ничего не знает. Только вот больше никто конкретно эту опору делать не умеет. А без нее рухнет уже весь мост.
Иными словами: узкий специалист является незаменимым в своей области. Широкий же не является незаменимым ни в одной из своих областей.
*незаменимый — тяжело, долго, дорогоjehy
03.03.2016 21:40+5Узкого специалиста легко заменить — так как заменяется стандартная деталь в любом конструкторе. Если его заменить быстро, то никто ничего даже не заметит. А широкий является нестандартной деталью, которую в лучшем случае можно заменить несколькими другими.
Vilyx
03.03.2016 21:43+1Если специалист работает только с определённой технологией и давно, то он отличный специалист и потерять его обидно, но почти всегда можно найти менее опытного специалиста.
А вот если человек знает несколько технологий, которые встречаются вместе только в вашем проекте, то даже найти человека со знанием именно этих технологий уже вопрос сложный.
ikaktys
04.03.2016 09:18я сужу по той же индустрии / корпорациям. Узкий специалист: проект похерили и девать его особо некуда, надо увольнять или переучивать или ткнуть куда-нить на минимальную занятость. Широкий специалист — можно ткнуть куда угодно, особенно если профсоюз еще вмешается и скажет что "вон там а увас люди ищутся, ну почти такого же профиля".
jehy
04.03.2016 09:58Если проект один, то да. Но если в компании много похожих проектов, то можно, например, перекинуть слабого узкого специалиста на проект, который стал менее приоритетным, и взять оттуда более сильного разработчика.
ikaktys
03.03.2016 16:00+1Плюсы на основе опыта работы в корпорации и вообще разных фирмах
Вы можете выбирать, кем работать дальше
Тебя могут и пошлют работать в произвольный проект
Вы меньше выгораете
Тебя могут и пошлют работать в произвольный проект в произвольный момент времени
Вам проще расти в тимлида или архитектора
"он не знает ничего абсолютно идеально, куда ему в начальники"
Вы можете отдебажить всё, что угодно
Ты можешь и будешь дебажить код других, паралелльно к своей работе
Работать веселее, интереснее и познавательнее
При этом твое желание мало кто спрашивает, можешь же ?
В одиночку вы можете создавать чудесные вещи на стыке разных технологий
Задачи будут ставится "ну ты сделай там это все, вот это, красиво, ну ты ж можешь"
Ваши решения работают быстрее и надёжнее
это мало кого волнует, но для себя да, часто приносит удовлетворение
Вы можете пользоваться почти любыми исходниками
Тебе придется пользоваться любыми исходниками, например у меня сейчас есть с датами от 1989 до 2016, в одном проекте
Вы постигаете дзен
Это завсегда ...VoronServer
03.03.2016 16:24+1Соответственно, надо выбирать — на кого и с кем работать. Испытательные сроки даются не только для разработчика, но и для компании(проекта). Практически все здесь перечисленное — результат не грамотного менеджмента. Обычно такого человека теряют, в последствии (как вариант) вместе с проектом. Однако, НЕТ сказать сложно, здесь я согласен. НО пойдет на благо.
Fesor
03.03.2016 17:41+1Тебя могут и пошлют работать в произвольный проект
Так с любыми разработчиками, просто у full-stack разработчика выбор больше.
«он не знает ничего абсолютно идеально, куда ему в начальники»
Так это же идеальный начальник. А позиция "архитектор" как по мне вообще пережиток 90-х, архитектура должна строиться всей командой а не одним человеком.
При этом твое желание мало кто спрашивает, можешь же ?
Потому возвращаемся к предыдущему пункту, растем в начальники, делигируем свою работу, делаем то что нравится.
это мало кого волнует, но для себя да, часто приносит удовлетворение
Вот тут весьма странно. Если компания или клиенты не заинтересованы в "скорости и надежности" — то причем тут full-stack?
Тебе придется пользоваться любыми исходниками, например у меня сейчас есть с датами от 1989 до 2016, в одном проекте
Эта проблема преследует не только full-stack разработчиков.
cavin
05.03.2016 01:27+1Если бы программист был тварью дрожащей — то эти замечания были бы очень к месту. Когда меня пытались пристроить делать то, что я могу, но не хочу, я говорил "да, могу — но будет медленно и плохо, делать?" и сразу отставали. С тех пор программисты стали даже большей "элитой среднего звена", или как это назвать.
ikaktys
09.03.2016 09:10"да, могу — но будет медленно и плохо, делать?" — а в чем разница с тварью дрожжащей ?
Для меня б была разница — "я хочу заниматься вот той темй, эту углУбить, и вот этим проектом, ну, я пошел туда ?" и мне в ответ "о, проявляешь инициативу, молодец, идина тебе еще денег"
Но такое обычно надо выморачивать долго, нудно и с неопределенным результатом.Fesor
09.03.2016 10:34Но такое обычно надо выморачивать долго, нудно и с неопределенным результатом.
И какой из этого сделать вывод? Забить предлагаете? Или проявлять инициативу?
arielf
08.03.2016 16:10+3Прошу прощения, Вы не рабом были случайно?
ikaktys
09.03.2016 08:58что значит был, и являюсь, с подводной лодки обычно только один путь — за борт
Стандартный ответ начальства — фирма большая, незаменимых нет, тебя тут никто не держитFesor
09.03.2016 10:35фирма большая, незаменимых нет, тебя тут никто не держит
Ну так кто ж вас держит то? Незаменимых на самом деле нет, но это не означает что можно заменить разработчика без каких-либо потерь.ikaktys
09.03.2016 10:59ну как обычно, возраст, жена, дети, кредит и далее по списку, реализовываться и выделываться можно было в 25, когда я менял 10 фирм в год и очень неплохо себя чуствовал на фрилансе.
jehy
04.03.2016 09:56Плюсы не притянуты за уши, а скорее индивидуальны, и в общем всё сводится к тому, хочется ли уметь делать разное, или хочется развиваться и заниматься только одним направлением.
gotch
03.03.2016 15:48+5Вы, разработчики, не одиноки в метаниях душевных
https://habrahabr.ru/post/278485/
Gorthauer87
03.03.2016 15:48+1Дзен можно постичь если просто интересоваться программированием как таковым, не нужно для этого быть fullstack'ом. А дзен по жизни искать уж явно нужно с другого края начинать.
inf
03.03.2016 18:13+2Вы пролетите свежим бризом над граблями, которые до вас собрали тысячи других разработчиков.
Спасибо, посмеялся)) Или же "Вы с размаху пробежитесь по всем граблям расставленными вам другими разработчиками" :))inf
03.03.2016 20:17Не, мне и правда речевой оборот понравился. Второе предложение уже собственная боль))
jehy
04.03.2016 10:00Бегать по оставленным граблям — это само собой разумеется. Но если делать с нуля, то велика вероятность на все эти грабли наступить заново.
А так — есть возможность брать популярные репозитории, помогать в их исправлении и ещё и нахаляву получать исправление незамеченных грабель. Конечно, новые грабли тоже будут вылезать — но в этом весь процесс разработки.
inf
03.03.2016 18:17+1Ещё один плюс можно добавить, вытекающий из:
В одиночку вы можете создавать чудесные вещи на стыке разных технологий
+++ "При наличии видения потребностей мира вы способны сами проектировать и создавать коммерчески востребованные продукты".evsan
03.03.2016 18:21+2+++ «При наличии видения потребностей мира вы способны сами проектировать и создавать коммерчески востребованные продукты».
Но, к сожалению, конкуренты с бoльшим количеством людей всегда будут на шаг впереди.
misato
03.03.2016 18:46+2Нанять людей можно всегда, но если ты умеешь всё сам, то ты можешь в одиночку сделать наглядный прототип или MVP и таким образом быстрее и правильнее стартовать с самого начала.
misato
03.03.2016 18:54+6Подтверждаю, всё очень правильно написано.
Сам я веб-разработчик, на нормальном уровне умею в дизайн, фронтенд, бэкенд, контент (плюс, всё сопутствующее, что нужно для жизни: управление проектами, финансы, бухгалтерия). Это интересно, но нужно только если ты принципиально хочешь всё сам. Ну или как платформа для старта своей компании (хотя, всё равно ничего не гарантируется).
Если говорить об эффективности, то на комплексных задачах объемом до человеко-месяца команды специалистов не выдерживают никакой конкуренции против такого универсального человека. Никаких потерь на коммуникацию, на передачу работы к следующему этапу, плюс, с заказчиком компетентно и грамотно общается конечный исполнитель и всё такое. Но в каждом конкретном деле ты проигрываешь в глубине знаний.
Так я про себя и пишу — дилетант широкого профиля.
stifff
03.03.2016 19:01+2У меня вот стек начинается где-то с разработки электронных устройств.
Описанное очень похоже на происходящее.
Только у меня есть чувство, что мультиинструменталисты не особо-то и нужны. Особенно если они не выросли в лидов+
boblenin
03.03.2016 20:56+3В каждой отдельной области вы хуже, чем узкий специалист
Ну это утверждение не верно хотя бы с точки зрения формальной логики. Доказать такое утверждение будет сложно, а опровергнуть — легко. Думается, что вы начали с ложной предпосылки.
Вам сложнее продвигаться глубже
Собственно почему? Специалист широкого профиля может начать специализироваться в узком, обратное сделать, как мне кажется сложнее. (легче двигаться от общего к частному, чем наоборот).
У вас больше вероятность перегрузки задачами
Не очень понятен ваш способ подсчета вероятности в данном случае. Я думаю, что time-management навыки влияют на профессиональные навыки несколько иначе. Как вам вариант того, что специалист широкого профиля потому и имеет более широкий профиль, что эффективнее управляет своим временем и успевает узнать больше? Ну это как один из сценариев. Мне кажется вы опять начали с ложной предпосылки.
Вас сложно заменить
Узкого специалиста заменить всегда сложнее. Ну а в целом то, что кажется нерешаемым на одном уровне принятия решений — вообще не является проблемой уровнем чуть выше. Я хочу сказать, что не очень-то рассчитывайте на незаменимость.
У вас нет чёткой зоны ответственности
Есть. Такая же как у всех — это продукт и в конечном итоге прибыль. Все остальное — это мелочь и офиснопланктонные игры.
Вы не всегда пишете оптимальный код
Никто не пишет оптимальный код всегда.
Вам не верят
Странный момент. Если речь идет о резюме, то количество технологий не является чем-то определяющем (по крайней мере когда я собеседую людей). Если вы написали через запятую 5 или 10 ключевых слов — это одинаково малодостоверная информация для меня. Если вы написали ДЛЯ ЧЕГО и в каком проекте вы использовали технологию, то опять же сколько ключевых слов вы написали — не важно.
Если речь идет о собеседовании — дык все же легко проверяется. Надо только дать человеку расскрыться во всем своем великолепии.
Вы можете начать завидовать зарплате узких специалистов
Это точно. Но и узкие специалисты могут начать завидовать вашей.
А вот с плюсами я пожалуй больше соглашусь.
Вообще, узкий специалист требует дополнительное организационное звено — архитектора или тимлида для разработки сложного продукта. А это усложняет саму организацию, а значит снижает ее эффективность. Если же специалист может спрятать часть сложности системы внутри себя — то в целом организация будет более эффективной, т.к. меньше управленческих или организационных звеньев нужно для получения продукта.jehy
04.03.2016 10:49+1Ну это утверждение не верно хотя бы с точки зрения формальной логики. Доказать такое утверждение будет сложно, а опровергнуть — легко.
В качестве доказательства — при наличии времени t со стимулом s, вы получаете некую работу txs, которую можете потратить на развитие. При равномерном распределении векторов развития, каждое ваше знание будет увеличиваться на txs/n, где n — это количество этих самых векторов. Следовательно, чем меньше n у человека с таким же стимулов и количеством времени, как у вас, тем больше он сумеет узнать в каждой конкретной области.
Естественно, есть куча предпосылок, в которых всё становится совершенно не так. Например, если вы fullstack javascript разработчик, то с очевидностью вы будете знать javascript лучше, чем узкий frontend разработчик. Но именно потому, что на самом деле ваше n меньше, чем у него, и у вас главенствует именно вектор javascript, на который вы тратите основное время.
Не следует воспринимать всю статью дословно — она рассчитана на некоторую внутреннюю обработку и адаптацию в конкретной ситуации, и может в итоге вам принести совершенно разные выводы. Конечно, можно было бы везде поставить сноски "скорее всего", "вероятно" и "обычно", но после этого текст стал бы совершенно ужасен.
Никто не пишет оптимальный код всегда.
Конечно же! Но речь шла о том, что у хорошего узкого специалиста больше шансов написать оптимальный код, чем у fullstack.
В общем, по всем остальным пунктам то же самое — не надо воспринимать статью как утверждение про абсолютные истины, надо просто подумать над указанными пунктами и тем, что они для вас значат.boblenin
04.03.2016 15:57-1при наличии времени t со стимулом s, вы получаете некую работу txs, которую можете потратить на развитие.
Ну вот. Т.е. мы считаем, что все люди одинаковые? Или мы считаем, что один и тот же человек одинаково хорошо развивается как в одной области так и в другой? Это ваши исходные?
Конечно же! Но речь шла о том, что у хорошего узкого специалиста больше шансов написать оптимальный код, чем у fullstack.
Не понятно откуда вы это взяли. Например как вам такой вариант: человек с широким кругозором может применять техники из смежных областей, в то время как человек с узкой специализацией будет выдавать одни и те же типовые решения, даже тогда, когда они не подходят.
И в конечном итоге то, кто из них напишет более качественный код зависит от кучи факторов. Например умение прогнозировать (написал и оказалось, что угадал с тем как система будет развиваться далее и не надо рефакторить лишний раз) — а тут опять же перевес на стороне того, кто лучше видит всю картинку целиком.
Специалист широкого профиля имеет более полное представление о системе, следовательно имеет больший горизонт планирования и значит решения такого специалиста стратегически более верные.
Ведь что такое "оптимальный код"? Я считаю, что это код который позволяет максимизировать прибыль и минимизировать издержки. Или если обращаться к классике, то по Альтшуллеру: "Идеальная техническая система — это система, которой нет, а ее функции выполняются, то есть цели достигаются без средств.".
Antelle
03.03.2016 22:45+2Надо разделять два вида "фуллстек-разработчиков":
- Кто очень хорошо знает что-то одно (фронт-енд, например) и в принципе может заниматься остальным (например, есть прошлый опыт, представляет что как устроено на сервере, в базе данных, знает используемые алготирмы и протоколы). Это одно, и такой человек ценен, и получать будет больше чем фронтенд, который ничего о сервере не знает и знать не хочет в принципе.
- Те кто знают кое-что обо всём и работают "как-то так". По-старому, вебмастер: дали ему сайт, он за ним ухаживает, поддерживает, и скрипты пишет (хреновые, глючные, страшные, но в целом рабочие), и за базой следит, и бэкенд пилит, отлаживая "print 1" прямо на продакшене. Это совсем другое, в стартапе, веб-студиях оно надо, но вобщем стоит недорого, уважается мало, а иногда ещё и столы носить придётся, ну или сеть протянуть.
RioMan
04.03.2016 09:26На втором пункте чуть не заплакал, как всё знакомо… Просто вся жизнь перед глазами.
valeriyk
03.03.2016 23:14+1Ассемблер в стек нонче входит?
jehy
04.03.2016 10:54В какой-то стек наверняка входит. Стек — это всего лишь некий набор технологий со смысловым обобщением. Например, если вы разрабатываете классические микроконтроллеры, то в ваш стек будет входить ассемблер, умение паять, знание электротехники и возможно умение пить водку с дворником Петровичем, который занимается сваркой деталей для вашего робота.
MTonly
04.03.2016 02:54+2Главное — чтоб не Full StackOverflow.
Full Stack Overflow developers work almost entirely by copying and pasting code from Stack Overflow instead of understanding what they are doing. Instead of researching a topic, they go there first to ask a question hoping people will just give them the result.
AlexanderByndyu
04.03.2016 06:08+1Поддерживаю мнение о том, что full stack разработчик для сложных проектов менее эффективен https://habrahabr.ru/post/275333/
deppkind
04.03.2016 09:34+2Верно, но по факту в практике если фулстек это некий самостоятельный боец в поле — доля несложных проектов ~90% на рынке и все они поддаются фуллстеку.
AlexanderByndyu
04.03.2016 10:09Ага, для простых проектов, которых большинство, full stack будет лучше.
boblenin
04.03.2016 16:00Ведь вы же читали мифический человеко-месяц? http://www.amazon.com/The-Mythical-Man-Month-Engineering-Anniversary/dp/0201835959
MechanisM
04.03.2016 08:23По непонятной мне причине, часто ищут разработчика, который в совершенстве умеет применить что-то, что вышло в релиз полгода назад.
Как по мне, нормальный разработчик(любой) должен заглядывать далеко вперед и играться с альфа/бета версиями продуктов, до такой степени, что к моменту релиза новой технологии или фреймворка — он уже все это знает. Считаю очень хорошей чертой, когда разработчик не просто умеет что-то писать а еще и имеет широкий кругозор в плане технологий. Это здорово, когда разработчик активно интересуется всем вокруг своей деятельности и любит экспериментировать с чем-то новым.jehy
04.03.2016 10:05+3Здесь надо хорошо понимать один нюанс. Знать о нововведениях и примерно понимать, чем они хороши — это одно.
А попробовать их и суметь быстро и корректно ввести в продакшн — уже другое.
При широком спектре технологий успеваешь прочитаешь все интересные статьи и новости и получить представление — но погонять вживую часто не удаётся.
MTonly
04.03.2016 17:56+2должен заглядывать далеко вперед и играться с альфа/бета версиями продуктов
Это только если разработчик очень молод, и ему некуда девать время. Разработчики помудрее стараются быть в курсе событий, но глубокое изучение конкретной технологии откладывают на момент, когда/если она реально потребуется на практике. ;-)
Manul
04.03.2016 09:54+2Это, конечно, замечательно много знать и многое уметь, но, например, частая смена контекста при работе на нескольких разных проектах одновременно приводит к нервному истощению быстрее, чем если вы работает с один и тем же, но на разных проектах. Все еще усугубляется тогда, когда начальство начинает намекать, что надо бы сделать быстрее, лучше и краше, да и проекты подгорают, а у тебя просто нет достаточно глубоких знаний и сильных навыков. Приходится помимо выполнения работы так же тратить время на дополнительное обучение, а это приводит к конфликтам в других областях жизни. Лично бывал (да и есть) в такой ситуации, ничего хорошего в этом нет, с моей точки зрения. Конечно, это актуально, если относится ко всему ответственно.
Верно подмечено, что full stack разработчик нужен на начальной стадии проекта или стартапа, но позднее, когда есть более-менее стабильный продукт/система, он должен быть вытеснен специалистами. Это необходимо для нормального развития проекта / стартапа.
Наверное, быть специалистом в какой-то одной области гораздо комфортнее и выгоднее, чем "full stack" разработчиком.
grossws
04.03.2016 10:10Верно подмечено, что full stack разработчик нужен на начальной стадии проекта или стартапа, но позднее, когда есть более-менее стабильный продукт/система, он должен быть вытеснен специалистами. Это необходимо для нормального развития проекта / стартапа.
Или full stack переключается на создание следующей версии, как вариант.
Ещё пример полезности full stack разработчика — R&D, когда навыки jack of all trades полезны. Правда необходим перекос в основную область деятельности, что даёт уже среднее между full stack и specialist.Manul
04.03.2016 11:28Или full stack переключается на создание следующей версии, как вариант.
Full stack может начать углублятся в специализацию, что мало вероятно, либо идти на другой проект / стартап.
denis_g
04.03.2016 09:55Например, чтобы наладить взаимоотношения с девушкой (для примера назовём её Катей).
Вот этот кусок просто высадил в астрал :D Спасибо за статью.
Rathil
04.03.2016 10:58- если сам разбираешься во многом — проще сделать стартап.
cavin
05.03.2016 01:36+1Только стартап кроме развертывания сервера, проектирования базы данных, бекенда, фронтенда, хранилищ, бекапов,
бутстрапа и вордпрессаобычно требует еще дизайна, проектирования интерфейса, создания презентаций, разговорного и письменного английского, заключение договоров с платежными системами и бог знает чего еще. Причем, практика показывает — что чаще всего не-разработки там гораздо больше и от нее зависит гораздо больше.
IvanIDSolutions
04.03.2016 11:31Все это очень знакомо:) солидарен с автором. Наличие широкого стека знаний и технологий является большим плюсом, если ты собственник айтишного бизнеса.
AirWorker
08.03.2016 14:12+1Когда ты 14 лет в професси, очень странно, когда ты не full stack. Такие технологии как gulp или sass на базовом уровне учатся за выходные например.
Full stack во что угодно может превратиться. За всеми тенденциями конечно уследить нельзя, но когда попадаешь в команду, все равно начинаешь заниматься преимущественно каким-то направлением, за 1-2 месяца подтянешься до узкого спеца.
HotFire
08.03.2016 15:52+1Джуниором пошел в фирму, где был full stack. Не жалею. Попробовал одно, другое, третье. Нащупал, чем нравится заниматься больше всего. И пошел в итоге узким специалистом.
Имхо, джуниору лучше пойти именно на full stack (хотя бы бекенд + фронтенд по обязанностями, 50 на 50). Как поймешь, чем хочешь заниматься, не попробовав в бою все эти технологии?
datacompboy
09.03.2016 14:01+1Очень много "очевидно", когда это во-1х не очевидно, во-2х еще и не так.
Особенно, забывая о очень важном (опять же упущенном моменте), про "при прочих равных".
Full-stack разработчики не такие же люди, как узкие специалисты. Именно за счет своих отличий они и пошли в узкую специализацию широкого профиля.
К тому же, помнить, учитывать, скрещивать, искать параллели, применять решение не типичное для области, но крайне необходимое здесь и сейчас — это тоже специализация.
Кросс-системная оптимизация глубоко зарытым дотнетером/явером без фулстекера рядом так же лажает, как и ассемблерная оптимизация узкого места ПХПшником
nos
как то про full-stack javascript вообще не упомянули — а ведь бывает уже full stack в одной технологии. но вообще статья веселая, а “О, дайте ему — он разберётся!” это вообще очень жизненно :)
jehy
Full stack в одой технологии действительно уже бывает, но я намеренно старался абстрагироваться от любой конкретики, чтобы у каждого был шанс себя узнать.
Alexufo
Так вот кто у нас гороскопы делает)
ikaktys
бывает наверно уже, но это IMHO таки не full stack, а так, нюансы.
full stack — это когда я админю Oracle, MSSQL, программлю параллельно C#, JS, мультиплатформенный C++, и под конец пихаю все в MSI/WiX/InstallShield, и это все — два параллельных проекта. И нифига не стартап, а обычная мультинациональная корпорация с 150+ летней историей в которой ты винтик и где экономят на всем.
Steamus
И лампочки в коридоре менять. Боюсь, то что вы перечислили называется "И швец, и жнец, и на дуде игрец". Везде может пристроиться как-то...
full stack — это когда некий разработчик способен в одиночку спроектировать и реализовать все уровни некоей многоуровневой системы. К примеру если говорить о Java-WEB, то он знает принципы проектирования БД, способен это сделать и умеет писать SQL запросы и использовать JDBC/ORM. Затем он знает Spring и как хранится бизнес логика. Владеет неким фреймворком, на котором генерируется клиент (скажем Wicket или JSF). Ну и наконец способен программировать самого клиента. Приемлемо знает HTML, CSS, Javascript, jQuery, Bootstrap. И всё это на пристойном уровне понимания, что бы имея под рукой интернет как справочник, можно было реализовать проект достаточно профессионально.
Сам факт скакания с языка на язык и способность что-то там на нём написать — ещё не делает человека full stack разработчиком.
evsan
Даже в таком случае есть специализация. Есть общие и необходимые знания, которые должны быть на приемлемом уровне.
А то, что указали Вы — это, по-моему, backend программист, явно не джуниор, который может писать frontend, если задача не особо сложная или если основные frontend разработчики заняты и их не хочется дергать ради "добавить пару текстовых полей, их валидацию и кнопку для отправки всего этого на сервер."
Тем более, что сейчасдля всех языков программирования есть фреймворки, которые позволяют из коробки, без особого знания тонкостей языка и фреймворка, на коленке, по мануалу и с гуглом собрать "прототипчик".
Steamus
Приемлимое понимание механики хорошего, мощного фреймворка — требует времени. И понимания технологий/протоколов за ним стоящих. На коленке по мануалу вы сделаете студенческую поделку для курсача.
asm0dey
Там выше описан я, но я ещё при необходимости и питон могу, и хаскель. Могу развернуть систему, могу построить отказоустойчивую систему и настроить автоматическое разворачивание её — и всё это будет чуть хуже работать, чем у узких специалистов в каждой области.
Portah
Сложно сказать. Я по специализации прикладной математик ) Всегда относил себя к универсальным солдатам, наверное теперь знаю как они называются. Статья точно отражает смысл того что приходится делать. Попробую написать то что я делал в течении года.
Так сложилось меня занесло в биоинформатики более четырех лет назад, т.е. как минимум мне пришлось начать понимать азы биологии (необходимые для работы). Все термины гуглятся. Дык вот за последний год я:
И это какая-то часть она не передает всех задач которые выполняешь. И главное, что мне нравится больше всего, что скучать не приходится. Основная проблема — поговорить почти не с кем. Единицы умеют вникать в детали технологий и связывать одни технологии с другими делая этот симбиоз продуктивным.
Иногда правда грусть накатывает, редко но бывает, хочется просто хорошо программировать на C++.
ikaktys
не, лампочки нельзя, это заоутсосено, тут же у нас не просто так, а корпорация.
А "способен в одиночку спроектировать и реализовать все уровни некоей многоуровневой системы" не работает, потому что такие системы требуют затрат не в человеко-месяцы, а часто многие человеко-годы и в одиночку их совершенно нереально разработать каким бы суперменом ты не был, но зато с одной стороны есть плюсы в том что можно попилить эту систему на разных углах, с другой — тебе придется ее пилить на разных углах, так как за время разработки или тебя перекинут или другие будут болеть, уйдут в отпуск, уйдут вообще...
Steamus
Сколько человеко-лет требуется на реализацию проекта, зависит не от его архитектуры, а от сложности/функциональности системы. Можно и за день реализовать простую трёх-уровневую систему со стеком технологий.