Комментарии 20
Что же касается маркетинга (подразумевая, что речь о маркетинге в рамках ИТ отрасли), то тут даже и говорить не о чём: знание технической стороны вопроса — это очень сильный плюс.
Если под наукой понимается именно computer science, то прошлый опыт программирования пригодится куда как с большей вероятностью, чем в кабине электровоза :)
Опыт программирования, если натягивать сову на глобус, можно приткнуть много куда.
А вот в академию «со стороны» так вот просто не попасть, опыт у вас или не опыт. Можно конечно говорить о сферических в вакууме случаях, но институциональные барьеры тут сыграют ту же практическую роль, что и, например, в случае «уйти в маркетинг» или еще куда-то, где багаж знаний не очень релевантен.
Вообще, очень даже большая разница. Написать нейросеть и сконструировать роборуки, во-первых, сложно, во-вторых, не дадут использовать. Это, чтобы как-то применить багаж знаний при работе машинистом.
А вот про науку и маркетинг… И там, и там, можно и нужно программировать, составлять отчеты (для себя же), регрессии и прочие красивые картинки.
Сегодняшний маркетинг без анализа, без программирования — это пыль в глаза. Настоящий таргетинг начинается хотя бы с азов программирования. Более того, я еще не видел ни одной маркетологическо-таргетинговой системы с настроенным CI/CD. (не говоря про inhouse-решения).
А уж науку можно развивать прямо по специальности: применять научные подходы к сравнению парадигм, фреймворков, методов, а не как 99% статей, основанных на личном опыте с использованием эмпирического подхода.
Вообще, очень даже большая разница. Написать нейросеть и сконструировать роборуки, во-первых, сложно, во-вторых, не дадут использовать.
Вы слишком плохо пытаетесь натянуть сову. Это — не дадут, а вот применить навыки алгоритмизации к деятельности машиниста — вполне возможно. Сильно много это конечно же не даст (потому что там уже много что проделано), но что делать.
А вот про науку и маркетинг… И там, и там, можно и нужно программировать, составлять отчеты (для себя же), регрессии и прочие красивые картинки.
И там, и там — программировать это совсем не главное. Как и в случае с машинистом. Да, вы с высокой вероятностью сможете добавить программирование к прочим профильным навыкам, и получить с этого большую отдачу (well, большую чем для машиниста) — но это разница количественная, а никак не качественная. И главное — вам всё равно будут нужны другие профильные навыки (или публикации и прочая хрень, если речь про академию).
Риск «мнимого» роста. Он особенно подстерегает людей, давно работающих на одном проекте. Тезис следующий: если вам кажется, что вы знаете все, потому что видели каждый потаенный участок кода своего проекта, это абсолютно не значит, что, если вас пересадить на другой проект, все получится. Как проверить себя? Попробуйте сделать что-то на технологиях незнакомых вам.
Мне кажется это правда лишь отчасти и в такой формулировке выглядит, как будто это писал кто-то из HR. Само собой при использовании новых, не знакомых тебе технологий, ты будешь испытывать какие-то трудности. Даже имея за плечами большой и разнообразный опыт можно столкнуться с парадигмой, которая тебя раньше обходила стороной. Но сам по себе факт, что ты не сразу начинаешь разбираться в новых для себя технологиях так же, как и в хорошо знакомых, не обесценивает твой опыт и не делает рост «мнимым». В общем случае, если ты глубоко познал какую-то технологию, то и другую скорее всего сможешь освоить, при условии, что она не следует какой-нибудь диаметрально противоположной концепции, что бывает не часто. И никак не «Не можешь сходу эффективно использовать незнакомую технологию — никакой ты не синьор».
Переквалифицироваться в аналитики
Вкину спорное утверждение — в таком виде, как описано в статье аналитики существовать не должны. Удобством интерфейсов должны заниматься специально обученные люди а в бизнесе должны побольше разбираться разработчики. Аналитик, по сути, выступает интерфейсом между источником требований и теми, кто их реализует. И в том виде, который описан в статье, он превращается в очень обширный интерфейс, нарушая тем самым interface segregation principle. Так что чем меньше в вашей структуре аналитиков в «классическом понимании», тем, на мой взгляд, лучше.
А как же вариант сделать свой стартап? Можно хоть 30 лет работать на кого-то, но сопоставимого объёма знания, опыта общения, убеждения, понимания процессов и людей не получишь.
9. Консалтинг
Это для тебя, потому что:
- Ты о себе высокого мнения, и это невидимым током флюидов передается окружающим
- Ты не любишь и не хочешь отвечать за результат
- Ты легко схватываешь новые модные технологии по верхам, но устал подробно изучать каждую из них
- На свой внешний вид: встречают по одежке
- На манеру речи
- На Social Skills
- На постоянное обновление своего списка модных технологий: впрочем, тут достаточно уметь завлекательно рассказывать о них, глубоко их знать не обязательно
- На наличие знакомых, которые реально смогут сделать порекомендованное; хотя, при высоких Social Skills можно обойтись и без этого.
ты появился, когда никто тебя не звал, хочешь получить плату за ответ, который я уже знаю, на вопрос, который тебе никто не задавал, и к тому же ты ни хрена не смыслишь в моей работе
А плох или хорош — это смотря с какой стороны смотреть. Мне вот, по жизни, всё больше приходилось свою собаку возвращать. Но в каждом таком случае была и другая сторона, и люди на ней бабло делавшие.
Обычно должность таких разработчиков имеет префикс Principal или Expert.
После Senior есть еще две ступени с общепринятыми названиями Principal и Distinguished.
И да, вот эти двое обычно и аналитики, и архитекторы, и немного консультвнты вообще везде, их зовут на все принципиальные совещания по развитию продукта.
Ну возможно кого-то заинтересует именно видео доклада Зураба по этой теме → http://www.0x1.tv/20191114AM (слабовидящие, желающие подкрепится харизмой докладчика и т.п.)
Есть ли жизнь после Синьора?