Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 79
Если разработчик знает много всего и умеет это применять на практике это конечно очень круто, спору нет.
Но нужно понимать что все знать невозможно, как бы не хотелось.
Сейчас слишком много различных областей и технологий, и с одной стороны это хорошо.
Да и глубокое понимание технологий приходит именно на практике.
Но нужно понимать что все знать невозможно, как бы не хотелось.
Сейчас слишком много различных областей и технологий, и с одной стороны это хорошо.
Да и глубокое понимание технологий приходит именно на практике.
Да, но в таком случае где они находят таких специалистов?
Получается, что это могут быть, либо молодые стартаперы, которые сами полностью подымали большой проект, где сталкивались со всеми этими вопросами. Либо это «супергуру», которые участвовали в средних или больших проектах. Причем не просто разработчиками, а принимали участие во всех аспектах разработки, и соответственно набрались опыта. Ну или это обычный программист работавший в обычной конторе, но кроме этого у него есть свой раскрученный сайт, есть несколько своих приложений под разные платформы, и еще у него большой опыт работы с базами данных.
Много ли таких людей, и сколько тогда им платят?
Получается, что это могут быть, либо молодые стартаперы, которые сами полностью подымали большой проект, где сталкивались со всеми этими вопросами. Либо это «супергуру», которые участвовали в средних или больших проектах. Причем не просто разработчиками, а принимали участие во всех аспектах разработки, и соответственно набрались опыта. Ну или это обычный программист работавший в обычной конторе, но кроме этого у него есть свой раскрученный сайт, есть несколько своих приложений под разные платформы, и еще у него большой опыт работы с базами данных.
Много ли таких людей, и сколько тогда им платят?
Если б я знал где они их находят, если находят, я б тут не сидел))
Вы усугубляете. Важно понимать, что знание — это не «помнить наизусть», а действительно уметь искать и знать что можно найти. С последним очень помогает принцип «ничего невозможного не бывает».
Далее, для примера, лично мой опыт, но не думаю, что я прямо-таки особенный.
Итого: на данный момент практически по любой мейнстримовой технологии в области веба я в короткие сроки могу найти нужную информацию или вовсе вывести из головы как оно должно работать — и совпаcть в мнении с разработчиками этой самой технологии.
Напоминаю — все это за три года.
Причем я отчетливо понимаю, что сейчас уже не могу в таком бешеном темпе впитывать информацию — в первую очередь потому, что поменялось мое отношение к работе. Стал больше ориентироваться на решения, а не изучение. Но не думаю, что это нельзя повернуть вспять ценой некоторых потерь (зарплатных, например).
По поводу «сколько им платят»: да столько же, в общем, ну может быть процентов на десять больше в среднем. Слишком широкие специалисты, как и слишком узкие, нужны редко и мало где.
Так что вакансии все те же, а разница з/п не такая сильная, чтобы играть сколько-нибудь значительную роль. Это скорее самому специалисту плюс, посколько позволяет тратить меньше времени/усилий/нервов на решение каких-то побочных задач (например, иногда проще самому исправить верстку, чем согласовывать задачу верстальщику и ждать от него результатов).
Далее, для примера, лично мой опыт, но не думаю, что я прямо-таки особенный.
На первом месте я за три года:
Погрузился в сети, достаточно неплохо выучил стек TCP/IP, очень глубоко HTTP (писал собственный сервер), более-менее UDP/ICMP и прочее около-вебовое.
Набил руку на автоматах (собственные шаблонизаторы).
Освоил *nix, без проблем могу проадминить удаленный веб-сервер (не уведя его в ребут с выключенным ssh :) ).
Глубоко познал СУБД (в моем случае на примере MSSQL), спокойно в уме прикидываю узкие места запросов, нет проблем с индексами и прочими оптимизациями. Могу поднять partitioning и кластер.
С головой погрузился в .NET, научился в уме просчитывать, во что транслируется тот или иной код (в плане CLR => Native), запомнил основные правила работы GC, на уровне моторики применяю всякие микрооптимизации. В свою очередь это потащило за собой WinForms, WPF, ASP.NET с одной стороны, и WinAPI и, в частности, GDI — с другой.
ASP + п. 1 сильно упростил дальнейшее понимание веб-фрейморков вообще, так что изучение всяческих PHP, RoR, питонов не составило труда (прим.: тут технически некорректное предложение — имеются ввиду веб-решения). Причем, например, питон я теперь знаю очень глубоко — пришлось писать полностью свой веб-стек.
WinAPI позволил прикоснуться к нэйтиву, плюс приходилось писать расширения под питон, так что в копилку добавились C/C++ и навыки кросс-платформенной разработки.
Про JS я вообще молчу, в веб-разработке это must-have для client-side, что, естественно, заставляет интересоваться и node.js.
Плюс куча всякой мелочи и эзотерики — разметка, css, erlang, haskell, flash, создание CDN, работа с соц. сервисами, UX и т.д.
Итого: на данный момент практически по любой мейнстримовой технологии в области веба я в короткие сроки могу найти нужную информацию или вовсе вывести из головы как оно должно работать — и совпаcть в мнении с разработчиками этой самой технологии.
Напоминаю — все это за три года.
Причем я отчетливо понимаю, что сейчас уже не могу в таком бешеном темпе впитывать информацию — в первую очередь потому, что поменялось мое отношение к работе. Стал больше ориентироваться на решения, а не изучение. Но не думаю, что это нельзя повернуть вспять ценой некоторых потерь (зарплатных, например).
По поводу «сколько им платят»: да столько же, в общем, ну может быть процентов на десять больше в среднем. Слишком широкие специалисты, как и слишком узкие, нужны редко и мало где.
Так что вакансии все те же, а разница з/п не такая сильная, чтобы играть сколько-нибудь значительную роль. Это скорее самому специалисту плюс, посколько позволяет тратить меньше времени/усилий/нервов на решение каких-то побочных задач (например, иногда проще самому исправить верстку, чем согласовывать задачу верстальщику и ждать от него результатов).
Толку в этих навыках? Я 13 лет с компьютерами, могу настраивать операционки от Novell Netware, Windows NT до Linux/BSD, работал с серверами различных размеров от подборки железа до сборки настройки профилактики. Протоколы писал на ассемблере, а винду облазил с софтайсом. Реализовывал прокси, http/ftp/smtp/pop3 сервера на ассемблере, парсеры сайтов на C#, понимаю «от ядра», как написать большую CMS, в разработке каковой участвовал и сделал пользовательский интерфейc. Писал программы под микрокалькуляторы, на бейсике, паскале, делфи, питоне, ассемблере, с. Работал в БД MySQL, MS SQL, Oracle.Сейчас же пишу на джаваскрипте под фреймворк ExtJs, понимаю верстку, но верстать могу только с дизайнером и по большей части с гуглом.
Работал в таких критических ситуациях, что врагу не посоветуешь, всегда брал на себя ответственность за свою работу и свои ошибки. И что? Нормальную работу найти не могу, ибо все знания поверхностны, а углубляюсь в область только при необходимости технологии под конкретную задачу. + Теряюсь на собеседованиях напрочь. Итог — приходит товарищ, у которого в резюме охеренный опыт. А ничего углубленного ответить не могет. Вобщем…
Хрен знает, мне кажется, чтобы реально хорошо знать ВСЕ эти технологии надо быть гением как минимум и иметь знания на уровне великого Онотоле.
Работал в таких критических ситуациях, что врагу не посоветуешь, всегда брал на себя ответственность за свою работу и свои ошибки. И что? Нормальную работу найти не могу, ибо все знания поверхностны, а углубляюсь в область только при необходимости технологии под конкретную задачу. + Теряюсь на собеседованиях напрочь. Итог — приходит товарищ, у которого в резюме охеренный опыт. А ничего углубленного ответить не могет. Вобщем…
Хрен знает, мне кажется, чтобы реально хорошо знать ВСЕ эти технологии надо быть гением как минимум и иметь знания на уровне великого Онотоле.
Было дело с фейсбуком. Не знаю откуда это информация, но проходил собеседование на Android разработчика. Их интересует не «full stack» кто бы это не был, а интересует человек знающий как решать олимпиадные задачки, сложность алгоритмов Big(O) ну и конечно же дизайн и полное понимание Android SDK.
p.s. прошел на 40% хорошо последнюю задачку, что и дало отказ. Остальные задания были пройдены на отлично. Всего собеседований и человек со мной общающихся составило 14 человек.
p.s.s. «знать где копать», как выразились ниже, никого не интересует. Показать свою работу — 2 месяца создал лаунчер, удивило и поразило их, меня конечно же проверили что это я сделал, кучей вопросов. Но всеравно отказ. Грубо говворя перед вами маркер, доска и 30 минут. Но было весело.
p.s. прошел на 40% хорошо последнюю задачку, что и дало отказ. Остальные задания были пройдены на отлично. Всего собеседований и человек со мной общающихся составило 14 человек.
p.s.s. «знать где копать», как выразились ниже, никого не интересует. Показать свою работу — 2 месяца создал лаунчер, удивило и поразило их, меня конечно же проверили что это я сделал, кучей вопросов. Но всеравно отказ. Грубо говворя перед вами маркер, доска и 30 минут. Но было весело.
За частую, важно лишь знать, что данная реализация задачи возможна и известно, где «копать» дальше.
Не важно знать все, важно знать где найти информацию, за максимально короткий срок.
Не всегда. Иногда ты не можешь найти информацию за короткий срок, потому что просто не знаешь о существовании той области, информация о которой тебе нужна.
Важно не знать, а применять знания на практике.
Что применять, если знаний нет?
Что применять, если знаний нет?
Какой прок от этих знаний, если человек их не может применить?
Я не говорил, что знания не нужны, а лишь намекнул, что вы однобоко смотрите на вещи. Даже если человек мастер поиска, какой в нём толк, если он эти знания применить не может?
Я как раз обобщенно смотрю на вещи, если человек не может найти информацию, то и применить он ее точно не сможет, а если хотя бы умеет добыть инфу, то хотя бы сможет ее применить, по крайней мере попытаться.
Full Stack — это человек, который может написать в резюме: «При наличие гугла — богоподобен».
Full Stack — это человек, который может написать в резюме: «При наличие гугла — богоподобен».
Тех, кто такое напишет, надо обходить дальней дорогой.
Ага! И не забудьте перекреститься.
Если вы встречали Full Stack программиста, то не забудьте перекреститься тоже, их не существует. Равносильно обсуждать утопические взгляды.
Наивное мнение. Никакого rocket science в указанных навыках нет, оно вполне естественно может получаться при эволюции разработчика.
простите почему еще?
Простая психология и наблюдения на практике. Те кто о себе так пишут… почти никогда не имеют основания для этого. Хуже всего то, что такой человек не, имея адекватной оценки себя, нередко списывает свои огрехи на других раздувая из них большую проблему… В общем некомфортно с такими работать. Впрочем опыт из несколько иной, нежели программирования, среды, поэтому может несколько/сильно не соответствовать действительности, поэтому такое отношение остаётся моим личным мнением (с которым другие могут быть согласны, не со всем согласны, либо совсем не согласны) и не больше.
Да, ещё небольшое уточнение: настоящий full stack подразумевает под собой настолько широкий набор технологий и сфер знаний, что просто тяжело быть грамотным везде. Без грамотного понимания поисковик бесполезен — результат в лучшем случае будет далёк от идеала, о худшем даже говорить не хочется.
Как же называется этот принцип?.. забыл.
Суть в том что не имея достаточного уровня понимания, человек не может извлекать уроки из своих ошибок. Это порождает уверенность.
С другой стороны, умный человек видит свои ошибки, поэтому сомневается — в частности, в собственных скиллах и возможностях.
В результате, люди с низкой квалификацией часто обладают необоснованной уверенностью (Гомер Симпсон), а человек умный — неуверенностью и жёсткой самокритикой (Перельман).
Суть в том что не имея достаточного уровня понимания, человек не может извлекать уроки из своих ошибок. Это порождает уверенность.
С другой стороны, умный человек видит свои ошибки, поэтому сомневается — в частности, в собственных скиллах и возможностях.
В результате, люди с низкой квалификацией часто обладают необоснованной уверенностью (Гомер Симпсон), а человек умный — неуверенностью и жёсткой самокритикой (Перельман).
«При наличие гугла — богоподобен»
Звучит как «нет опыта» )
Не согласен. Если выходить на знания с большем уровнем абстракции, чем например написание библиотеки для чтения файла или как установить nginx под debian то уже не работает эта схема.
Например для того чтобы построить хорошую архитектуру или нарисовать нормальный интерфейс (прим. не дизайн) то гугл вам никак не поможет.
PS Я не говорю о том что надо знать все мануалы наизусть
Например для того чтобы построить хорошую архитектуру или нарисовать нормальный интерфейс (прим. не дизайн) то гугл вам никак не поможет.
PS Я не говорю о том что надо знать все мануалы наизусть
Сильно зависит от задач и области ответственности. Для типовых и мелких задач это справедливо. Риски не так велики. Для сложных, комплексных — уже нет. Слишком много переменных. Без реального опыта искать придется долго, зачастую безрезультатно, придется наступать на грабли не раз и не два. Без хоть каких-то знаний вообще в предметной области, технологиях и инструментах искать становится просто бессмысленно.
Неплохой набор знаний. 80% владельцев интернет-магазинов не отказались бы от такого работника. А, ну да, это же из сказки Пушкина. 
надо было 8й пункт и название «Full stack» разработчика не существует =)
нет, я искренне верю, что такие люди есть, но их единицы, которые понимают весь процесс целиком. Уверен, что в том же Facebook'е таких людей много меньше общего числа разработчиков
нет, я искренне верю, что такие люди есть, но их единицы, которые понимают весь процесс целиком. Уверен, что в том же Facebook'е таких людей много меньше общего числа разработчиков
Смущает «перевод» — и фото Онотоле. Он уже в FB работает?
У нас в компании тоже все разработчики взаимозаменимы. Но само собой у каждого есть своя специализация.
Например, любой бекэнд разработчик может сеть писать фронтенд часть, как и наоборот, но это будет медленнее и код будет чуть хуже. В итоге, если кто-то, например, заболел — проект не останавливается, он просто разрабатывается чуть медленнее.
Например, любой бекэнд разработчик может сеть писать фронтенд часть, как и наоборот, но это будет медленнее и код будет чуть хуже. В итоге, если кто-то, например, заболел — проект не останавливается, он просто разрабатывается чуть медленнее.
Вообще у full-stack разработчиков, или ещё можно их назвать «человек-оркестр» есть проблема: всё делается медленнее (читай — дороже). Программист быстрее напишет код, а дизайнер быстрее сделает макет. И с поиском работы тоже проблема — ты и не кодер, и не верстальщик и не копирайтер… Это я по себе сужу.
Зато гораздо меньше времени на общение и согласования, централизована ответственность, нет необходимости гнать человека в офис каждый день. Удобно и нанимателю и разработчику.
Зато всё больше времени уходит на переключение контекста между разными уровнями проекта: если сегодня тебя просят добавить ещё один канал данных в поток вывода бортового процессора, завтра — обработать этот канал в программе, послезавтра — использовать результат обработки для улучшения какого-нибудь алгоритма распознавания образов, а через неделю — добавить в пользовательское приложение панель управления этим каналом, то просто не хватает времени вспомнить все необходимые факты про очередной уровень. На документацию полагаться нельзя: на неё нет спроса (ведь общение не требуется), а следовательно, и времени :(
Мне кажется, что уровни проекта достаточно гармонично друг с другом перекликаются. А вот переключать контекст между различным функционалом — это действительно неприятно. Сегодня пишешь табеля, завтра — расчёт з/п, а послезавтра — вообще в ККМ лезешь. Когда же работаешь над, скажем, расчётом з/п, то хорошо понимаешь и бизнес-логику, и модель данных, и как нужно UI правильно для этого построить.
Да, но это если речь о громадных правках в разных местах. А так — круто за 5 минут уметь пофиксить баг в верстке и прислать человеку, который за нее отвечает, очевидный дифф вместо того, чтобы полдня объяснять где, что, при каких условиях воспроизводится.
Более того, гипотетически, если я сделаю макет верстки мне это может помочь понять возможные проблемы у верстальщика, запустить мою часть пораньше и меньше залипать на взаимодействиях, т.е. суммарное переключение контекстов будет меньше. Этот макет я потом покажу и дам верстальщику и опять же сэкономлю на объяснениях. Ну естественно, это навскидку и для чего-то более-менее примитивного.
Ну и тому же пресловутому верстальщику тоже, думаю, иногда полезно посмотреть в базу данных, написать dummy-версию сервиса и уметь tcpdump-ить сетевое взаимодействие.
ИМХО тут важно, что говорится именно о навыках, роль при этом у меня может быть вполне конкретная.
Более того, гипотетически, если я сделаю макет верстки мне это может помочь понять возможные проблемы у верстальщика, запустить мою часть пораньше и меньше залипать на взаимодействиях, т.е. суммарное переключение контекстов будет меньше. Этот макет я потом покажу и дам верстальщику и опять же сэкономлю на объяснениях. Ну естественно, это навскидку и для чего-то более-менее примитивного.
Ну и тому же пресловутому верстальщику тоже, думаю, иногда полезно посмотреть в базу данных, написать dummy-версию сервиса и уметь tcpdump-ить сетевое взаимодействие.
ИМХО тут важно, что говорится именно о навыках, роль при этом у меня может быть вполне конкретная.
full-stack разработчик не будет делать дизайн :-) Он всё-таки разработчик, пусть и многопрофильный, а не дизайнер и не художник, и даже не специалист по юзабилити. Впрочем, последнее он тоже может понимать достаточно неплохо, чтобы не отвлекать юзабелиста по мелочам.
Насчёт «медленнее». Может, отдельную вещь он будет делать дольше. Однако, хорошо себе представляя цели проекта, характер взаимодействия между слоями/звеньями, он не будет постоянно переделывать из-за косяков во взаимодействии разработчиков, или ждать, пока бэкэнд-разработчики реализуют интерфейс или аналитик подправит ТЗ.
Насчёт «медленнее». Может, отдельную вещь он будет делать дольше. Однако, хорошо себе представляя цели проекта, характер взаимодействия между слоями/звеньями, он не будет постоянно переделывать из-за косяков во взаимодействии разработчиков, или ждать, пока бэкэнд-разработчики реализуют интерфейс или аналитик подправит ТЗ.
Здесь подразумевается всё же full-stack разработчик а не человек-оркестр. Разница в том, что он не верстальщик и уж точно не дизайнер. Такой человек может к примеру, утром написать патч к nginx, вечером захотфиксить пару багов в алгоритмах backend-а, а на следующий день запилить прикольный фронтенд на bootstrap + ajax для какой-нибудь внутренней утилиты.
Мне, честно говоря, иногда сложно разделить, где заканчивается кодинг и начинается дизайн. В интерфейсах они часто переплетены. Когда я предлагаю вместо стандартного контрола взять select2, при этом чуть поправив заточив внешний вид и встроив в общую конву сайта — я выступил как верстальщик, программер или дизайнер. Короче — я запутался.
А у нас в конторе их называют не «человек-оркестр», а «слесарь-многостаночник»
В немецком языке есть замечательное выражение «Eierlegende Wollmilchsau», дословно «яйценосная длинношерстная молочная свинья».
Соответственно под спойлером портрет такого разработчика:
Соответственно под спойлером портрет такого разработчика:
Скрытый текст
Пойду скину им резюме =)
Осталось найти компании которые готовы платить адекватное вознаграждение таким специалистам. А то даже facebook немного выше среднего по Долине.
Для того чтобы обладать всеми перечисленными навыками нужно быть нехилым таким комбайном. Но мне вот думается что посадить подобного разработчика за рутину (любую) — уже не получится, он будет рваться на свободу. Кроме того, подобное широкое по охвату развитие возможно только если предметная область или стек технологий относительно стабильны — иначе всё время уйдёт на погружение в то и другое.
Насторожили слова понимание, надлежащее, знакомы, суть пользы и так далее. Все они подразумевают наличие судьи, а от компании к компании уровень судей значительно меняется.
Например знаком может варьироваться от читал и могу бустро разобраться до уже сделал небольшой проект.
Например знаком может варьироваться от читал и могу бустро разобраться до уже сделал небольшой проект.
Поп ему в ответ: «Нужен мне работник:
Повар, конюх и плотник.
А где найти мне такого
Служителя не слишком дорогого?»
мне кажется нужно просто чаще общаться с разными людьми/коллегами и обсуждать проблемы, как ваши, так и их. Зачастую решение находится именно на таких кофеболтологических посиделках. А иметь под боком человека, который знает все и всем владеет, удобно, но редко встречается. Да и как правило,
такие люди заняты выши крыши.
Повар, конюх и плотник.
А где найти мне такого
Служителя не слишком дорогого?»
мне кажется нужно просто чаще общаться с разными людьми/коллегами и обсуждать проблемы, как ваши, так и их. Зачастую решение находится именно на таких кофеболтологических посиделках. А иметь под боком человека, который знает все и всем владеет, удобно, но редко встречается. Да и как правило,
такие люди заняты выши крыши.
Идеальный многорукий шива.
Хм, интересно почему так негативно отреагировали почти все комментирующие. Кажется, это из-за недопонимания сути самого термина.
Не стоит представлять под «full stack» разработчиком некоего Васю, который делает сайты на Wordpress-е с подправленной, бесплатной темой.
«Full stack» разработчик — это человек, который хорошо знает, понимает и применяет компьютерные технологии на различних уровнях: это понимание работы компьютера, структур данных и алгоритмов, языков программирования и компиляторов, принципов дизайна и архитектуры приложений.
Не такая это уж и большая редкость — программист, который на протяжении карьеры работал на разных ролях в большом количестве проектов. Такое часто случается, например, в аутсорсинге.
Если взять за пример среднестатистического программиста с 10-летним опытом и предположить, что он работал над десятью проектами по году каждый, то полностью реальным видится достаточный для «фулл стека» опыт в фронтенде, серверах, базах данных, UX и архитектуре.
Не стоит представлять под «full stack» разработчиком некоего Васю, который делает сайты на Wordpress-е с подправленной, бесплатной темой.
«Full stack» разработчик — это человек, который хорошо знает, понимает и применяет компьютерные технологии на различних уровнях: это понимание работы компьютера, структур данных и алгоритмов, языков программирования и компиляторов, принципов дизайна и архитектуры приложений.
Не такая это уж и большая редкость — программист, который на протяжении карьеры работал на разных ролях в большом количестве проектов. Такое часто случается, например, в аутсорсинге.
Если взять за пример среднестатистического программиста с 10-летним опытом и предположить, что он работал над десятью проектами по году каждый, то полностью реальным видится достаточный для «фулл стека» опыт в фронтенде, серверах, базах данных, UX и архитектуре.
+1. Правда, аутсорсинг там, где я его видел, к сожалению, не даёт знаний и навыков для действительно крупных распределённых систем (и, как следствие, понимания архитектуры для хайлоада — все эти блокировки и прочие шардинги). А так, при желании и способности разобраться во всём этом ничего сложного нет — объём вышеуказанных знаний для «full stack» и правда небольшой и «типичный».
Я бы плюсанул если бы мог :)
Как-то все превратно понимают данное понятие. Человек может увлекаться множеством вещей в своей жизни и таковые совмещать.
Вместе со мной работал человек, который прикрасно разбирается в ассемблере, программирует на С++, пишет под Direct3D и OpenGL (ну хобби у него такое), при всем при этом знает РНР и писал для него плагины (реализация некоторых вещей на нативном С++ через библиотечные вызовы из РНР работает намного быстрее чем реализация того же самого на языке интерпретатора — минус в том, что надо было тащить этот свой модуль).
Обычная беда таких людей, что им очень трудно становится в жизни искать работу — когда читают такое обширное резюме, большинство работодателей начинают подкалывать — «а дворником и водителем трамвая не работали?»
Невдомек нынешним HR, что если инженер от природы имеет пытливый ум, то ему не сложно разобраться в сути любой технологии, а также понять механизмы и приемы работы с этой технологией.
Стандартное заблуждение — что если человек много умеет, то уровень его умений не будет высоким.
Желаю всем расстаться с этим заблуждением и почаще пробовать что-то новое! Разносторонний опыт никогда никому не шел во вред!
Как-то все превратно понимают данное понятие. Человек может увлекаться множеством вещей в своей жизни и таковые совмещать.
Вместе со мной работал человек, который прикрасно разбирается в ассемблере, программирует на С++, пишет под Direct3D и OpenGL (ну хобби у него такое), при всем при этом знает РНР и писал для него плагины (реализация некоторых вещей на нативном С++ через библиотечные вызовы из РНР работает намного быстрее чем реализация того же самого на языке интерпретатора — минус в том, что надо было тащить этот свой модуль).
Обычная беда таких людей, что им очень трудно становится в жизни искать работу — когда читают такое обширное резюме, большинство работодателей начинают подкалывать — «а дворником и водителем трамвая не работали?»
Невдомек нынешним HR, что если инженер от природы имеет пытливый ум, то ему не сложно разобраться в сути любой технологии, а также понять механизмы и приемы работы с этой технологией.
Стандартное заблуждение — что если человек много умеет, то уровень его умений не будет высоким.
Желаю всем расстаться с этим заблуждением и почаще пробовать что-то новое! Разносторонний опыт никогда никому не шел во вред!
Где-то крутой совет читал: разделять в резюме навыки на активные (например «пользуюсь раз в неделю») и пассивные («раз в месяц» или «писал много, но с того момента прошло 2 года»).
Ну и естественно, под свой список можно и не 2, а 3 категории подобных сделать. А какой-нибудь нерелевантый опыт работы, мне кажется, может оказаться проще и опустить (например халтурки во время учебы с участивем зоопарка технологий).
Еще совет читал из той же серии: писать только важное и главное, понимая, что резюме должно заинтересовать за первые 15 секунд прочтения. Я конечно, сам не суперспец по написанию резюме и не всех кадровиков готов оправдать (один раз мне дали лист 3-4-буквенных аббревиатур и спросили что из этого я «узнаю»). Но что-то в этом «умении себя подать» правильное и здравое есть.
Ну и естественно, под свой список можно и не 2, а 3 категории подобных сделать. А какой-нибудь нерелевантый опыт работы, мне кажется, может оказаться проще и опустить (например халтурки во время учебы с участивем зоопарка технологий).
Еще совет читал из той же серии: писать только важное и главное, понимая, что резюме должно заинтересовать за первые 15 секунд прочтения. Я конечно, сам не суперспец по написанию резюме и не всех кадровиков готов оправдать (один раз мне дали лист 3-4-буквенных аббревиатур и спросили что из этого я «узнаю»). Но что-то в этом «умении себя подать» правильное и здравое есть.
Вот откуда берётся fullstack. Допустим, есть у нас предметная область, мы тут же садимся и пишем бизнес-логику и на неё — юнит-тесты. Далее, когда не задумываясь, навешиваем на свои entity-классы JPA-аннотации (ну или не в Java — своими инструментами обходимся), оказывается, что приложение тормозит. Поэтому надо понимать реляционную модель. Либо иметь DBA, который понимает ещё и DDD. Далее, у того же Фаулера описано, какие могут возникать проблемы с распределённой системой (а таковой она становится, если клиент и сервер находятся на разных машинах), и проблемы с разграничением транзакций, тут же появляются remote facade, DTO. Ну а тут и до UI недалеко. Да и в том же DDD люди касаются вопросов построения UI, чтобы получился не банальный CRUD, а приложение, всё так же отражающее логику.
Так вот. Между каждым из слоёв возникают нечёткие переходы. Поэтому нужно, чтобы разработчики как минимум понимали не только «свою» область, но и близлежающую. Иначе начнутся интересные вещи, когда либо апологет DDD пойдёт грузить entity миллионами на транзакцию, либо DBA сделает систему, «пляшущую» от данных, и потому несколько запутанную, либо UI-ник напишет фронтэнд, который будет гонять данные между клиентом и сервером в синхронном режиме тысячами мелких запросов. В нетривиальных вопросах каждого из уровней отдельный человек может разбираться лучше, но эти нетривиальные вопросы возникают не так часто, а в повседневности как раз нужно просто неплохо владеть пониманием, как всё устроено.
Так вот. Между каждым из слоёв возникают нечёткие переходы. Поэтому нужно, чтобы разработчики как минимум понимали не только «свою» область, но и близлежающую. Иначе начнутся интересные вещи, когда либо апологет DDD пойдёт грузить entity миллионами на транзакцию, либо DBA сделает систему, «пляшущую» от данных, и потому несколько запутанную, либо UI-ник напишет фронтэнд, который будет гонять данные между клиентом и сервером в синхронном режиме тысячами мелких запросов. В нетривиальных вопросах каждого из уровней отдельный человек может разбираться лучше, но эти нетривиальные вопросы возникают не так часто, а в повседневности как раз нужно просто неплохо владеть пониманием, как всё устроено.
Да-да, мне тоже пришла в голову первая мысль, что fullstack специалисты лучше справляются с протекающими абстракциями на стыках областей.
Но тут есть встречная опасность. Такому специалисту ничего не стоит при случае написать вызов или даже прямое обращение к полю объекта, пробивающее три-четыре слоя абстракций — просто потому, что сейчас это надо, а времени сделать всё правильно (и разобраться, а почему собственно такой вызов понадобился и не получается), как всегда, нет. Хорошо, если найдётся возможность глобального рефакторинга проекта. Но вероятность этого даже меньше, чем найти ещё одного подходящего full-stack разработчика в команду.
Таких людей не так уж и мало. Но тут как везде, есть крайности: на одной стороне действительно хорошие специалисты с широким кругозором, с другой стороны, как их любит называть мой отец, специалисты широкого профиля с узким захватом знаний. И первых, как и везде, меньшинство.
Только вот таким людям оркестрам очень тяжело искать работу действительно по своему профилю. Чаще нужны либо эникейщики, либо специалисты с определенным узким профилем. Знаю очень хорошо, так как у самого очень обширный кругозор за пределами чистого программирования, и имею определенные трудности с удовлетворением потребности в использовании всего своего профиля знаний и умений.
Только вот таким людям оркестрам очень тяжело искать работу действительно по своему профилю. Чаще нужны либо эникейщики, либо специалисты с определенным узким профилем. Знаю очень хорошо, так как у самого очень обширный кругозор за пределами чистого программирования, и имею определенные трудности с удовлетворением потребности в использовании всего своего профиля знаний и умений.
Судя по опыту, full stack developer, — обычно кандидат в techlead.
Ну тут же еще нужна любовь (желательно вместе с умением) к управлению. Один мой товарищ, когда вынужденно стал тимлидом, взвыл от необходимости гораздо более формально планировать и отчитываться о своей работе. Ну и куча народу есть, которая митинги всякие не любит, а тут уже не отмажешься.
В некоторых организациях должности techlead и teamlead различаются.
P.S. Картинку умыкнул с javarush.ru
P.S. Картинку умыкнул с javarush.ru
Ну я верю, что там побольше измерений будет на самом деле. Но не суть, просто обычно чем выше по иерархии, тем больше отчитываться и формальностей вообще, это не связано с full-stack-овостью. Например, если техлид — это почти архитектор, значит, вероятно, ему нужно как минимум с кучей народу согласовывать то, что он напридумывал.
Дожились. Продвинутые разработчики не знают, что обозначают термины full stack, empty stack. Терминам уж лет 30 точно.
Будучи на конференции OSCON, работник Facebook сказал мне, что они нанимают только «Full Stack» разработчиков.
так вот почему в FB такой говно-UI, непредсказуемая новостная лента и куча багов
Попытаюсь выразить свои мысли таким примером:
Зачем нам брать готовый и дорогой высокопроизводительный фабричный процессор «Мастодонт» который умеет выполнять миллион задач, когда можно спроектировать свой маленький процессор под одну конкретную задачу, который будет выполнять ее во много раз быстрее, чем процессор «Мастодонт» под миллион задач.
Зачем нам брать готовый и дорогой высокопроизводительный фабричный процессор «Мастодонт» который умеет выполнять миллион задач, когда можно спроектировать свой маленький процессор под одну конкретную задачу, который будет выполнять ее во много раз быстрее, чем процессор «Мастодонт» под миллион задач.
Я так понимаю оверхед на проектирование своего процессора, запуск его в производство, а также временные издержки покрывают с лихвой покупку процессора «Мастодонт»?
В конечном итоге да — когда тираж изделия превысит миллион. За счёт большей производительности и функциональности спрос на продукцию будет выше, чем у конкурентов.
telteron, спасибо, что подкинули мне пищу для размышления. Я об этом даже и не думал. Но вот теперь стал задумываться.
В моей организации выпускают устройства с единичным экземпляром. Даже более новая версия старого устройства, как правило в корне отличается — а это уже совсем другое устройство, так как требования могут поменяться в корне.
Я никогда ничего не делал в серийное производство в больших экземплярах. И поэтому, врать не буду, в этом я не компетентен. Но хотелось бы узнать больше.
P.S. Хорошая тема для статьи — Разработка единичного экземпляра vs. разработка для серийного производства — подходы, способы и методики.
В моей организации выпускают устройства с единичным экземпляром. Даже более новая версия старого устройства, как правило в корне отличается — а это уже совсем другое устройство, так как требования могут поменяться в корне.
Я никогда ничего не делал в серийное производство в больших экземплярах. И поэтому, врать не буду, в этом я не компетентен. Но хотелось бы узнать больше.
P.S. Хорошая тема для статьи — Разработка единичного экземпляра vs. разработка для серийного производства — подходы, способы и методики.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Кто такой «Full Stack» разработчик?