Отличное замечание! Я намеренно не указывал ветку прогрессии IC ( Individual Contributor) но могу описать и этот путь, хоть для меня он будет скорее умозрительным.
Грубо говоря, выглядит примерно так
Junior > Middle > Senior > Stuff Engineer > Principal > Senior Principal (опционально в корпорациях есть Member of technical Staff )
Сколько людей, столько и мнений. Если данная статья Вам не понравилась или показалась баянной, не значит, что не будет человека, который бы не вынес полезного из этого. Опыт у всех разный, если вам не подошло, прекрасно, комментируйте или проходите мимо. Ваши ожидания пост не оправдал и был не о том, что вам хотелось - бывает, найдёте своего автора :) Спасибо за комментарий и хорошего дня!
К слову об РП, я уточнял не про позицию, а про аббревиатуру, поскольку этого сокращения никогда не слышал.
Идея была в том, чтобы коротко обозначить положение и личное состояние, чем делать полное описание всех обязанностей.
К сожалению, сложилось неверное представление о том, что хотел донести в статье. Конечно, на поверхности, обязанности Тим Лида и менеджера схожи, чем-то пересекаются, но идея была в том, чтобы раскрыть разницу позже, чтобы доставлять информацию постепенно.
Поскольку я сам занимаю эту должность, то прекрасно понимаю о чём говорю. Проблема в том, что в целом область не до конца определилась, что она видит в Engineering Manager. После прохождения интервью в разных компаниях, появилось ощущение, что компании сами не понимают или не определились. В FAANG на эту позицию ищут скорее тех лида с навыком управления и проектами, и людьми. Просто в глобальных компаниях ищут скорее People / Tech Project Manager. Вообще понимание тех лида (простите не знаю, что значит РП-шпик) разительно отличается. У нас, например нет техлида, но есть отдельно Stuff Engineer который управляет большими техническими инициативами на уровне стека (iOS / android / web / backend ), а менеджер управляет отдельной командой и развитием программистов. Но если есть узкий технический вопрос по конкретному стеку, то это к Stuff Engineer.
С радостью! Там много деталей есть, и со стороны нагрузки в деталях, и со стороны плюшек. Цель была узнать насколько тема вообще интересна хоть кому либо
Iqorek не могу не согласиться + покрытие не всегда означает, что реально работает все что должно. Vkuvaev Пример с тачкой, как нельзя лучше описывают ситуацию =) Но сейчас, в современном мире разработки, разработчики не то, что тачку не покупают, они вообще на земле спят)
Ничем — делает абсолютно тоже, только написано на TypeScript. State-machine всегда выполняет одно и тоже — будет присутствовать только небольшая разница в имплементации — и все. В данном случае — бонус для TypeScript любителей.
Redux — управление состоянием всего приложения используя лишь один основной Store + определенное количество reducers, которые state меняют и actions, которые что-то делают — например клик юзера по блоку или загрузка данных. Именно это и является имплементацией Flux. Тогда как, моя маленькая библиотечка служит примитивным целям — просто менять состояние простого обьекта и в зависимости от состояния, приложение может что-то делать.
У Redux есть связи между reducers, Store и actions, тогда как у меня все просто:
Создал машину состояний
Поменял состояние
При изменении, можно заставить приложение как-то на это отреагировать.
В конце концов, по сути, и моя либа и Redux делает одно и тоже — управляет состоянием, но уровень размаха разный.
Ну почему Вы не читаете внимательно. Имелось ввиду среднестатистически. На 10 продуктов, написанных фуллстек и узкими спецами, шанс того, что у фуллстек все будет хуже- выше
Я не про хипстерские вещи у которых свой потенциал, но реальных приложений, дай Боже, если с сотню наберется. Я про зарекомендовавшие себя технологии и, рано или поздно, любой продукт надо переписывать. А каша из технологий зачастую лишь там, где либо нет толкового лида, либо он настолько задерган, что у него нет ни сил ни времени со всеми спорить.
Тренды — это то куда сообщество движется и, конечно, надо понимать стоит ли конкретно Вам за ним следовать или нет, но Вы, как разработчик обязаны знать их и быть способным применить при необходимости. Согласны?
В итоге, проще взять человека, у которого есть знания во всех этих частях и который сможет достаточно быстро въехать в новые библиотеки и фреймворки.
А на практике — сложнее, потому что таких людей крайне мало. Вьезжать он будет быстрее, но, если у узкого специалиста есть шанс догнать тренды, то у фуллстека он гораздо ниже, потому что он просядет в какой-либо из дисциплин быстрее.
Нет, к сожалению, повсеместно. Повторюсь, я не против Fullstack, просто на практике выходит, что средний фуллстек хуже специалиста. Для любителей придираться к словам, средний значит, что из 100 кандидатов узкого профиля выше шанс того, что попадется толковые, чем у Fullstack.
И этих ребят я обожаю, потому что они действительно круты, но меня угнетает тенденция к тому, что сейчас работодатели хотят, чтобы все ими стали, а я, например, пока не готов писать коммерческие приложения, как BE, поскольку еще изучаю этот вопрос, а хочу дальше делать то, что умею. Как только рынок уйдет в FullStack, любой адекватный человек обязан будет подтянуться в этой области, чтобы быть востребованным, но пока это не так — я буду придерживаться своего мнения.
Никогда и не пытался. Я люблю Frontend, делаю его хорошо и с удовольствием. Не все пишется от обиды или злобы, решил высказаться и послушать, что умные люди по этому поводу скажут.
Согласен, но тут имелось ввиду, что шанс того, что приложение будет проблематичным, если в нем будет вместо 2 компетентных ФЕ и БЕ, 4 — Фуллстека.
Имеются ввиду среднестатистические разработчики. Конечно, всегда есть вероятность того, что Фуллстеки будут компетентнее, чем ФЕ или БЕ, но, опять же, тут скорее речь о статистике.
Отличное замечание! Я намеренно не указывал ветку прогрессии IC ( Individual Contributor) но могу описать и этот путь, хоть для меня он будет скорее умозрительным.
Грубо говоря, выглядит примерно так
Junior > Middle > Senior > Stuff Engineer > Principal > Senior Principal (опционально в корпорациях есть Member of technical Staff )
Специализация - Frontend, но руковожу командой мобильных разработчиков, Frontend, Backend
Сколько людей, столько и мнений. Если данная статья Вам не понравилась или показалась баянной, не значит, что не будет человека, который бы не вынес полезного из этого. Опыт у всех разный, если вам не подошло, прекрасно, комментируйте или проходите мимо. Ваши ожидания пост не оправдал и был не о том, что вам хотелось - бывает, найдёте своего автора :) Спасибо за комментарий и хорошего дня!
К слову об РП, я уточнял не про позицию, а про аббревиатуру, поскольку этого сокращения никогда не слышал.
Идея была в том, чтобы коротко обозначить положение и личное состояние, чем делать полное описание всех обязанностей.
К сожалению, сложилось неверное представление о том, что хотел донести в статье. Конечно, на поверхности, обязанности Тим Лида и менеджера схожи, чем-то пересекаются, но идея была в том, чтобы раскрыть разницу позже, чтобы доставлять информацию постепенно.
Поскольку я сам занимаю эту должность, то прекрасно понимаю о чём говорю. Проблема в том, что в целом область не до конца определилась, что она видит в Engineering Manager. После прохождения интервью в разных компаниях, появилось ощущение, что компании сами не понимают или не определились. В FAANG на эту позицию ищут скорее тех лида с навыком управления и проектами, и людьми. Просто в глобальных компаниях ищут скорее People / Tech Project Manager. Вообще понимание тех лида (простите не знаю, что значит РП-шпик) разительно отличается. У нас, например нет техлида, но есть отдельно Stuff Engineer который управляет большими техническими инициативами на уровне стека (iOS / android / web / backend ), а менеджер управляет отдельной командой и развитием программистов. Но если есть узкий технический вопрос по конкретному стеку, то это к Stuff Engineer.
С радостью! Там много деталей есть, и со стороны нагрузки в деталях, и со стороны плюшек. Цель была узнать насколько тема вообще интересна хоть кому либо
Vkuvaev Пример с тачкой, как нельзя лучше описывают ситуацию =) Но сейчас, в современном мире разработки, разработчики не то, что тачку не покупают, они вообще на земле спят)
Ничем — делает абсолютно тоже, только написано на TypeScript. State-machine всегда выполняет одно и тоже — будет присутствовать только небольшая разница в имплементации — и все. В данном случае — бонус для TypeScript любителей.
Redux — управление состоянием всего приложения используя лишь один основной Store + определенное количество reducers, которые state меняют и actions, которые что-то делают — например клик юзера по блоку или загрузка данных. Именно это и является имплементацией Flux. Тогда как, моя маленькая библиотечка служит примитивным целям — просто менять состояние простого обьекта и в зависимости от состояния, приложение может что-то делать.
У Redux есть связи между reducers, Store и actions, тогда как у меня все просто:
В конце концов, по сути, и моя либа и Redux делает одно и тоже — управляет состоянием, но уровень размаха разный.
Согласен, надо убрать и упростить, работаем над этим, спасибо за комментарий.
Изначально, я разрабатывал ее под Angular2, но она действительно достаточно проста, чтобы ее переиспользовать
Я обернул nativeElement, чтобы проще с DOM работать.
Из личного опыта, к сожалению
Ну почему Вы не читаете внимательно. Имелось ввиду среднестатистически. На 10 продуктов, написанных фуллстек и узкими спецами, шанс того, что у фуллстек все будет хуже- выше
Я не про хипстерские вещи у которых свой потенциал, но реальных приложений, дай Боже, если с сотню наберется. Я про зарекомендовавшие себя технологии и, рано или поздно, любой продукт надо переписывать. А каша из технологий зачастую лишь там, где либо нет толкового лида, либо он настолько задерган, что у него нет ни сил ни времени со всеми спорить.
Тренды — это то куда сообщество движется и, конечно, надо понимать стоит ли конкретно Вам за ним следовать или нет, но Вы, как разработчик обязаны знать их и быть способным применить при необходимости. Согласны?
А на практике — сложнее, потому что таких людей крайне мало. Вьезжать он будет быстрее, но, если у узкого специалиста есть шанс догнать тренды, то у фуллстека он гораздо ниже, потому что он просядет в какой-либо из дисциплин быстрее.
Имеются ввиду среднестатистические разработчики. Конечно, всегда есть вероятность того, что Фуллстеки будут компетентнее, чем ФЕ или БЕ, но, опять же, тут скорее речь о статистике.