Comments 43
Прошло уже пол часа, и где срач? Обман, кругом обман… а может это заклинание такое эффективное?
А я во много согласен с автором. Возможно потому что сам Full stack :)
Ага, все мы немного фулстек… И штраф двойного класса на максимальный уровень в игре тоже присутствует.
опять какие-то границы… почему я как фулстек обязательно должен быть хуже узкоспециализированного специалиста? Языки развиваются довольно медленно, фреймворки на них быстрее, но все равно апдейты выходят в лучшем случае раз в полгода. Сколько нужно потратить времени на изучение языка, чтобы пользоваться им на уровне синьора?
тут скорее не тот факт, что не можем, а тот что из-за объемов смежных знаний просто всего не успеть изучить, вот и получается что некоторые детали можно успеть только по верхам, с закладами на детали.
Впрочем это не означает что какой-либо набор технологий фулстек не может знать очень глубоко.
Впрочем это не означает что какой-либо набор технологий фулстек не может знать очень глубоко.
А где критерии лучше/хуже?
Если говорить о багаже знаний и скиллов, то, при прочих равных, вы всегда будете знать и уметь меньше, чем узкоспециализированный спец. Тут еще стоит учесть факт, что хороший узкий спец, разбирается в смежных областях как минимум на уровне джуна.
Если говорить о багаже знаний и скиллов, то, при прочих равных, вы всегда будете знать и уметь меньше, чем узкоспециализированный спец. Тут еще стоит учесть факт, что хороший узкий спец, разбирается в смежных областях как минимум на уровне джуна.
А совет №6? =)
Как-то все переусложнено и большая поляризация. Все зависит от нужд проекта и требований к Вам
Я занимаюсь триатлоном и получаю от этого удовольствие пока от меня не требуют побеждать или быть впереди в отдельных заплывах или велогонках.
Если в триатлоне я могу финишировать в первых 5-10%, то в отдельной велогонке я буду в первых 40-50%
Также и технологиями, когда-то в начинующей компании я был сильно полезен как универсал. Появилась потребность масштабироваться, копать вглубь и развивать новые сервисы, я уже меньше подхожу и всячески пытаюсь избавиться от как можно больших направлений, чтобы оставить минимум для фокуса
Я занимаюсь элементами:
— стратегии
— продукта
— инфраструктуры
— общего бекэнда
— машинное обучение
— аналитика
Как результат:
— недостаточно времени для погружения в исследования по продукту
— я не умею нормально пользоваться утилитами производительности в linux и иногда дела решаются вертикальным масшабированием. Из примера, оказалась что мы около года запускали Mongo с неоптимальными параметрами диска и можно было сильно улучшить
— когда раньше раз в год падал Kubernetes кластер, я не мог понять куда копать и просто создал новый
— я потерял способность писать и читать аналитические sql запросы. Занимает время осмыслить новые функции
— в перерыве работы с ML я забыл многие основы линейной алгебры, забыл специфики фреймворков.
В текущем положении я активно работаю над тем, чтобы уменьшить круг своих экспертиз.
Но напомню, когда-то я был более полезен как универсал
Я занимаюсь триатлоном и получаю от этого удовольствие пока от меня не требуют побеждать или быть впереди в отдельных заплывах или велогонках.
Если в триатлоне я могу финишировать в первых 5-10%, то в отдельной велогонке я буду в первых 40-50%
Также и технологиями, когда-то в начинующей компании я был сильно полезен как универсал. Появилась потребность масштабироваться, копать вглубь и развивать новые сервисы, я уже меньше подхожу и всячески пытаюсь избавиться от как можно больших направлений, чтобы оставить минимум для фокуса
Я занимаюсь элементами:
— стратегии
— продукта
— инфраструктуры
— общего бекэнда
— машинное обучение
— аналитика
Как результат:
— недостаточно времени для погружения в исследования по продукту
— я не умею нормально пользоваться утилитами производительности в linux и иногда дела решаются вертикальным масшабированием. Из примера, оказалась что мы около года запускали Mongo с неоптимальными параметрами диска и можно было сильно улучшить
— когда раньше раз в год падал Kubernetes кластер, я не мог понять куда копать и просто создал новый
— я потерял способность писать и читать аналитические sql запросы. Занимает время осмыслить новые функции
— в перерыве работы с ML я забыл многие основы линейной алгебры, забыл специфики фреймворков.
В текущем положении я активно работаю над тем, чтобы уменьшить круг своих экспертиз.
Но напомню, когда-то я был более полезен как универсал
Да, все верно. Это и называется «конечность ресурсов». Т.е. вы уперлись в свой потолок производительности в рамках данного проекта (он перестал вмещаться в вас и требует дополнительных ресурсов) и совершенно логично сокращаете круг задач, чтобы повысить производительность. Я как раз об этом и писал:
Работа в одну каску подразумевает конечность ресурсов. Т.е. вы не сможете реализовать по-настоящему крупный программный продукт. Даже если хватит знаний, не хватит времени.
Частично согласен с автором. Fullstack — выглядит как затычка в любой бочке. Эдакий и швец, и жнец, и на дуде игрец. Это смесь front-, back- и devops. Да, сложно изучать все. Да нельзя знать все, но ничего не мешает быть в каком-то сегменте технологий на самом «гребне волны».
Для меня есть несколько проблем:
1) Постоянно нужно учиться, что очень сильно влияет на личную/общественную жизнь.
2) Из-за №1 нужно постоянно распределять время на задачи: работа / учеба / семья /…
3) Постоянно находишься на краю выгорания
4) Постоянная борьба сделать все «правильно» и «доставить продукт / фичу вовремя»
Плюсы:
1) Можно найти решение задачи, которое будет проще / легче / быстрее / правильнее на стыке технологий, чем решение той же задачи в одной технологии. Например, отдавать файлы очень большие файлы с проверкой доступа по большому количеству правил.
2) Возможность разобраться в коде другого приложения, которые используется проектом и, возможно, исправить баг
3) Понимание того, как протекают процессы в более широком смысле. Не в рамках PHP или Java, а начиная с момента его формирования и заканчивая рендером.
4) Можно в любой момент заменить любого члена команды, пока тот болеет.
Совет: закладывайте правильную архитектуру с начала, но не пишите все сразу. Расставляйте приоритеты и планируйте.
Для меня есть несколько проблем:
1) Постоянно нужно учиться, что очень сильно влияет на личную/общественную жизнь.
2) Из-за №1 нужно постоянно распределять время на задачи: работа / учеба / семья /…
3) Постоянно находишься на краю выгорания
4) Постоянная борьба сделать все «правильно» и «доставить продукт / фичу вовремя»
Плюсы:
1) Можно найти решение задачи, которое будет проще / легче / быстрее / правильнее на стыке технологий, чем решение той же задачи в одной технологии. Например, отдавать файлы очень большие файлы с проверкой доступа по большому количеству правил.
2) Возможность разобраться в коде другого приложения, которые используется проектом и, возможно, исправить баг
3) Понимание того, как протекают процессы в более широком смысле. Не в рамках PHP или Java, а начиная с момента его формирования и заканчивая рендером.
4) Можно в любой момент заменить любого члена команды, пока тот болеет.
Совет: закладывайте правильную архитектуру с начала, но не пишите все сразу. Расставляйте приоритеты и планируйте.
Совет: закладывайте правильную архитектуру с начала, но не пишите все сразу.
Я тоже был сторонником этого совета, пока не научился хорошо эмулировать многозадачность мозга :)
Как пример — при работе с основным проектом (скажем, на C#), почти всегда открыт более мелкий, который на данный момент не критичен по времени (или вообще в рамках самообразования), например что-нибудь на PHP или JS.
Когда я упираюсь в производительность своей головы (нужно придумать правильный алгоритм работы, чтобы не превратить код в костыль, уперся в явное несоответствие архитектуры, просто устал делать этот проект), я без особого труда переключаюсь на второй (как правило, он гораздо легче в плане архитектуры и алгоритмов). Работаю в нем какое-то время (ментально отдыхая), пока мозг не скажет «ок, я кажется сообразил, что нужно сделать в главном проекте, погнали туда», или просто пока не почувствую, что снова готов погрызть сложный орех.
И знаете, вполне себе неплохо получается, не смотря на массовую критику знакомыми разработчиками такого подхода.
Понятия не имею, можно ли этому просто научиться или это какое-то особое строение/расстройство моего мозга.
У меня как-то само сложилось во времена, когда я был молод, глуп и жаден (и брал на себя больше, чем получалось унести).
Еще одно важное преимущество Full Stack: шанс создать свой продукт или партнерство в создании продукта.
А ведь еще несколько лет назад fullstack'и назывались эникейщиками. Казалось бы — суть одна, зато как теперь гордо звучит.
А ведь еще несколько лет назад fullstack'и назывались эникейщиками. Казалось бы — суть одна, зато как теперь гордо звучит.
Несколько лет назад — это сколько? Вроде бы я в профессии уже больше 15 лет, но никогда ни разу не слышал, чтобы fullstack'а называли эникейщиком. И суть совершенно разная. Скорее даже наоборот, лет 10 назад было вполне нормальным, что разработчик пишет и бэк (включая БД) и фронт (хотя, может это так мне повезло). Но сейчас всё усложнилось сильно, особенно фронт, и теперь очень сложно быть сильным во всём.
А в чем разница между эникейщиком и fullstack'ом, описанным в статье?
А в чем разница между эникейщиком и fullstack'ом, описанным в статье?
Думаю, что в «официальных» словарях такого слова нет, народные интернет-словари дают такие определения:
эникейщик — Название должности «специалиста по всему» в области компьютеров, оргтехники, телефонии, не требующей углублённых знаний. Он решает мелкие простые повседневные проблемы рядовых пользователей, чтобы не отнимать ценное время у админов
эникейщик — помощник системного администратора или сотрудник техподдержки (в основном занимается тем, что разбирается с пустяковыми проблемами пользователей; происходит от названия несуществующей клавиши any key, которую система просит нажать...
эникейщик — шуточное название штатной должности работника, обязанностью которого является техническая поддержка пользователей компьютера внутри компании
Т.е. совершенно ничего общего с тем, что написано в статье. У вас, конечно, может быть своё собственное определение, но не вижу смысла это ваше личное определение обсуждать.
Первое же Ваше определение довольно сильно схоже с тем, что описано в статье и в Вашем же комментарии. То есть человек, который и сервер поднимет, и базу, и бекенд, и фронтенд, правда все это будет на относительно низком уровне, что нормально для малого бизнеса и легких приложений, то есть по сути он действительно решает любые задачи в своей области, которые не требуют более углубленного подхода и по сути являются «простыми».
Здесь все зависит от того, как вы видите этот «низкий уровень». Поделитесь вашей шкалой, чтобы иметь общее представление, стоит ли вступать с вами в дискуссию?
Я не зря написал "относительно низкий уровень" (Вы ведь сами согласны с утверждением, что fulltstack слабее в определенной области по сравнению с узконаправленным специалистом). Грубо говоря, у приложений, которые под ключ сделаны одним человеком, имхо всегда много мелких косяков (если говорить про малый бизнес) во всех областях:
— В базе индекс бесполезный поставил, или не поставил полезный, или по поводу архитектуры особо не заморачивался
— Во фронте какая-то форма криво отображается при определенном поведении
— В бекенде не подумал о масштабировании
— В сервере забил на какие-то настройки
И для малого бизнеса и не нагруженного приложения — это не страшно, но как только приложение начнет расти — эти казалось бы незначительно косяки выше начнут скапливаться в нехилый технический долг со временем. И в зависимости от опыта изначального разработчика могут привести к более серьезным проблемам.
— В базе индекс бесполезный поставил, или не поставил полезный, или по поводу архитектуры особо не заморачивался
— Во фронте какая-то форма криво отображается при определенном поведении
— В бекенде не подумал о масштабировании
— В сервере забил на какие-то настройки
И для малого бизнеса и не нагруженного приложения — это не страшно, но как только приложение начнет расти — эти казалось бы незначительно косяки выше начнут скапливаться в нехилый технический долг со временем. И в зависимости от опыта изначального разработчика могут привести к более серьезным проблемам.
Грубо говоря, у приложений, которые под ключ сделаны одним человеком, имхо всегда много мелких косяков (если говорить про малый бизнес) во всех областях
Мягко говоря, это не совсем правда.
Все перечисленные проблемы встречаются в абсолютном большинстве крупных и не очень продуктов, над которыми работает команда «не-аникеев». И криво спроектированные БД, и кривой фронт. И костылей в исходном коде встречается даже побольше, чем в «коробке одного работника».
И зависит это в большинстве случаев не от того, сделан ли продукт одним человеком или командой, а
в зависимости от опыта изначального разработчика
Чем выше опыт, тем меньше ошибок.
Проблема (а скорее ограничение) fullstack не в подходе к проектированию, даже не в качестве кода, а в том, что после определенного предела масштабов проекта, он перестает умещаться в одном разработчике. Как в плане количества используемых технологий, так и в плане временных рамок.
И вот в таком случае fullstack без проблем может стать его архитектором, нанимая, руководя и направляя специалистов в нужном русле. Хотя бы потому, что он имеет хорошее представление, как все это работает изнутри, а не отдавать на откуп весь проект команде, мол раз они спецы, значит сами знают, как лучше (из такого подхода часто получается лебедь рак и щука, и как итог — абсолютно несбалансированное приложение/проект, срывы сроков и т.п.). Сколотить команду не как «партнеры по интересам», а нанять конкретных специалистов, которые нужны для ликвидации узких мест в проекте. Направлять их именно туда, где они нужны, максимизировать производительность разработки.
На мой взгляд, это никак не коррелирует с термином «аникей».
Эникейщик — это человек, который умеет нажимать «Any key». Т.е. решать шаблонные задачи даже не задумываясь, что и почему происходит — «Попробуйте перезагрузить компьютер»
Любой системный администратор может с легкостью эмулировать работу эникейщика, поскольку тоже умеет решать эти шаблонные задачи, но, в отличии, он обычно понимает что и почему делает.
Если и дальше проводить аналогии между админством и разработкой, то fullstack — это админ универсал, который умеет в *nix, Windows, сетевое оборудование и телефонию. Именно умеет, а не просто потыркать кнопки по инструкции.
Он проиграет узко-специализированному админу Windows на его поле, но, зато, уделает его в сухую на поле *nix, сети… И т.д.
Любой системный администратор может с легкостью эмулировать работу эникейщика, поскольку тоже умеет решать эти шаблонные задачи, но, в отличии, он обычно понимает что и почему делает.
Если и дальше проводить аналогии между админством и разработкой, то fullstack — это админ универсал, который умеет в *nix, Windows, сетевое оборудование и телефонию. Именно умеет, а не просто потыркать кнопки по инструкции.
Он проиграет узко-специализированному админу Windows на его поле, но, зато, уделает его в сухую на поле *nix, сети… И т.д.
Эникей не может в БД, не может в бэк, не может во фронт. По факту эникей может поставить систему со зверь-CD, поменять картридж да перекрутить пару плат, пропылесосить системник. Продвинутый может продиагностировать систему и найти неисправность, почистить не очень сложные вирусы. Изредка пару простейших скриптов написать может, но никогда не слышал чтобы эникеем называли кого-то, хоть отдалённо похожего на разработчика.
примите как факт то, что вы всегда (всегда) будете уступать узкоспециализированным разработчикам во всемКак сказал Бобук — не редко fullstack специалист вырастает, как раз, из узкоспециализированного, как результат fullstack = узкоспециализированный + смежные области. Поэтому он не будет уступать в своей «специализации».
Он почти всегда так вырастает. Но если изучать одновременно 5-10 технологий, вы в любом случае не сможете так же хорошо, как человек, который изучает и работает только в одной-двух. Просто не хватит времени.
Но поддерживать знания «исходной технологии» на приемлемом (т.е. если были условным «синьором», то ниже вряд ли опуститесь) уровне разумеется можно.
Но поддерживать знания «исходной технологии» на приемлемом (т.е. если были условным «синьором», то ниже вряд ли опуститесь) уровне разумеется можно.
Пока будет изучать смежные области деградирует в своей специализации, ведь чтобы стоять на месте нужно очень быстро бежать.
хитрый интроверт с силой воли
Как емко и точно — снимаю шляпу! *Прикопал для статусов в социалках
Вы меня совсем запутали: один говорит — не беги, другой — беги. Куда бежать, что делать? Куда податься стройными рядами? Вот остановлюсь и вообще ничего делать не буду.
Вот остановлюсь и вообще ничего делать не буду.
Я так пробовал. Хватило ненадолго, все равно обратно затянуло :)
А правильный ответ, имхо, делать то что нравится. Не, если оценивать с точки зрения денег или востребованности — там можно обсуждать, но по факту если тянет на разные технологии — хорошо, хочется копать одну — прекрасно. Иначе на мой взгляд есть шанс потерять интерес если делать не то что нравится а то что выгодно.
Найти работу для fullstack гораздо проще, чем для разработчика одной технологии. Но найти высокооплачиваемую работу все же сложнее. Парадокс, да?
Нет, так устроен мир.
UFO just landed and posted this here
По-моему, вы невнимательно прочли статью. В ней прямо в том самом месте, которое вы процитировали, написано:
Вы же зачем-то приводите как раз тот случай, где фуллстек выполняет роль «шестеренки». Разумеется, для такой задачи (которую вы приводите) эффективней будет нанять узкого специалиста (команду разноплановых специалистов). Но даже в вашем случае фуллстеком вполне может быть тимлид/архитектор — человек, который понимает на приемлемом уровне во всех применяемых технологиях, способен разрабатывать/вести архитектуру проекта, а так же управлять разработчиками, поддерживая общий баланс проекта. Про это тоже написано.
Я про такое даже не упоминал.
Найти работу для fullstack гораздо проще, чем для разработчика одной технологии. Но найти высокооплачиваемую работу все же сложнее. Парадокс, да? Тем не менее, в подавляющем большинстве случаев, так оно и есть (если конечно мы хотим использовать фуллстек, как фуллстек, а не как «программиста Java»). Там, где много платят с первых дней/месяцев работы, обычно не требуется «и швец и жнец, и на дуде игрец» — там требуется еще одна хорошо смазанная шестеренка в общий механизм, которая будет делать ровно одну задачу, и делать ее хорошо, так, как сказал тимлид.
Вы же зачем-то приводите как раз тот случай, где фуллстек выполняет роль «шестеренки». Разумеется, для такой задачи (которую вы приводите) эффективней будет нанять узкого специалиста (команду разноплановых специалистов). Но даже в вашем случае фуллстеком вполне может быть тимлид/архитектор — человек, который понимает на приемлемом уровне во всех применяемых технологиях, способен разрабатывать/вести архитектуру проекта, а так же управлять разработчиками, поддерживая общий баланс проекта. Про это тоже написано.
И тенденции что якобы всё больше людей нужны на фуллстэк, я, признаться, совсем не наблюдаю.
Я про такое даже не упоминал.
А с чего Вы взяли что full stack должен разбираться в DevOps? И не обязательно прыгать по языкам. Мне к примеру достаточно php и js как основных и далее я в них капаю как можно глубже, работа с разными фреймворками и тд. Насколько я понимаю это только фронтенд и бекенд, а админы это уже совсем другая история.
Вряд ли будет умным стаффить фуллстэка и поставить его готовить DevOps с докером на AWS, попутно давая писать код на C# для микросервиса и ещё лабать формочки на js/html/css. В этом нет смысла, кроме если бюджеты съели, и надо нанять человека для счёта.
В этом есть смысл, например, если даже двух девопсов бюджет проекта не потянет, или просто выкидыванием денег, потому что даже одного на 100% не нагрузить, а резервирование нужно.
Или ещё проще, у вас классический скрам. Команда разработки, минимальный состав по специализациям:
- дизайнер (с хотя бы минимальным знанием верстки)
- бэкендер (Java/C#/PHP/JS… + SQL/NoSQL/...)
- фронтендер (JS+вёрстка)
- тестировщик (мануал+ авто)
- девопс (администрирование и немного разработки)
Уже 5 человек, причём почти каждый из них уже мини-фуллстэк и никакого резервирования, резервировать каждого — минимум 10 человек, что выше рекомендуемого максимума в 9 человек, ну пускай дизайнера не резервируем, можно какое-то время пожить без него — достигаем максимума. Но если задачи идут неравномерно хотя бы по спринтам, то сталкиваемся с недонагрузкой команды. Разве не будет оптимальным к 5 специалистам добавить хотя бы пару фуллстеков?
Был опыт разработки и мобильного приложения, и серверной/фронтовой части для него в другой команде. Как описать весь этот опыт в резюме и найти такую компанию, где это востребовано?
Почему-то тронули ваши обсуждения выше. Всегда считал себя универсалом.
В компании где я работаю мне приходится закупать, ремонтировать технику, тяну сети, ставить сервера БД, обучать пользователей, поддерживать бухгалтерию, сдавать гос. отчётность, писать оконные приложения, писать по для интеграции онлайн касс, разрабатывать и внедрять систему транспортной логистики предприятия, поддерживать систему складского учёта, разработанную 20 лет назад, со всем сонмом отчётов и изменений в законодательстве, поддерживать сайт с онлайн магазином, совмещать всё с работой менеджера по торговле, и егаис, всё без помощника в не маленькой в общем фирме. И так 10 лет.
И кто я fullstack или эникейщик? Всё чаще склоняюсь к тому что я просто кадр.
В последнее время всё больше хочется писать игрушки, и баловаться дизайном, наверно выгорание.
В компании где я работаю мне приходится закупать, ремонтировать технику, тяну сети, ставить сервера БД, обучать пользователей, поддерживать бухгалтерию, сдавать гос. отчётность, писать оконные приложения, писать по для интеграции онлайн касс, разрабатывать и внедрять систему транспортной логистики предприятия, поддерживать систему складского учёта, разработанную 20 лет назад, со всем сонмом отчётов и изменений в законодательстве, поддерживать сайт с онлайн магазином, совмещать всё с работой менеджера по торговле, и егаис, всё без помощника в не маленькой в общем фирме. И так 10 лет.
И кто я fullstack или эникейщик? Всё чаще склоняюсь к тому что я просто кадр.
В последнее время всё больше хочется писать игрушки, и баловаться дизайном, наверно выгорание.
Ни одной сказки и ни одной песни он не знал больше чем наполовину, но зато это были русские, украинские, западнославянские, немецкие, английские, по-моему, даже японские, китайские и африканские сказки, легенды, притчи, баллады, песни, романсы, частушки и припевки.
Не примите на свой счёт, просто вспомнилось :)
«Любой человек должен уметь менять пелёнки, планировать вторжения, резать свиней, конструировать здания, управлять кораблями, писать сонеты, вести бухгалтерию, возводить стены, вправлять кости, облегчать смерть, исполнять приказы, отдавать приказы, сотрудничать, действовать самостоятельно, решать уравнения, анализировать новые проблемы, вносить удобрения, программировать компьютеры, вкусно готовить, хорошо сражаться, достойно умирать. Специализация — удел насекомых».Роберт Хайнлайн.
Значит такой дизайн не ужасен а наоборот?
Sign up to leave a comment.
Fullstack – почему это клево, или как получать от работы удовольствие