У меня 20 лет назад было уже 17 лет опыта. Насколько я помню, получал как раз в районе 100 тыс. рублей на должности Business Application Manager в российском филиале крупной агропромышленной корпорации.
В целом, верю. Во-первых, это уже управленческая должность. А во-вторых, людей с 17 годами IT-опыта 20 лет назад было реально мало.
Вот только ветка была про затраты на джунов и то, что сейчас они стали менее выгодной инвестицией. Поэтому ваш пример не слишком релевантен.
Хм, я 17 лет назад, как начинающий программист (ака джун) получал 8 т.р. gross за полставки. Кто 20 лет назад получал 100 т.р. даже сложно представить. Может, такие программисты и были, но это явно что-то крайне редкое было. Если по российской инфляции пересчитать, то моя тогдашняя зарплата - это 57 т.р. gross по текущим деньгам за полную ставку.
При этом я в момент трудоустройства уже имел опыт студенческих проектов на Delphi и C#, плюс знания по PHP, JS, HTML, CSS и базам данных.
Нынешние кандидаты в джуны гораздо наглее: думают, что можно немного поизучать один ЯП и ждать оффер на 100 т.р.
А мониторить при этом надо все. Прямо просто все. Любой кусок кода должен быть наблюдаем.
Ну, я ж говорю, культ мониторинга. Если коротко, то вы не правы. Всё подряд мониторить - это как раз таки равно создавать лишний шум. Мониторить надо то, что важно мониторить и это вполне может быть указано в постановке задачи. А уж кто там у вас их мидлам ставит, сеньоры, сисаналитики или исключительно техлид - это уже специфика вашей команды.
Так это комплексы какие-то, если для вас существует только 2 крайности: либо вам все вежливо объясняют в чём с вами не согласны, либо вы - главный му*ак вселенной.
Вы, видимо, форумы не застали, где могли и послать за плохую формулировку вопроса, а не только минус поставить. Сейчас же все нежные стали, как цветочки прям ??♂️
Это всё понятно. Но как вы сами признались, собрать циферки несложно, с этим мидл справится. А вопрос какие циферки надо собирать и какие поверх них алерты настраивать - это вне компетенции мидлов, как ни крути.
Зачем дёргать менеджера по продажам, когда есть бизнес-аналитик, системный аналитик и product owner до кучи. С ними со всеми сеньор должен уметь коммуницировать, иначе тех.лид просто станет узким местом в команде.
Вот если задача оказалась слишком сложной, то там уже сеньор сам объяснит её техлиду и попросит помощи.
У вас прям какой-то культ мониторинга. Причём вы его преподносите как чуть-ли не самое сложное в разработке. Хотя по факту, это довольно тупая обвязка над имеющейся в любой технологии телеметрией.
Разработчик не должен коммуницировать, чтобы понять, что подразумевал создатель задачи.
Разработчик на уровне Junior не должен.
На уровне Middle - должен.
На уровне Senior - обязан.
В этом собственно одно из ключевых отличий этих уровней - насколько разработчик способен осознавать бизнес-потребность и самостоятельно коммуницировать.
1) 10 ms - это меньше пинга. Но в целом, есть большая бизнес-ценность в том, чтобы ответ от сервера доходил до конечного пользователя быстрее 500 ms. Даже исследования на эту тему проводили.
2) Работу с БД тоже можно оптимизировать и за счёт этого улучшить производительность иногда даже на порядки
3) Оптимизация архитектуры - это тоже оптимизация
P.S. Все выше перечисленные пункты не означают, что на алгоритмическую сложность самого кода можно забить и писать O(n^3) повсюду
Хоть по факту в крупные компании берут практически всех подряд, если человек адекватную з/п запрашивает. Какая-то элитарность Яндекса осталась в 90-х, начале 00-х. А у Сбера её по-моему и тогда уже не было.
Хм, ну если всё-таки сначала один раз продумать, и только потом делать, то это уже ближе к инженерному подходу. А если ещё потом порефлексировать над получившимся результатом, чтоб улучшить его, то вообще норм.
не исчезнет на неделю, а потом окажется, что он ничего не сделал, потому что "я не знаю, как это сделать". Если он чего-то не знает, то узнает и задачу выполнит. Если не может выполнить задачу по не зависящим от него причинам, то своевременно уведомит всех заинтересованных лиц, а не будет молчать неделю.
Это всё прекрасно. Только это определение мидла. Если вы можете исчезнуть на неделю и за вами нужно постоянно присматривать, то вы максимум джун.
Те, кто не ошибся с выбором профессии, те и без курсов всему научатся. Понятно, что ИПР может повысить эффективность обучения, но для начинающих и так навалом этих планов развития в свободном доступе.
Вон ниже препод с курсов статистику приводит, что 90% обучающихся на курсах вообще не одупляют, что они делают. Тупо механически какие-то действия проводят. И это курсы для типа миддлов. На курсах для начинающих - 99% таких.
В IT есть только один работающий способ обучения - самообучение. Если им не овладеть, то вы пожизненно будете минимум половину зарплаты менторам отдавать)
То, чего вам не хватает в 90+% студентов, называется инженерное мышление. И это нормально, оно есть у очень небольшого кол-ва людей. Проблема курсов в маркетинге, который продвигает откровенную ложь о том, что любой может стать программистом (если купит их курс)
Так вы не призываете учиться готовить. Вы призываете тупо повторять рецепт, написанный на упаковке. Возможно, что-то получится, возможно это будет даже съедобно, но вряд ли вкусно, и профессиональным поваром вы так не станете.
В целом, верю. Во-первых, это уже управленческая должность. А во-вторых, людей с 17 годами IT-опыта 20 лет назад было реально мало.
Вот только ветка была про затраты на джунов и то, что сейчас они стали менее выгодной инвестицией. Поэтому ваш пример не слишком релевантен.
Хм, я 17 лет назад, как начинающий программист (ака джун) получал 8 т.р. gross за полставки. Кто 20 лет назад получал 100 т.р. даже сложно представить. Может, такие программисты и были, но это явно что-то крайне редкое было. Если по российской инфляции пересчитать, то моя тогдашняя зарплата - это 57 т.р. gross по текущим деньгам за полную ставку.
При этом я в момент трудоустройства уже имел опыт студенческих проектов на Delphi и C#, плюс знания по PHP, JS, HTML, CSS и базам данных.
Нынешние кандидаты в джуны гораздо наглее: думают, что можно немного поизучать один ЯП и ждать оффер на 100 т.р.
Ну, я ж говорю, культ мониторинга. Если коротко, то вы не правы. Всё подряд мониторить - это как раз таки равно создавать лишний шум. Мониторить надо то, что важно мониторить и это вполне может быть указано в постановке задачи. А уж кто там у вас их мидлам ставит, сеньоры, сисаналитики или исключительно техлид - это уже специфика вашей команды.
Так это комплексы какие-то, если для вас существует только 2 крайности: либо вам все вежливо объясняют в чём с вами не согласны, либо вы - главный му*ак вселенной.
Вы, видимо, форумы не застали, где могли и послать за плохую формулировку вопроса, а не только минус поставить. Сейчас же все нежные стали, как цветочки прям ??♂️
Это всё понятно. Но как вы сами признались, собрать циферки несложно, с этим мидл справится. А вопрос какие циферки надо собирать и какие поверх них алерты настраивать - это вне компетенции мидлов, как ни крути.
Судя по описанию, там вообще низкоселективная. Ведь по определению, чем больше уникальных значений в индексе, тем ниже селективность)
Зачем дёргать менеджера по продажам, когда есть бизнес-аналитик, системный аналитик и product owner до кучи. С ними со всеми сеньор должен уметь коммуницировать, иначе тех.лид просто станет узким местом в команде.
Вот если задача оказалась слишком сложной, то там уже сеньор сам объяснит её техлиду и попросит помощи.
У вас прям какой-то культ мониторинга. Причём вы его преподносите как чуть-ли не самое сложное в разработке. Хотя по факту, это довольно тупая обвязка над имеющейся в любой технологии телеметрией.
Разработчик на уровне Junior не должен.
На уровне Middle - должен.
На уровне Senior - обязан.
В этом собственно одно из ключевых отличий этих уровней - насколько разработчик способен осознавать бизнес-потребность и самостоятельно коммуницировать.
1) 10 ms - это меньше пинга. Но в целом, есть большая бизнес-ценность в том, чтобы ответ от сервера доходил до конечного пользователя быстрее 500 ms. Даже исследования на эту тему проводили.
2) Работу с БД тоже можно оптимизировать и за счёт этого улучшить производительность иногда даже на порядки
3) Оптимизация архитектуры - это тоже оптимизация
P.S. Все выше перечисленные пункты не означают, что на алгоритмическую сложность самого кода можно забить и писать O(n^3) повсюду
А стажировки смотрели? Если хотите, могу по вашему резюме обратную связь дать. Присылайте ссылку в личку.
Это, конечно, совсем печально звучит.
Хоть по факту в крупные компании берут практически всех подряд, если человек адекватную з/п запрашивает. Какая-то элитарность Яндекса осталась в 90-х, начале 00-х. А у Сбера её по-моему и тогда уже не было.
Хм, ну если всё-таки сначала один раз продумать, и только потом делать, то это уже ближе к инженерному подходу. А если ещё потом порефлексировать над получившимся результатом, чтоб улучшить его, то вообще норм.
Это всё прекрасно. Только это определение мидла. Если вы можете исчезнуть на неделю и за вами нужно постоянно присматривать, то вы максимум джун.
Те, кто не ошибся с выбором профессии, те и без курсов всему научатся. Понятно, что ИПР может повысить эффективность обучения, но для начинающих и так навалом этих планов развития в свободном доступе.
Или не приходит ??♂️
Вон ниже препод с курсов статистику приводит, что 90% обучающихся на курсах вообще не одупляют, что они делают. Тупо механически какие-то действия проводят. И это курсы для типа миддлов. На курсах для начинающих - 99% таких.
В IT есть только один работающий способ обучения - самообучение. Если им не овладеть, то вы пожизненно будете минимум половину зарплаты менторам отдавать)
То, чего вам не хватает в 90+% студентов, называется инженерное мышление. И это нормально, оно есть у очень небольшого кол-ва людей. Проблема курсов в маркетинге, который продвигает откровенную ложь о том, что любой может стать программистом (если купит их курс)
Так вы не призываете учиться готовить. Вы призываете тупо повторять рецепт, написанный на упаковке. Возможно, что-то получится, возможно это будет даже съедобно, но вряд ли вкусно, и профессиональным поваром вы так не станете.
Зависит от конкретного упражнения. Иногда можно умозрительно результат проверить. Ну, а если нельзя, то самое время учиться писать тесты)