Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 93
как то про full-stack javascript вообще не упомянули — а ведь бывает уже full stack в одной технологии. но вообще статья веселая, а “О, дайте ему — он разберётся!” это вообще очень жизненно :)
Full stack в одой технологии действительно уже бывает, но я намеренно старался абстрагироваться от любой конкретики, чтобы у каждого был шанс себя узнать.
бывает наверно уже, но это IMHO таки не full stack, а так, нюансы.
full stack — это когда я админю Oracle, MSSQL, программлю параллельно C#, JS, мультиплатформенный C++, и под конец пихаю все в MSI/WiX/InstallShield, и это все — два параллельных проекта. И нифига не стартап, а обычная мультинациональная корпорация с 150+ летней историей в которой ты винтик и где экономят на всем.
full stack — это когда я админю Oracle, MSSQL, программлю параллельно C#, JS, мультиплатформенный C++, и под конец пихаю все в MSI/WiX/InstallShield, и это все — два параллельных проекта. И нифига не стартап, а обычная мультинациональная корпорация с 150+ летней историей в которой ты винтик и где экономят на всем.
И лампочки в коридоре менять. Боюсь, то что вы перечислили называется "И швец, и жнец, и на дуде игрец". Везде может пристроиться как-то...
full stack — это когда некий разработчик способен в одиночку спроектировать и реализовать все уровни некоей многоуровневой системы. К примеру если говорить о Java-WEB, то он знает принципы проектирования БД, способен это сделать и умеет писать SQL запросы и использовать JDBC/ORM. Затем он знает Spring и как хранится бизнес логика. Владеет неким фреймворком, на котором генерируется клиент (скажем Wicket или JSF). Ну и наконец способен программировать самого клиента. Приемлемо знает HTML, CSS, Javascript, jQuery, Bootstrap. И всё это на пристойном уровне понимания, что бы имея под рукой интернет как справочник, можно было реализовать проект достаточно профессионально.
Сам факт скакания с языка на язык и способность что-то там на нём написать — ещё не делает человека full stack разработчиком.
full stack — это когда некий разработчик способен в одиночку спроектировать и реализовать все уровни некоей многоуровневой системы. К примеру если говорить о Java-WEB, то он знает принципы проектирования БД, способен это сделать и умеет писать SQL запросы и использовать JDBC/ORM. Затем он знает Spring и как хранится бизнес логика. Владеет неким фреймворком, на котором генерируется клиент (скажем Wicket или JSF). Ну и наконец способен программировать самого клиента. Приемлемо знает HTML, CSS, Javascript, jQuery, Bootstrap. И всё это на пристойном уровне понимания, что бы имея под рукой интернет как справочник, можно было реализовать проект достаточно профессионально.
Сам факт скакания с языка на язык и способность что-то там на нём написать — ещё не делает человека full stack разработчиком.
Даже в таком случае есть специализация. Есть общие и необходимые знания, которые должны быть на приемлемом уровне.
А то, что указали Вы — это, по-моему, backend программист, явно не джуниор, который может писать frontend, если задача не особо сложная или если основные frontend разработчики заняты и их не хочется дергать ради "добавить пару текстовых полей, их валидацию и кнопку для отправки всего этого на сервер."
Тем более, что сейчасдля всех языков программирования есть фреймворки, которые позволяют из коробки, без особого знания тонкостей языка и фреймворка, на коленке, по мануалу и с гуглом собрать "прототипчик".
А то, что указали Вы — это, по-моему, backend программист, явно не джуниор, который может писать frontend, если задача не особо сложная или если основные frontend разработчики заняты и их не хочется дергать ради "добавить пару текстовых полей, их валидацию и кнопку для отправки всего этого на сервер."
Сам факт скакания с языка на язык и способность что-то там на нём написать — ещё не делает человека full stack разработчиком.
Тем более, что сейчасдля всех языков программирования есть фреймворки, которые позволяют из коробки, без особого знания тонкостей языка и фреймворка, на коленке, по мануалу и с гуглом собрать "прототипчик".
Приемлимое понимание механики хорошего, мощного фреймворка — требует времени. И понимания технологий/протоколов за ним стоящих. На коленке по мануалу вы сделаете студенческую поделку для курсача.
Там выше описан я, но я ещё при необходимости и питон могу, и хаскель. Могу развернуть систему, могу построить отказоустойчивую систему и настроить автоматическое разворачивание её — и всё это будет чуть хуже работать, чем у узких специалистов в каждой области.
Сложно сказать. Я по специализации прикладной математик ) Всегда относил себя к универсальным солдатам, наверное теперь знаю как они называются. Статья точно отражает смысл того что приходится делать. Попробую написать то что я делал в течении года.
Так сложилось меня занесло в биоинформатики более четырех лет назад, т.е. как минимум мне пришлось начать понимать азы биологии (необходимые для работы). Все термины гуглятся. Дык вот за последний год я:
И это какая-то часть она не передает всех задач которые выполняешь. И главное, что мне нравится больше всего, что скучать не приходится. Основная проблема — поговорить почти не с кем. Единицы умеют вникать в детали технологий и связывать одни технологии с другими делая этот симбиоз продуктивным.
Иногда правда грусть накатывает, редко но бывает, хочется просто хорошо программировать на C++.
Так сложилось меня занесло в биоинформатики более четырех лет назад, т.е. как минимум мне пришлось начать понимать азы биологии (необходимые для работы). Все термины гуглятся. Дык вот за последний год я:
- Написал дополнительный функционал к 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++.
не, лампочки нельзя, это заоутсосено, тут же у нас не просто так, а корпорация.
А "способен в одиночку спроектировать и реализовать все уровни некоей многоуровневой системы" не работает, потому что такие системы требуют затрат не в человеко-месяцы, а часто многие человеко-годы и в одиночку их совершенно нереально разработать каким бы суперменом ты не был, но зато с одной стороны есть плюсы в том что можно попилить эту систему на разных углах, с другой — тебе придется ее пилить на разных углах, так как за время разработки или тебя перекинут или другие будут болеть, уйдут в отпуск, уйдут вообще...
А "способен в одиночку спроектировать и реализовать все уровни некоей многоуровневой системы" не работает, потому что такие системы требуют затрат не в человеко-месяцы, а часто многие человеко-годы и в одиночку их совершенно нереально разработать каким бы суперменом ты не был, но зато с одной стороны есть плюсы в том что можно попилить эту систему на разных углах, с другой — тебе придется ее пилить на разных углах, так как за время разработки или тебя перекинут или другие будут болеть, уйдут в отпуск, уйдут вообще...
Это какой-то исключительный случай, по-моему.
Устаревание ведь проходит не мгновенно. И вытесняющие технологии обычно изучать не так трудно, они похожи. По-моему, большинство Swing Java разработчиков вполне комфортно себя будут чувствовать, используя Vaadin. В крайнем случае применить полученные за годы работы со Swing знания в UX во front-end разработке на JS с каким-нибудь модным фреймворком, если серверное программирование "не его".
Единственная проблема — это поиск работы без коммерческого опыта в конкретной технологии, но и это решается.
Устаревание ведь проходит не мгновенно. И вытесняющие технологии обычно изучать не так трудно, они похожи. По-моему, большинство Swing Java разработчиков вполне комфортно себя будут чувствовать, используя Vaadin. В крайнем случае применить полученные за годы работы со Swing знания в UX во front-end разработке на JS с каким-нибудь модным фреймворком, если серверное программирование "не его".
Единственная проблема — это поиск работы без коммерческого опыта в конкретной технологии, но и это решается.
Про то, что ораклоид долго ищет работу — это странно. У меня вот в резюме разработчика написано про сертификацию в качестве Oracle DBA — звонят постоянно и обещают горы золота. Может, у вашего знакомого что-то не так с резюме? Попробуйте показать его знакомому HR'у. Резюме, не знакомого.
Full-stack разработчики — мастхев для стартапов почти на любом этапе развития. Это в том числе касается пункта "Вас сложно заменить" — если есть несколько универсалов, они неплохо друг друга дополняют и заменяют.
Да, упустил как-то из виду этот хороший вариант решения проблемы замены. Правда, обычно универсалов довольно мало. Хотя не знаю ситуации со стартапами.
Для стартапов или маленьких команд полезны, но если есть пара фулстеков, то в конечном итоге все равно разделят между собой и станут заниматься чем-то одним.
А почему сложнее искать подходящую вакансию? Обычно так и пишут "full stack". На всякий можно ещё и "fullstack".
Уточню, возможно было не совсем понятно из статьи. Те, кто ищут fullstack в явном виде — часто хотят взять одного человека на три вакансии, и чтобы он ещё вечерами мусор выносил. Да и немного вакансий — сейчас по Москве на хедхантере к примеру только 8 штук.
Зачастую гораздо интереснее искать вакансии по каким-то другим конкретным ключевикам.
Зачастую гораздо интереснее искать вакансии по каким-то другим конкретным ключевикам.
Можно еще добавить «Многостаночник»
Плюсы как-то притянуты за уши
вот да, после 10+ лет опыта работы full stack в корпорации из этих плюсов есть только одно — тебя сложнее уволить и проще пихнуть в другой проект, все остальное — только "чуство глубокого удовлетворения" и плюсы для начальства, опять же только потому что тебя моугт пихнуть в любой проект, не особо интерсуясь мнением.
А объясните почему "тебя сложнее уволить". На мой взгляд как раз узкий специалист в гораздо большей степени незаменим. По аналогии с постройкой моста: да, он занимается лишь одной единственной опорой, а про другие части вообще ничего не знает. Только вот больше никто конкретно эту опору делать не умеет. А без нее рухнет уже весь мост.
Иными словами: узкий специалист является незаменимым в своей области. Широкий же не является незаменимым ни в одной из своих областей.
*незаменимый — тяжело, долго, дорого
Иными словами: узкий специалист является незаменимым в своей области. Широкий же не является незаменимым ни в одной из своих областей.
*незаменимый — тяжело, долго, дорого
Узкого специалиста легко заменить — так как заменяется стандартная деталь в любом конструкторе. Если его заменить быстро, то никто ничего даже не заметит. А широкий является нестандартной деталью, которую в лучшем случае можно заменить несколькими другими.
Если специалист работает только с определённой технологией и давно, то он отличный специалист и потерять его обидно, но почти всегда можно найти менее опытного специалиста.
А вот если человек знает несколько технологий, которые встречаются вместе только в вашем проекте, то даже найти человека со знанием именно этих технологий уже вопрос сложный.
А вот если человек знает несколько технологий, которые встречаются вместе только в вашем проекте, то даже найти человека со знанием именно этих технологий уже вопрос сложный.
я сужу по той же индустрии / корпорациям. Узкий специалист: проект похерили и девать его особо некуда, надо увольнять или переучивать или ткнуть куда-нить на минимальную занятость. Широкий специалист — можно ткнуть куда угодно, особенно если профсоюз еще вмешается и скажет что "вон там а увас люди ищутся, ну почти такого же профиля".
Плюсы на основе опыта работы в корпорации и вообще разных фирмах
Вы можете выбирать, кем работать дальше
Тебя могут и пошлют работать в произвольный проект
Вы меньше выгораете
Тебя могут и пошлют работать в произвольный проект в произвольный момент времени
Вам проще расти в тимлида или архитектора
"он не знает ничего абсолютно идеально, куда ему в начальники"
Вы можете отдебажить всё, что угодно
Ты можешь и будешь дебажить код других, паралелльно к своей работе
Работать веселее, интереснее и познавательнее
При этом твое желание мало кто спрашивает, можешь же ?
В одиночку вы можете создавать чудесные вещи на стыке разных технологий
Задачи будут ставится "ну ты сделай там это все, вот это, красиво, ну ты ж можешь"
Ваши решения работают быстрее и надёжнее
это мало кого волнует, но для себя да, часто приносит удовлетворение
Вы можете пользоваться почти любыми исходниками
Тебе придется пользоваться любыми исходниками, например у меня сейчас есть с датами от 1989 до 2016, в одном проекте
Вы постигаете дзен
Это завсегда ...
Вы можете выбирать, кем работать дальше
Тебя могут и пошлют работать в произвольный проект
Вы меньше выгораете
Тебя могут и пошлют работать в произвольный проект в произвольный момент времени
Вам проще расти в тимлида или архитектора
"он не знает ничего абсолютно идеально, куда ему в начальники"
Вы можете отдебажить всё, что угодно
Ты можешь и будешь дебажить код других, паралелльно к своей работе
Работать веселее, интереснее и познавательнее
При этом твое желание мало кто спрашивает, можешь же ?
В одиночку вы можете создавать чудесные вещи на стыке разных технологий
Задачи будут ставится "ну ты сделай там это все, вот это, красиво, ну ты ж можешь"
Ваши решения работают быстрее и надёжнее
это мало кого волнует, но для себя да, часто приносит удовлетворение
Вы можете пользоваться почти любыми исходниками
Тебе придется пользоваться любыми исходниками, например у меня сейчас есть с датами от 1989 до 2016, в одном проекте
Вы постигаете дзен
Это завсегда ...
Соответственно, надо выбирать — на кого и с кем работать. Испытательные сроки даются не только для разработчика, но и для компании(проекта). Практически все здесь перечисленное — результат не грамотного менеджмента. Обычно такого человека теряют, в последствии (как вариант) вместе с проектом. Однако, НЕТ сказать сложно, здесь я согласен. НО пойдет на благо.
Тебя могут и пошлют работать в произвольный проект
Так с любыми разработчиками, просто у full-stack разработчика выбор больше.
«он не знает ничего абсолютно идеально, куда ему в начальники»
Так это же идеальный начальник. А позиция "архитектор" как по мне вообще пережиток 90-х, архитектура должна строиться всей командой а не одним человеком.
При этом твое желание мало кто спрашивает, можешь же ?
Потому возвращаемся к предыдущему пункту, растем в начальники, делигируем свою работу, делаем то что нравится.
это мало кого волнует, но для себя да, часто приносит удовлетворение
Вот тут весьма странно. Если компания или клиенты не заинтересованы в "скорости и надежности" — то причем тут full-stack?
Тебе придется пользоваться любыми исходниками, например у меня сейчас есть с датами от 1989 до 2016, в одном проекте
Эта проблема преследует не только full-stack разработчиков.
Если бы программист был тварью дрожащей — то эти замечания были бы очень к месту. Когда меня пытались пристроить делать то, что я могу, но не хочу, я говорил "да, могу — но будет медленно и плохо, делать?" и сразу отставали. С тех пор программисты стали даже большей "элитой среднего звена", или как это назвать.
"да, могу — но будет медленно и плохо, делать?" — а в чем разница с тварью дрожжащей ?
Для меня б была разница — "я хочу заниматься вот той темй, эту углУбить, и вот этим проектом, ну, я пошел туда ?" и мне в ответ "о, проявляешь инициативу, молодец, идина тебе еще денег"
Но такое обычно надо выморачивать долго, нудно и с неопределенным результатом.
Для меня б была разница — "я хочу заниматься вот той темй, эту углУбить, и вот этим проектом, ну, я пошел туда ?" и мне в ответ "о, проявляешь инициативу, молодец, иди
Но такое обычно надо выморачивать долго, нудно и с неопределенным результатом.
Прошу прощения, Вы не рабом были случайно?
что значит был, и являюсь, с подводной лодки обычно только один путь — за борт
Стандартный ответ начальства — фирма большая, незаменимых нет, тебя тут никто не держит
Стандартный ответ начальства — фирма большая, незаменимых нет, тебя тут никто не держит
Плюсы не притянуты за уши, а скорее индивидуальны, и в общем всё сводится к тому, хочется ли уметь делать разное, или хочется развиваться и заниматься только одним направлением.
Дзен можно постичь если просто интересоваться программированием как таковым, не нужно для этого быть fullstack'ом. А дзен по жизни искать уж явно нужно с другого края начинать.
Вы пролетите свежим бризом над граблями, которые до вас собрали тысячи других разработчиков.
Спасибо, посмеялся)) Или же "Вы с размаху пробежитесь по всем граблям расставленными вам другими разработчиками" :))
Не, мне и правда речевой оборот понравился. Второе предложение уже собственная боль))
Бегать по оставленным граблям — это само собой разумеется. Но если делать с нуля, то велика вероятность на все эти грабли наступить заново.
А так — есть возможность брать популярные репозитории, помогать в их исправлении и ещё и нахаляву получать исправление незамеченных грабель. Конечно, новые грабли тоже будут вылезать — но в этом весь процесс разработки.
А так — есть возможность брать популярные репозитории, помогать в их исправлении и ещё и нахаляву получать исправление незамеченных грабель. Конечно, новые грабли тоже будут вылезать — но в этом весь процесс разработки.
Ещё один плюс можно добавить, вытекающий из:
+++ "При наличии видения потребностей мира вы способны сами проектировать и создавать коммерчески востребованные продукты".
В одиночку вы можете создавать чудесные вещи на стыке разных технологий
+++ "При наличии видения потребностей мира вы способны сами проектировать и создавать коммерчески востребованные продукты".
+++ «При наличии видения потребностей мира вы способны сами проектировать и создавать коммерчески востребованные продукты».
Но, к сожалению, конкуренты с бóльшим количеством людей всегда будут на шаг впереди.
Зато сколько можно придумать забавных, но со смыслом, опечаток: full-stuck, fool-stack, full-suck и т.п.
Просто раздолье для HR-тролля.
Просто раздолье для HR-тролля.
Подтверждаю, всё очень правильно написано.
Сам я веб-разработчик, на нормальном уровне умею в дизайн, фронтенд, бэкенд, контент (плюс, всё сопутствующее, что нужно для жизни: управление проектами, финансы, бухгалтерия). Это интересно, но нужно только если ты принципиально хочешь всё сам. Ну или как платформа для старта своей компании (хотя, всё равно ничего не гарантируется).
Если говорить об эффективности, то на комплексных задачах объемом до человеко-месяца команды специалистов не выдерживают никакой конкуренции против такого универсального человека. Никаких потерь на коммуникацию, на передачу работы к следующему этапу, плюс, с заказчиком компетентно и грамотно общается конечный исполнитель и всё такое. Но в каждом конкретном деле ты проигрываешь в глубине знаний.
Так я про себя и пишу — дилетант широкого профиля.
Сам я веб-разработчик, на нормальном уровне умею в дизайн, фронтенд, бэкенд, контент (плюс, всё сопутствующее, что нужно для жизни: управление проектами, финансы, бухгалтерия). Это интересно, но нужно только если ты принципиально хочешь всё сам. Ну или как платформа для старта своей компании (хотя, всё равно ничего не гарантируется).
Если говорить об эффективности, то на комплексных задачах объемом до человеко-месяца команды специалистов не выдерживают никакой конкуренции против такого универсального человека. Никаких потерь на коммуникацию, на передачу работы к следующему этапу, плюс, с заказчиком компетентно и грамотно общается конечный исполнитель и всё такое. Но в каждом конкретном деле ты проигрываешь в глубине знаний.
Так я про себя и пишу — дилетант широкого профиля.
У меня вот стек начинается где-то с разработки электронных устройств.
Описанное очень похоже на происходящее.
Только у меня есть чувство, что мультиинструменталисты не особо-то и нужны. Особенно если они не выросли в лидов+
Описанное очень похоже на происходящее.
Только у меня есть чувство, что мультиинструменталисты не особо-то и нужны. Особенно если они не выросли в лидов+
В каждой отдельной области вы хуже, чем узкий специалист
Ну это утверждение не верно хотя бы с точки зрения формальной логики. Доказать такое утверждение будет сложно, а опровергнуть — легко. Думается, что вы начали с ложной предпосылки.
Вам сложнее продвигаться глубже
Собственно почему? Специалист широкого профиля может начать специализироваться в узком, обратное сделать, как мне кажется сложнее. (легче двигаться от общего к частному, чем наоборот).
У вас больше вероятность перегрузки задачами
Не очень понятен ваш способ подсчета вероятности в данном случае. Я думаю, что time-management навыки влияют на профессиональные навыки несколько иначе. Как вам вариант того, что специалист широкого профиля потому и имеет более широкий профиль, что эффективнее управляет своим временем и успевает узнать больше? Ну это как один из сценариев. Мне кажется вы опять начали с ложной предпосылки.
Вас сложно заменить
Узкого специалиста заменить всегда сложнее. Ну а в целом то, что кажется нерешаемым на одном уровне принятия решений — вообще не является проблемой уровнем чуть выше. Я хочу сказать, что не очень-то рассчитывайте на незаменимость.
У вас нет чёткой зоны ответственности
Есть. Такая же как у всех — это продукт и в конечном итоге прибыль. Все остальное — это мелочь и офиснопланктонные игры.
Вы не всегда пишете оптимальный код
Никто не пишет оптимальный код всегда.
Вам не верят
Странный момент. Если речь идет о резюме, то количество технологий не является чем-то определяющем (по крайней мере когда я собеседую людей). Если вы написали через запятую 5 или 10 ключевых слов — это одинаково малодостоверная информация для меня. Если вы написали ДЛЯ ЧЕГО и в каком проекте вы использовали технологию, то опять же сколько ключевых слов вы написали — не важно.
Если речь идет о собеседовании — дык все же легко проверяется. Надо только дать человеку расскрыться во всем своем великолепии.
Вы можете начать завидовать зарплате узких специалистов
Это точно. Но и узкие специалисты могут начать завидовать вашей.
А вот с плюсами я пожалуй больше соглашусь.
Вообще, узкий специалист требует дополнительное организационное звено — архитектора или тимлида для разработки сложного продукта. А это усложняет саму организацию, а значит снижает ее эффективность. Если же специалист может спрятать часть сложности системы внутри себя — то в целом организация будет более эффективной, т.к. меньше управленческих или организационных звеньев нужно для получения продукта.
Ну это утверждение не верно хотя бы с точки зрения формальной логики. Доказать такое утверждение будет сложно, а опровергнуть — легко.
В качестве доказательства — при наличии времени t со стимулом s, вы получаете некую работу txs, которую можете потратить на развитие. При равномерном распределении векторов развития, каждое ваше знание будет увеличиваться на txs/n, где n — это количество этих самых векторов. Следовательно, чем меньше n у человека с таким же стимулов и количеством времени, как у вас, тем больше он сумеет узнать в каждой конкретной области.
Естественно, есть куча предпосылок, в которых всё становится совершенно не так. Например, если вы fullstack javascript разработчик, то с очевидностью вы будете знать javascript лучше, чем узкий frontend разработчик. Но именно потому, что на самом деле ваше n меньше, чем у него, и у вас главенствует именно вектор javascript, на который вы тратите основное время.
Не следует воспринимать всю статью дословно — она рассчитана на некоторую внутреннюю обработку и адаптацию в конкретной ситуации, и может в итоге вам принести совершенно разные выводы. Конечно, можно было бы везде поставить сноски "скорее всего", "вероятно" и "обычно", но после этого текст стал бы совершенно ужасен.
Никто не пишет оптимальный код всегда.
Конечно же! Но речь шла о том, что у хорошего узкого специалиста больше шансов написать оптимальный код, чем у fullstack.
В общем, по всем остальным пунктам то же самое — не надо воспринимать статью как утверждение про абсолютные истины, надо просто подумать над указанными пунктами и тем, что они для вас значат.
при наличии времени t со стимулом s, вы получаете некую работу txs, которую можете потратить на развитие.
Ну вот. Т.е. мы считаем, что все люди одинаковые? Или мы считаем, что один и тот же человек одинаково хорошо развивается как в одной области так и в другой? Это ваши исходные?
Конечно же! Но речь шла о том, что у хорошего узкого специалиста больше шансов написать оптимальный код, чем у fullstack.
Не понятно откуда вы это взяли. Например как вам такой вариант: человек с широким кругозором может применять техники из смежных областей, в то время как человек с узкой специализацией будет выдавать одни и те же типовые решения, даже тогда, когда они не подходят.
И в конечном итоге то, кто из них напишет более качественный код зависит от кучи факторов. Например умение прогнозировать (написал и оказалось, что угадал с тем как система будет развиваться далее и не надо рефакторить лишний раз) — а тут опять же перевес на стороне того, кто лучше видит всю картинку целиком.
Специалист широкого профиля имеет более полное представление о системе, следовательно имеет больший горизонт планирования и значит решения такого специалиста стратегически более верные.
Ведь что такое "оптимальный код"? Я считаю, что это код который позволяет максимизировать прибыль и минимизировать издержки. Или если обращаться к классике, то по Альтшуллеру: "Идеальная техническая система — это система, которой нет, а ее функции выполняются, то есть цели достигаются без средств.".
Ассемблер в стек нонче входит?
В какой-то стек наверняка входит. Стек — это всего лишь некий набор технологий со смысловым обобщением. Например, если вы разрабатываете классические микроконтроллеры, то в ваш стек будет входить ассемблер, умение паять, знание электротехники и возможно умение пить водку с дворником Петровичем, который занимается сваркой деталей для вашего робота.
Главное — чтоб не 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.
Поддерживаю мнение о том, что full stack разработчик для сложных проектов менее эффективен https://habrahabr.ru/post/275333/
Верно, но по факту в практике если фулстек это некий самостоятельный боец в поле — доля несложных проектов ~90% на рынке и все они поддаются фуллстеку.
Ведь вы же читали мифический человеко-месяц? http://www.amazon.com/The-Mythical-Man-Month-Engineering-Anniversary/dp/0201835959
По непонятной мне причине, часто ищут разработчика, который в совершенстве умеет применить что-то, что вышло в релиз полгода назад.
Как по мне, нормальный разработчик(любой) должен заглядывать далеко вперед и играться с альфа/бета версиями продуктов, до такой степени, что к моменту релиза новой технологии или фреймворка — он уже все это знает. Считаю очень хорошей чертой, когда разработчик не просто умеет что-то писать а еще и имеет широкий кругозор в плане технологий. Это здорово, когда разработчик активно интересуется всем вокруг своей деятельности и любит экспериментировать с чем-то новым.
Здесь надо хорошо понимать один нюанс. Знать о нововведениях и примерно понимать, чем они хороши — это одно.
А попробовать их и суметь быстро и корректно ввести в продакшн — уже другое.
При широком спектре технологий успеваешь прочитаешь все интересные статьи и новости и получить представление — но погонять вживую часто не удаётся.
А попробовать их и суметь быстро и корректно ввести в продакшн — уже другое.
При широком спектре технологий успеваешь прочитаешь все интересные статьи и новости и получить представление — но погонять вживую часто не удаётся.
должен заглядывать далеко вперед и играться с альфа/бета версиями продуктовЭто только если разработчик очень молод, и ему некуда девать время. Разработчики помудрее стараются быть в курсе событий, но глубокое изучение конкретной технологии откладывают на момент, когда/если она реально потребуется на практике. ;-)
Спасибо за статью, концовка особа порадовала))
Верно подмечено, что full stack разработчик нужен на начальной стадии проекта или стартапа, но позднее, когда есть более-менее стабильный продукт/система, он должен быть вытеснен специалистами. Это необходимо для нормального развития проекта / стартапа.Или full stack переключается на создание следующей версии, как вариант.
Ещё пример полезности full stack разработчика — R&D, когда навыки jack of all trades полезны. Правда необходим перекос в основную область деятельности, что даёт уже среднее между full stack и specialist.
- если сам разбираешься во многом — проще сделать стартап.
Только стартап кроме развертывания сервера, проектирования базы данных, бекенда, фронтенда, хранилищ, бекапов, бутстрапа и вордпресса обычно требует еще дизайна, проектирования интерфейса, создания презентаций, разговорного и письменного английского, заключение договоров с платежными системами и бог знает чего еще. Причем, практика показывает — что чаще всего не-разработки там гораздо больше и от нее зависит гораздо больше.
Все это очень знакомо:) солидарен с автором. Наличие широкого стека знаний и технологий является большим плюсом, если ты собственник айтишного бизнеса.
Когда ты 14 лет в професси, очень странно, когда ты не full stack. Такие технологии как gulp или sass на базовом уровне учатся за выходные например.
Full stack во что угодно может превратиться. За всеми тенденциями конечно уследить нельзя, но когда попадаешь в команду, все равно начинаешь заниматься преимущественно каким-то направлением, за 1-2 месяца подтянешься до узкого спеца.
Full stack во что угодно может превратиться. За всеми тенденциями конечно уследить нельзя, но когда попадаешь в команду, все равно начинаешь заниматься преимущественно каким-то направлением, за 1-2 месяца подтянешься до узкого спеца.
Джуниором пошел в фирму, где был full stack. Не жалею. Попробовал одно, другое, третье. Нащупал, чем нравится заниматься больше всего. И пошел в итоге узким специалистом.
Имхо, джуниору лучше пойти именно на full stack (хотя бы бекенд + фронтенд по обязанностями, 50 на 50). Как поймешь, чем хочешь заниматься, не попробовав в бою все эти технологии?
Имхо, джуниору лучше пойти именно на full stack (хотя бы бекенд + фронтенд по обязанностями, 50 на 50). Как поймешь, чем хочешь заниматься, не попробовав в бою все эти технологии?
Очень много "очевидно", когда это во-1х не очевидно, во-2х еще и не так.
Особенно, забывая о очень важном (опять же упущенном моменте), про "при прочих равных".
Full-stack разработчики не такие же люди, как узкие специалисты. Именно за счет своих отличий они и пошли в узкую специализацию широкого профиля.
К тому же, помнить, учитывать, скрещивать, искать параллели, применять решение не типичное для области, но крайне необходимое здесь и сейчас — это тоже специализация.
Кросс-системная оптимизация глубоко зарытым дотнетером/явером без фулстекера рядом так же лажает, как и ассемблерная оптимизация узкого места ПХПшником
Особенно, забывая о очень важном (опять же упущенном моменте), про "при прочих равных".
Full-stack разработчики не такие же люди, как узкие специалисты. Именно за счет своих отличий они и пошли в узкую специализацию широкого профиля.
К тому же, помнить, учитывать, скрещивать, искать параллели, применять решение не типичное для области, но крайне необходимое здесь и сейчас — это тоже специализация.
Кросс-системная оптимизация глубоко зарытым дотнетером/явером без фулстекера рядом так же лажает, как и ассемблерная оптимизация узкого места ПХПшником
Прекрасная статья! Роскошь!
Аж всплакнул, когда прочитал статью о моих суровых буднях =)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Чем плохо быть full stack разработчиком