Напихали автору в панамку, но по существу он прав. Если отбросить некоторые преувеличения в зарплатах курьеров и слегка истеричный стиль подачи, то видим, что можно относительно быстро вырасти до синьора, но дальше рост сильно замедляется. Потому что джуны в синьора могут расти параллельно, а вот тимлид уже может быть только один на 10 человек. Груплид - один на 40 человек. Рук.отдела - один на 120 человек. И можно быть сколько угодно крутым специалистом, но ты не станешь груплидом, потому что груплид уже есть. А больше некуда. Да, где-то цифры могут отличаться, где-то могут создаваться новые команды и отделы, но сути это не меняет.
Сейчас ещё можно прокатиться на волне за 300 к/наносек, но в потолок вы упрётесь за несколько лет, а скакать по компаниям долго не получится просто потому что когда вам будет 35, на вашу позицию синьор разработчика найдется несколько 25-летних, которые будут делать вашу работу гораздо лучше.
В который раз читаю "появляется много новых технологий", "не поспеваем в ногу со временем" и вот это всё. Наверное я и сам отстал от жизни, но скажите, как часто появляются альтернативы TCP, http, реляционным бд, брокерам сообщений? Новые способы виртуализации? Новые парадигмы программирования? Может быть новые способы физического размещения данных на дисках? Новые типы процессоров с принципиально иной архитектурой? Новая реализация сортировки пузырьком?
Конечно, если вы учите фреймворки, и для вас каждая версия реакта и ангулара или новая либа для реализации http api на питоне - повод обучаться с нуля, то да, вам придётся бежать очень быстро, но фундаментальных изменений не так много. Если есть базовые знания, овладеть инструментами можно в короткие сроки.
В таком случае, можно заявить, что у нас есть шифр, который отображает любой набор входных данных в единицу, а ключом являются сами исходные данные.
Давайте мысленно зашифруем два блокнота и выбросим ключи. У нас есть две единицы. Можем ли мы заявить, что информация из обоих блокнотов сохранилась ? Или только из одного? Если из одного, то из какого?
Скорее нет, чем да. Кажется, ни разу не сталкивался с тем, чтобы схема движения принципиально менялась на крупных развязках.
Понятно, что ответственность с водителя никто не снимает, но увидеть, например, что поворот с крайних двух полос, но эти полосы появляются только за 100 метров до перекрёстка - это удобно.
Будет ли что-нибудь сделано с тем, что в режиме навигации очень сложно (иногда невозможно) увидеть название улицы, по которой ты едешь, или на которую хочешь свернуть? При дефолтном масштабе названия не видно, при увеличении отрисовывается что угодно, кроме названия. Особенно это заметно на длинных улицах, которые приходится мотать туда-сюда в надежде найти незанятый кусок, на котором название всё-таки будет видно
Как ни странно, RnD задачи тоже можно и нужно оценивать. Не в терминах "я найду решение за 4 дня", а в терминах "мы готовы выделить на исследование 4 дня". Во втором случае по истечении этого времени должны быть зафиксированы промежуточные результаты и принято решение о продолжении или отказе от дальнейшего RnD. В противном случае такое исследование рискует превратиться в бесконечную задачу по итогам которой будет сказано: "не шмогла я".
Имхо, хороший индикатор накруток - обилие бессмысленных комментариев в стиле "спасибо, что раскрыли глаза", "очень полезно" и прочее капитанство в стиле GPT генератора, никак не отражающее суть статьи.
Итого, вы взяли сферу деятельности с низким порогом входа и обнаружили, что дешевле взять студента, который готов работать за еду, и быстро его обучить, чем сотрудника, который уже давно работает и всё ещё находится на этой базовой позиции. А потом решили экстраполировать это кликбейтным заголовком на всё айти (мы же на Хабре?).
За сбои и аварии не скажу, но заметно снизилась скорость создания и качество новых продуктов. Усилилось проникновение "ведущих разработчиков" от Сбера с опытом работы в полгода, особенно в нефинансовых сферах. Причём попадают они на действительно ведущие позиции, только ведут куда-то не туда.
Возможно, мы ещё не видим всех последствий, а начнём их замечать лет через 5-10.
Крайне странное и ничем не подтвержденное утверждение про то, что отношение роста джунов в мидлы составляет 1:30, а в синьоры - 1:100. Что, по-вашему, происходит со всеми этими людьми? Они уходят в Макдак?
Я не троллю, а реально хочу понять, хотя бы потому, что на первом этапе, по крайней мере, вижу конверсию примерно 1:1
Там не было пятитысячников, зато была такая же неподготовленность. Эта трагедия лишний раз подчёркивает, что без подготовки погибнуть можно даже в самых простых условиях, а двое инструкторов не способны организовать группу из 50 человек. Это никаким образом не оправдывает поход без подготовки в ещё более сложных условиях.
Моя статья показывает, как по мне, другую сторону таких походов.
Ваша статья показывает ровно то, что и происходит в таких походах: полную безответственность, неподготовленность и непонимание рисков.
Всё дело в том, что итоговый посыл вашей статьи воспринимается как: были трудности, но я справился и сходил на крутую вершину.
Тогда как здравомыслящий человек ожидает вывода: я по глупости пошёл на сложное восхождение неподготовленным и чуть не погиб. Больше никогда не буду так делать.
Возможно это поможет таким же новичкам как и я совершить свое первое восхождение, подскажет, как лучше спланировать поездку, подготовится к ней, избежать некоторых ошибок.
Единственное, чем может и должна помочь эта статья - привить читателю понимание, что невозможно безопасно сходить на Эльбрус имея за спиной 1 день снежно-ледовых занятий и неделю опыта спортивного туризма/альпинизма, не говоря о совершенно недостаточной акклиматизации и физподготовке.
Да, на Эльбрус в хорошую погоду можно забежать в кроссовках за 5-6 часов, но вот в случае наступления плохой погоды вам понадобится гораздо больше, чем просто кроссовки. А погода на вершине меняется ой как часто.
К сожалению, коммерческие туристы считают, что восхождение на Эльбрус - это такой же по сложности тур, как и поездка в Анталию, а туроператоры всячески поддерживают это заблуждение, но если в Анталии в случае возникновения проблем вы просто садитесь в кафе и ждёте пока оператор всё решит, то на высоте 5000 метров гид физически не способен спасти 6-7, а порой и 10+ паникующих людей без малейшей базовой подготовки. Более того, в сложных условиях гид и не будет их спасать, потому что его опыта как раз достаточно для того чтобы вернуться, а любые суды и разбирательства - куда лучшая перспектива, чем смерть.
Как вы отслеживаете ситуации, когда у вас новая версия сервиса применила миграции к бд, а старый сервис при этом перезапустился? Например, при а/б тестах.
В этом случае старый сервис получит дто, сгенерированный по новой схеме бд, и с некоторой вероятностью взорвётся.
Не соглашусь насчёт "логика течёт". Вы можете полностью изолировать логику работы с бд в слое репозиториев. Более того, можете навесить на репозитории интерфейсы и точечно ограничить применение тех или иных методов на уровне сервиса.
Единственный минус жука: мне не всегда подходят pojo, которые он генерирует, но эта проблема легко решается собственными dto и мапперами (бойлерплейт или контроль?). В жуке есть встроенный механизм для маппинга результата запроса буквально во что угодно. Таким образом, абсолютно всё, что касается работы с бд, не выходит дальше репозитория.
С этой точки зрения, жук, на мой взгляд, не отличается от других орм в части структурирования кода.
Напихали автору в панамку, но по существу он прав. Если отбросить некоторые преувеличения в зарплатах курьеров и слегка истеричный стиль подачи, то видим, что можно относительно быстро вырасти до синьора, но дальше рост сильно замедляется. Потому что джуны в синьора могут расти параллельно, а вот тимлид уже может быть только один на 10 человек. Груплид - один на 40 человек. Рук.отдела - один на 120 человек. И можно быть сколько угодно крутым специалистом, но ты не станешь груплидом, потому что груплид уже есть. А больше некуда. Да, где-то цифры могут отличаться, где-то могут создаваться новые команды и отделы, но сути это не меняет.
Сейчас ещё можно прокатиться на волне за 300 к/наносек, но в потолок вы упрётесь за несколько лет, а скакать по компаниям долго не получится просто потому что когда вам будет 35, на вашу позицию синьор разработчика найдется несколько 25-летних, которые будут делать вашу работу гораздо лучше.
Примерно в любой крупной ИТ компании. ВБ, Озон, Авито, Тиньков, Альфа, Сбер, Т1 и так далее.
Для вашего понимания, и синьор, и ведущий разработчик - это тоже линейные специалисты. И даже тимлид - это линейный менеджер 1 уровня.
В который раз читаю "появляется много новых технологий", "не поспеваем в ногу со временем" и вот это всё. Наверное я и сам отстал от жизни, но скажите, как часто появляются альтернативы TCP, http, реляционным бд, брокерам сообщений? Новые способы виртуализации? Новые парадигмы программирования? Может быть новые способы физического размещения данных на дисках? Новые типы процессоров с принципиально иной архитектурой? Новая реализация сортировки пузырьком?
Конечно, если вы учите фреймворки, и для вас каждая версия реакта и ангулара или новая либа для реализации http api на питоне - повод обучаться с нуля, то да, вам придётся бежать очень быстро, но фундаментальных изменений не так много. Если есть базовые знания, овладеть инструментами можно в короткие сроки.
В таком случае, можно заявить, что у нас есть шифр, который отображает любой набор входных данных в единицу, а ключом являются сами исходные данные.
Давайте мысленно зашифруем два блокнота и выбросим ключи. У нас есть две единицы. Можем ли мы заявить, что информация из обоих блокнотов сохранилась ? Или только из одного? Если из одного, то из какого?
На отрезке с 2008 года по сегодня депозиты в среднем немного обгоняют инфляцию.
Победит более быстрый маршрут. Регулярно приходится переключать предложенные маршруты, которые на 4 минуты быстрее, но на 15 км длиннее.
А после малейшего схода с маршрута - на заправку или в соседний переулок, маршрут снова перестраивается по длинному пути.
Скорее нет, чем да. Кажется, ни разу не сталкивался с тем, чтобы схема движения принципиально менялась на крупных развязках.
Понятно, что ответственность с водителя никто не снимает, но увидеть, например, что поворот с крайних двух полос, но эти полосы появляются только за 100 метров до перекрёстка - это удобно.
Будет ли что-нибудь сделано с тем, что в режиме навигации очень сложно (иногда невозможно) увидеть название улицы, по которой ты едешь, или на которую хочешь свернуть? При дефолтном масштабе названия не видно, при увеличении отрисовывается что угодно, кроме названия. Особенно это заметно на длинных улицах, которые приходится мотать туда-сюда в надежде найти незанятый кусок, на котором название всё-таки будет видно
Как ни странно, RnD задачи тоже можно и нужно оценивать. Не в терминах "я найду решение за 4 дня", а в терминах "мы готовы выделить на исследование 4 дня". Во втором случае по истечении этого времени должны быть зафиксированы промежуточные результаты и принято решение о продолжении или отказе от дальнейшего RnD. В противном случае такое исследование рискует превратиться в бесконечную задачу по итогам которой будет сказано: "не шмогла я".
Имхо, хороший индикатор накруток - обилие бессмысленных комментариев в стиле "спасибо, что раскрыли глаза", "очень полезно" и прочее капитанство в стиле GPT генератора, никак не отражающее суть статьи.
Ага, именно по этой причине найм мидл разработчика занимает по 3-4 месяца, а синьор QA - полгода.
Итого, вы взяли сферу деятельности с низким порогом входа и обнаружили, что дешевле взять студента, который готов работать за еду, и быстро его обучить, чем сотрудника, который уже давно работает и всё ещё находится на этой базовой позиции. А потом решили экстраполировать это кликбейтным заголовком на всё айти (мы же на Хабре?).
делЗа сбои и аварии не скажу, но заметно снизилась скорость создания и качество новых продуктов. Усилилось проникновение "ведущих разработчиков" от Сбера с опытом работы в полгода, особенно в нефинансовых сферах. Причём попадают они на действительно ведущие позиции, только ведут куда-то не туда.
Возможно, мы ещё не видим всех последствий, а начнём их замечать лет через 5-10.
Это что же, они придумали Maven? А вообще, интересно было бы попробовать. В императивном грейдле слишком просто выстрелить себе в ногу.
Крайне странное и ничем не подтвержденное утверждение про то, что отношение роста джунов в мидлы составляет 1:30, а в синьоры - 1:100. Что, по-вашему, происходит со всеми этими людьми? Они уходят в Макдак?
Я не троллю, а реально хочу понять, хотя бы потому, что на первом этапе, по крайней мере, вижу конверсию примерно 1:1
Там не было пятитысячников, зато была такая же неподготовленность. Эта трагедия лишний раз подчёркивает, что без подготовки погибнуть можно даже в самых простых условиях, а двое инструкторов не способны организовать группу из 50 человек. Это никаким образом не оправдывает поход без подготовки в ещё более сложных условиях.
Ваша статья показывает ровно то, что и происходит в таких походах: полную безответственность, неподготовленность и непонимание рисков.
Всё дело в том, что итоговый посыл вашей статьи воспринимается как: были трудности, но я справился и сходил на крутую вершину.
Тогда как здравомыслящий человек ожидает вывода: я по глупости пошёл на сложное восхождение неподготовленным и чуть не погиб. Больше никогда не буду так делать.
Единственное, чем может и должна помочь эта статья - привить читателю понимание, что невозможно безопасно сходить на Эльбрус имея за спиной 1 день снежно-ледовых занятий и неделю опыта спортивного туризма/альпинизма, не говоря о совершенно недостаточной акклиматизации и физподготовке.
Да, на Эльбрус в хорошую погоду можно забежать в кроссовках за 5-6 часов, но вот в случае наступления плохой погоды вам понадобится гораздо больше, чем просто кроссовки. А погода на вершине меняется ой как часто.
К сожалению, коммерческие туристы считают, что восхождение на Эльбрус - это такой же по сложности тур, как и поездка в Анталию, а туроператоры всячески поддерживают это заблуждение, но если в Анталии в случае возникновения проблем вы просто садитесь в кафе и ждёте пока оператор всё решит, то на высоте 5000 метров гид физически не способен спасти 6-7, а порой и 10+ паникующих людей без малейшей базовой подготовки. Более того, в сложных условиях гид и не будет их спасать, потому что его опыта как раз достаточно для того чтобы вернуться, а любые суды и разбирательства - куда лучшая перспектива, чем смерть.
Как вы отслеживаете ситуации, когда у вас новая версия сервиса применила миграции к бд, а старый сервис при этом перезапустился? Например, при а/б тестах.
В этом случае старый сервис получит дто, сгенерированный по новой схеме бд, и с некоторой вероятностью взорвётся.
Не соглашусь насчёт "логика течёт". Вы можете полностью изолировать логику работы с бд в слое репозиториев. Более того, можете навесить на репозитории интерфейсы и точечно ограничить применение тех или иных методов на уровне сервиса.
Единственный минус жука: мне не всегда подходят pojo, которые он генерирует, но эта проблема легко решается собственными dto и мапперами (бойлерплейт или контроль?). В жуке есть встроенный механизм для маппинга результата запроса буквально во что угодно. Таким образом, абсолютно всё, что касается работы с бд, не выходит дальше репозитория.
С этой точки зрения, жук, на мой взгляд, не отличается от других орм в части структурирования кода.