Как ни странно, но многие разработчики, начиная с джуниоров и заканчивая синьорами, видят только один путь своего развития: менеджмент. Они планируют переходить в руководители проектов или становиться техническими руководителями. Но IT-сфера намного шире, вариантов и путей развития большое количество. Развиваться можно, не только получая новые навыки, но и совершенствуя существующие. Об этом и о нескольких возможных дорогах для дальнейшего развития карьеры разработчика я расскажу в своем посте. Интересно будет не только начинающим свою карьеру, но и опытным разработчикам, которые еще не определились со своей судьбой или просто устали писать код.
Источник
В сфере информационных технологий много стереотипов, как и везде. Один из них касается карьеры разработчика. Иногда кажется, что, если ты пишешь код в сорок лет, с тобой что-то не то, и единственный путь – расти и становиться руководителем. Из-за этого я периодически наблюдаю картину, когда опытные разработчики не двигаются с места годами, ожидая “того самого места выше”. Но те пути развития специалиста, о которых я расскажу ниже, полезно знать нам всем, от джуниора до синьора — сменить направление работы никогда не поздно. Оговорюсь сразу. Я не буду говорить о деньгах и зарплатах (оставим все это за рамками, наконец, есть hh.ru), а буду рассуждать именно о возможном творческом и карьерном развитии.
Я могу выделить несколько основных путей развития в IT для тех, кто имеет опыт разработчика. Каждый из них очевиднее предыдущего, кто-то может вообще ничего нового не услышать. Но часто то, что мы ищем, как раз и лежит на поверхности, нужно только обратить на это внимание.
Итак, поехали:
Источник
Тот самый “стандартный” путь, живущий в умах большинства разработчиков. Куда он приводит знакомо всем: руководство группой (TeamLead), проектами, отделом, технологической практикой, техдиректор… В каждой компании свой набор должностей. Этот вариант предполагает наличие навыков управления. Нужно начинать изучать премудрости менеджмента, находить подход к людям, понимать, как работает компания. Опыт разработчика тут уже уходит на второй план и выступает в качестве бэкграунда. Код писать становится уже либо совсем не нужно, либо нужно в гораздо меньшем объеме.
Это для тебя, потому что:
На что стоит обратить внимание:
Источник
Тут все просто: продолжаешь делать то, что тебе интересно. Осваиваешь новые подходы и технологии, развиваешься в ширину. Имея огромный опыт, можно уже не уделять много времени написанию кода, но быстро вникать в контекст проблемы и эффективно ее решать, заниматься обучением и наставничеством. Если долгое время, а лучше с самого начала, работать в рамках одного продукта, то рано или поздно будешь знать все, даже самые отдаленные и темные уголки кода. Обычно должность таких разработчиков имеет префикс Principal или Expert. Это рок-звезды программирования. Такие сотрудники высоко ценятся не только в текущей компании, но и на рынке в целом. Многие даже не задумываются об этом пути развития, а он того стоит и стоит тех усилий, которые придется вложить.
Это для тебя, потому что:
На что стоит обратить внимание:
Источник
Возвращаемся к техническим направлениям. Если написание кода можно приравнять к выточке деталей на станке, то тут речь пойдет о создании чертежей этой самой детали, а то и всего агрегата. Проектирование будущего продукта, создание фундамента, выбор используемых решений — это все требует глубоких знаний в предметной области и часто становится ключевым фактором в скорости создания продукта. Кстати, само понятие «что такое архитектор» у нас еще не сложилось. Если вы спросите трех людей из разных компаний, кто такой архитектор, то, скорее всего, получите три разных ответа.
Это для тебя, потому что:
На что стоит обратить внимание:
Источник
Это более редкий и менее популярный вариант. IT — такой же бизнес, и всю работу разработчиков нужно продвигать. Это направление находится где-то между продажами, рекрутингом и маркетингом. Сюда попадают такие должности как Developer Advocate и Евангелист. Человеку с большим техническим опытом проще объяснить другим разработчикам, в чем преимущества того или иного продукта, найти подход и “правильно” рассказать про свою компанию. Ни один классический маркетолог не сделает это так, как человек, который сам был когда-то разработчиком. А уж тем более, если ваша задача – это развитие HR-бренда, то есть привлечение и удержание разработчиков в своей компании. Такие люди, как правило, много общаются в соцсетях, пишут статьи и выступают на конференциях. Этот путь не для интровертов.
Это для тебя, потому что:
На что стоит обратить внимание:
Источник
Актуально как для продуктовых, так и для аутсорсных компаний. В продолжение темы предыдущего пункта, работа программистов требует не только продвижения, но и продаж. Тут можно выделить две большие подкатегории. С одной стороны, это классический сотрудник отдела продаж: предложение услуг или продукта, обсуждение условий и т.д. Технический опыт тут помогает меньше, требуется большее понимание бизнеса и умение общаться. С другой стороны, это такие специалисты, как Solution Architect, которые предлагают заказчику конкретные решения проблем, подбирают подходящий набор продуктов. Во втором случае опыт разработки сильно играет на руку.
Это для тебя, потому что:
На что стоит обратить внимание:
Источник
Имея опыт нескольких проектов и пройдя путь от джуниора до синьора, разработчик понимает, как работают приложения изнутри, как они должны работать со стороны пользователя, и, что самое главное, как удовлетворить обе стороны. Если вы не умеете рисовать и работать с графическими редакторами, но хотите творческой работы, вам сюда. Продумывание деталей продукта — важный этап, если изначально выбрать неправильную концепцию, дальше можно потерять очень много ресурсов на устранении ошибок. Аналитик с опытом разработки знает не только, как сделать хорошо пользователям, но и насколько сложно это будет реализовать разработчикам. Найдя баланс, можно сильно сэкономить время компании и заказчику.
Это для тебя, потому что:
На что стоит обратить внимание:
Источник
IT — это не только практика. Есть огромный пласт тем, которые требуют изучения. При наличии хорошего уровня теоретических знаний и многолетнего практического опыта, можно попробовать себя в исследовании новых подходов и инструментов. Уйти в науку и перейти от практики к теории.
Это для тебя, потому что:
На что стоит обратить внимание:
Источник
Накопленный, но не переданный опыт — пустая трата времени. Имея за спиной огромный багаж знаний, подводных камней и собранных граблей, просто необходимо передавать его новому поколению специалистов. Это один из ключевых моментов развития всей IT-сферы. Вас ждут преподавание в университете или открытие собственных курсов, выступления на конференциях и митапах с техническими темами. А может быть, стоит создать корпоративный университет внутри своей компании? Кстати, никто не отменяет совмещение преподавания с Вашей текущей работой. Именно так надо начинать путь преподавания.
Это для тебя, потому что:
На что стоит обратить внимание:
Я намеренно не стал ничего писать про конкретные навыки специалистов. Эти пути доступны как суровым бэкэндщикам, так и кропотливым тестировщикам, как творческим фронт-разработчикам, так и отъявленным мобильщикам. Никто и никогда не помешает остановиться на достигнутом уровне и начать развиваться в ширину, постигать те знания, которыми жонглируют ребята за соседними столами. Так рождаются full stack разработчики. Зная, как располагаются цвета на других сторонах кубика Рубика, намного легче собрать свою.
Важно помнить, что не обязательно концентрироваться на чем-то одном. Например, преподавать можно параллельно с любым из остальных пунктов, выступать на конференциях, рассказывая о продукте, над которым работаешь в основное время, заниматься наукой и проектировать приложения, развивать Open Source. Эти восемь пунктов лишь капля в море возможностей. Например, еще есть продукт оунеры, коучи, можно создать собственный бизнес. Я за свою бытность в «Рексофте» видел коллег, которые выбрали и успешно реализовали каждый из описанных выше путей. Ограничений нет, сфера информационных технологий шире, чем кажется, а объем еще не проделанной работы колоссален. Главное – найти свое место в этом океане и делать свою работу качественно и ответственно, и получать кайф от того, что делаешь! И помните, все стереотипы у вас в голове, не бойтесь пробовать себя и развиваться!
Это материал руководителя группы практики Java компании «Рексофт» Зураба Белого, написанный по итогам его выступления на SECR-2019. Доклад получил первое место по результатам голосования участников мероприятия.
Источник
В сфере информационных технологий много стереотипов, как и везде. Один из них касается карьеры разработчика. Иногда кажется, что, если ты пишешь код в сорок лет, с тобой что-то не то, и единственный путь – расти и становиться руководителем. Из-за этого я периодически наблюдаю картину, когда опытные разработчики не двигаются с места годами, ожидая “того самого места выше”. Но те пути развития специалиста, о которых я расскажу ниже, полезно знать нам всем, от джуниора до синьора — сменить направление работы никогда не поздно. Оговорюсь сразу. Я не буду говорить о деньгах и зарплатах (оставим все это за рамками, наконец, есть hh.ru), а буду рассуждать именно о возможном творческом и карьерном развитии.
Я могу выделить несколько основных путей развития в IT для тех, кто имеет опыт разработчика. Каждый из них очевиднее предыдущего, кто-то может вообще ничего нового не услышать. Но часто то, что мы ищем, как раз и лежит на поверхности, нужно только обратить на это внимание.
Итак, поехали:
Источник
1. Переходить в руководство
Тот самый “стандартный” путь, живущий в умах большинства разработчиков. Куда он приводит знакомо всем: руководство группой (TeamLead), проектами, отделом, технологической практикой, техдиректор… В каждой компании свой набор должностей. Этот вариант предполагает наличие навыков управления. Нужно начинать изучать премудрости менеджмента, находить подход к людям, понимать, как работает компания. Опыт разработчика тут уже уходит на второй план и выступает в качестве бэкграунда. Код писать становится уже либо совсем не нужно, либо нужно в гораздо меньшем объеме.
Это для тебя, потому что:
- Нет необходимости писать код, актуально для тех, кто хочет что-то поменять.
- Реальное управление и влияние.
На что стоит обратить внимание:
- Нужно будет много копать в другом направлении – хорошими управленцами не рождаются. Придется серьезно учиться.
- Накопленный опыт разработчика применяется уже косвенно. Знание, как задеплоить докер в кубернетис, вам не потребуется. И те 10 лет, которые вы потратили, чтобы стать сеньором, можно вычеркнуть. Вы становитесь джуниором в менеджменте – и это тоже надо принять, чтобы все получилось.
- Выше уровень ответственности. Когда вы пишете код, вы отвечаете только за него. При переходе в руководство ответственность повышается в разы. Вы отвечаете за всю команду и проект, а значит и за деньги для вашей команды или даже компании.
- Меньше вакансий. Разработчики нужны и желанны буквально в любой компании. Как только вы претендуете на руководящую должность, количество вариантов для перехода сокращается. И чем выше позиция, тем круг компаний для выбора меньше.
Источник
2. Продолжить писать код
Тут все просто: продолжаешь делать то, что тебе интересно. Осваиваешь новые подходы и технологии, развиваешься в ширину. Имея огромный опыт, можно уже не уделять много времени написанию кода, но быстро вникать в контекст проблемы и эффективно ее решать, заниматься обучением и наставничеством. Если долгое время, а лучше с самого начала, работать в рамках одного продукта, то рано или поздно будешь знать все, даже самые отдаленные и темные уголки кода. Обычно должность таких разработчиков имеет префикс Principal или Expert. Это рок-звезды программирования. Такие сотрудники высоко ценятся не только в текущей компании, но и на рынке в целом. Многие даже не задумываются об этом пути развития, а он того стоит и стоит тех усилий, которые придется вложить.
Это для тебя, потому что:
- Весь накопленный опыт используется каждый день.
- Нет кардинальных изменений в работе.
- Высокая ценность на рынке, за вами охотятся.
На что стоит обратить внимание:
- Приходится успевать за развитием технологий, чтобы оставаться на плаву и в своем статусе.
- Подходит только для тех, кому нравится сам процесс разработки.
- Риск «мнимого» роста. Он особенно подстерегает людей, давно работающих на одном проекте. Тезис следующий: если вам кажется, что вы знаете все, потому что видели каждый потаенный участок кода своего проекта, это абсолютно не значит, что, если вас пересадить на другой проект, все получится. Как проверить себя? Попробуйте сделать что-то на технологиях, незнакомых вам.
Источник
3. Податься в архитекторы
Возвращаемся к техническим направлениям. Если написание кода можно приравнять к выточке деталей на станке, то тут речь пойдет о создании чертежей этой самой детали, а то и всего агрегата. Проектирование будущего продукта, создание фундамента, выбор используемых решений — это все требует глубоких знаний в предметной области и часто становится ключевым фактором в скорости создания продукта. Кстати, само понятие «что такое архитектор» у нас еще не сложилось. Если вы спросите трех людей из разных компаний, кто такой архитектор, то, скорее всего, получите три разных ответа.
Это для тебя, потому что:
- Частая смена проектов. Сделали, следующий проект. Это драйв.
- Создание фундамента приложений. Кайф от глобальности своей задачи.
- Весь накопленный опыт используется на 100%, а то и 150%. Постоянный поиск нового и оптимального решения.
На что стоит обратить внимание:
- Высокая ответственность за каждый проект. Цена ошибки высока – это жизненный цикл вашей системы. А ее еще нет… Здание пока только в вашей голове.
- Много бумажной работы. Написание технических документов. Одно дело придумать, другое дело все это описать, включая большой объем правок от коллег и заказчика.
- Работа с типовыми архитектурами. А куда без них? И здесь иногда будет «день сурка».
- Умение отстаивать свою позицию и решение.
- Требуется постоянное изучение новых технологий и решений.
Источник
4. Опробовать маркетинг
Это более редкий и менее популярный вариант. IT — такой же бизнес, и всю работу разработчиков нужно продвигать. Это направление находится где-то между продажами, рекрутингом и маркетингом. Сюда попадают такие должности как Developer Advocate и Евангелист. Человеку с большим техническим опытом проще объяснить другим разработчикам, в чем преимущества того или иного продукта, найти подход и “правильно” рассказать про свою компанию. Ни один классический маркетолог не сделает это так, как человек, который сам был когда-то разработчиком. А уж тем более, если ваша задача – это развитие HR-бренда, то есть привлечение и удержание разработчиков в своей компании. Такие люди, как правило, много общаются в соцсетях, пишут статьи и выступают на конференциях. Этот путь не для интровертов.
Это для тебя, потому что:
- Общение с разными людьми.
- Выступления на конференциях и митапах.
- Жажда популярности и узнаваемости.
На что стоит обратить внимание:
- Требуется грамотная речь и умение быстро реагировать на неожиданные и порой очень нестандартные вопросы,
- Нужно уметь легко и быстро писать, знать иностранные языки
- Очень мало вакансий. Скорее это путь внутри своей компании.
- Одиночная работа, при калейдоскопе общения и людей вокруг. Можете забыть о понятии команда, к которому вы привыкли в разработке.
- Постоянные командировки и поездки. И это не романтика (О! Я объезжу весь мир!), это тяжелый труд, вереница отелей и постоянное отсутствие дома.
Источник
5. Стать звездой продаж
Актуально как для продуктовых, так и для аутсорсных компаний. В продолжение темы предыдущего пункта, работа программистов требует не только продвижения, но и продаж. Тут можно выделить две большие подкатегории. С одной стороны, это классический сотрудник отдела продаж: предложение услуг или продукта, обсуждение условий и т.д. Технический опыт тут помогает меньше, требуется большее понимание бизнеса и умение общаться. С другой стороны, это такие специалисты, как Solution Architect, которые предлагают заказчику конкретные решения проблем, подбирают подходящий набор продуктов. Во втором случае опыт разработки сильно играет на руку.
Это для тебя, потому что:
- Работа в самом сердце бизнеса, вы будете зарабатывать деньги.
- Общение напрямую с заказчиком. Много встреч и переговоров.
- Никакого кода.
- Вам сюда, если вы хотите заработать все золото мира.
На что стоит обратить внимание:
- Требуется грамотная речь, и, скорее всего, знание английского.
- Требуются навыки продаж, в том числе, умение вести переговоры. Если для вас проблема, поторговаться с бабушкой на рынке…., то вам придется ломать себя.
- Необходимо понимание бизнеса заказчика и своих продуктов. Сейчас в условиях цифровой трансформации без этого никуда.
Источник
6. Переквалифицироваться в аналитики
Имея опыт нескольких проектов и пройдя путь от джуниора до синьора, разработчик понимает, как работают приложения изнутри, как они должны работать со стороны пользователя, и, что самое главное, как удовлетворить обе стороны. Если вы не умеете рисовать и работать с графическими редакторами, но хотите творческой работы, вам сюда. Продумывание деталей продукта — важный этап, если изначально выбрать неправильную концепцию, дальше можно потерять очень много ресурсов на устранении ошибок. Аналитик с опытом разработки знает не только, как сделать хорошо пользователям, но и насколько сложно это будет реализовать разработчикам. Найдя баланс, можно сильно сэкономить время компании и заказчику.
Это для тебя, потому что:
- Более творческая работа, чем разработка.
- Никакого кода.
- Наконец-то вы спроектируете “реально правильный интерфейс”. И теперь другие разработчики будут делать ваш “правильный и юзерфрендли интерфейс”.
- Широкая сфера деятельности. Сегодня у вас проект из банковской сферы, а через два месяца приложение авиакомпании или сети АЗС.
На что стоит обратить внимание:
- Много бумажной работы (гораздо больше, чем у архитектора).
- Знание предметной области и бизнеса заказчика. Разбираться в терминах и процессах.
- Требуются знания в проектировании интерфейсов.
Источник
7. Уйти в науку
IT — это не только практика. Есть огромный пласт тем, которые требуют изучения. При наличии хорошего уровня теоретических знаний и многолетнего практического опыта, можно попробовать себя в исследовании новых подходов и инструментов. Уйти в науку и перейти от практики к теории.
Это для тебя, потому что:
- Создание чего-то нового.
- Открытия.
- Ваш личный вклад в развитие IT в целом как отрасли.
- Возможность войти в историю.
На что стоит обратить внимание:
- Необходим высокий уровень теоретической подготовки. Вы же хорошо учились в универе?
- Скрупулезная, кропотливая и долгая работа.
- Готовность к тому, что ваша теория может быть неверна, или даст плоды через десятилетия.
Источник
8. Преподавать
Накопленный, но не переданный опыт — пустая трата времени. Имея за спиной огромный багаж знаний, подводных камней и собранных граблей, просто необходимо передавать его новому поколению специалистов. Это один из ключевых моментов развития всей IT-сферы. Вас ждут преподавание в университете или открытие собственных курсов, выступления на конференциях и митапах с техническими темами. А может быть, стоит создать корпоративный университет внутри своей компании? Кстати, никто не отменяет совмещение преподавания с Вашей текущей работой. Именно так надо начинать путь преподавания.
Это для тебя, потому что:
- Это для тех, кто любит объяснять и имеет дар к популяризации знаний.
- Вклад в развитие IT. Ваш труд – вклад в другое поколение.
- Повышение квалификации разработчиков.
- Сумасшедшая энергетика молодого поколения. Замечали, что преподаватели в универе часто хорошо выглядят и вообще молоды душой?
На что стоит обратить внимание:
- Умение объяснять – это непросто. Объяснить порой сложнее, чем сделать. Этому нужно учиться.
- Иметь крепкую психику. Вам придется раз за разом объяснять одно и то же и миллион раз отвечать на одни и те же вопросы.
- Нужен навык публичных выступлений перед большой аудиторией.
- Много времени на проверку домашней работы и вопросов от студентов. И это вне рабочего времени.
- Уверенное знание предмета, который преподаете.
- Обычно невысокие зарплаты.
Я намеренно не стал ничего писать про конкретные навыки специалистов. Эти пути доступны как суровым бэкэндщикам, так и кропотливым тестировщикам, как творческим фронт-разработчикам, так и отъявленным мобильщикам. Никто и никогда не помешает остановиться на достигнутом уровне и начать развиваться в ширину, постигать те знания, которыми жонглируют ребята за соседними столами. Так рождаются full stack разработчики. Зная, как располагаются цвета на других сторонах кубика Рубика, намного легче собрать свою.
Важно помнить, что не обязательно концентрироваться на чем-то одном. Например, преподавать можно параллельно с любым из остальных пунктов, выступать на конференциях, рассказывая о продукте, над которым работаешь в основное время, заниматься наукой и проектировать приложения, развивать Open Source. Эти восемь пунктов лишь капля в море возможностей. Например, еще есть продукт оунеры, коучи, можно создать собственный бизнес. Я за свою бытность в «Рексофте» видел коллег, которые выбрали и успешно реализовали каждый из описанных выше путей. Ограничений нет, сфера информационных технологий шире, чем кажется, а объем еще не проделанной работы колоссален. Главное – найти свое место в этом океане и делать свою работу качественно и ответственно, и получать кайф от того, что делаешь! И помните, все стереотипы у вас в голове, не бойтесь пробовать себя и развиваться!
Это материал руководителя группы практики Java компании «Рексофт» Зураба Белого, написанный по итогам его выступления на SECR-2019. Доклад получил первое место по результатам голосования участников мероприятия.
Комментарии (17)
Lofty
19.12.2019 12:22+1Риск «мнимого» роста. Он особенно подстерегает людей, давно работающих на одном проекте. Тезис следующий: если вам кажется, что вы знаете все, потому что видели каждый потаенный участок кода своего проекта, это абсолютно не значит, что, если вас пересадить на другой проект, все получится. Как проверить себя? Попробуйте сделать что-то на технологиях незнакомых вам.
Мне кажется это правда лишь отчасти и в такой формулировке выглядит, как будто это писал кто-то из HR. Само собой при использовании новых, не знакомых тебе технологий, ты будешь испытывать какие-то трудности. Даже имея за плечами большой и разнообразный опыт можно столкнуться с парадигмой, которая тебя раньше обходила стороной. Но сам по себе факт, что ты не сразу начинаешь разбираться в новых для себя технологиях так же, как и в хорошо знакомых, не обесценивает твой опыт и не делает рост «мнимым». В общем случае, если ты глубоко познал какую-то технологию, то и другую скорее всего сможешь освоить, при условии, что она не следует какой-нибудь диаметрально противоположной концепции, что бывает не часто. И никак не «Не можешь сходу эффективно использовать незнакомую технологию — никакой ты не синьор».
Переквалифицироваться в аналитики
Вкину спорное утверждение — в таком виде, как описано в статье аналитики существовать не должны. Удобством интерфейсов должны заниматься специально обученные люди а в бизнесе должны побольше разбираться разработчики. Аналитик, по сути, выступает интерфейсом между источником требований и теми, кто их реализует. И в том виде, который описан в статье, он превращается в очень обширный интерфейс, нарушая тем самым interface segregation principle. Так что чем меньше в вашей структуре аналитиков в «классическом понимании», тем, на мой взгляд, лучше.
dim_s
19.12.2019 15:38На счет мнимого роста, это вполне реально и я на практике встречал таких людей не раз. Так что этот вариант возможен, но далеко не во всех случаях.
somebody4
19.12.2019 18:07+1Продолжить писать код
Особое преимущество, что после получения достаточного опыта, делая левой ногой за полчаса, ты всё равно будешь делать лучше и качественнее и на фоне остальных будет казаться что ты суперзвезда. И если достаточно опыта, то новые технологии заходят легче и быстрее чем раньше и «успевать за развитием технологий, чтобы оставаться на плаву и в своем статусе» не проблема.
Податься в архитекторы
Всегда интересно чем занимаются архитекторы на проекте после того как архитектура выбрана, описана и т.п. А потом надо просто пилить его годами.
Понятно если ты архитект в компании и там десять проектов текущих проектов и новые всё время добавляются. Но на самом деле если посмотртеть, то на каждом проекте из трех калек, парачка из них, архитекты, а оставшийся, принципал архитект.
Или это в основном про лычки?
chapuza
20.12.2019 10:32после того как архитектура выбрана, описана и т.п. А потом надо просто пилить его годами.
Смешно :)
PyerK
19.12.2019 23:13А как же вариант сделать свой стартап? Можно хоть 30 лет работать на кого-то, но сопоставимого объёма знания, опыта общения, убеждения, понимания процессов и людей не получишь.
mvv-rus
20.12.2019 03:16IMHO забыт идеальный вариант дальнейше карьеры:
9. Консалтинг
Это для тебя, потому что:
- Ты о себе высокого мнения, и это невидимым током флюидов передается окружающим
- Ты не любишь и не хочешь отвечать за результат
- Ты легко схватываешь новые модные технологии по верхам, но устал подробно изучать каждую из них
- На свой внешний вид: встречают по одежке
- На манеру речи
- На Social Skills
- На постоянное обновление своего списка модных технологий: впрочем, тут достаточно уметь завлекательно рассказывать о них, глубоко их знать не обязательно
- На наличие знакомых, которые реально смогут сделать порекомендованное; хотя, при высоких Social Skills можно обойтись и без этого.
chapuza
20.12.2019 10:31Обычно должность таких разработчиков имеет префикс Principal или Expert.
После Senior есть еще две ступени с общепринятыми названиями Principal и Distinguished.
И да, вот эти двое обычно и аналитики, и архитекторы, и немного консультвнты вообще везде, их зовут на все принципиальные совещания по развитию продукта.
JustDont
Странно, что в списке есть «уйти в науку» и «уйти в маркетинг», но нет, например, «уйти в машинисты электропоезда». Общего между программированием и сабжем во всех случаях — одинаково нисколько.
oldschoolgeek
Если под наукой понимается именно computer science, то прошлый опыт программирования пригодится куда как с большей вероятностью, чем в кабине электровоза :)
Что же касается маркетинга (подразумевая, что речь о маркетинге в рамках ИТ отрасли), то тут даже и говорить не о чём: знание технической стороны вопроса — это очень сильный плюс.
Neikist
В биоинформатике вроде как тоже программисты бывшие нужны) Как и во многих других областях. Ну в смысле опыт программирования будет полезен для эффективного анализа данных, написания для себя вспомогательных тулзов и т.п. Сколько сейчас говорят про кризис воспроизводимости по причине что не могут восстановить что там ученый накодил и наанализировал.
JustDont
Опыт программирования, если натягивать сову на глобус, можно приткнуть много куда.
А вот в академию «со стороны» так вот просто не попасть, опыт у вас или не опыт. Можно конечно говорить о сферических в вакууме случаях, но институциональные барьеры тут сыграют ту же практическую роль, что и, например, в случае «уйти в маркетинг» или еще куда-то, где багаж знаний не очень релевантен.
0xd34df00d
Хехе, прям сегодня, вот 20 минут назад, наконец, решился написать письма паре профессоров на тему, нет ли у них каких открытых позиций в ресерч-группах. Посмотрим, как пойдет.
JustDont
Ну, надеюсь, что в США с закрытостью академии чуть лучше. Я знаю только ситуацию в РФ и некоторых странах ближнего зарубежья, и там — ужс. В лучшем случае можно поработать, как говорится, «на птичьих правах» и за очень условные деньги, а в худшем и с этим не выходит.
Carduelis
Вообще, очень даже большая разница. Написать нейросеть и сконструировать роборуки, во-первых, сложно, во-вторых, не дадут использовать. Это, чтобы как-то применить багаж знаний при работе машинистом.
А вот про науку и маркетинг… И там, и там, можно и нужно программировать, составлять отчеты (для себя же), регрессии и прочие красивые картинки.
Сегодняшний маркетинг без анализа, без программирования — это пыль в глаза. Настоящий таргетинг начинается хотя бы с азов программирования. Более того, я еще не видел ни одной маркетологическо-таргетинговой системы с настроенным CI/CD. (не говоря про inhouse-решения).
А уж науку можно развивать прямо по специальности: применять научные подходы к сравнению парадигм, фреймворков, методов, а не как 99% статей, основанных на личном опыте с использованием эмпирического подхода.
JustDont
Вы слишком плохо пытаетесь натянуть сову. Это — не дадут, а вот применить навыки алгоритмизации к деятельности машиниста — вполне возможно. Сильно много это конечно же не даст (потому что там уже много что проделано), но что делать.
И там, и там — программировать это совсем не главное. Как и в случае с машинистом. Да, вы с высокой вероятностью сможете добавить программирование к прочим профильным навыкам, и получить с этого большую отдачу (well, большую чем для машиниста) — но это разница количественная, а никак не качественная. И главное — вам всё равно будут нужны другие профильные навыки (или публикации и прочая хрень, если речь про академию).
tretyakovmax
А интересно, насколько реален такой путь для категории «после 30-ти»? )
chapuza
Я в 30 ушел (и несколько месяцев проработал) в копирайтеры (в не связанной с техникой тематике). Считается?