Чем плохо быть full stack разработчиком

    Введение


    Прежде всего определимся с терминами. Есть много разных представлений о том, кто же такой full stack разработчик, кто-то даже вполне обоснованно считает, что такие разработчики — это миф, но в этой статье будет иметься в виду разработчик, который обладает знаниями и умениями, позволяющими с нуля написать некий софт и вывести его в продакшн. При этом софт может быть рассчитан на web платформу, мобильные приложения или десктопные. Идеальный full stack разработчик — это тот, кто владеет в какой-то мере всеми платформами и может разработать и установить на них свой софт. Но это действительно скорее миф.
    Неплохое определение с quora.com
    Когда люди ищут 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 человека. Запрограммировать микроконтроллер для интернета вещей, который общается с веб сервером, пишет в базу данных, и данные с которого можно просматривать на веб сайте, в приложении или на мобильном устройстве? Легко! Вы один можете представить всю систему и реализовать её без согласований, недопониманий и проволочек.

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

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

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

    Здесь должна была быть картинка, на которой показано, как просветлённый программист в позе Лотоса медленно возносится над горами Тибета, а вокруг него танцуют, обнимаются и водят хоровод языки программирования и различные технологии в образе очаровательных девушек — но увы, такой картинки почему-то не нашёл. Пожалуйста, представьте это сами.
    Поделиться публикацией

    Комментарии 92

      +7
      как то про full-stack javascript вообще не упомянули — а ведь бывает уже full stack в одной технологии. но вообще статья веселая, а “О, дайте ему — он разберётся!” это вообще очень жизненно :)
        +1
        Full stack в одой технологии действительно уже бывает, но я намеренно старался абстрагироваться от любой конкретики, чтобы у каждого был шанс себя узнать.
          +2
          Так вот кто у нас гороскопы делает)
          –4
          бывает наверно уже, но это IMHO таки не full stack, а так, нюансы.

          full stack — это когда я админю Oracle, MSSQL, программлю параллельно C#, JS, мультиплатформенный C++, и под конец пихаю все в MSI/WiX/InstallShield, и это все — два параллельных проекта. И нифига не стартап, а обычная мультинациональная корпорация с 150+ летней историей в которой ты винтик и где экономят на всем.
            +14
            И лампочки в коридоре менять. Боюсь, то что вы перечислили называется "И швец, и жнец, и на дуде игрец". Везде может пристроиться как-то...

            full stack — это когда некий разработчик способен в одиночку спроектировать и реализовать все уровни некоей многоуровневой системы. К примеру если говорить о Java-WEB, то он знает принципы проектирования БД, способен это сделать и умеет писать SQL запросы и использовать JDBC/ORM. Затем он знает Spring и как хранится бизнес логика. Владеет неким фреймворком, на котором генерируется клиент (скажем Wicket или JSF). Ну и наконец способен программировать самого клиента. Приемлемо знает HTML, CSS, Javascript, jQuery, Bootstrap. И всё это на пристойном уровне понимания, что бы имея под рукой интернет как справочник, можно было реализовать проект достаточно профессионально.
            Сам факт скакания с языка на язык и способность что-то там на нём написать — ещё не делает человека full stack разработчиком.
              +3
              Даже в таком случае есть специализация. Есть общие и необходимые знания, которые должны быть на приемлемом уровне.
              А то, что указали Вы — это, по-моему, backend программист, явно не джуниор, который может писать frontend, если задача не особо сложная или если основные frontend разработчики заняты и их не хочется дергать ради "добавить пару текстовых полей, их валидацию и кнопку для отправки всего этого на сервер."

              Сам факт скакания с языка на язык и способность что-то там на нём написать — ещё не делает человека full stack разработчиком.

              Тем более, что сейчасдля всех языков программирования есть фреймворки, которые позволяют из коробки, без особого знания тонкостей языка и фреймворка, на коленке, по мануалу и с гуглом собрать "прототипчик".
                +1
                Приемлимое понимание механики хорошего, мощного фреймворка — требует времени. И понимания технологий/протоколов за ним стоящих. На коленке по мануалу вы сделаете студенческую поделку для курсача.
                  0
                  Там выше описан я, но я ещё при необходимости и питон могу, и хаскель. Могу развернуть систему, могу построить отказоустойчивую систему и настроить автоматическое разворачивание её — и всё это будет чуть хуже работать, чем у узких специалистов в каждой области.
                    +3
                    Сложно сказать. Я по специализации прикладной математик ) Всегда относил себя к универсальным солдатам, наверное теперь знаю как они называются. Статья точно отражает смысл того что приходится делать. Попробую написать то что я делал в течении года.
                    Так сложилось меня занесло в биоинформатики более четырех лет назад, т.е. как минимум мне пришлось начать понимать азы биологии (необходимые для работы). Все термины гуглятся. Дык вот за последний год я:

                    • Написал дополнительный функционал к bedtools(C/C++) отняло где-то неделю времени. Скажем тут не совсем неделя, я до этого написал свою утилиту, просто потом понял, что правильнее включить этот функционал в этот проект. А когда писал утилиту учил биологию и биоинформатику
                    • Разобрался с технологиями семантик веб для проекта Common Workflow Language (CWL) освоил: SPARQL, apache-fuseki, JSON-LD, RDF + ко всему этому туча аннотаций foaf, doap, dc,dcterms, schema.org… простите что в одну кучу программы и языки — но это для универсального солдата неразлучно. Это заняло около месяца.
                    • Разобрался в синтаксисе CWL, написал пару фиксов к reference implementation на Python. Скрестил airbnb airflow с CWL разобрался с celery ибо придется запускать на cluster/cloud/server — это было долго месяца 3
                    • Сейчас пишу систему, чтобы все то что перечислил выше интегрировать в одну систему. Изучаю и пишу в параллель для meteor (nodejs)/angular2/monogodb мелочевку не буду перечислять. Примерно уже 3 месяца
                    • И все это время поддерживал основную работу C/C++, R, Python. BioWardrobe project — PHP, ExtJS

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

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

                    А "способен в одиночку спроектировать и реализовать все уровни некоей многоуровневой системы" не работает, потому что такие системы требуют затрат не в человеко-месяцы, а часто многие человеко-годы и в одиночку их совершенно нереально разработать каким бы суперменом ты не был, но зато с одной стороны есть плюсы в том что можно попилить эту систему на разных углах, с другой — тебе придется ее пилить на разных углах, так как за время разработки или тебя перекинут или другие будут болеть, уйдут в отпуск, уйдут вообще...
                      +1
                      Сколько человеко-лет требуется на реализацию проекта, зависит не от его архитектуры, а от сложности/функциональности системы. Можно и за день реализовать простую трёх-уровневую систему со стеком технологий.
                +9
                А еще узкий специалист может проснуться и обнаружить, что он не нужен, т.к. его ниша устарела и пора было давно переучиваться на что-то другое, что не грозит fullstack разрабу.
                  +2
                  Это какой-то исключительный случай, по-моему.
                  Устаревание ведь проходит не мгновенно. И вытесняющие технологии обычно изучать не так трудно, они похожи. По-моему, большинство Swing Java разработчиков вполне комфортно себя будут чувствовать, используя Vaadin. В крайнем случае применить полученные за годы работы со Swing знания в UX во front-end разработке на JS с каким-нибудь модным фреймворком, если серверное программирование "не его".

                  Единственная проблема — это поиск работы без коммерческого опыта в конкретной технологии, но и это решается.
                    +1
                    У меня пример из сферы DBA, знакомый 15 лет занимался базами Oracle, больше ничего толком не знает, и когда на предприятии решили перейти на postgresql, то наняли тех, кто разбирается в postgresql и после миграции он, ораклист, был уволен, т.к. не хотел переучиваться и решил, что найдет без проблем другое место. Но с другим местом довольно долго не срасталось, т.к. отказываются от оракла много где и достаточно хороших специалистов переизбыток, возможно что уже больше полугода ищет, после НГ не спрашивал еще.
                      –1
                      Чует мое сердце, что среднему оракловщику платят больше чем DBA постгреса, так что возможно ваш знакомый таки прав.
                        +3
                        речь о том, что хлебные места разобраны
                        +2
                        Про то, что ораклоид долго ищет работу — это странно. У меня вот в резюме разработчика написано про сертификацию в качестве Oracle DBA — звонят постоянно и обещают горы золота. Может, у вашего знакомого что-то не так с резюме? Попробуйте показать его знакомому HR'у. Резюме, не знакомого.
                    +8
                    Full-stack разработчики — мастхев для стартапов почти на любом этапе развития. Это в том числе касается пункта "Вас сложно заменить" — если есть несколько универсалов, они неплохо друг друга дополняют и заменяют.
                      0
                      Да, упустил как-то из виду этот хороший вариант решения проблемы замены. Правда, обычно универсалов довольно мало. Хотя не знаю ситуации со стартапами.
                        0
                        Как ни странно, универсалов не мало в численном выражении, но очень мало в отношении количество вакансий на одного человека.
                        0
                        Для стартапов или маленьких команд полезны, но если есть пара фулстеков, то в конечном итоге все равно разделят между собой и станут заниматься чем-то одним.
                          +1
                          4 года стартапов говорят мне об обратном: один за всех и все за одного — теперь это лозунг универсалов в одной лодке
                        +1
                        А почему сложнее искать подходящую вакансию? Обычно так и пишут "full stack". На всякий можно ещё и "fullstack".
                          +5
                          Уточню, возможно было не совсем понятно из статьи. Те, кто ищут fullstack в явном виде — часто хотят взять одного человека на три вакансии, и чтобы он ещё вечерами мусор выносил. Да и немного вакансий — сейчас по Москве на хедхантере к примеру только 8 штук.
                          Зачастую гораздо интереснее искать вакансии по каким-то другим конкретным ключевикам.
                            0
                            Черт возьми, меня же один раз уволили за то, что я не стал мусор выносить!
                            +1
                            Можно еще добавить «Многостаночник»
                              0
                              Человек-оркестр :)
                            0
                            Плюсы как-то притянуты за уши
                              +1
                              вот да, после 10+ лет опыта работы full stack в корпорации из этих плюсов есть только одно — тебя сложнее уволить и проще пихнуть в другой проект, все остальное — только "чуство глубокого удовлетворения" и плюсы для начальства, опять же только потому что тебя моугт пихнуть в любой проект, не особо интерсуясь мнением.
                                –1
                                А объясните почему "тебя сложнее уволить". На мой взгляд как раз узкий специалист в гораздо большей степени незаменим. По аналогии с постройкой моста: да, он занимается лишь одной единственной опорой, а про другие части вообще ничего не знает. Только вот больше никто конкретно эту опору делать не умеет. А без нее рухнет уже весь мост.

                                Иными словами: узкий специалист является незаменимым в своей области. Широкий же не является незаменимым ни в одной из своих областей.

                                *незаменимый — тяжело, долго, дорого
                                  +5
                                  Узкого специалиста легко заменить — так как заменяется стандартная деталь в любом конструкторе. Если его заменить быстро, то никто ничего даже не заметит. А широкий является нестандартной деталью, которую в лучшем случае можно заменить несколькими другими.
                                    +1
                                    Если специалист работает только с определённой технологией и давно, то он отличный специалист и потерять его обидно, но почти всегда можно найти менее опытного специалиста.
                                    А вот если человек знает несколько технологий, которые встречаются вместе только в вашем проекте, то даже найти человека со знанием именно этих технологий уже вопрос сложный.
                                      0
                                      я сужу по той же индустрии / корпорациям. Узкий специалист: проект похерили и девать его особо некуда, надо увольнять или переучивать или ткнуть куда-нить на минимальную занятость. Широкий специалист — можно ткнуть куда угодно, особенно если профсоюз еще вмешается и скажет что "вон там а увас люди ищутся, ну почти такого же профиля".
                                        0
                                        Если проект один, то да. Но если в компании много похожих проектов, то можно, например, перекинуть слабого узкого специалиста на проект, который стал менее приоритетным, и взять оттуда более сильного разработчика.
                                    +1
                                    Плюсы на основе опыта работы в корпорации и вообще разных фирмах

                                    Вы можете выбирать, кем работать дальше
                                    Тебя могут и пошлют работать в произвольный проект

                                    Вы меньше выгораете
                                    Тебя могут и пошлют работать в произвольный проект в произвольный момент времени

                                    Вам проще расти в тимлида или архитектора
                                    "он не знает ничего абсолютно идеально, куда ему в начальники"

                                    Вы можете отдебажить всё, что угодно
                                    Ты можешь и будешь дебажить код других, паралелльно к своей работе

                                    Работать веселее, интереснее и познавательнее
                                    При этом твое желание мало кто спрашивает, можешь же ?

                                    В одиночку вы можете создавать чудесные вещи на стыке разных технологий
                                    Задачи будут ставится "ну ты сделай там это все, вот это, красиво, ну ты ж можешь"

                                    Ваши решения работают быстрее и надёжнее
                                    это мало кого волнует, но для себя да, часто приносит удовлетворение

                                    Вы можете пользоваться почти любыми исходниками
                                    Тебе придется пользоваться любыми исходниками, например у меня сейчас есть с датами от 1989 до 2016, в одном проекте

                                    Вы постигаете дзен
                                    Это завсегда ...
                                      +1
                                      Соответственно, надо выбирать — на кого и с кем работать. Испытательные сроки даются не только для разработчика, но и для компании(проекта). Практически все здесь перечисленное — результат не грамотного менеджмента. Обычно такого человека теряют, в последствии (как вариант) вместе с проектом. Однако, НЕТ сказать сложно, здесь я согласен. НО пойдет на благо.
                                        +1
                                        Тебя могут и пошлют работать в произвольный проект

                                        Так с любыми разработчиками, просто у full-stack разработчика выбор больше.

                                        «он не знает ничего абсолютно идеально, куда ему в начальники»

                                        Так это же идеальный начальник. А позиция "архитектор" как по мне вообще пережиток 90-х, архитектура должна строиться всей командой а не одним человеком.

                                        При этом твое желание мало кто спрашивает, можешь же ?

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

                                        это мало кого волнует, но для себя да, часто приносит удовлетворение

                                        Вот тут весьма странно. Если компания или клиенты не заинтересованы в "скорости и надежности" — то причем тут full-stack?

                                        Тебе придется пользоваться любыми исходниками, например у меня сейчас есть с датами от 1989 до 2016, в одном проекте

                                        Эта проблема преследует не только full-stack разработчиков.
                                          +1
                                          Если бы программист был тварью дрожащей — то эти замечания были бы очень к месту. Когда меня пытались пристроить делать то, что я могу, но не хочу, я говорил "да, могу — но будет медленно и плохо, делать?" и сразу отставали. С тех пор программисты стали даже большей "элитой среднего звена", или как это назвать.
                                            0
                                            "да, могу — но будет медленно и плохо, делать?" — а в чем разница с тварью дрожжащей ?

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

                                              И какой из этого сделать вывод? Забить предлагаете? Или проявлять инициативу?
                                            +3
                                            Прошу прощения, Вы не рабом были случайно?
                                              0
                                              что значит был, и являюсь, с подводной лодки обычно только один путь — за борт
                                              Стандартный ответ начальства — фирма большая, незаменимых нет, тебя тут никто не держит
                                                0
                                                фирма большая, незаменимых нет, тебя тут никто не держит

                                                Ну так кто ж вас держит то? Незаменимых на самом деле нет, но это не означает что можно заменить разработчика без каких-либо потерь.
                                                  0
                                                  ну как обычно, возраст, жена, дети, кредит и далее по списку, реализовываться и выделываться можно было в 25, когда я менял 10 фирм в год и очень неплохо себя чуствовал на фрилансе.
                                            0
                                            Плюсы не притянуты за уши, а скорее индивидуальны, и в общем всё сводится к тому, хочется ли уметь делать разное, или хочется развиваться и заниматься только одним направлением.
                                            +5
                                            Вы, разработчики, не одиноки в метаниях душевных
                                            https://habrahabr.ru/post/278485/
                                              +1
                                              Дзен можно постичь если просто интересоваться программированием как таковым, не нужно для этого быть fullstack'ом. А дзен по жизни искать уж явно нужно с другого края начинать.
                                                +2
                                                Вы пролетите свежим бризом над граблями, которые до вас собрали тысячи других разработчиков.

                                                Спасибо, посмеялся)) Или же "Вы с размаху пробежитесь по всем граблям расставленными вам другими разработчиками" :))
                                                  0
                                                  Не, мне и правда речевой оборот понравился. Второе предложение уже собственная боль))
                                                    0
                                                    Бегать по оставленным граблям — это само собой разумеется. Но если делать с нуля, то велика вероятность на все эти грабли наступить заново.
                                                    А так — есть возможность брать популярные репозитории, помогать в их исправлении и ещё и нахаляву получать исправление незамеченных грабель. Конечно, новые грабли тоже будут вылезать — но в этом весь процесс разработки.
                                                    +1
                                                    Ещё один плюс можно добавить, вытекающий из:

                                                    В одиночку вы можете создавать чудесные вещи на стыке разных технологий

                                                    +++ "При наличии видения потребностей мира вы способны сами проектировать и создавать коммерчески востребованные продукты".
                                                      +2
                                                      +++ «При наличии видения потребностей мира вы способны сами проектировать и создавать коммерчески востребованные продукты».

                                                      Но, к сожалению, конкуренты с бóльшим количеством людей всегда будут на шаг впереди.
                                                        +2
                                                        Нанять людей можно всегда, но если ты умеешь всё сам, то ты можешь в одиночку сделать наглядный прототип или MVP и таким образом быстрее и правильнее стартовать с самого начала.
                                                          +1
                                                          не обязательно делать все самому, но есть возможность контролировать других разработчиков, поскольку есть экспертиза в нужных сферах.
                                                            0
                                                            Да, и это тоже
                                                          +2
                                                          Ну да, девять женщин точно смогут.
                                                        +1
                                                        Зато сколько можно придумать забавных, но со смыслом, опечаток: full-stuck, fool-stack, full-suck и т.п.
                                                        Просто раздолье для HR-тролля.
                                                          +2
                                                          full-slack
                                                            0
                                                            только мне в голову сразу одни матерные варианты лезут?
                                                            +6
                                                            Подтверждаю, всё очень правильно написано.

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

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

                                                            Так я про себя и пишу — дилетант широкого профиля.
                                                              0
                                                              Очень точно. Забираю цитату себе в статью про качественный полноценный фриланс — это как раз про это. Спасибо за ясность мысли.
                                                                0
                                                                Пожалуйста :)
                                                              +2
                                                              У меня вот стек начинается где-то с разработки электронных устройств.
                                                              Описанное очень похоже на происходящее.

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

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

                                                                Вам сложнее продвигаться глубже

                                                                Собственно почему? Специалист широкого профиля может начать специализироваться в узком, обратное сделать, как мне кажется сложнее. (легче двигаться от общего к частному, чем наоборот).

                                                                У вас больше вероятность перегрузки задачами

                                                                Не очень понятен ваш способ подсчета вероятности в данном случае. Я думаю, что time-management навыки влияют на профессиональные навыки несколько иначе. Как вам вариант того, что специалист широкого профиля потому и имеет более широкий профиль, что эффективнее управляет своим временем и успевает узнать больше? Ну это как один из сценариев. Мне кажется вы опять начали с ложной предпосылки.

                                                                Вас сложно заменить

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

                                                                У вас нет чёткой зоны ответственности

                                                                Есть. Такая же как у всех — это продукт и в конечном итоге прибыль. Все остальное — это мелочь и офиснопланктонные игры.

                                                                Вы не всегда пишете оптимальный код

                                                                Никто не пишет оптимальный код всегда.

                                                                Вам не верят

                                                                Странный момент. Если речь идет о резюме, то количество технологий не является чем-то определяющем (по крайней мере когда я собеседую людей). Если вы написали через запятую 5 или 10 ключевых слов — это одинаково малодостоверная информация для меня. Если вы написали ДЛЯ ЧЕГО и в каком проекте вы использовали технологию, то опять же сколько ключевых слов вы написали — не важно.

                                                                Если речь идет о собеседовании — дык все же легко проверяется. Надо только дать человеку расскрыться во всем своем великолепии.

                                                                Вы можете начать завидовать зарплате узких специалистов

                                                                Это точно. Но и узкие специалисты могут начать завидовать вашей.

                                                                А вот с плюсами я пожалуй больше соглашусь.

                                                                Вообще, узкий специалист требует дополнительное организационное звено — архитектора или тимлида для разработки сложного продукта. А это усложняет саму организацию, а значит снижает ее эффективность. Если же специалист может спрятать часть сложности системы внутри себя — то в целом организация будет более эффективной, т.к. меньше управленческих или организационных звеньев нужно для получения продукта.
                                                                  +1
                                                                  Ну это утверждение не верно хотя бы с точки зрения формальной логики. Доказать такое утверждение будет сложно, а опровергнуть — легко.

                                                                  В качестве доказательства — при наличии времени t со стимулом s, вы получаете некую работу txs, которую можете потратить на развитие. При равномерном распределении векторов развития, каждое ваше знание будет увеличиваться на txs/n, где n — это количество этих самых векторов. Следовательно, чем меньше n у человека с таким же стимулов и количеством времени, как у вас, тем больше он сумеет узнать в каждой конкретной области.

                                                                  Естественно, есть куча предпосылок, в которых всё становится совершенно не так. Например, если вы fullstack javascript разработчик, то с очевидностью вы будете знать javascript лучше, чем узкий frontend разработчик. Но именно потому, что на самом деле ваше n меньше, чем у него, и у вас главенствует именно вектор javascript, на который вы тратите основное время.
                                                                  Не следует воспринимать всю статью дословно — она рассчитана на некоторую внутреннюю обработку и адаптацию в конкретной ситуации, и может в итоге вам принести совершенно разные выводы. Конечно, можно было бы везде поставить сноски "скорее всего", "вероятно" и "обычно", но после этого текст стал бы совершенно ужасен.

                                                                  Никто не пишет оптимальный код всегда.

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

                                                                  В общем, по всем остальным пунктам то же самое — не надо воспринимать статью как утверждение про абсолютные истины, надо просто подумать над указанными пунктами и тем, что они для вас значат.
                                                                    –1
                                                                    при наличии времени t со стимулом s, вы получаете некую работу txs, которую можете потратить на развитие.

                                                                    Ну вот. Т.е. мы считаем, что все люди одинаковые? Или мы считаем, что один и тот же человек одинаково хорошо развивается как в одной области так и в другой? Это ваши исходные?

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

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

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

                                                                    Ведь что такое "оптимальный код"? Я считаю, что это код который позволяет максимизировать прибыль и минимизировать издержки. Или если обращаться к классике, то по Альтшуллеру: "Идеальная техническая система — это система, которой нет, а ее функции выполняются, то есть цели достигаются без средств.".
                                                                  +2
                                                                  Надо разделять два вида "фуллстек-разработчиков":

                                                                  1. Кто очень хорошо знает что-то одно (фронт-енд, например) и в принципе может заниматься остальным (например, есть прошлый опыт, представляет что как устроено на сервере, в базе данных, знает используемые алготирмы и протоколы). Это одно, и такой человек ценен, и получать будет больше чем фронтенд, который ничего о сервере не знает и знать не хочет в принципе.
                                                                  2. Те кто знают кое-что обо всём и работают "как-то так". По-старому, вебмастер: дали ему сайт, он за ним ухаживает, поддерживает, и скрипты пишет (хреновые, глючные, страшные, но в целом рабочие), и за базой следит, и бэкенд пилит, отлаживая "print 1" прямо на продакшене. Это совсем другое, в стартапе, веб-студиях оно надо, но вобщем стоит недорого, уважается мало, а иногда ещё и столы носить придётся, ну или сеть протянуть.
                                                                    0
                                                                    На втором пункте чуть не заплакал, как всё знакомо… Просто вся жизнь перед глазами.
                                                                    +1
                                                                    Ассемблер в стек нонче входит?
                                                                      0
                                                                      В какой-то стек наверняка входит. Стек — это всего лишь некий набор технологий со смысловым обобщением. Например, если вы разрабатываете классические микроконтроллеры, то в ваш стек будет входить ассемблер, умение паять, знание электротехники и возможно умение пить водку с дворником Петровичем, который занимается сваркой деталей для вашего робота.
                                                                      +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.

                                                                        +1
                                                                        Поддерживаю мнение о том, что full stack разработчик для сложных проектов менее эффективен https://habrahabr.ru/post/275333/
                                                                          +2
                                                                          Верно, но по факту в практике если фулстек это некий самостоятельный боец в поле — доля несложных проектов ~90% на рынке и все они поддаются фуллстеку.
                                                                            0
                                                                            Ага, для простых проектов, которых большинство, full stack будет лучше.
                                                                            0
                                                                            Ведь вы же читали мифический человеко-месяц? http://www.amazon.com/The-Mythical-Man-Month-Engineering-Anniversary/dp/0201835959
                                                                          0
                                                                          По непонятной мне причине, часто ищут разработчика, который в совершенстве умеет применить что-то, что вышло в релиз полгода назад.

                                                                          Как по мне, нормальный разработчик(любой) должен заглядывать далеко вперед и играться с альфа/бета версиями продуктов, до такой степени, что к моменту релиза новой технологии или фреймворка — он уже все это знает. Считаю очень хорошей чертой, когда разработчик не просто умеет что-то писать а еще и имеет широкий кругозор в плане технологий. Это здорово, когда разработчик активно интересуется всем вокруг своей деятельности и любит экспериментировать с чем-то новым.
                                                                            +3
                                                                            Здесь надо хорошо понимать один нюанс. Знать о нововведениях и примерно понимать, чем они хороши — это одно.
                                                                            А попробовать их и суметь быстро и корректно ввести в продакшн — уже другое.
                                                                            При широком спектре технологий успеваешь прочитаешь все интересные статьи и новости и получить представление — но погонять вживую часто не удаётся.
                                                                              +2
                                                                              должен заглядывать далеко вперед и играться с альфа/бета версиями продуктов
                                                                              Это только если разработчик очень молод, и ему некуда девать время. Разработчики помудрее стараются быть в курсе событий, но глубокое изучение конкретной технологии откладывают на момент, когда/если она реально потребуется на практике. ;-)
                                                                              0
                                                                              Спасибо за статью, концовка особа порадовала))
                                                                              • НЛО прилетело и опубликовало эту надпись здесь
                                                                                  0
                                                                                  Верно подмечено, что full stack разработчик нужен на начальной стадии проекта или стартапа, но позднее, когда есть более-менее стабильный продукт/система, он должен быть вытеснен специалистами. Это необходимо для нормального развития проекта / стартапа.
                                                                                  Или full stack переключается на создание следующей версии, как вариант.

                                                                                  Ещё пример полезности full stack разработчика — R&D, когда навыки jack of all trades полезны. Правда необходим перекос в основную область деятельности, что даёт уже среднее между full stack и specialist.
                                                                                  • НЛО прилетело и опубликовало эту надпись здесь
                                                                                  0
                                                                                  Например, чтобы наладить взаимоотношения с девушкой (для примера назовём её Катей).

                                                                                  Вот этот кусок просто высадил в астрал :D Спасибо за статью.
                                                                                    0
                                                                                    • если сам разбираешься во многом — проще сделать стартап.
                                                                                      +1
                                                                                      Только стартап кроме развертывания сервера, проектирования базы данных, бекенда, фронтенда, хранилищ, бекапов, бутстрапа и вордпресса обычно требует еще дизайна, проектирования интерфейса, создания презентаций, разговорного и письменного английского, заключение договоров с платежными системами и бог знает чего еще. Причем, практика показывает — что чаще всего не-разработки там гораздо больше и от нее зависит гораздо больше.
                                                                                      0
                                                                                      Все это очень знакомо:) солидарен с автором. Наличие широкого стека знаний и технологий является большим плюсом, если ты собственник айтишного бизнеса.
                                                                                        +1
                                                                                        Когда ты 14 лет в професси, очень странно, когда ты не full stack. Такие технологии как gulp или sass на базовом уровне учатся за выходные например.

                                                                                        Full stack во что угодно может превратиться. За всеми тенденциями конечно уследить нельзя, но когда попадаешь в команду, все равно начинаешь заниматься преимущественно каким-то направлением, за 1-2 месяца подтянешься до узкого спеца.
                                                                                          +1
                                                                                          Джуниором пошел в фирму, где был full stack. Не жалею. Попробовал одно, другое, третье. Нащупал, чем нравится заниматься больше всего. И пошел в итоге узким специалистом.

                                                                                          Имхо, джуниору лучше пойти именно на full stack (хотя бы бекенд + фронтенд по обязанностями, 50 на 50). Как поймешь, чем хочешь заниматься, не попробовав в бою все эти технологии?
                                                                                            +1
                                                                                            Очень много "очевидно", когда это во-1х не очевидно, во-2х еще и не так.
                                                                                            Особенно, забывая о очень важном (опять же упущенном моменте), про "при прочих равных".

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

                                                                                            К тому же, помнить, учитывать, скрещивать, искать параллели, применять решение не типичное для области, но крайне необходимое здесь и сейчас — это тоже специализация.
                                                                                            Кросс-системная оптимизация глубоко зарытым дотнетером/явером без фулстекера рядом так же лажает, как и ассемблерная оптимизация узкого места ПХПшником
                                                                                              0
                                                                                              Прекрасная статья! Роскошь!
                                                                                                0
                                                                                                Аж всплакнул, когда прочитал статью о моих суровых буднях =)

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

                                                                                                Самое читаемое