Вероятность того, что получится узнать что-то ценное, прослушивая часы конкретного ребёнка, не очень большая, скорее всего. Хотя есть шанс случайно наткнуться на интересные разговоры о планах, ценностях, которые где-то лежат. Или есть ли шанс, что вы рядом с ребёнком скажете что-то такое, что не хотели бы, чтобы кто-то услышал? Какие-то подробности семейной жизни, мнение о других людях, планы в бизнесе, что-то ещё?
Но есть второй момент: дети гораздо сильнее подвержены манипуляциям просто из-за меньшего жизненного опыта и страза неодобрения со стороны близких (как бы при этом не старались родители создать доверительные отношения, все равно не хочется перед ними позориться). И поэтому шанс, что какая-то ерунда (с нашей точки зрения), вроде подслушанного разговора или фотографий с часов, станет хорошей основой для шантажа, весьма велик. Я общался со специалистами, которые разбирались с последствиями похожих ситуаций, и могу точно сказать, что не хотел бы пожелать кому-то понять, что все это произошло из-за херни, которую они нацепили на ребёнка.
И я не против детских часов из-за вопросов их безопасности, я за то, чтобы родители осознавали, какую вещь они покупают, какие у неё вообще есть возможности, насколько она надежная, и кто ее производитель.
С часами для детей есть один нюанс: в районе 2019-2021 года многие часы проектировались непонятно кем: некачественное и дырявое ПО, логические проблемы, странные вшитые пароли. Для многих моделей картина выглядела так: если ты дал ребенку часы, то фактически предоставил неограниченный доступ к микрофону и камере этих часов практически неограниченному кругу людей, которые способны прочитать инструкцию. Наверное, эти люди могут придумать много не самых добрых вещей, которые можно сделать с такими возможностями.
Возможно, что-то сейчас изменилось. Возможно (и скорее всего), не все модели вообще сейчас имеют хоть одну проблему. Но надо очень хорошо подумать, если вы просто решили купить и нацепить на ребенка какое-то устройство по отзывам в сети...
При этом увольнения затронули работников, которые ранее получали «отзывы о высокой эффективности», и некоторых менеджеров, зарабатывающих от $500 тысяч до $1 млн.
Важный момент - высокая эффективность не равна высокой полезности. Условный крудошлеп, который выкатывает по 200 новых API в неделю, крайне эффективен. Но если это происходит в бессмысленном проекте, то польза от него околонулевая. Поэтому и получается, что долгое время хвалили эффективных, а в итоге сохранили полезных.
Как минимум, они видят начальников этих работников в беде и руководителей уровнем выше. Условно, разработчик видит, что его руководитель спокойно ходит, когда часть его подчиненных бесплатно поработала. Мне интересно, что чувствуют разработчики, и как к этому относятся.
Если все действительно так, как описано в статье, то мне крайне интересно, что в такой ситуации думают другие разработчики этой компании. Человек ходит каждый день в офис/сидит в чатах и видит тех, кто не платит деньги его коллеге/кто не предупредил об этом/пишет насмешливые письма, что есть проблемы с выплатами, потерпите. Какие мысли при это возникают в голове, чувства уважения и доверия?
Кто все эти люди? У любого специалиста и эксперта есть фамилия, имя и отчество. Время безымянных авторитетов в сфере ИБ прошло. А так - другие эксперты заявляли, что этот способ более безопасный и надёжный в случае Сбера, чем использование магазина приложений.
А по теме - люди из Сбера молодцы, реализовали неплохой способ частично решить проблему. Но не очень понятно, зачем об этом растрезвонили журналистам.
При этом работы полно, вакансий тысячи и из каждого утюга слышно, как говорят, что «не хватает айтишников»
Имхо, люди, которые такое говорят, либо нагло врут, либо специально что-то не договаривают. Не хватает квалифицированных сотрудников, готовых за определённые деньги (желательно небольшие) качественно делать то, что им сказали, в срок. Это условный минимум, который нужен, и он вообще не похож на «Не хватает айтишников».
А с сертификациями ситуация очень простая: достаточно сделать так, чтобы сертификаты что-то гарантировали. Компания сертифицирована джависта, а он не знает, как работает что-то? Отлично, собрали комиссию, подтвердили это, сертификационная компания выплатила 5 зарплат этого джависта в качестве компенсации и отозвала сертификат у него. Иначе получается очень удобно, можно сидеть и штамповать дорогие сертификаты, но при этом не отвечать за них финансово. Если будет такая система, то есть шанс, что останутся только вопросы по опыту работы и нетехнические вопросы. Правда, потребуется 5-10 сертификатов на среднюю вакансию, но это же явно лучше, чем отвечать на вопросы технического собеседования.
Интересно, появится ли в ближайшее время в лексиконе термин "(не)эффективные программисты"? Умеют красиво говорить, описывать процессы и то, что надо сделать, а в итоге продукт у такой команды не получился ни разу. Зато успешно обвиняют менеджеров, HR и бизнес во всех проблемах.
Имхо, такой безопасник - это именно что дармоед. Если человек не может выстроить процесс работы так, чтобы уязвимости исправлялись или компенсировались, а изменения согласовывались с ним, то он сидит и занимается симуляцией ИБ. Не дают ресурсов, полномочий, не получается договориться? А зачем тогда сидеть в таком месте? Получение зарплаты в таких условиях - это очень похоже на дармоедство.
ИБ - это уже давно не запуск Nessus и печать кучи PDF-отчётов. Это серьезная работа с людьми и организация процессов.
Проблема зачастую в том, что на многих конференциях выступают не люди, которые реально что-то знают в теме, о которой рассказывают, а те, кто хочет выступить. Особенно часто это встречаю тогда, когда специалист в одной теме зачем-то рассказывает о не совсем смежной теме, в которой он что-то знает. Например, на конференциях и митапах по тестированию любят рассказывать про информационную безопасность. И если тестировщик рассказывает про ИБ, то очень часто он допускает либо серьезные фактические ошибки, либо рассказывает правильные вещи, но так, что их почти гарантированно неправильно поймёт человек, который с этой темой незнаком. Но зато у выступающих нет никаких проблем с синдромом самозванца.
Есть метрики "чем меньше обращений покупателей и продавцов в поддержку, тем лучше",
По моему опыту, это привело просто к тому, что на каждое обращение в поддержку появляется окно, в котором предлагают оценить ответ поддержки. Недавно заказал товар, у которого срок годности год, приехала упаковка, у которой срок годности истекает меньше, чем через 2 недели. Написал в поддержку, мне предложили его относить куда-то, что-то заполнять, куда-то отсылать. Оценил качество поддержки на минимум, написал, туда ряд вопросов, никто не ответил.
А главный вопрос - зачем Озон хочет, чтобы я возвращал товар, который к моменту возврата станет просроченным? Куда его денут?)
И в чате добиться возможности написать человеку стало сложнее. Зато KPI улучшился.
Имхо, один из главных моментов - не надо превращать материал на 5 минут в доклад на 30. Слушатель прекрасно понимает, что автор просто тянет время, потому что «5 минут - это некруто» или «Слоты только по 30 или 60 минут». Да и хороший доклад на 5-10 минут с огромным удовольствием можно посмотреть на Ютубе, а вот что-то на полчаса, час или вообще на 2 - только при очень большом желании посмотреть конкретно это видео.
Имхо, тут все не так однобоко, как описано в статье, есть ещё минимум два момента:
Сейчас стало довольно много разработчиков, которые живут в практически идеальных условиях: современнейшая техника, последние модели телефонов, постоянный интернет не ниже LTE, устойчивая связь даже на другом континенте. И это приводит к тому, что даже очень плохо написанные сервисы внезапно работают довольно хорошо (у этих разработчиков). И возникает ощущение, что так у всех. Пару лет назад я обсуждал с разработчиками и безопасниками очень известной соцсети, что для того, чтобы получить доступ к практически любому аккаунту достаточно знать номер телефона и прервать доступ человек в интернет на 5 минут. И эти люди (весьма молодые) на полном серьезе говорили, что у них интернет не пропадает, они все уведомления всегда получают, таких проблем нет. И только после обсуждения того, что есть самолёты, есть поезда, есть подвалы, есть даже реанимации, где интернет есть, но пользоваться обычно им не хочется, начался конструктивный диалог. Существует довольно много разработчиков, которые в целом с проблемами не сталкиваются, зачем им писать нормальные (а критерий нормальности - тоже спорная штука)) формы и сервисы.
> Так себе это представляет бизнес, и когда управлению скажут что оно работает, но что-то может пойти не так, и на обработку этого не так надо еще +N дней, то есть увеличить время разработки фичи, например, в 2 раза, то обычно чаша весов склоняются в сторону “если не должно быть, в теории, то и не делаем, не критично”. И вот это не критично выливается в удобство использования и многочисленные негативные возгласы в отзывах на продукт.
Довольно часто (не сказал бы, что в большинстве случаев, но встречается нередко) бывает немного другая ситуация: приходит условный бизнес/руководство и говорит, что надо сделать что-то очень хорошо (я это обычно это наблюдаю в вопросах безопасности из-за специфики работы, но это встречается много где), выделяет разработчикам запрошенное время, спрашивает, нужно ли ещё что-то, все ок. А в результате оказывается, что не сделано практически ничего, в худшем же случае резко возникает десяток историй про то, что все хорошо, это коллеги ничего не поняли, все сделано так, как договаривались. Проблема частично в том, что хорошо разрабатывать очень скучно: надо делать много рутинных и обязательных вещей, которые делать лень. Скорее всего, вам самому было бы лень делать проверки на все те случаи загрузки файла, которые описаны в статье, гораздо проще выкинуть ошибку с кодом 200 и написать «Ошибка загрузки». И только самоуважение, серьезная дисциплина разработки, либо неизбежная кара за косяки приводит к тому, что ПО получается довольно качественным хотя бы на уровне отсутствия базовых проблем, вроде непонятных ошибок или постоянных вылетов.
ИМХО, все может быть гораздо проще: бывает тупо выгодно плодить огромное количество проектов и создавать гору бесполезных сервисов просто потому, что под это можно создать команду, а потом и группу команд, чтобы стать уже довольно влиятельным менеджером. Самое сложное в этом - начать, надо убедить окружающих, что ты делаешь что-то полезное, а потом уже проще: ты владелец 10 сервисов, на которые что-то завязано, ставь сам себе цели, сам их достигай, завязывай на свои сервисы больше систем, в итоге станешь почти незаменимым руководителем серьезного проекта, которого сможет выгнать только очень жесткий менеджер. Нанимаешь таких же программистов, ставите себе подходящие планы, получаете премии, выступаете на паре мероприятий - все, вы выглядите успешнее, чем большая часть разработчиков и менеджеров компании, которые таким не занимаются. Высший пилотаж - завязать кучу неважных сервисов друг на друга так, чтобы они выглядели как важная экосистема, но на самом деле обслуживали бы пару запросов в секунду и не требовали бы серьезной квалификации для их развития. Так и появляются команды, увольнения которых никто не заметил, и горящие за свой проект разработчики, у которых он за 6 лет почему-то начинает тормозить все сильнее и сильнее.
Нет ничего плохого в 1000 микросервисах, вопросы возникают к тому, что их надо постоянно обслуживать (это возможно) и настраивать (а вот это очень странно). И это либо действительно знак, что у команды все крайне плохо с качеством работы, либо их целенаправленно топят, а это интересно.
По данным источников, Twitter — это система с более чем 1000 микросервисов, которые требуют постоянной настройки и обслуживания, и если ошибки вовремя не исправить, то они перерастут в угрозу для безопасности и данных пользователей.
Я не знаю, проблемы ли это с переводом, или что-то еще, но как же смачно разработчиков и безопасников Твиттера мешают с мусором. 1000 микросервисов, которые требуют постоянной настройки, да еще и грозящие постоянно протечь, если этого не делать. Не очень понимаю, так все настолько плохо, либо переводчики постарались?
Имхо, этот вопрос разумнее рассматривать немного иначе. Давайте пересчитаем все расходы на найм джуна, который будет учиться внутри компании: рабочее место, техника, реальные затраты времени наставника/наставников, упущенные задачи в проектах, если они возникают, и так далее, в зависимости от конкретной компании. И получится какая-то сумма N, с которой уже можно думать в стиле «Мы можем нанять этого человека, заплатить ему 60 тысяч, через полгода повысить до 120 тысяч, при этом ещё надо потратить на него 1 200 000 за полгода. Мы готовы к этому, либо есть способ потратить такие суммы лучше?»
С таким подходом гораздо проще избежать ситуации, когда куча денег утрачена, проекты страдают, а ехидный джун говорит, что ему дали х2, не дадите столько же - уйду. И уходит.
Twitter не пояснила, будет ли им выплачена компенсация и моральный ущерб в такой ситуации.
ИМХО, меня бы напугало, если кто-то бы пришел и сказал, что Твиттер что-то пояснила...
А если серьезно, то очень расстраивает тренд на обезличенные новости, где Твиттер что-то сделала/не сделала/обещала. Все это делают конкретные люди, которые принимают решения и несут за них ответственность, а не абстрактная компания. Сейчас можно наблюдать интереснейшую ситуацию, когда толпу разработчиков просто вышвырнули на улицу.
Протупил начальник и не защитил своих подчиненных? Напишите честно об этом.
Начальник исправил свою ошибку и отстоял подчиненных? Напишите и об этом.
Уволили две тысячи, а позвали двадцать человек в два отдела? Или же назад позвали половину, так как конкретные кадровики сделали все кое-как?
Это важно, с этими людьми потом работать, а их тщательно обеляют и оберегают авторы статей.
Без конкретики это выглядит как "Маск купил Твиттер, кого-то уволили, кого-то нет, кого-то позвали назад, кому-то заплатили мало, кому-то много, сотрудники говорят, что непонятно, кто виноват, Твиттер молчит".
Но почему он обязан это делать и соблюдать всё новые «требования к безопасности», которые для него принимают посторонние лица?
Зачастую проблема связана с желанием авторов сидеть на двух стульях. С одной стороны, хочется уважения сообщества, похвалы и всяких ништяков. С другой - хочется иметь возможность уйти в любой момент так, чтобы никто не поругал, а еще бы и сказали спасибо за все. Казалось бы, не уверен в себе, сомневаешься - повесь плашку, что это проект без планов по поддержке, баги не обязательно будут исправлены, уязвимости закрывать не хочу, будете лезть - забаню. Хотите поддержку - хотите. Но если так сделать, то уважения почему-то мало, а тысяч довольных пользователей нет. А так да, у ОперСорса растут стандарты качества, выкинуть на форум zip-архив с кодом - это уже несколько не то.
Могу поздравить с хорошим спором с соломенным чучелом, вы довели аргументы несуществующей стороны до абсурда, но даже так не смогли их нормально опровергнуть.
Но на самом деле важно совсем не это: неважно, кто и в каком количестве отсеялся в процессе отбора кандидатов, важно, кто остался. Если остались люди, которые работают за нужные деньги, делают нудные задачи с нужным процентом провалов - ваша схема отлично подходит. И здесь не обязательно критерием является ВО, я знаю людей, которые требовали любовь к бане, кальянам в офисе, прохождение «теста на реакцию на непроизвольное испускание газов». И они собирали неплохие команды (в рамках критериев выше), правда почему-то эти начальники не оказались спустя долгие годы ни руководителями чего-то крутого, ни долларовыми миллионерами, ни звёздами статей. Так, середнячки с уклоном к слабому.
Но если команда не показывает нужный результат, вот тогда начальника надо очень внимательно проверять: как он нанимает, кого отсеивает, почему, где эти люди работают сейчас, насколько эти компании лучше вашей. Это только в плане найма. И карать за осознанные решения: большие права — большая ответственность.
Вопрос в том, в каком смысле параноидальное :)
Вероятность того, что получится узнать что-то ценное, прослушивая часы конкретного ребёнка, не очень большая, скорее всего. Хотя есть шанс случайно наткнуться на интересные разговоры о планах, ценностях, которые где-то лежат. Или есть ли шанс, что вы рядом с ребёнком скажете что-то такое, что не хотели бы, чтобы кто-то услышал? Какие-то подробности семейной жизни, мнение о других людях, планы в бизнесе, что-то ещё?
Но есть второй момент: дети гораздо сильнее подвержены манипуляциям просто из-за меньшего жизненного опыта и страза неодобрения со стороны близких (как бы при этом не старались родители создать доверительные отношения, все равно не хочется перед ними позориться). И поэтому шанс, что какая-то ерунда (с нашей точки зрения), вроде подслушанного разговора или фотографий с часов, станет хорошей основой для шантажа, весьма велик. Я общался со специалистами, которые разбирались с последствиями похожих ситуаций, и могу точно сказать, что не хотел бы пожелать кому-то понять, что все это произошло из-за херни, которую они нацепили на ребёнка.
И я не против детских часов из-за вопросов их безопасности, я за то, чтобы родители осознавали, какую вещь они покупают, какие у неё вообще есть возможности, насколько она надежная, и кто ее производитель.
С часами для детей есть один нюанс: в районе 2019-2021 года многие часы проектировались непонятно кем: некачественное и дырявое ПО, логические проблемы, странные вшитые пароли. Для многих моделей картина выглядела так: если ты дал ребенку часы, то фактически предоставил неограниченный доступ к микрофону и камере этих часов практически неограниченному кругу людей, которые способны прочитать инструкцию. Наверное, эти люди могут придумать много не самых добрых вещей, которые можно сделать с такими возможностями.
Возможно, что-то сейчас изменилось. Возможно (и скорее всего), не все модели вообще сейчас имеют хоть одну проблему. Но надо очень хорошо подумать, если вы просто решили купить и нацепить на ребенка какое-то устройство по отзывам в сети...
Важный момент - высокая эффективность не равна высокой полезности. Условный крудошлеп, который выкатывает по 200 новых API в неделю, крайне эффективен. Но если это происходит в бессмысленном проекте, то польза от него околонулевая. Поэтому и получается, что долгое время хвалили эффективных, а в итоге сохранили полезных.
Как минимум, они видят начальников этих работников в беде и руководителей уровнем выше. Условно, разработчик видит, что его руководитель спокойно ходит, когда часть его подчиненных бесплатно поработала. Мне интересно, что чувствуют разработчики, и как к этому относятся.
Если все действительно так, как описано в статье, то мне крайне интересно, что в такой ситуации думают другие разработчики этой компании. Человек ходит каждый день в офис/сидит в чатах и видит тех, кто не платит деньги его коллеге/кто не предупредил об этом/пишет насмешливые письма, что есть проблемы с выплатами, потерпите. Какие мысли при это возникают в голове, чувства уважения и доверия?
Кто все эти люди? У любого специалиста и эксперта есть фамилия, имя и отчество. Время безымянных авторитетов в сфере ИБ прошло. А так - другие эксперты заявляли, что этот способ более безопасный и надёжный в случае Сбера, чем использование магазина приложений.
А по теме - люди из Сбера молодцы, реализовали неплохой способ частично решить проблему. Но не очень понятно, зачем об этом растрезвонили журналистам.
Имхо, люди, которые такое говорят, либо нагло врут, либо специально что-то не договаривают. Не хватает квалифицированных сотрудников, готовых за определённые деньги (желательно небольшие) качественно делать то, что им сказали, в срок. Это условный минимум, который нужен, и он вообще не похож на «Не хватает айтишников».
А с сертификациями ситуация очень простая: достаточно сделать так, чтобы сертификаты что-то гарантировали. Компания сертифицирована джависта, а он не знает, как работает что-то? Отлично, собрали комиссию, подтвердили это, сертификационная компания выплатила 5 зарплат этого джависта в качестве компенсации и отозвала сертификат у него. Иначе получается очень удобно, можно сидеть и штамповать дорогие сертификаты, но при этом не отвечать за них финансово. Если будет такая система, то есть шанс, что останутся только вопросы по опыту работы и нетехнические вопросы. Правда, потребуется 5-10 сертификатов на среднюю вакансию, но это же явно лучше, чем отвечать на вопросы технического собеседования.
Интересно, появится ли в ближайшее время в лексиконе термин "(не)эффективные программисты"? Умеют красиво говорить, описывать процессы и то, что надо сделать, а в итоге продукт у такой команды не получился ни разу. Зато успешно обвиняют менеджеров, HR и бизнес во всех проблемах.
Имхо, такой безопасник - это именно что дармоед. Если человек не может выстроить процесс работы так, чтобы уязвимости исправлялись или компенсировались, а изменения согласовывались с ним, то он сидит и занимается симуляцией ИБ. Не дают ресурсов, полномочий, не получается договориться? А зачем тогда сидеть в таком месте? Получение зарплаты в таких условиях - это очень похоже на дармоедство.
ИБ - это уже давно не запуск Nessus и печать кучи PDF-отчётов. Это серьезная работа с людьми и организация процессов.
Проблема зачастую в том, что на многих конференциях выступают не люди, которые реально что-то знают в теме, о которой рассказывают, а те, кто хочет выступить. Особенно часто это встречаю тогда, когда специалист в одной теме зачем-то рассказывает о не совсем смежной теме, в которой он что-то знает. Например, на конференциях и митапах по тестированию любят рассказывать про информационную безопасность. И если тестировщик рассказывает про ИБ, то очень часто он допускает либо серьезные фактические ошибки, либо рассказывает правильные вещи, но так, что их почти гарантированно неправильно поймёт человек, который с этой темой незнаком. Но зато у выступающих нет никаких проблем с синдромом самозванца.
По моему опыту, это привело просто к тому, что на каждое обращение в поддержку появляется окно, в котором предлагают оценить ответ поддержки.
Недавно заказал товар, у которого срок годности год, приехала упаковка, у которой срок годности истекает меньше, чем через 2 недели. Написал в поддержку, мне предложили его относить куда-то, что-то заполнять, куда-то отсылать. Оценил качество поддержки на минимум, написал, туда ряд вопросов, никто не ответил.
А главный вопрос - зачем Озон хочет, чтобы я возвращал товар, который к моменту возврата станет просроченным? Куда его денут?)
И в чате добиться возможности написать человеку стало сложнее. Зато KPI улучшился.
Имхо, один из главных моментов - не надо превращать материал на 5 минут в доклад на 30. Слушатель прекрасно понимает, что автор просто тянет время, потому что «5 минут - это некруто» или «Слоты только по 30 или 60 минут». Да и хороший доклад на 5-10 минут с огромным удовольствием можно посмотреть на Ютубе, а вот что-то на полчаса, час или вообще на 2 - только при очень большом желании посмотреть конкретно это видео.
Имхо, тут все не так однобоко, как описано в статье, есть ещё минимум два момента:
Сейчас стало довольно много разработчиков, которые живут в практически идеальных условиях: современнейшая техника, последние модели телефонов, постоянный интернет не ниже LTE, устойчивая связь даже на другом континенте. И это приводит к тому, что даже очень плохо написанные сервисы внезапно работают довольно хорошо (у этих разработчиков). И возникает ощущение, что так у всех. Пару лет назад я обсуждал с разработчиками и безопасниками очень известной соцсети, что для того, чтобы получить доступ к практически любому аккаунту достаточно знать номер телефона и прервать доступ человек в интернет на 5 минут. И эти люди (весьма молодые) на полном серьезе говорили, что у них интернет не пропадает, они все уведомления всегда получают, таких проблем нет. И только после обсуждения того, что есть самолёты, есть поезда, есть подвалы, есть даже реанимации, где интернет есть, но пользоваться обычно им не хочется, начался конструктивный диалог. Существует довольно много разработчиков, которые в целом с проблемами не сталкиваются, зачем им писать нормальные (а критерий нормальности - тоже спорная штука)) формы и сервисы.
> Так себе это представляет бизнес, и когда управлению скажут что оно работает, но что-то может пойти не так, и на обработку этого не так надо еще +N дней, то есть увеличить время разработки фичи, например, в 2 раза, то обычно чаша весов склоняются в сторону “если не должно быть, в теории, то и не делаем, не критично”. И вот это не критично выливается в удобство использования и многочисленные негативные возгласы в отзывах на продукт.
Довольно часто (не сказал бы, что в большинстве случаев, но встречается нередко) бывает немного другая ситуация: приходит условный бизнес/руководство и говорит, что надо сделать что-то очень хорошо (я это обычно это наблюдаю в вопросах безопасности из-за специфики работы, но это встречается много где), выделяет разработчикам запрошенное время, спрашивает, нужно ли ещё что-то, все ок. А в результате оказывается, что не сделано практически ничего, в худшем же случае резко возникает десяток историй про то, что все хорошо, это коллеги ничего не поняли, все сделано так, как договаривались. Проблема частично в том, что хорошо разрабатывать очень скучно: надо делать много рутинных и обязательных вещей, которые делать лень. Скорее всего, вам самому было бы лень делать проверки на все те случаи загрузки файла, которые описаны в статье, гораздо проще выкинуть ошибку с кодом 200 и написать «Ошибка загрузки». И только самоуважение, серьезная дисциплина разработки, либо неизбежная кара за косяки приводит к тому, что ПО получается довольно качественным хотя бы на уровне отсутствия базовых проблем, вроде непонятных ошибок или постоянных вылетов.
ИМХО, все может быть гораздо проще: бывает тупо выгодно плодить огромное количество проектов и создавать гору бесполезных сервисов просто потому, что под это можно создать команду, а потом и группу команд, чтобы стать уже довольно влиятельным менеджером. Самое сложное в этом - начать, надо убедить окружающих, что ты делаешь что-то полезное, а потом уже проще: ты владелец 10 сервисов, на которые что-то завязано, ставь сам себе цели, сам их достигай, завязывай на свои сервисы больше систем, в итоге станешь почти незаменимым руководителем серьезного проекта, которого сможет выгнать только очень жесткий менеджер. Нанимаешь таких же программистов, ставите себе подходящие планы, получаете премии, выступаете на паре мероприятий - все, вы выглядите успешнее, чем большая часть разработчиков и менеджеров компании, которые таким не занимаются. Высший пилотаж - завязать кучу неважных сервисов друг на друга так, чтобы они выглядели как важная экосистема, но на самом деле обслуживали бы пару запросов в секунду и не требовали бы серьезной квалификации для их развития. Так и появляются команды, увольнения которых никто не заметил, и горящие за свой проект разработчики, у которых он за 6 лет почему-то начинает тормозить все сильнее и сильнее.
Нет ничего плохого в 1000 микросервисах, вопросы возникают к тому, что их надо постоянно обслуживать (это возможно) и настраивать (а вот это очень странно). И это либо действительно знак, что у команды все крайне плохо с качеством работы, либо их целенаправленно топят, а это интересно.
Я не знаю, проблемы ли это с переводом, или что-то еще, но как же смачно разработчиков и безопасников Твиттера мешают с мусором. 1000 микросервисов, которые требуют постоянной настройки, да еще и грозящие постоянно протечь, если этого не делать. Не очень понимаю, так все настолько плохо, либо переводчики постарались?
Имхо, этот вопрос разумнее рассматривать немного иначе. Давайте пересчитаем все расходы на найм джуна, который будет учиться внутри компании: рабочее место, техника, реальные затраты времени наставника/наставников, упущенные задачи в проектах, если они возникают, и так далее, в зависимости от конкретной компании. И получится какая-то сумма N, с которой уже можно думать в стиле «Мы можем нанять этого человека, заплатить ему 60 тысяч, через полгода повысить до 120 тысяч, при этом ещё надо потратить на него 1 200 000 за полгода. Мы готовы к этому, либо есть способ потратить такие суммы лучше?»
С таким подходом гораздо проще избежать ситуации, когда куча денег утрачена, проекты страдают, а ехидный джун говорит, что ему дали х2, не дадите столько же - уйду. И уходит.
ИМХО, меня бы напугало, если кто-то бы пришел и сказал, что Твиттер что-то пояснила...
А если серьезно, то очень расстраивает тренд на обезличенные новости, где Твиттер что-то сделала/не сделала/обещала. Все это делают конкретные люди, которые принимают решения и несут за них ответственность, а не абстрактная компания. Сейчас можно наблюдать интереснейшую ситуацию, когда толпу разработчиков просто вышвырнули на улицу.
Протупил начальник и не защитил своих подчиненных? Напишите честно об этом.
Начальник исправил свою ошибку и отстоял подчиненных? Напишите и об этом.
Уволили две тысячи, а позвали двадцать человек в два отдела? Или же назад позвали половину, так как конкретные кадровики сделали все кое-как?
Это важно, с этими людьми потом работать, а их тщательно обеляют и оберегают авторы статей.
Без конкретики это выглядит как "Маск купил Твиттер, кого-то уволили, кого-то нет, кого-то позвали назад, кому-то заплатили мало, кому-то много, сотрудники говорят, что непонятно, кто виноват, Твиттер молчит".
Зачастую проблема связана с желанием авторов сидеть на двух стульях. С одной стороны, хочется уважения сообщества, похвалы и всяких ништяков. С другой - хочется иметь возможность уйти в любой момент так, чтобы никто не поругал, а еще бы и сказали спасибо за все. Казалось бы, не уверен в себе, сомневаешься - повесь плашку, что это проект без планов по поддержке, баги не обязательно будут исправлены, уязвимости закрывать не хочу, будете лезть - забаню. Хотите поддержку - хотите. Но если так сделать, то уважения почему-то мало, а тысяч довольных пользователей нет. А так да, у ОперСорса растут стандарты качества, выкинуть на форум zip-архив с кодом - это уже несколько не то.
Могу поздравить с хорошим спором с соломенным чучелом, вы довели аргументы несуществующей стороны до абсурда, но даже так не смогли их нормально опровергнуть.
Но на самом деле важно совсем не это: неважно, кто и в каком количестве отсеялся в процессе отбора кандидатов, важно, кто остался. Если остались люди, которые работают за нужные деньги, делают нудные задачи с нужным процентом провалов - ваша схема отлично подходит. И здесь не обязательно критерием является ВО, я знаю людей, которые требовали любовь к бане, кальянам в офисе, прохождение «теста на реакцию на непроизвольное испускание газов». И они собирали неплохие команды (в рамках критериев выше), правда почему-то эти начальники не оказались спустя долгие годы ни руководителями чего-то крутого, ни долларовыми миллионерами, ни звёздами статей. Так, середнячки с уклоном к слабому.
Но если команда не показывает нужный результат, вот тогда начальника надо очень внимательно проверять: как он нанимает, кого отсеивает, почему, где эти люди работают сейчас, насколько эти компании лучше вашей. Это только в плане найма. И карать за осознанные решения: большие права — большая ответственность.