Или будет как с врачами - долгое обучение, потом долгий набор опыта - и только потом выход на высокий заработок. Сейчас подобный тренд наметился в программировании (но пока еще слабо выражен).
Нет. Тут вопрос в том, что обсуждали и как, а также в том, что же это за синьоры.
Самое главное отличие синьора от миддла в том, что первый понимает, что одну и ту же задачу можно решить громадным числом способов, причем с использованием схожего объема ресурсов (т.е. деньги на лицензии, время и так далее). Мидл же зачастую проталкивает единственное и самое правильное решение.
В случае грамотного обсуждения (когда известно, какую задачу решаем, когда присутствует уважение и пр.), зачастую решение принимается и без тимлида (который, в итоге, просто его формально озвучит и будет отстаивать). В малом числе случаев необходимо сделать выбор в стиле “правостороннее vs левостороннее движение” (по сути, можно выбирать любое, тут главное - это определиться).
Собственно, если добавить к синьорам требование в обсуждение (просто минимальный уровень, чтобы была конструктивная беседа), а к тимлиду умение в корректную модерацию, то и получим то, что сказал товарищ выше.
И поэтому мне очень смешна убежденность многих (и на хабре в том числе) в том, что ИИ людей не заменит в ИТ.
Глядя на то, как самые современные модели (не годовой давности) работают с существующим проектами на плюсах, а также зная то, что внезапно две передовые компании отложили IPO и предложили замедлить ИИ, у меня есть определенный скептицизм по замене программистов.
Как помощник и выполнитель рутины - да. Как способ сделать больше силами одного квалифицированного - да (то есть IT может стать похожим на медицину, где необходимо десятилетиями учиться, прежде чем пойдет серьезный заработок). А вот говорить про полную замену еще ой как рано.
In proceedings against any person for an offence under this section, if it is shown that that person was in possession of a key to any protected information at any time before the time of the giving of the section 49 notice, that person shall be taken for the purposes of those proceedings to have continued to be in possession of that key at all subsequent times, unless it is shown that the key was not in his possession after the giving of the notice and before the time by which he was required to disclose it.
Вольный перевод:
если только не будет доказано, что ключа не было у него после направления уведомления и до истечения срока, к которому он должен был его раскрыть.
Собственно, если ключ действительно забыт или его и не было никогда, то это и ответ. Пример из жизни можно найти в интернете - “Boris Johnson ‘has forgotten’ passcode for phone wanted by Covid inquiry” (Борис Джонсон забыл пароль от Whats App, которым не пользовался сколько-то там лет).
Что самое интересное, что закон также защитит человека, если пароль был написан на листочке, который потерялся, а потом нашелся, но уже совсем после срока раскрытия данных.
Вряд ли они серьезно надеются, что компания, которая даже не производитель, будет будет проверять каждый товар, чтобы подстроится под регламенты каждой страны в мире.
А разве не так супермаркеты работают? Они не производят продукт, плюс крупные сети работают в разных странах.
А можете чуть подробнее расписать про 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 или статей на том же Хабре, то как можно понять, что первое резюме честное и от профессионала, а три других содержат обман выше порога?
Или будет как с врачами - долгое обучение, потом долгий набор опыта - и только потом выход на высокий заработок. Сейчас подобный тренд наметился в программировании (но пока еще слабо выражен).
Нет. Тут вопрос в том, что обсуждали и как, а также в том, что же это за синьоры.
Самое главное отличие синьора от миддла в том, что первый понимает, что одну и ту же задачу можно решить громадным числом способов, причем с использованием схожего объема ресурсов (т.е. деньги на лицензии, время и так далее). Мидл же зачастую проталкивает единственное и самое правильное решение.
В случае грамотного обсуждения (когда известно, какую задачу решаем, когда присутствует уважение и пр.), зачастую решение принимается и без тимлида (который, в итоге, просто его формально озвучит и будет отстаивать). В малом числе случаев необходимо сделать выбор в стиле “правостороннее vs левостороннее движение” (по сути, можно выбирать любое, тут главное - это определиться).
Собственно, если добавить к синьорам требование в обсуждение (просто минимальный уровень, чтобы была конструктивная беседа), а к тимлиду умение в корректную модерацию, то и получим то, что сказал товарищ выше.
Глядя на то, как самые современные модели (не годовой давности) работают с существующим проектами на плюсах, а также зная то, что внезапно две передовые компании отложили IPO и предложили замедлить ИИ, у меня есть определенный скептицизм по замене программистов.
Как помощник и выполнитель рутины - да. Как способ сделать больше силами одного квалифицированного - да (то есть IT может стать похожим на медицину, где необходимо десятилетиями учиться, прежде чем пойдет серьезный заработок). А вот говорить про полную замену еще ой как рано.
Не совсем. Вот закон - https://www.legislation.gov.uk/ukpga/2000/23/section/53, смотрим внимательно на пункт 53 (именно он говорит о последствиях отказа), а точнее - на подпункт 2:
Вольный перевод:
Собственно, если ключ действительно забыт или его и не было никогда, то это и ответ. Пример из жизни можно найти в интернете - “Boris Johnson ‘has forgotten’ passcode for phone wanted by Covid inquiry” (Борис Джонсон забыл пароль от Whats App, которым не пользовался сколько-то там лет).
Что самое интересное, что закон также защитит человека, если пароль был написан на листочке, который потерялся, а потом нашелся, но уже совсем после срока раскрытия данных.
А разве не так супермаркеты работают? Они не производят продукт, плюс крупные сети работают в разных странах.
А зачем там делать? Опытный разработчик как раз заранее знает о таких тонкостях, так что функциональности первого 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 или статей на том же Хабре, то как можно понять, что первое резюме честное и от профессионала, а три других содержат обман выше порога?