Например, чтобы позволить разработчикам выполнять сканирование в IDE, нужно использовать инструмент, который поддерживает распространенное программное обеспечение IDE. Например, анализатор SonarJava интегрируется в сборочную систему Gradle, Maven и запускается в различных IDE через плагин SonarLint.
Есть очень важный момент, который надо учитывать: правильное внедрение инструментов требует понимания того, как они работают, и того, что именно они делают. Например, SonarLint неплох, но он не включает в себя весь SonarJava, а только часть проверок. При этом, имхо, самые интересные проверки как раз не включены. Довольно легко можно создать иллюзию безопасной разработки, когда анализируется каждый коммит, гудят серверы с разными сканерами и фаззерами, но при этом мимо них пролетают реальные уязвимости просто потому, что в данном конвейере нет технологий и правил для значимой части проблем.
Если фантазировать (с оглядкой на запросы работодателей, разумеется), то портрет идеального программиста, за которым будут охотиться все, будет выглядеть примерно так…..
Имхо, надо понимать важный момент: тут описан идеальный программист с точки зрения рекрутера (возможно, что с точки зрения компании, но не факт). Для специалиста это значит, что он должен быть «удобным» Но зачем? Быстро найти работу? Я не знаю ни одного специалиста, который бы вообще не смог найти работу. Быть максимально предсказуемым и понятным? А за это есть реальная надбавка? Иметь стабильное и надежное рабочее место? Что-то я не видел историй, где сокращали весь отдел, но паре человек сказали, что вы нам очень нравитесь, оставайтесь, будем платить зарплату просто так.
Удобный специалист нужен компании, HR, рекрутеру. Но не самому себе. Лучше быть неудобным в удобной для себя компании, чем удобным в неудобной для себя. Не надо быть мудаком, но лучше быть нужным, чем удобным: за довольно редкими исключениями, вас все равно прямо или косвенно уволят, как только вы перестанете подходить под какие-то требования, поэтому надо стремиться к тому, чтобы постоянно увеличивать уровень требований, под которые вы подпадаете. Быть приятным и удобным - это пожелания, а не требования.
Тут я согласен, что нормальные школы могут быть весьма заинтересованы в том, чтобы улучшить процесс прохождения курсов. Но и им есть смысл помнить, что даже при благих намерениях руководства могут пролезть сомнительные преподаватели, особенно если вознаграждение для авторов и ведущих курсов на этих платформах хорошее. Кривые пересказы документации пролезают на тренинги даже на профильных конференциях, хотя казалось бы, что там тренинги - не основной источник денег (но довольно значимый).
Распространённые проблемы, с которыми сталкиваются студенты:
1. Слишком плотный график учёбы, ученики по разным причинам не укладываются в дедлайны с домашними заданиями.
2. Слишком сложный материал или недостаточно раскрыта тема. Не хватает поддержки куратора и экспертов в предоставлении обратной связи, от чего ученик себя чувствует брошенным.
3. Ожидания о профессии / курсе / темах обучения / методах преподавателей не совпали с реальностью.
Возникает вопрос, а где самая распространённая причина «Курс полное дерьмо»? «Ожидания не совпали с реальностью» - это про ситуации, когда ты купил курс по Питону, чтобы использовать его в тестировании, а автор курса больше рассматривал направления анализа данных. А если плохоговорящий, непрофессиональный автор из конторы третьего эшелона на плохую камеру записывает какие-то видео по бумажке - этот курс дерьмо.
Не надо стесняться говорить о проблемах. Если вы хотите, чтобы все курсы воспринимались как продукты инфоцыган по выкачиванию денег за плохие материалы - продолжайте рассказывать о том, как у людей не сходятся ожидания с реальностью, как не хватает помощи наставника, как нужна геймификация и чаты.
Если же вы хотите, чтобы курсы воспринимались хоть как-то серьезно, то первым делом надо согласиться, что значительная часть из них ужасны. И что есть платформы с курсами, которые держат ужасные курсы только потому, что надо грести деньги, побольше денег.
А мягкие формулировки и сожаления давайте оставим маркетологам платформ, которые продают пустые курсы а потом говорят, что им очень жаль, что курс не подошёл.
Имхо, сама схема в целом жизнеспособна, ради шутки можно даже сказать, что она применяется везде (просто распределение разное, какие-то группы отсутствуют). Но вот тут скрыт интересный момент:
Минусы в основном проистекают из неаккуратности и отсутствия опыта работы с таким "пирогом". Если неопытный руководитель попытается, например, поручить незнакомому почасовику написать ту часть, которую вообще-то должна делать "ядерная" команда, то потом от результата работы этих "почасовиков" можно поседевшие волосы во всех местах рвать.
Неопытный руководитель такое разделение не сможет сделать, скорее всего. То есть, руководитель должен быть очень хорошим техническим специалистом, чтобы понять, где команда ошибается, а где его хотят нагло обмануть, чтобы не делать неприятные задачи, либо вообще спихнуть «жирную» задачу знакомому фрилансеру. Но что должно удерживать такого руководителя в такой компании? Если он очень крут технически, то он будет видеть, что фрилансер получает гораздо больше за час, это демотивирует. Если организационно - то есть места руководителей проектов в ряде компаний, где платят очень много. Если и технически, и организационно, то потенциально появляются вообще безумно интересные варианты. А тут предлагается сидеть и готовить не самый стабильный и интересный пирог.
Есть важный момент: часто SAST вызывает у людей чувство, что почти любая проблема будет отловлена на этапе анализа исходного кода. В то время, как качество SAST состоит как минимум из 4 китов:
Качество сканирующего ядра
Качество и полнота правил
Качество документации (как следствие, либо качество интеграции, либо хотя бы шанс не пропустить неочевидный момент) и поддержки поставщика (иногда понять, как сканировать какой-то код, или почему возникает проблема, бывает крайне сложно). Например, даже при использовании весьма качественного SonarQube можно легко пропустить критичную SQL-инъекцию просто потому, что тот, кто использует систему, не знал о том, как именно работает подавление уязвимостей.
Соответствие рекламных материалов реальности (обожаю SAST, которые заявляют поддержку кучи функционала, хотя в реальности не имеют либо правил под него, либо вообще не поддерживают).
Поэтому я почти призываю писать перед каждой статьей, что SAST (и вообще SSDLC) - это очень сложно, но очень круто.
Тут возникает интересный вопрос: допустим, клиент пришёл с возвратом, ему отказали. А что дальше?
Если это был мошенник, то вопросов нет.
Если это был добросовестный покупатель, который купил не то, что ожидал - у него хотя бы есть работающий товар (хотя зачем кому-то нужны условные ботинки на размер больше, непонятно. Их можно продать, но это сложно и невыгодно).
А если это был добросовестный покупатель, который получил бракованный товар? Например, я недавно на Ламоде купил кроссовки и рубашку: в итоге месяца через полтора-два у кроссовок сломалось что-то в заднике, в итоге какая-то деталь впивается в ногу, а рубашка потеряла цвет и протерлась. Формально, на одежду и обувь есть гарантия 30 дней, но я не ношу 30 дней подряд одно и то же, чтобы заметить, что что-то идёт не так. Могу ли я доказать, что это не по моей вине произошло? Скорее всего, нет. Заменит ли Ламода товары на нормальные? Не знаю. Буду ли я рад, если не заменят? Точно не буду, а способов создать сложности магазину много, плюс это сильная утрата доверия.
Имхо, самая важная фраза в этой статье -- вот эта:
Если меры поддержки окажутся действенными, то в течение года-двух можно ожидать поступления на рынок IT-труда новых профессионалов.
По моему опыту, ни один курс, ни один универ не может обучить человека и сделать из него профессионала. Профессионалом можно стать в процессе работы. Наверное, если условный Гикбрейнс напряжется, то через год или два можно получить хоть 200-300 тысяч выпускников, но что делать дальше? Можно получить гораздо менее приятную ситуацию, когда вместо отсутствия кандидатов будет много неопытных разработчиков, с которыми компании не смогут реализовать какие-то более-менее сложные проекты. Если сейчас проект не начинается из-за отсутствия разработчиков, то потом проект может начаться, но не завершиться, либо погрязнуть в процессе бесконечной разработки. И непонятно, что лучше.
Тут есть нюанс: понятно, что фидбек полезен. Как и полезны многие другие вещи: тесты, хорошая документация, хороший CI/CD. Вопрос в том, есть ли более полезные способы потратить время и деньги, которые тратятся на него.
В любом случае есть какая-то внутренняя оценка (конфликтный/неконфликтный, слабый/сильный, что-то знает, что-то не умеет), ее можно использовать для большинства внутренних задач (и для тимлида, и для HR, и для оценки зарплат), но ее нельзя просто так отдать кандидату, к сожалению: требуется ее причесать, убрать кривые и опасные формулировки (но не потерять смысл, то есть этим должен заниматься технический специалист довольно высокого уровня), в части случаев/компаний провести через юристов и HR (так как неудачная формулировка - шанс получить серьёзные проблемы), потом отправить кандидату, далее игнорировать/обрабатывать его замечания. И вот тут возникает проблема: эти удовольствия стоят дорого и занимают довольно много времени. И я пока не видел каких-то хороших попыток проанализировать, выгоден ли он компании или нет.
Есть большое количество историй о том, как кто-то был на собеседовании в определенной компании и по истечении нескольких недель не получил никакого вердикта. Написал или позвонил, чтобы узнать его, но и тут - тишина. Жесть… После такого, в эти компании думаю, что даже в большими офферами не заманишь его. И чаще всего информация о подобном отношении к кандидатам распространяется повсеместно, и у таких компаний количество кандидатов резко сокращается.
Имхо, вопрос фидбэка - это очень сложная и спорная тема. Я не видел ни статистически значимых доказательств того, что он хоть как-то положительно влияет на найм сотрудников в краткосрочной или долгосрочной перспективе (отношение кандидатов в отрыва от найма - весьма бесполезная штука), ни доказательств того, что отсутствие фидбэка мешает нанимать (условно, хотя бы 10 сеньоров, сказавших что они не пойдут работать за 500 тысяч, так как года два назад им не ответили).
Я всецело за то, чтобы кандидаты могли получить обратную связь. Но я просто не могу говорить кому-то, что они должны давать обратную связь, когда никто не показал, что этот процесс несёт какую-то пользу. Фидбек - дорогое удовольствие, к сожалению.
Согласен, что культура прощения ошибок - это очень круто. Но, имхо, есть очень важный момент: не надо путать ошибки и намеренные действия.
Если бы СЕО поспорил бы с парнем, пусть даже долго и агрессивно, а потом бы сам сказал, что он ошибался, то вопросов нет, СЕО признал ошибку, это круто и достойно уважения.
А если он долго спорил, угрожал юристами, а только после публичного обсуждения, кучи недовольных довольно влиятельных (если я правильно помню) людей извинился и сказал, что не будет преследовать парня, то я бы не сказал, что это признание ошибки. Да, это отказ от претензий и прекращение давления в проигрышной ситуации, но не честное самостоятельное признание ошибки.
Перед тем, как писать длинный комментарий, хотелось бы уточнить, эта статья - это экспертное мнение специалиста по ИБ и Геймдеву? Или скорее боль пользователя?
Люди не пытаются нагнуть вас в сделках, они играют в долгую игру и распределяют стимулы таким образом, чтобы выигрывали все.
Надо понимать, что основатель стартапа (да и вообще кто угодно) может говорить что угодно, пока в тени происходит что-то другое: кто-то выступает за уважение, равноправие и культуру общения, но при этом орет на волонтёров, которые не могут делать тяжёлую и опасную работу без инструментов быстро. Другой - пишет про Win - Win (видимо, Win себе и Win сыну), но при этом пытается показать маленький pet-проект:
«Я думаю, вам следует закрыть проект и прекратить работать над ним. Я привлеку наших адвокатов в понедельник, если к тому времени вы не выполните условия. [...] Мы были крошечной компанией, когда вы стажировались у нас [...] К счастью, сейчас мы намного больше, и, что очень важно, у нас есть много денег, чтобы заплатить за лучших юристов, если мы будем вынуждены пойти по этому пути.»— из переписки с CEO Replit
ИМХО, тут есть интересный вопрос: а какие вообще юридические особенности применения таких меток? Условно, метки указывают на сотрудника, к нему приходят, он говорит, что вообще не знает, что за метки, что курили безопасники, и вообще, админ какой-то подозрительный, нарисовал свои точки и слил явно.
Встречаются ситуации, когда системы меток не только не позволяют что-то сделать с потенциально виновным, но и подставить заведомо невиновных (как админу, который может многое сделать в система, так и хитрому сотруднику)
Проблема, ИМХО, в другом. У Яндекс.Еды просто не прокатило.
В рамках Bug Bounty я находил безумные утечки данных из разных доставок еды, товаров, такси и подобных сервисов. Эти разные доставки жили на сумасшедшей инфраструктуре (как вам ежедневный отчёт по всем клиентам, который прилетает в открытый чат в ТГ?) из разных сервисов, которые друг с другом связаны плохо, либо вообще не связаны. И это прокатывало просто потому, что никто, кто это находил, не публиковал это (кому-то не хотелось, кому-то за это платили). И те, кто работал в компании, и таскал базы на флешках, в Гугл-дисках и других местах, их не сливали.
А тут просто не прокатило, и кто-то слил или спер. Это не значит, что Яндекс.Еда более дырявая, чем другие сервисы доставки, они просто первые, кому настолько крупно не повезло.
Александр — Penetration Tester с хорошим бекграундом, он получает заработную плату в 200 тысяч рублей, и за месяц делает 2-3 проекта в уважаемой компании. Сама же компания продает эти проекты по 1,2-1,5 миллиона для крупных Заказчиков.
ИМХО, это дно. Реальное время на такие проекты - неделя. Какой пентест можно провести в одиночку за неделю? Просканировать диапазоны из договора, найти то, что там установлено, использовать готовые эксплоиты, вскрыть пару сервисов и написать отчёт? А кому он нужен? Тем, кто хочет просто красивую бумажку от уважаемой компании? Так биржа не решит эту задачу, бумажка от лидера рынка и от Александра - это совершенно разные вещи, как был крут Александр не был.
Правильно выбранная компания - это экспертиза разных людей и возможность нанимать кого-то ещё (отдельных специалистов или подрядчиков), если они нужны. Что будет делать Александр, если не будет знать, что делать с этой системой? Или если окажется, что в рамках аудита надо будет работать с технологиями, которые он не любит и не понимает?
С точки зрения заказчика - это дно, если ты не умеешь выбирать и искать подрядчиков, то биржа не поможет. А с точки зрения исполнителя такая биржа - прикольная штука, можно взять пару заказов тысяч на 300-400, запустить сканеры и за месяц накопить на отпуск. А небольшие заказчики без своих ИБ-специалистов даже не смогут понять, было ли что-то действительно сделано. Но оставят хорошие отзывы, ведь отчёт на русском, понятен, горы задач для не было, кайф.
1) Многие считают, что «хорошие разработчики» могут разобраться в проблемах и разработать исправление, которое починит проблемы. С моей точки зрения, это совсем не так: умение разрабатывать сложные системы и умение разбираться, как они работают на самом деле, и как их починить - это совершенно разные навыки. Понятно, что если решить переписывать всю систему, то они ее перепишут, и есть шанс, что она будет даже работать без базовых проблем. Но вот понять, что именно надо исправить в существующей системе, они обязательно смогут. Для этого нужны совсем другие навыки и компетенции.
2) Существует очень мало информации о том, что надо делать, если готовая сложная система работает плохо. Есть базовые советы по рефакторингу, есть много материалов по переходу на другие технологии, но понятных рекомендаций или алгоритмов по тому, как исправлять сложные системы, очень мало.
Поэтому весьма логично, что хорошие разработчики, тимлиды, техлиды и архитекторы не могут исправить подобные проблемы. Это просто не их компетенции (возможно, кто-то знает, догадывается или угадывает, как это делать, но не потому, что он хороший разработчик).
В случае сертификации вопрос всегда один: что именно она подтверждает?
Курс состоит из 50+ коротких видео. Также к курсу прилагаются презентация и статьи.
Этот сертификат подтверждает, что человек способен просмотреть 50 видео, почитать статьи и ответить на вопросы? И при этом называется … practitioner? Я не очень понимаю, как это работает, если честно.
Имхо, проблема в том, что учиться на ошибках практически невозможно: для этого нужно, чтобы была полная информация об ошибке, плюс материалы для учебы. В случае шифровальщика, например, это значит, что компания должна рассказать о том, что они словили, как, какие меры защиты были, кто и по какой причине выбрал именно такие меры. И должна быть исчерпывающая инструкция по защите от шифровальщиков. Но ни компания, ни инструкция никому ничего не должны. И поэтому часто это выглядит так:
- Учитесь на ошибках других!
- Хорошо, а в чем именно была их ошибка?
- Ой, это закрытая информация, есть только сухое письмо компании
- Хорошо, а где материалы для учебы взять?
- Ой, поищите в интернете, они есть, вон те ребята их нашли, успешно применяют
ИМХО, тут есть очень тонкий момент: IT у многих бизнесменов вызывает если не отвращение, то недоверие: я неоднократно встречал ситуации, когда айтишники, которые говорили, что проект слишком сложный, нереализуемый за эти сроки, внезапно его реализовывали, когда им давали выбор: либо премии в х2-х3 от зарплаты, либо увольнение с реальными помехами в дальнейшей работе. И проблема IT не в том, что они такие глупые или ленивые, а в том, что они не смогли показать, что это исключительная ситуация, когда люди безумно перерабатывали, жертвовали надёжностью и стабильностью систем, чтобы их потом дорабатывать. И для бизнеса они выглядят не как партнёры, которые донесли риски и сделали безумное усилие, а как нахлебники, которых надо жестко бить, угнетать, заставлять сидеть в офисе с контролем по пропускам, чтобы они начали работать. IT - это не только написание кода и подготовка инфраструктуры, но и серьезная работа по постоянному (!) объяснению, зачем они нужны, и почему так работают. Например: почему топ-менеджер компании получат месячную зарплату айтишники за день? Не потому, что он просто делает свою работу, а ещё и потому, что может объяснить, почему она важна.
Есть очень важный момент, который надо учитывать: правильное внедрение инструментов требует понимания того, как они работают, и того, что именно они делают. Например, SonarLint неплох, но он не включает в себя весь SonarJava, а только часть проверок. При этом, имхо, самые интересные проверки как раз не включены. Довольно легко можно создать иллюзию безопасной разработки, когда анализируется каждый коммит, гудят серверы с разными сканерами и фаззерами, но при этом мимо них пролетают реальные уязвимости просто потому, что в данном конвейере нет технологий и правил для значимой части проблем.
Имхо, надо понимать важный момент: тут описан идеальный программист с точки зрения рекрутера (возможно, что с точки зрения компании, но не факт). Для специалиста это значит, что он должен быть «удобным» Но зачем? Быстро найти работу? Я не знаю ни одного специалиста, который бы вообще не смог найти работу. Быть максимально предсказуемым и понятным? А за это есть реальная надбавка? Иметь стабильное и надежное рабочее место? Что-то я не видел историй, где сокращали весь отдел, но паре человек сказали, что вы нам очень нравитесь, оставайтесь, будем платить зарплату просто так.
Удобный специалист нужен компании, HR, рекрутеру. Но не самому себе. Лучше быть неудобным в удобной для себя компании, чем удобным в неудобной для себя. Не надо быть мудаком, но лучше быть нужным, чем удобным: за довольно редкими исключениями, вас все равно прямо или косвенно уволят, как только вы перестанете подходить под какие-то требования, поэтому надо стремиться к тому, чтобы постоянно увеличивать уровень требований, под которые вы подпадаете. Быть приятным и удобным - это пожелания, а не требования.
Тут я согласен, что нормальные школы могут быть весьма заинтересованы в том, чтобы улучшить процесс прохождения курсов. Но и им есть смысл помнить, что даже при благих намерениях руководства могут пролезть сомнительные преподаватели, особенно если вознаграждение для авторов и ведущих курсов на этих платформах хорошее. Кривые пересказы документации пролезают на тренинги даже на профильных конференциях, хотя казалось бы, что там тренинги - не основной источник денег (но довольно значимый).
Возникает вопрос, а где самая распространённая причина «Курс полное дерьмо»? «Ожидания не совпали с реальностью» - это про ситуации, когда ты купил курс по Питону, чтобы использовать его в тестировании, а автор курса больше рассматривал направления анализа данных. А если плохоговорящий, непрофессиональный автор из конторы третьего эшелона на плохую камеру записывает какие-то видео по бумажке - этот курс дерьмо.
Не надо стесняться говорить о проблемах. Если вы хотите, чтобы все курсы воспринимались как продукты инфоцыган по выкачиванию денег за плохие материалы - продолжайте рассказывать о том, как у людей не сходятся ожидания с реальностью, как не хватает помощи наставника, как нужна геймификация и чаты.
Если же вы хотите, чтобы курсы воспринимались хоть как-то серьезно, то первым делом надо согласиться, что значительная часть из них ужасны. И что есть платформы с курсами, которые держат ужасные курсы только потому, что надо грести деньги, побольше денег.
А мягкие формулировки и сожаления давайте оставим маркетологам платформ, которые продают пустые курсы а потом говорят, что им очень жаль, что курс не подошёл.
Имхо, сама схема в целом жизнеспособна, ради шутки можно даже сказать, что она применяется везде (просто распределение разное, какие-то группы отсутствуют). Но вот тут скрыт интересный момент:
Неопытный руководитель такое разделение не сможет сделать, скорее всего. То есть, руководитель должен быть очень хорошим техническим специалистом, чтобы понять, где команда ошибается, а где его хотят нагло обмануть, чтобы не делать неприятные задачи, либо вообще спихнуть «жирную» задачу знакомому фрилансеру. Но что должно удерживать такого руководителя в такой компании? Если он очень крут технически, то он будет видеть, что фрилансер получает гораздо больше за час, это демотивирует. Если организационно - то есть места руководителей проектов в ряде компаний, где платят очень много. Если и технически, и организационно, то потенциально появляются вообще безумно интересные варианты. А тут предлагается сидеть и готовить не самый стабильный и интересный пирог.
Есть важный момент: часто SAST вызывает у людей чувство, что почти любая проблема будет отловлена на этапе анализа исходного кода. В то время, как качество SAST состоит как минимум из 4 китов:
Качество сканирующего ядра
Качество и полнота правил
Качество документации (как следствие, либо качество интеграции, либо хотя бы шанс не пропустить неочевидный момент) и поддержки поставщика (иногда понять, как сканировать какой-то код, или почему возникает проблема, бывает крайне сложно). Например, даже при использовании весьма качественного SonarQube можно легко пропустить критичную SQL-инъекцию просто потому, что тот, кто использует систему, не знал о том, как именно работает подавление уязвимостей.
Соответствие рекламных материалов реальности (обожаю SAST, которые заявляют поддержку кучи функционала, хотя в реальности не имеют либо правил под него, либо вообще не поддерживают).
Поэтому я почти призываю писать перед каждой статьей, что SAST (и вообще SSDLC) - это очень сложно, но очень круто.
Тут возникает интересный вопрос: допустим, клиент пришёл с возвратом, ему отказали. А что дальше?
Если это был мошенник, то вопросов нет.
Если это был добросовестный покупатель, который купил не то, что ожидал - у него хотя бы есть работающий товар (хотя зачем кому-то нужны условные ботинки на размер больше, непонятно. Их можно продать, но это сложно и невыгодно).
А если это был добросовестный покупатель, который получил бракованный товар? Например, я недавно на Ламоде купил кроссовки и рубашку: в итоге месяца через полтора-два у кроссовок сломалось что-то в заднике, в итоге какая-то деталь впивается в ногу, а рубашка потеряла цвет и протерлась. Формально, на одежду и обувь есть гарантия 30 дней, но я не ношу 30 дней подряд одно и то же, чтобы заметить, что что-то идёт не так. Могу ли я доказать, что это не по моей вине произошло? Скорее всего, нет. Заменит ли Ламода товары на нормальные? Не знаю. Буду ли я рад, если не заменят? Точно не буду, а способов создать сложности магазину много, плюс это сильная утрата доверия.
Имхо, самая важная фраза в этой статье -- вот эта:
По моему опыту, ни один курс, ни один универ не может обучить человека и сделать из него профессионала. Профессионалом можно стать в процессе работы. Наверное, если условный Гикбрейнс напряжется, то через год или два можно получить хоть 200-300 тысяч выпускников, но что делать дальше? Можно получить гораздо менее приятную ситуацию, когда вместо отсутствия кандидатов будет много неопытных разработчиков, с которыми компании не смогут реализовать какие-то более-менее сложные проекты. Если сейчас проект не начинается из-за отсутствия разработчиков, то потом проект может начаться, но не завершиться, либо погрязнуть в процессе бесконечной разработки. И непонятно, что лучше.
Тут есть нюанс: понятно, что фидбек полезен. Как и полезны многие другие вещи: тесты, хорошая документация, хороший CI/CD. Вопрос в том, есть ли более полезные способы потратить время и деньги, которые тратятся на него.
В любом случае есть какая-то внутренняя оценка (конфликтный/неконфликтный, слабый/сильный, что-то знает, что-то не умеет), ее можно использовать для большинства внутренних задач (и для тимлида, и для HR, и для оценки зарплат), но ее нельзя просто так отдать кандидату, к сожалению: требуется ее причесать, убрать кривые и опасные формулировки (но не потерять смысл, то есть этим должен заниматься технический специалист довольно высокого уровня), в части случаев/компаний провести через юристов и HR (так как неудачная формулировка - шанс получить серьёзные проблемы), потом отправить кандидату, далее игнорировать/обрабатывать его замечания. И вот тут возникает проблема: эти удовольствия стоят дорого и занимают довольно много времени. И я пока не видел каких-то хороших попыток проанализировать, выгоден ли он компании или нет.
Имхо, вопрос фидбэка - это очень сложная и спорная тема. Я не видел ни статистически значимых доказательств того, что он хоть как-то положительно влияет на найм сотрудников в краткосрочной или долгосрочной перспективе (отношение кандидатов в отрыва от найма - весьма бесполезная штука), ни доказательств того, что отсутствие фидбэка мешает нанимать (условно, хотя бы 10 сеньоров, сказавших что они не пойдут работать за 500 тысяч, так как года два назад им не ответили).
Я всецело за то, чтобы кандидаты могли получить обратную связь. Но я просто не могу говорить кому-то, что они должны давать обратную связь, когда никто не показал, что этот процесс несёт какую-то пользу. Фидбек - дорогое удовольствие, к сожалению.
Согласен, что культура прощения ошибок - это очень круто. Но, имхо, есть очень важный момент: не надо путать ошибки и намеренные действия.
Если бы СЕО поспорил бы с парнем, пусть даже долго и агрессивно, а потом бы сам сказал, что он ошибался, то вопросов нет, СЕО признал ошибку, это круто и достойно уважения.
А если он долго спорил, угрожал юристами, а только после публичного обсуждения, кучи недовольных довольно влиятельных (если я правильно помню) людей извинился и сказал, что не будет преследовать парня, то я бы не сказал, что это признание ошибки. Да, это отказ от претензий и прекращение давления в проигрышной ситуации, но не честное самостоятельное признание ошибки.
А за перевод спасибо, было интересно почитать.
Перед тем, как писать длинный комментарий, хотелось бы уточнить, эта статья - это экспертное мнение специалиста по ИБ и Геймдеву? Или скорее боль пользователя?
Надо понимать, что основатель стартапа (да и вообще кто угодно) может говорить что угодно, пока в тени происходит что-то другое: кто-то выступает за уважение, равноправие и культуру общения, но при этом орет на волонтёров, которые не могут делать тяжёлую и опасную работу без инструментов быстро. Другой - пишет про Win - Win (видимо, Win себе и Win сыну), но при этом пытается показать маленький pet-проект:
https://habr.com/ru/company/macloud/blog/561544/
ИМХО, тут есть интересный вопрос: а какие вообще юридические особенности применения таких меток? Условно, метки указывают на сотрудника, к нему приходят, он говорит, что вообще не знает, что за метки, что курили безопасники, и вообще, админ какой-то подозрительный, нарисовал свои точки и слил явно.
Встречаются ситуации, когда системы меток не только не позволяют что-то сделать с потенциально виновным, но и подставить заведомо невиновных (как админу, который может многое сделать в система, так и хитрому сотруднику)
Проблема, ИМХО, в другом. У Яндекс.Еды просто не прокатило.
В рамках Bug Bounty я находил безумные утечки данных из разных доставок еды, товаров, такси и подобных сервисов. Эти разные доставки жили на сумасшедшей инфраструктуре (как вам ежедневный отчёт по всем клиентам, который прилетает в открытый чат в ТГ?) из разных сервисов, которые друг с другом связаны плохо, либо вообще не связаны. И это прокатывало просто потому, что никто, кто это находил, не публиковал это (кому-то не хотелось, кому-то за это платили). И те, кто работал в компании, и таскал базы на флешках, в Гугл-дисках и других местах, их не сливали.
А тут просто не прокатило, и кто-то слил или спер. Это не значит, что Яндекс.Еда более дырявая, чем другие сервисы доставки, они просто первые, кому настолько крупно не повезло.
ИМХО, это дно. Реальное время на такие проекты - неделя. Какой пентест можно провести в одиночку за неделю? Просканировать диапазоны из договора, найти то, что там установлено, использовать готовые эксплоиты, вскрыть пару сервисов и написать отчёт? А кому он нужен? Тем, кто хочет просто красивую бумажку от уважаемой компании? Так биржа не решит эту задачу, бумажка от лидера рынка и от Александра - это совершенно разные вещи, как был крут Александр не был.
Правильно выбранная компания - это экспертиза разных людей и возможность нанимать кого-то ещё (отдельных специалистов или подрядчиков), если они нужны. Что будет делать Александр, если не будет знать, что делать с этой системой? Или если окажется, что в рамках аудита надо будет работать с технологиями, которые он не любит и не понимает?
С точки зрения заказчика - это дно, если ты не умеешь выбирать и искать подрядчиков, то биржа не поможет. А с точки зрения исполнителя такая биржа - прикольная штука, можно взять пару заказов тысяч на 300-400, запустить сканеры и за месяц накопить на отпуск. А небольшие заказчики без своих ИБ-специалистов даже не смогут понять, было ли что-то действительно сделано. Но оставят хорошие отзывы, ведь отчёт на русском, понятен, горы задач для не было, кайф.
Имхо, есть две проблемы:
1) Многие считают, что «хорошие разработчики» могут разобраться в проблемах и разработать исправление, которое починит проблемы. С моей точки зрения, это совсем не так: умение разрабатывать сложные системы и умение разбираться, как они работают на самом деле, и как их починить - это совершенно разные навыки. Понятно, что если решить переписывать всю систему, то они ее перепишут, и есть шанс, что она будет даже работать без базовых проблем. Но вот понять, что именно надо исправить в существующей системе, они обязательно смогут. Для этого нужны совсем другие навыки и компетенции.
2) Существует очень мало информации о том, что надо делать, если готовая сложная система работает плохо. Есть базовые советы по рефакторингу, есть много материалов по переходу на другие технологии, но понятных рекомендаций или алгоритмов по тому, как исправлять сложные системы, очень мало.
Поэтому весьма логично, что хорошие разработчики, тимлиды, техлиды и архитекторы не могут исправить подобные проблемы. Это просто не их компетенции (возможно, кто-то знает, догадывается или угадывает, как это делать, но не потому, что он хороший разработчик).
В случае сертификации вопрос всегда один: что именно она подтверждает?
Этот сертификат подтверждает, что человек способен просмотреть 50 видео, почитать статьи и ответить на вопросы? И при этом называется … practitioner? Я не очень понимаю, как это работает, если честно.
Имхо, проблема в том, что учиться на ошибках практически невозможно: для этого нужно, чтобы была полная информация об ошибке, плюс материалы для учебы. В случае шифровальщика, например, это значит, что компания должна рассказать о том, что они словили, как, какие меры защиты были, кто и по какой причине выбрал именно такие меры. И должна быть исчерпывающая инструкция по защите от шифровальщиков. Но ни компания, ни инструкция никому ничего не должны. И поэтому часто это выглядит так:
- Учитесь на ошибках других!
- Хорошо, а в чем именно была их ошибка?
- Ой, это закрытая информация, есть только сухое письмо компании
- Хорошо, а где материалы для учебы взять?
- Ой, поищите в интернете, они есть, вон те ребята их нашли, успешно применяют
ИМХО, тут есть очень тонкий момент: IT у многих бизнесменов вызывает если не отвращение, то недоверие: я неоднократно встречал ситуации, когда айтишники, которые говорили, что проект слишком сложный, нереализуемый за эти сроки, внезапно его реализовывали, когда им давали выбор: либо премии в х2-х3 от зарплаты, либо увольнение с реальными помехами в дальнейшей работе. И проблема IT не в том, что они такие глупые или ленивые, а в том, что они не смогли показать, что это исключительная ситуация, когда люди безумно перерабатывали, жертвовали надёжностью и стабильностью систем, чтобы их потом дорабатывать. И для бизнеса они выглядят не как партнёры, которые донесли риски и сделали безумное усилие, а как нахлебники, которых надо жестко бить, угнетать, заставлять сидеть в офисе с контролем по пропускам, чтобы они начали работать. IT - это не только написание кода и подготовка инфраструктуры, но и серьезная работа по постоянному (!) объяснению, зачем они нужны, и почему так работают. Например: почему топ-менеджер компании получат месячную зарплату айтишники за день? Не потому, что он просто делает свою работу, а ещё и потому, что может объяснить, почему она важна.