Комментарии 23
НЛО прилетело и опубликовало эту надпись здесь
Например, потому что именно умение видеть общую картину не только изнутри, но также со стороны конечного пользователя и бизнеса, и отличает разработчика-сеньора от младших грейдов.
Нравится или нет — другой вопрос, но если ты хочешь быть специалистом высокого уровня, ты обязан искренне интересоваться не только полным технологическим стеком продуктов, в разработке которых принимаешь участие. Ты ещё обязан понимать, что чувствует твой конечный пользователь, и как твой заказчик собирается зарабатывать деньги на этом продукте.
Впрочем, никто не заставляет, можно всю жизнь в мидлах проходить. Если тебе нравится всю жизнь заниматься только стрелочными переводами, почему нет.
Нравится или нет — другой вопрос, но если ты хочешь быть специалистом высокого уровня, ты обязан искренне интересоваться не только полным технологическим стеком продуктов, в разработке которых принимаешь участие. Ты ещё обязан понимать, что чувствует твой конечный пользователь, и как твой заказчик собирается зарабатывать деньги на этом продукте.
Впрочем, никто не заставляет, можно всю жизнь в мидлах проходить. Если тебе нравится всю жизнь заниматься только стрелочными переводами, почему нет.
НЛО прилетело и опубликовало эту надпись здесь
Думаю ноги тут растут не из «фуллстек» историй. Последнее время agile техники все больше набируют обороты, а там одна из ключевых характеристик, что команда несет коллективную ответственность за продукт и имеет постоянное обсуждение функционального состава продукта. То есть разработчики вникают в истории использования продукта. Это не отменяет специализацию, на уровне разбиения функциональности на задачи, сами задачи уже «улетают» согласно компетенциям.
Скорее не разница между full и не full stack, а разница между "писать код" и "решать задачу".
Именно что.
«Писать код можно и обезьяну надрессировать, и она, может быть, будет делать это лучше, чем большинство из вас», — любил повторять один из моих вузовских преподавателей, — «а вы, как инженеры, учитесь решать задачи». Мерзкий мужик был, но через пару лет, когда я дорос до управления небольшим отделом из трёх разработчиков, мне пришлось признать, что он был абсолютно прав. Цель программиста не состоит в написании кода, а в достижении задач бизнеса путём автоматизации рутинных действий.
И чтобы делать это эффективно, нужно иметь компетенции от постановки задачи и проектирования пользовательского интерфейса вплоть до железа, в комплексе. Наличие специализации этому никак не противоречит, кстати. Просто задачи, в которых ты не специализируешься, отгружаешь другим членам команды, — а потом ревюишь, оцениваешь, и принимаешь решения.
«Писать код можно и обезьяну надрессировать, и она, может быть, будет делать это лучше, чем большинство из вас», — любил повторять один из моих вузовских преподавателей, — «а вы, как инженеры, учитесь решать задачи». Мерзкий мужик был, но через пару лет, когда я дорос до управления небольшим отделом из трёх разработчиков, мне пришлось признать, что он был абсолютно прав. Цель программиста не состоит в написании кода, а в достижении задач бизнеса путём автоматизации рутинных действий.
И чтобы делать это эффективно, нужно иметь компетенции от постановки задачи и проектирования пользовательского интерфейса вплоть до железа, в комплексе. Наличие специализации этому никак не противоречит, кстати. Просто задачи, в которых ты не специализируешься, отгружаешь другим членам команды, — а потом ревюишь, оцениваешь, и принимаешь решения.
Но почему, например, проектировщику стрелочных переводов должен быть интересен технологический цикл изготовления сидений в электричке, мне непонятно.
Зная технологический процесс производства сидений, «стрелочник» будет иметь чёткое представление об устройстве сидений, и есть вероятность, что применив эти знания, разработает такой стрелочный перевод, который при проезде по нему не будет ощущаться пассажирами, которые на этих сидениях сидят.
Много букв. Я бы написал покороче:
— Как сталь мидлом? Поработать 2-3 года и сменить компанию. Точно также становятся сеньором: работают ещё 3-4 года и меняют компанию.
— Как получать много денег за ту же самую работу? Менять команды, проекты и компании при первой возможности. Каждый раз когда вы меняете компанию, вы договариваетесь о зарплате и остальных плюшках с HR. Просто работая внутри компании вы не сможете прийти к HR и сказать, что хотите в 2 раза больше денег за ту же самую работу. В идеале надо менять компанию пару раз в год и каждый раз выбивать повышение, но это будет выглядеть плохо в вашем резюме. С другой стороны если вы долго (5 лет) торчите в одной компании, это тоже выглядит плохо в врезюме.
— Как иметь много возможностей для смены компании, команды и проекта? Заводить и поддерживать полезные знакомства. Сейчас вы два интерна и кодите мелкий проект на лето, а через 15 лет ваш друг будет вице-президентом в большой корпорации. Вам это знакомство очень пригодится. Гораздо больше чем знание стандарта C++.
— Как проходить собеседования? У вас должно быть нужное количество лет опыта и нужное количество интересных и важных на вид проектов. Количество лет опыта придаёт вашим словам вес. Именно поэтому нужно менять проекты как можно чаще: сделали что то существенное в важном проекте, добавили строчку в резюме и поменяли проект. Когда вы будете менять компанию и иметь значение будет лишь то как выглядит со стороны ваша роль в этих проектах и сколько их было. Не тратьте время зря на бесполезные проекты: представьте как будет выглядеть в резюме эта строчка и если она выглядит не очень, то и заниматься этим не стоит.
— Как сталь мидлом? Поработать 2-3 года и сменить компанию. Точно также становятся сеньором: работают ещё 3-4 года и меняют компанию.
— Как получать много денег за ту же самую работу? Менять команды, проекты и компании при первой возможности. Каждый раз когда вы меняете компанию, вы договариваетесь о зарплате и остальных плюшках с HR. Просто работая внутри компании вы не сможете прийти к HR и сказать, что хотите в 2 раза больше денег за ту же самую работу. В идеале надо менять компанию пару раз в год и каждый раз выбивать повышение, но это будет выглядеть плохо в вашем резюме. С другой стороны если вы долго (5 лет) торчите в одной компании, это тоже выглядит плохо в врезюме.
— Как иметь много возможностей для смены компании, команды и проекта? Заводить и поддерживать полезные знакомства. Сейчас вы два интерна и кодите мелкий проект на лето, а через 15 лет ваш друг будет вице-президентом в большой корпорации. Вам это знакомство очень пригодится. Гораздо больше чем знание стандарта C++.
— Как проходить собеседования? У вас должно быть нужное количество лет опыта и нужное количество интересных и важных на вид проектов. Количество лет опыта придаёт вашим словам вес. Именно поэтому нужно менять проекты как можно чаще: сделали что то существенное в важном проекте, добавили строчку в резюме и поменяли проект. Когда вы будете менять компанию и иметь значение будет лишь то как выглядит со стороны ваша роль в этих проектах и сколько их было. Не тратьте время зря на бесполезные проекты: представьте как будет выглядеть в резюме эта строчка и если она выглядит не очень, то и заниматься этим не стоит.
Букв, действительно, немало, т.к. статья ориентирована на начинающих разработчиков, поэтому, короче не получилось. :)
По вашим комментариям 1-3: ну, я все же фокуссировался на качестве, которое называется skill (не номинальную смену должности из-за перехода). Если skill есть, то за ним как правило и подтягиваются более хорошие финансовые и карьерные условия.
Вы же как раз пишите пример логики, который я привожу в разделе «Смена работы». Чем смена работы, особенно в первые 3 года опыта может быть плоха — я привожу пример в статье. Будете прыгать — опыта так можете и не получить нормального. Но да: ЗП поднимите, должность, возможно, тоже поднимите. Потом захотите поработать на более крутом проекте — упс, не получается.
Опыт — отличная вещь, чтобы а) попасть на собеседование на интересную позицию б) при условии, что вы прошли тех. интервью, быть при прочих равных первым кандидатом на нее.
На собеседованиях (если мы говорим про позиции jun-dev-senior) вы во многом продаете ведь не опыт, а ваше знание технологий и умение решать задачи прямо на собеседовании (например, писать код на листочке).
Частично согласен. Но был ли проект бесполезным, возможно, вы сразу не узнаете. Вообще, опять же, в первые 1-3 года опыта бесполезных проектов практически не бывает. Когда у вас опыта нет, они все приносят какой-то полезный опыт и формируют подход. У меня есть личный пример: на первом году работы я несколько месяцев занимался тем, что сейчас называется DevOps. Мне не очень нравилось, ну все-таки это не разработка самой системы. Но опыт, который я там получил, до сих пор формирует у меня планку качества и понимание того, как должна быть устроена, например, автоматизация развертывания и среды тестирования, и какие бенефиты это все дает: я понимаю это не на бумаге и не потому, что так написано в книгах или статьях, а потому — что я трогал это руками и видел конкретные результаты. Это ощущение стоит дорого и позволяет правильно оценивать важность задач и выхлоп от их внедрения. Не все важные задачи интересны конкретным разработчикам или менеджерам — это правда.
По вашим комментариям 1-3: ну, я все же фокуссировался на качестве, которое называется skill (не номинальную смену должности из-за перехода). Если skill есть, то за ним как правило и подтягиваются более хорошие финансовые и карьерные условия.
Вы же как раз пишите пример логики, который я привожу в разделе «Смена работы». Чем смена работы, особенно в первые 3 года опыта может быть плоха — я привожу пример в статье. Будете прыгать — опыта так можете и не получить нормального. Но да: ЗП поднимите, должность, возможно, тоже поднимите. Потом захотите поработать на более крутом проекте — упс, не получается.
Когда вы будете менять компанию и иметь значение будет лишь то как выглядит со стороны ваша роль в этих проектах и сколько их было.
Опыт — отличная вещь, чтобы а) попасть на собеседование на интересную позицию б) при условии, что вы прошли тех. интервью, быть при прочих равных первым кандидатом на нее.
На собеседованиях (если мы говорим про позиции jun-dev-senior) вы во многом продаете ведь не опыт, а ваше знание технологий и умение решать задачи прямо на собеседовании (например, писать код на листочке).
Не тратьте время зря на бесполезные проекты
Частично согласен. Но был ли проект бесполезным, возможно, вы сразу не узнаете. Вообще, опять же, в первые 1-3 года опыта бесполезных проектов практически не бывает. Когда у вас опыта нет, они все приносят какой-то полезный опыт и формируют подход. У меня есть личный пример: на первом году работы я несколько месяцев занимался тем, что сейчас называется DevOps. Мне не очень нравилось, ну все-таки это не разработка самой системы. Но опыт, который я там получил, до сих пор формирует у меня планку качества и понимание того, как должна быть устроена, например, автоматизация развертывания и среды тестирования, и какие бенефиты это все дает: я понимаю это не на бумаге и не потому, что так написано в книгах или статьях, а потому — что я трогал это руками и видел конкретные результаты. Это ощущение стоит дорого и позволяет правильно оценивать важность задач и выхлоп от их внедрения. Не все важные задачи интересны конкретным разработчикам или менеджерам — это правда.
Будете прыгать — опыта так можете и не получить нормального. Но да: ЗП поднимите, должность, возможно, тоже поднимите. Потом захотите поработать на более крутом проекте — упс, не получается.
По моим наблюдением наоборот: самый качественный опыт получают те новички в профессии, которые первое время гонятся за деньгами, даже ценой частой смены работы. В рамках выбранной специализации, конечно. Причин, думаю, несколько:
1. Зачастую новичкам приходится соглашаться на первую же работу, на которую их взяли, так как отсутствие хоть какой-нибудь работы — это всегда стресс. Устроившись же можно спокойно подготовиться, детальнее посмотреть на рынок труда, походить по разным компаниям, и в итоге значительно улучшить условия.
2. Адекватные успешные компании с интересными проектами обычно не жмутся на зарплату даже новичкам. В компании, где больше платят, junior наверняка получит более ценный опыт. Зачем ждать 3 года, чтобы туда перейти?
3. Работодатель не ценит тех, кто достался ему очень дёшево. Будут нагружать всякой ерундой, которую другие программисты делать отказываются. Если же зарплата адекватно высокая, работодатель будет всячески прокачивать новичка.
В-общем, новичкам могу посоветовать: устроились на работу — сразу же начинайте искать новую. Не афишируя этого, конечно.
Вопрос про вопрос «что должен знать мидл?». Один из комментариев раскрывает один из способов повышения — смена проекта или компании. А если говорить про вариант работы на том же проекте, то такой вопрос задаёт себе каждый лид.
Кто-то использует матрицы компетенций, различные профили специальностей, наборы курсов и систему их прохождения с получением баллов. Ещё есть оценка 360, просто разговоры по душам. И это только начало.
Понятно, что система повышения должна быть прозрачной и справедливой. И что это большой труд.
Как лучше такую систему сделать?
Кто-то использует матрицы компетенций, различные профили специальностей, наборы курсов и систему их прохождения с получением баллов. Ещё есть оценка 360, просто разговоры по душам. И это только начало.
Понятно, что система повышения должна быть прозрачной и справедливой. И что это большой труд.
Как лучше такую систему сделать?
Как лучше такую систему сделать?
Я тут недавно слышал интересную мысль: матрицы компетенций не нужны потому, что пока вы будете ее составлять она и сама и устареет (новые технологии приходят, старые — уходят), и навыки ваших специалистов тоже устареют. :)
На самом деле, ваш вопрос, пожалуй, самый сложный во всем этом процессе, связанном с формальным ростом внутри компании. Лично я не очень верю в систему баллов, ее сложно обосновать и сложно гранулировать (например, если у вас 100 баллов — вы получаете повышение, а если 98 — не получаете. ну бред же!). Но с другой стороны, сотрудники, которые проходят курсы и получают сертификаты как правило, знают в среднем больше и обладают большой мотивацией, которая и должна быть вознаграждена в итоге.
Вообще, общий подход, принятый во многих больших компаний — это постановка целей. Цели не только получают ранг, степень выполнения, но и степень влияния на команду, отдел и бизнес целиком. Например, если вы сделали очень простую систему, в которой может не быть ничего выдающегося с технической точки зрения, то она может экономить компании значительные деньги. Если же вы сделали систему, которая сложна и неповторима (в значении «сложно сделать») — это отличный пример, который показывает, что произошел рост в квалификации на качественном уровне, заслуживающий поощрения.
Но, понятно, что когда мы масштабируем эту систему оценки на всю компанию, то в ней встречаются сложные и неоднозначные кейсы, связанные с тем, что разные менеджеры по своему трактуют важность и степень достижений, с тем, наконец, что в компании существуют лимиты на повышения. Например, если есть 10 человек, которые получили отличные и одинаковые оценки на performance review, то для них нет гарантии, что они получат одинаковое вознаграждение. В целом, этот процесс имеет много изъянов и вещей, связанных со случайностью. Случайность работает в обе стороны: вам повезет и вы выполните какую-то важную цель из-за благоприятного стечения обстоятельств, либо наоборот.
в компании существуют лимиты на повышения
Такое видел. Лимиты заранее не известны даже руководителям. И может случиться так, что завершилась оценка, отправлено обоснование повышений команды руководителю, он согласует, уже оглашает команде даты и суммы. А потом выясняется, что о-па и упс, лимиты есть.
Бюджет надо заранее выяснять, просчитывать.
Вообще, общий подход, принятый во многих больших компаний — это постановка целей. Цели не только получают ранг, степень выполнения, но и степень влияния на команду, отдел и бизнес целиком
Спасибо за акцент на степени влияния на команду и бизнес. Думаю стоит оценить этот фактор, не выделял его явно
Какой подход порекомендуете при выборе целей?
Пример подхода — если есть на входе список из 7-ми целей, выбираю три наиболее интересные и важные основываясь на интуиции. Цели соответствуют SMART и их три.
На что обратить внимание при формировании и выборе целей?
Пример подхода — если есть на входе список из 7-ми целей, выбираю три наиболее интересные и важные основываясь на интуиции. Цели соответствуют SMART и их три.
На что обратить внимание при формировании и выборе целей?
Я видел самые разные примеры целей в разных компаниях. От «сделать такую-то техническую задачу Х» до «стать экспертом в системном администрировании». Цели первого вида ставить легко. Если есть какой-то проект, то его имплементация, та часть, которая возложена на вас, — это и есть цель. Иногда пытаются ставить вероятностную цель: пытаются угадать, на какой процент изменится поведение системы или пользователей. Заранее какой процент получится предугадать сложно, поэтому здесь риск недостижения может быть сколь угодно велик, в общем, на свой страх и риск :) Цели второго типа — они слишком общи и сложно измеримы. Тем не менее, есть компании, которые все равно требуют такие цели ставить потому, что у сотрудника должен быть вектор развития, который такими целями и управляется.
Для меня как для Juniora главной проблемой пять лет назад было попасть на собеседование.
Многие компании просматривают отклики на hh, но не дают никакоц обратной связи. В итоге со второго интервью меня взяли, а дальше было просто :)
Самое забавное когда компании проигнорировавшие тебя пять лет назад сейчас зовут на интервью.
Если вы ставите финансы первым номером, то, возможно, в будущем с удивлением для себя обнаружите, что за 4 года в индустрии вы научились только решать задачи из строго ограниченного круга на вашем проекте и не знаете и половину того, что вам может потребоваться при устройстве в другую компанию, где бы вы хотели работать.В корне не согласен! Вот как раз если вы 4 года проведёте в одной компании, то вы узнаете только те технологии, которыми эта компания пользуется. А это в любом случае окажется очень маленький стек. А вот если вы сменили несколько компаний, то вы просто вынуждены будете работать с более широким стеком технологий.
то вы узнаете только те технологии, которыми эта компания пользуется.
Ну а если вам другие технологии и не нужны?
За это время как раз и можно нормально изучить ограниченный набор технологий, но не только это. К примеру, если вы это время работали бы в продуктовой компании, то изучили бы как минимум несколько модулей на хорошем уровне, получив ценное знание о том, как они устроены. Это в разы повышает архитектурные скиллы, например.
как стать мидлом? заявится и устроится сеньером и поработать с полгода.
Автору спасибо за статью, узнал себя в ней. К сроку подходит мой третий год, и как раз встаёт вопрос о смене места. И к счатью (или несчатью) участились входящие сообщения на том же SO и LinkedIn. Грань пока не ясна, а надо ли менять или поднатаскаться ещё пока есть возможность.
Понимаю, мало что поменяется, но все таки интересно было бы узнать подобные особенности для хардварных разработчиков (плис, мк).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
О чем молчат Лиды: начало карьеры разработчика. Принципы или как стать Middl’ом