А можете чуть подробнее расписать про Zio - какую проблему он решает по сравнению с Kotlin + Virtual Threads (без coroutines)?
Основная проблема классических потоков (и в этом необходимость асинхронных примитивов) была в переключении контекста приложения. Виртуальные потоки это убрали, а потому и проблема ушла.
Собственно, теперь можно обрабатывать многопоточный код в классическом виде - это и работает быстрее, и читается легче, плюс стек вызовов стандартный, а потому дальнейшая диагностика улучшается.
Я с Вами не соглашусь, так как я неоднократно наблюдал именно то, что описывается в статье.
Собственно, 10х программист именно что поможет:
Сможем ли мы протестировать, вообще, эту фичу учитывая огромное количество legacy интеграций?
Да - именно в зависимости от квалификации и меняется ответ на этот вопрос.
Готовы ли смежные команды для внедрения нашей фичи?
Более квалифицированный человек (а 10х производительность ведь очень хорошо коррелирует с повышенной скоростью набора опыта) как раз сможет внедрить намного больше функциональности используя существующие возможности, а не будет просить всех немного помочь и подвинуться.
Готовы ли внешние интеграции к нашим изменениям?
Обратную совместимость непросто поддерживать - опять-таки, более грамотный сотрудник будет в плюсе.
Нет ли пропущенных кусков в наших планах, например, связанных с безопасностью транзакций?
И опять-таки, тут такие люди найдут проблемы быстрее, чем стандартный/классический работник.
Готовы ли мы деплоиться в период повышенного риска?
Отличный пример - 10х сотрудник именно что сможет сделать blue-green деплоймент, так что даже такого вопроса не возникнет. Собственно, а какие крупные фирмы так не делают с сайтом?
Сможем ли мы отказаться от этого решения, если оно окажется неудачным?
Вот это проблема - если потом заменить очень сильного на кого-то сильно дешевле, то далее запросто вырастет целая команда, которая будет смотреть годами на решения, оставшиеся от предыдущих, а также потратит несколько неудачных попыток переписать. Вот это нередко можно наблюдать в фирмах.
Пример из жизни - Скайп. Его сделала команда очень высокого уровня, а далее история известна.
Сколько сил мы готовы потратить на дополнительный раунд нагрузочного тестирования?
Здесь квалификация и грамотная архитектура опять очень сильно помогут.
Наше решения отвечает всем требованиям безопасности, если сейчас ресурс по безопасникам, или они заняты?
И что же такого 10х программист может не знать про безопасность? Такие люди, чаще всего, скорее сами расскажут безопасникам, где стоит корректировать подходы.
Другими словами - Вы четко описали именно то, что часто и происходит: условный 10х программист интересуется темой, очень хорошо разбирается в технологиях, имеет прекрасные T-shape навыки и так далее; а на его замену потребуется несколько людей попроще, безопасник, тестировщик, продукт менеджер, программ менеджер, скрам мастер, потом еще программисты и так далее.
Но с точки зрения внешнего злоумышленника как это эксплуатировать?
Ответ здесь тот же, как и на "зачем токены и куки имеют ограниченный срок действия?" Вероятность утечки ссылки на приватный документ за 3-5 лет слегка выше, чем она же за одну неделю.
Если кратко: на остров ведет один мост, но он принадлежит Министерству Обороны (как и земля на острове, прилегающая к нему). В "дальней" части острова живут гражданские (там же еще поля, например). Людям без пропуска проезжать через военную базу нельзя.
Вдоль берега идет коса, по которой можно добраться до поселка, не заезжая на территорию с военными. По ней не рекомендуется передвигаться без проводника, без контроля времени (чтобы не попасть в прилив) и так далее. Но эта дорога отмечена на картах.
Но разве это не базовое требование почти на все вакансии? Собственно, если необходимо отсортировать автомобили по скорости и вывести 10 самых быстрых, то это необходимо делать в условной базе с индексом (или в горячем сервисе, который вернет, как и база, первые 10 элементов в массива/дерева/списка, а не будет запрашивать всё, потом сортировать и так далее)?
Собственно, все собеседования в стиле system design требуют таких предположений. Ну а Live Coding неявно подразумевает, что навык может быть применен и вне собеседования..
Быстрее то может и будет, но надо не такты процессора оптимизировать а архитектуру и "работу", количество вычислений
Мне казалось, что для программиста это уже базовое правило по-умолчанию, которое даже произносить не надо. Ну то есть это где-то на уровне "надо проверять написанное".
Собственно, сейчас же в школах/вузах рассказывают про алгоритмы, а на собеседованиях спрашивают про всякие там сортировки и хеш таблицы. Логично, что люди с этими знаниями, дальше их применяют в работе.
Бизнесу нужна автоматизация любой ценой, и повышение надёжности процесса её просто убьёт.
Разве это так? Мне казалось, что цель у менеджера - нанять сотрудника посильнее, плюс тратить поменьше времени: как своего, так и в целом.
Более того, если на закрытие вакации потребуется Х месяцев, когда у конкурентов оно Х/2, то сильные кандидаты будут уходить к конкурентам. По факту, это ведь типичный случай: пока были раунды собеседований, человек уже получил оффер и согласился на него (ибо синица в руках и так далее).
Спасибо! Да, хорошо расписано. В целом, выглядит так, что просто система перестроится под другой подход, ибо кризис слишком очевиден. Сейчас очень легко накрутить опыт и умения, так что, возможно, появится что-то, что будет этому препятствовать: или история резюме будет трекаться, или появятся сервисы "с репутацией", которые будут делать первичную оценку знаний, но скорее всего - что-то очень неожиданное.
На деле, в западных крупных фирмах так и устроено - после собеседования будет background check, где проверят резюме: действительно ли человек учился в том вузе или правда ли, что человек работал в определенном месте.
Но это сейчас стало тоже плохо работать, так как если кто-то работал в определенной компании, а в резюме декларирует определенные навыки, то невозможно заранее определить, правду человек пишет или нет.
Я знаю. О том и речь - HR не может отличить, так как никто не может. Но, если на вакансию пришло несколько сотен человек, то придется кому-то проигнорировать основную массу.
Другими словами - с текущим подходом к разбору резюме, эта задача не может быть решена в принципе.
Возможно... Но мой же посыл в том, что, если резюме кто-то просто скопирует и сменит имя, то, за неимением никаких других средств верификации, без собеседования никто физически не сможет ответить, была ли фальсификация или нет.
А потому и получается, что HR (у которых есть только резюме на руках) не сможет никак отличить самозванца от специалиста.
следствие того что HR-ши некомпетентны и не могут отличить самозванца от специалиста
Ради интереса - а как это можно сделать? Допустим, что самозванец взял несколько реальных CV от специалистов, а далее просто поменял имя и отправил в разные компании.
Собственно, если нет быстрых пруфов в виде активности на GitHub или статей на том же Хабре, то как можно понять, что первое резюме честное и от профессионала, а три других содержат обман выше порога?
И либо сносит заодно вид всех прочих элементов, которым понаприсваивали стиль red-button, либо присваивает ей стиль red-button2, другого оттенка, ломая бизнес-логику, после чего куча народа срочно-срочно мечется по коду в поисках WTF?!
А тесты? Вроде, изначально автор говорил про сложность найма опытного и высококвалифицированного профессионала в профессиональную команду, так что аргумент "скорее всего бизнес логика сделана через стили, а тестов нет" слабо подходит к теме.
И все же, с вас финансовый директор будет спрашивать расходную часть бюджета, ему ж надо у инвестора защищать свой бюджет.
А как тогда Space X смогли защитить у инвесторов, если поступательный прогресс не работает?
Инвестору показывают тренд прибыли/убытков/оборота и подобных вещей, чтобы видеть перспективу. Если у Вас есть текущий бюджет и примерный план в стиле "оставляем ту же команду, нанимаем еще 10% и повышаем расход на существующих на ставку инфляции", то это и будет ответом финансовому директору. Если же финансовый директор требует точно запланировать, например, затраты на исправления будущих уязвимостей, то здесь уже вопросы будут к нему :)
мы будем Вам ставку менять поступательно - это ведь намного эффективней, да?
Ипотека - это типовой продукт. Мы говорим про IT, где именно создается новое решение. Поэтому, правильнее брать в пример тот же Space X, Tesla и так далее.
и все это вот с каждым релизом коту под хвост раз в пол года?
Релизы раз в неделю. Если продукт переписывают с нуля раз в неделю - то это странно.
И да, если вдруг станет выгодно деплоить сервисы в Kubernetes клиентов (так как рынок поменялся), а не хостить их на заранее выбранном сервисе - то, зачастую, выгоднее остановиться и начать делать решения для клиентов, а не продолжать следовать старому направлению, постепенно теряя доходы.
Это называется "корреляция". Например, выпускники сильных вузов чаще всего будут лучше в определенной профессии, чем выпускники слабых (при условии, что в вузе обучали именно эту профессию и так далее). Это не строгая зависимость, это просто корреляция.
Представьте что Вы руковод отдела, Вам надо бюджет заложить на год - год это стандартный период планирования
Вроде как уже много лет назад поняли, что такой способ планирования нерационален. Намного эффективнее поступательный прогресс, когда небольшими изменениями продукт двигается в сторону, которую определяют раз в X месяцев (или раз в год).
Собственно, пример - Linux или Chrome. Они поступательно улучшаются, с частыми релизами.
Вы же предлагаете классический подход, когда сначала люди пытаются спланировать всё-всё очень надолго (да еще и со сроками, с учетом рисков и так далее), а потом пытаются уложить именно в эти сроки именно эти запросы, даже несмотря на то, что ситуация может измениться.
Еще пример из инженерии: для условного Space X технологические прорывы будут играть на руку, а для более классического SLS - нет. Но это не говорит, что рост технологии плох, это говорит о разных способах управления.
А зачем там делать? Опытный разработчик как раз заранее знает о таких тонкостях, так что функциональности первого API будет достаточно
А можете чуть подробнее расписать про Zio - какую проблему он решает по сравнению с Kotlin + Virtual Threads (без coroutines)?
Основная проблема классических потоков (и в этом необходимость асинхронных примитивов) была в переключении контекста приложения. Виртуальные потоки это убрали, а потому и проблема ушла.
Собственно, теперь можно обрабатывать многопоточный код в классическом виде - это и работает быстрее, и читается легче, плюс стек вызовов стандартный, а потому дальнейшая диагностика улучшается.
Я с Вами не соглашусь, так как я неоднократно наблюдал именно то, что описывается в статье.
Собственно, 10х программист именно что поможет:
Да - именно в зависимости от квалификации и меняется ответ на этот вопрос.
Более квалифицированный человек (а 10х производительность ведь очень хорошо коррелирует с повышенной скоростью набора опыта) как раз сможет внедрить намного больше функциональности используя существующие возможности, а не будет просить всех немного помочь и подвинуться.
Обратную совместимость непросто поддерживать - опять-таки, более грамотный сотрудник будет в плюсе.
И опять-таки, тут такие люди найдут проблемы быстрее, чем стандартный/классический работник.
Отличный пример - 10х сотрудник именно что сможет сделать blue-green деплоймент, так что даже такого вопроса не возникнет. Собственно, а какие крупные фирмы так не делают с сайтом?
Вот это проблема - если потом заменить очень сильного на кого-то сильно дешевле, то далее запросто вырастет целая команда, которая будет смотреть годами на решения, оставшиеся от предыдущих, а также потратит несколько неудачных попыток переписать. Вот это нередко можно наблюдать в фирмах.
Пример из жизни - Скайп. Его сделала команда очень высокого уровня, а далее история известна.
Здесь квалификация и грамотная архитектура опять очень сильно помогут.
И что же такого 10х программист может не знать про безопасность? Такие люди, чаще всего, скорее сами расскажут безопасникам, где стоит корректировать подходы.
Другими словами - Вы четко описали именно то, что часто и происходит: условный 10х программист интересуется темой, очень хорошо разбирается в технологиях, имеет прекрасные T-shape навыки и так далее; а на его замену потребуется несколько людей попроще, безопасник, тестировщик, продукт менеджер, программ менеджер, скрам мастер, потом еще программисты и так далее.
По сути, Вы говорите о https://gdpr-info.eu/art-17-gdpr/ / https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/individual-rights/individual-rights/right-to-erasure/
Ответ здесь тот же, как и на "зачем токены и куки имеют ограниченный срок действия?" Вероятность утечки ссылки на приватный документ за 3-5 лет слегка выше, чем она же за одну неделю.
Есть видео, где описывается эта дорога: https://www.youtube.com/watch?v=mM7C_Pw7OL8 , а также есть статья на Википедии: https://ru.wikipedia.org/wiki/Брумвей
Если кратко: на остров ведет один мост, но он принадлежит Министерству Обороны (как и земля на острове, прилегающая к нему). В "дальней" части острова живут гражданские (там же еще поля, например). Людям без пропуска проезжать через военную базу нельзя.
Вдоль берега идет коса, по которой можно добраться до поселка, не заезжая на территорию с военными. По ней не рекомендуется передвигаться без проводника, без контроля времени (чтобы не попасть в прилив) и так далее. Но эта дорога отмечена на картах.
Но разве это не базовое требование почти на все вакансии? Собственно, если необходимо отсортировать автомобили по скорости и вывести 10 самых быстрых, то это необходимо делать в условной базе с индексом (или в горячем сервисе, который вернет, как и база, первые 10 элементов в массива/дерева/списка, а не будет запрашивать всё, потом сортировать и так далее)?
Собственно, все собеседования в стиле system design требуют таких предположений. Ну а Live Coding неявно подразумевает, что навык может быть применен и вне собеседования..
Мне казалось, что для программиста это уже базовое правило по-умолчанию, которое даже произносить не надо. Ну то есть это где-то на уровне "надо проверять написанное".
Собственно, сейчас же в школах/вузах рассказывают про алгоритмы, а на собеседованиях спрашивают про всякие там сортировки и хеш таблицы. Логично, что люди с этими знаниями, дальше их применяют в работе.
Разве это так? Мне казалось, что цель у менеджера - нанять сотрудника посильнее, плюс тратить поменьше времени: как своего, так и в целом.
Более того, если на закрытие вакации потребуется Х месяцев, когда у конкурентов оно Х/2, то сильные кандидаты будут уходить к конкурентам. По факту, это ведь типичный случай: пока были раунды собеседований, человек уже получил оффер и согласился на него (ибо синица в руках и так далее).
Спасибо! Да, хорошо расписано. В целом, выглядит так, что просто система перестроится под другой подход, ибо кризис слишком очевиден. Сейчас очень легко накрутить опыт и умения, так что, возможно, появится что-то, что будет этому препятствовать: или история резюме будет трекаться, или появятся сервисы "с репутацией", которые будут делать первичную оценку знаний, но скорее всего - что-то очень неожиданное.
Ух ты, вот тут интересно - а можно посмотреть?
На деле, в западных крупных фирмах так и устроено - после собеседования будет background check, где проверят резюме: действительно ли человек учился в том вузе или правда ли, что человек работал в определенном месте.
Но это сейчас стало тоже плохо работать, так как если кто-то работал в определенной компании, а в резюме декларирует определенные навыки, то невозможно заранее определить, правду человек пишет или нет.
Я знаю. О том и речь - HR не может отличить, так как никто не может. Но, если на вакансию пришло несколько сотен человек, то придется кому-то проигнорировать основную массу.
Другими словами - с текущим подходом к разбору резюме, эта задача не может быть решена в принципе.
Возможно... Но мой же посыл в том, что, если резюме кто-то просто скопирует и сменит имя, то, за неимением никаких других средств верификации, без собеседования никто физически не сможет ответить, была ли фальсификация или нет.
А потому и получается, что HR (у которых есть только резюме на руках) не сможет никак отличить самозванца от специалиста.
Ради интереса - а как это можно сделать? Допустим, что самозванец взял несколько реальных CV от специалистов, а далее просто поменял имя и отправил в разные компании.
Собственно, если нет быстрых пруфов в виде активности на GitHub или статей на том же Хабре, то как можно понять, что первое резюме честное и от профессионала, а три других содержат обман выше порога?
Вы про https://ru.wikipedia.org/wiki/Model_Context_Protocol?
А тесты? Вроде, изначально автор говорил про сложность найма опытного и высококвалифицированного профессионала в профессиональную команду, так что аргумент "скорее всего бизнес логика сделана через стили, а тестов нет" слабо подходит к теме.
А как тогда Space X смогли защитить у инвесторов, если поступательный прогресс не работает?
Инвестору показывают тренд прибыли/убытков/оборота и подобных вещей, чтобы видеть перспективу. Если у Вас есть текущий бюджет и примерный план в стиле "оставляем ту же команду, нанимаем еще 10% и повышаем расход на существующих на ставку инфляции", то это и будет ответом финансовому директору. Если же финансовый директор требует точно запланировать, например, затраты на исправления будущих уязвимостей, то здесь уже вопросы будут к нему :)
Ипотека - это типовой продукт. Мы говорим про IT, где именно создается новое решение. Поэтому, правильнее брать в пример тот же Space X, Tesla и так далее.
Релизы раз в неделю. Если продукт переписывают с нуля раз в неделю - то это странно.
И да, если вдруг станет выгодно деплоить сервисы в Kubernetes клиентов (так как рынок поменялся), а не хостить их на заранее выбранном сервисе - то, зачастую, выгоднее остановиться и начать делать решения для клиентов, а не продолжать следовать старому направлению, постепенно теряя доходы.
Это называется "корреляция". Например, выпускники сильных вузов чаще всего будут лучше в определенной профессии, чем выпускники слабых (при условии, что в вузе обучали именно эту профессию и так далее). Это не строгая зависимость, это просто корреляция.
Вроде как уже много лет назад поняли, что такой способ планирования нерационален. Намного эффективнее поступательный прогресс, когда небольшими изменениями продукт двигается в сторону, которую определяют раз в X месяцев (или раз в год).
Собственно, пример - Linux или Chrome. Они поступательно улучшаются, с частыми релизами.
Вы же предлагаете классический подход, когда сначала люди пытаются спланировать всё-всё очень надолго (да еще и со сроками, с учетом рисков и так далее), а потом пытаются уложить именно в эти сроки именно эти запросы, даже несмотря на то, что ситуация может измениться.
Еще пример из инженерии: для условного Space X технологические прорывы будут играть на руку, а для более классического SLS - нет. Но это не говорит, что рост технологии плох, это говорит о разных способах управления.