У меня за всю карьеру был буквально только один случай, когда мне отказались поднимать з\п при наличии оффера от другой компании или слов об этом оффере. Возможно, все дело только в том, насколько конкретный человек ценный для компании и какой вклад он дает в проект и продукт. Любой поиск нового человека стоит денег. А новый человек в месяц будет обходиться не дешевле старого уж точно(что-то давно рынок у нас не "падал" по зарплатам, как-то движется все наоборот обычно), а еще ему потребуется много времени на онбординг, вникание в бизнес-процессы и так далее и тому подобное. Так что нет, история не выдуманая, а вполне себе распространенная
Компании разные, ситуации разные, рыночное положение разное, бюджеты разные, доступное время более опытных спецов разное. Обожаю статьи в духе: "Делайте все как мы, это хорошо" без оговорок на контекст) Но нанимать джунов, скажем, в стартап - плохая идея.
Мой тезис заключается в том, что инжиниринговые умения здесь совершенно на втором плане. Понимать что происходит и иметь бэкграунд определенно нужно. Но ваше умение писать хороший код или, скажем, настраивать Jenkins ни на йоту не приближает вас к позиции CTO)
Человек не обладающий нужными менеджерскими скиллами либо не станет CTO, либо гарантированно будет очень плохим CTO. Хороший менеджер, не написавший в жизни ни строчки коммерческого кода может быть успешным CTO
Сравнение можно привести очень простое. Начальник производства на заводе. Конечно, неплохо, если начальник производства сам когда-то крутил гайки на этом же заводе. Но вот вообще не обязательно)
Вы тоже не горите желанием принимать другую точку зрения, только и всего) Возможно, никому из вас этого и не надо?) У всех свой путь и понимание мира, индустрии, происходящего. Вероятно, не всегда стоить убеждать человека в своей точке зрения. Но ментальная гимнастика забавная у вас тут получилась.
Про менеджмент, просто вкину мысль, что менеджмент это тоже программирование, просто машины намного более сложные и забагованные по самый небалуй, а языков программирования для них нет. Но и возможностей у них пока что значительно больше.
Олег, слежу за тредом, отвечу здесь) Это бесполезно программистам доказывать, что это "скучно" и "рутинно" и что они не делают что-то новое. И Вы тоже таким были. И я таким был. Это лечится годами в индустрии и ростом в ней. А у кого-то не лечится. И это тоже хорошо. Я понимаю о чем вы говорите и поддерживаю Вашу точку зрения, но по сути идет разговор слепого с глухим. Написал просто поддержать и пожелать добра)
В конце концов, чтобы компьютер работал код вообще не обязателен. Это лишь удобная абстракция. Которой может не быть. Можно программировать подавая и убирая напряжение с транзисторов. Программа должна быть понятна ИСПОЛНИТЕЛЮ в первую очередь. Код создан для того, чтобы быть понятным людям. Что такое программа в общем смысле? Набор инструкций. Если я даю своей розетке понятный ей набор инструкций(которые не содержат код) я ее программирую. Если я задаю этот набор инструкций при помощи рычагов ткацкому станку - поздравляю, я сделал программу для ткацкого станка
Давайте вместе подумаем, в какое место на этой машине нужно написать код.
Вам помочь нагуглить программы работающие без кода? Видели когда-нибудь ткацкий станок, производящий узор? Как работает механический таймер розетки представляете? А как работает реле, которое при определенной температуре подает напряжение, а при другой - нет? Про Аду Лавлейс, в конце-то концов что-то слышали?
Более того, в статье вы постоянно утверждаете "Конечная цель программирования". Не написания кода, а именно программирования. А тупой в итоге я, потому что под программированием должен был понять именно то, что понимаете вы, догадаться)
Человек со средним интеллектом способен вытащить из поста информацию, что он всё-таки именно про написание кода,
Ну значит, мой интеллект ниже среднего) И мы уже с вами не раз обсуждали, что для меня утверждение, что "конечная цель программирования" подразумевает вообще какой-то код не кажется очевидной. Что если я программирую при помощи диаграмм? Что если я программирую таймер на розетке? Что если я программирую свою любимую мультиварку? Ни в одном из этих случаев я не пишу никакой код.
Где технические детали? Хоть какие-то подробности процесса разработки? Или проработки идеи? Может расскажете что-то про бизнес-составляющую? Или про то, благодаря чему вы разработали продукт за 4 месяца, а не за год? Здесь только реклама, ничего больше. Занесите денег в Кассу Хабре и рекламируйтесь. Но это явно не тянет на пост и уж тем более на ТУТОРИАЛ. Чему вы научили в этой статье?
Я один не понимаю, почему HR'ы почти каждый день приходят на Хабру оправдываться и говорить что "не все HR плохие"? Как какие-то астрологи. Вон тот астролог шарлотан, а я нормальный
Не дискусиионо, а прямая неправда. CTO - менеджер. При этом высший менеджер в технической цепочки. CTO может не обладать качествами хорошего программиста или продакта. Все что от него требуется - умение организовать IT-департамент, привлечь нужных экспертов, наладить процессы и т.д и т.п.
Мимо 12 лет в IT и если честно, в этом комментарии вы написали полную херню, уж простите. Начнем с того, что системный аналитик и девопс - это НЕ рост разработчика. Вы как HR наверное понимаете, что Senior разработчик получает не меньше Senior DevOps/Senior Analyst. Это просто горизонтальная ротация, смена специализации.
К статье. Я искренне не понимаю, почему опыт ТЕСТИРОВЩИКА или АНАЛИТИКА должен предшествовать опыту ПРОДАКТА? Ну вы это серьезно? Где вы это берете? Product менеджер - отдельная специальность, можно начать сразу с этого став, внезапно, Junior Product Manager. И такой каши в вашей статье и картинках пруд пруди. Вы выдаете горизонтальную ротацию за рост. Это не так. Если я был Senior разработчиком, а стал Senior тестировщиком, или, скажем, Senior Project manager'ом - я НЕ вырос. Это как говорить, что из дизайнера сайтов можно вырасти в дизайнера упаковок.
У меня за всю карьеру был буквально только один случай, когда мне отказались поднимать з\п при наличии оффера от другой компании или слов об этом оффере. Возможно, все дело только в том, насколько конкретный человек ценный для компании и какой вклад он дает в проект и продукт. Любой поиск нового человека стоит денег. А новый человек в месяц будет обходиться не дешевле старого уж точно(что-то давно рынок у нас не "падал" по зарплатам, как-то движется все наоборот обычно), а еще ему потребуется много времени на онбординг, вникание в бизнес-процессы и так далее и тому подобное. Так что нет, история не выдуманая, а вполне себе распространенная
Компании разные, ситуации разные, рыночное положение разное, бюджеты разные, доступное время более опытных спецов разное. Обожаю статьи в духе: "Делайте все как мы, это хорошо" без оговорок на контекст) Но нанимать джунов, скажем, в стартап - плохая идея.
Комментарий, который в 100 раз полезней основного поста. Полностью согласен, сам так делал.
Или не была, а взяли первый попавшийся инструмент. Так или иначе, в статье нет об этом ни слова. Как и о других технических решениях.
Так я же нигде и не говорил, что не нужен бэкграунд в IT. Наоборот, говорил исключительно обратное)
Простите, а где отбирают в программисты? Куда в очередь встать?
Не удрежался)
Мой тезис заключается в том, что инжиниринговые умения здесь совершенно на втором плане. Понимать что происходит и иметь бэкграунд определенно нужно. Но ваше умение писать хороший код или, скажем, настраивать Jenkins ни на йоту не приближает вас к позиции CTO)
Человек не обладающий нужными менеджерскими скиллами либо не станет CTO, либо гарантированно будет очень плохим CTO. Хороший менеджер, не написавший в жизни ни строчки коммерческого кода может быть успешным CTO
Сравнение можно привести очень простое. Начальник производства на заводе. Конечно, неплохо, если начальник производства сам когда-то крутил гайки на этом же заводе. Но вот вообще не обязательно)
Вы тоже не горите желанием принимать другую точку зрения, только и всего) Возможно, никому из вас этого и не надо?) У всех свой путь и понимание мира, индустрии, происходящего. Вероятно, не всегда стоить убеждать человека в своей точке зрения.
Но ментальная гимнастика забавная у вас тут получилась.
Про менеджмент, просто вкину мысль, что менеджмент это тоже программирование, просто машины намного более сложные и забагованные по самый небалуй, а языков программирования для них нет. Но и возможностей у них пока что значительно больше.
Олег, слежу за тредом, отвечу здесь) Это бесполезно программистам доказывать, что это "скучно" и "рутинно" и что они не делают что-то новое. И Вы тоже таким были. И я таким был. Это лечится годами в индустрии и ростом в ней. А у кого-то не лечится. И это тоже хорошо.
Я понимаю о чем вы говорите и поддерживаю Вашу точку зрения, но по сути идет разговор слепого с глухим.
Написал просто поддержать и пожелать добра)
В конце концов, чтобы компьютер работал код вообще не обязателен. Это лишь удобная абстракция. Которой может не быть. Можно программировать подавая и убирая напряжение с транзисторов. Программа должна быть понятна ИСПОЛНИТЕЛЮ в первую очередь. Код создан для того, чтобы быть понятным людям. Что такое программа в общем смысле? Набор инструкций. Если я даю своей розетке понятный ей набор инструкций(которые не содержат код) я ее программирую. Если я задаю этот набор инструкций при помощи рычагов ткацкому станку - поздравляю, я сделал программу для ткацкого станка
Давайте вместе подумаем, в какое место на этой машине нужно написать код.
Вам помочь нагуглить программы работающие без кода? Видели когда-нибудь ткацкий станок, производящий узор? Как работает механический таймер розетки представляете? А как работает реле, которое при определенной температуре подает напряжение, а при другой - нет? Про Аду Лавлейс, в конце-то концов что-то слышали?
Более того, в статье вы постоянно утверждаете "Конечная цель программирования". Не написания кода, а именно программирования. А тупой в итоге я, потому что под программированием должен был понять именно то, что понимаете вы, догадаться)
Возможно, мир бы стал даже чуточку лучше, веселей и честней)
Ну значит, мой интеллект ниже среднего) И мы уже с вами не раз обсуждали, что для меня утверждение, что "конечная цель программирования" подразумевает вообще какой-то код не кажется очевидной. Что если я программирую при помощи диаграмм? Что если я программирую таймер на розетке? Что если я программирую свою любимую мультиварку? Ни в одном из этих случаев я не пишу никакой код.
Я даже ПТУ не закончил. Я даже не кодер получается? Так, обезьяна перед компом?))
Где технические детали? Хоть какие-то подробности процесса разработки? Или проработки идеи? Может расскажете что-то про бизнес-составляющую? Или про то, благодаря чему вы разработали продукт за 4 месяца, а не за год?
Здесь только реклама, ничего больше. Занесите денег в Кассу Хабре и рекламируйтесь. Но это явно не тянет на пост и уж тем более на ТУТОРИАЛ. Чему вы научили в этой статье?
Я один не понимаю, почему HR'ы почти каждый день приходят на Хабру оправдываться и говорить что "не все HR плохие"? Как какие-то астрологи. Вон тот астролог шарлотан, а я нормальный
Простите. Как будто бы автор статьи вчера пришел в IT, не разобрался в базовых ролях и пришел учить нас строить карьеру....
Не дискусиионо, а прямая неправда. CTO - менеджер. При этом высший менеджер в технической цепочки. CTO может не обладать качествами хорошего программиста или продакта. Все что от него требуется - умение организовать IT-департамент, привлечь нужных экспертов, наладить процессы и т.д и т.п.
Мимо 12 лет в IT и если честно, в этом комментарии вы написали полную херню, уж простите. Начнем с того, что системный аналитик и девопс - это НЕ рост разработчика. Вы как HR наверное понимаете, что Senior разработчик получает не меньше Senior DevOps/Senior Analyst. Это просто горизонтальная ротация, смена специализации.
К статье. Я искренне не понимаю, почему опыт ТЕСТИРОВЩИКА или АНАЛИТИКА должен предшествовать опыту ПРОДАКТА? Ну вы это серьезно? Где вы это берете? Product менеджер - отдельная специальность, можно начать сразу с этого став, внезапно, Junior Product Manager. И такой каши в вашей статье и картинках пруд пруди. Вы выдаете горизонтальную ротацию за рост. Это не так. Если я был Senior разработчиком, а стал Senior тестировщиком, или, скажем, Senior Project manager'ом - я НЕ вырос. Это как говорить, что из дизайнера сайтов можно вырасти в дизайнера упаковок.