‣ Почему для перехода в другую компанию нужно тренировать навыки, никак не относящиеся к работе?
‣ Почему вместо работы мы ходим на встречи, а вместо принятия рисков занимаемся гаданием?
‣ Почему нам говорят: «владейте продуктом», но прибылей от продукта не достается?
На все вопросы легко находятся ответы, если перестать притворяться, что братства техно-анархистов не существует.
Статья является последней в цикле «Заговора разработчиков»:
Тактика работы с коллективом (эта статья).
На каждом этапе жизненного цикла разработчика — собеседование, знакомство с корпоративной культурой, работа в скраме — подпольная организация анархистов пытается саботировать процесс, и ниже мы разберем используемые приемы и стратегии в хронологически верном для жизненного цикла порядке.
Собеседования спроектированы для унижения
Братство технического терроризма душит техно-гигантов, навязывая бесполезные стратегии отбора. Когда кандидат с релевантным опытом и навыками должен тратить время на «зарешивание» до дыр синтетических (бесполезных) задачек, иначе как унижением это назвать нельзя.
Автор и сам был вынужден решить более 400 задач с Leetcode, чтобы проходить подобные секции. Но проблема в том, что решить любую задачу средней+ сложности за 20-30 минут, комментируя свои шаги, без обратной связи (REPL) возможно только с постоянной практикой или сверхподготовкой (например, опыт олимпиадного программирования).
Leetcode-истерия
Не смог найти исследований о корреляции между умением решать искусственные алгоритмические задачи и задачи на работе. Написание кода под наблюдением в гугл-доке — не то, что разработчики делают каждый день, и никак не отражает, насколько разработчик будет эффективен на реальных задачах.
Единственный способ объяснить наличие алгоритмического лайвкодинга — искать ответы в деятельности всё того же тайного братства анархистов. Leetcode-истерия зародилась в FAANG, крупнейших американских корпорациях. Именно с ними анархисты и ведут войну.
На результаты смотрите сами. Далекие от IT и каких-либо технических навыков персонажи проходили Code Camp и через несколько месяцев устраивались в Google. Внутри на софт-скиллах входили в топ 5% «перформеров», а затем переходили с повышением в Facebook, решая все те же бесполезные задачки на множестве собеседований.
У Техлида была фраза (к сожалению, не смог найти то видео), что он мечтал попасть в Google, чтобы оказаться рядом с лучшими инженерами, а в итоге оказался в команде с кучкой идиотов, которые «заботали» алгоритмические задачи.
Failed my interview with AMD cause I spent 2 years making a renderer only to be asked a leetcode question… — комментарий из видео про чит-программу для прохождения livecoding-interview.
Зарубежные практики унижения кандидатов
Другой вариант подхода к отбору — огромные тестовые задания.
Проходил собеседование в Red Planet Labs, попросили написать конкатенативный (stack based) интерпретатор c предложенным синтаксисом.
Я реализовал. На очном интервью приятно пообщался со CTO, который тоже увлёкся лиспами после статей Пола Грэма. Тогда же решили продолжить процесс.
На этот раз нужно было поддержать больше синтаксиса, включая continuation (как в scheme). На вопрос, сколько времени есть, сказали: сколько угодно.
Я честно прочел книгу на немецком по теме через google translate, вернулся к SICP, реализовал 6 промежуточных интерпретаторов для тренировки и спустя две недели дал конечный результат с подсветкой синтаксиса и статическим анализом при запуске в Intellij IDEA.
Спустя еще две недели получил ответ: извините, уже выбрали другого разработчика. Ни обратной связи, ни предложения написать снова через 3 месяца, ни «напишем, когда откроются вакансии». Делился историей на ТГ-канале, там же в комментариях ссылка на подкаст со CTO этой самой Red Planet Labs.
Как бы выглядели собеседования, если бы не анархисты
Интервьюер бы смотрел не на решение алгоритмической задачи, а на рассуждения. Знаком ли кандидат с понятием асимптотики; знает ли структуры данных языка, на котором пишет решение; смотрит ли на входные данные, прежде чем думать об оптимизациях, и т.п. Может быть, давался бы кусочек кода с просьбой найти ошибки и предложить решения. Может быть, решали бы нестандартные задачи вместе в pair-programming стиле с возможность гуглить и пользоваться LLM.
Корпоративная культура вызывает скепсис
Так уж вышло, что образование у меня экономическое, и за время учебы попадались предметы про основы менеджмента, корпоративную культуру, этический кодекс и т.п. Может быть, на каких-то уровнях оно действительно работает, но у меня всегда вызывало скепсис.
Принципы лидеров
На собеседованиях (behavioral interview) в Амазон — да и в остальной FAANG — нужно готовиться отвечать на вопросы, связанные с Leadership Principles. Обязательно попросят привести пример, когда вы действовали согласно определенному принципу.
Например, «Leaders are owners». Вас спросят: когда вы последний раз были «владельцем» системы, которую разрабатывали? Ответ ниже считается неверным.
Никогда, ведь я не получаю долю от прибыли этого продукта, как настоящий владелец. Мне платят зарплату — в обмен на это я выполняю работу в рабочее время.
С таким ответом вас гарантированно не возьмут, независимо от того, делится ли компания своей прибылью или нет (через опционы, акции, премии с процентом от прибыльности).
Остальные принципы лидеров про то, что каждый в компании должен быть лидером. Нужно «деливерить» задачи в срок и с максимальным качеством, думая о клиенте. Нанимать только лучших из лучших и всё равно быть лучше лучших из лучших.
Не говорите о своих зарплатах
Очевидно, что сотруднику выгодно узнать, сколько получают другие, чтобы получать как минимум не меньше. Работодателю же выгодно держать всех в неведении, чтобы низкооплачиваемые сотрудники не просили больше.
Компании навязали идею о том, что разглашать свою зарплату ни в коем случае нельзя. Даже в частном разговоре. Где-то даже включают в NDA. Но разглашение, как разобрались на хабре, не может иметь юридических последствий, разве что репутационные.
Организация работы. SCRUM
В русскоязычном конклаве заговорщиков скрам принято расшифровывать как
Собрание
Крика
Раздора
Аффекта
Мизантропии.
Когда орден разрушения пришел к пониманию SCRUM, ликованию не было предела. Вместо уничтожения кодовых баз (первая статья про заговор) и пропаганды вредных архитектурных принципов (вторая статья) можно сосредоточиться на самом слабом звене в цепи корпоративной разработки — менеджменте.
Основная претензия к SCRUM — сфокусированность на процессе. Не важно, что за продукт и команда, SCRUM слепо и бездумно предлагает один и тот же процесс.
SCRUM подходит не везде
Команды тестирования, инфраструктуры, поддержки клиентов, кибербезопасности не нуждаются в SCRUM. Всё что нужно для работы — очередь задач с приоритетом, а вот спринты точно не имеют смысла.
R&D-команду SCRUM будет тормозить бесполезными церемониями и ограничениями. Если вы занимаетесь ресёрчем задачи, которую еще никто не делал, то последнее, что вам нужно — это стендапы, ретро, планирование и ограниченные по времени спринты.
Спринты несут больше проблем, чем пользы
Зачем используют спринты? Давайте для начала перечислим плюсы:
Давление к переработкам. Разработчик сам оценил задачу и возможная задержка будет на его совести.
Гибкость. Быстрая обратная связь в сравнении с waterfall, можно в следующий спринт взять другие задачи, если поменялись приоритеты.
Координация команд. К концу спринта будут готовы нужные фичи как раз к началу спринта другой команды, которая от них зависит.
Критика пунктов выше:
Перегорания из-за постоянных переработок не приводят ни к чему хорошему долгосрочно.
Обход процесса. Срочное и важное дадут, минуя спринт. То етсь гибкости SCRUM часто недостаточно для реальной разработки.
Нет гарантий выполнения сроков, особенно когда речь о больших командах или R&D-задачах. Поэтому и координировать не всегда получится.
Автор был не только разработчиком, но и тимлидом небольшой команды. А когда команда небольшая, легко и без спринтов контролировать фокус, понимая, кто чем должен заниматься. Если команда большая — ее придётся разбивать по тому же скраму.
По методологии хорошо успевать выполнять за спринт все задачи. Но где бы я ни работал за последние 10 лет, всегда были проблемы со сроками и часто приходилось перерабатывать. Команды играли в оценки задач в story point (SP), где никто не знает, что такое SP, но все как бы приспосабливаются оценивать в SP (либо просто говорят, что 1SP — это час).
Спустя какое-то время должно сложиться понимание некоего справедливого количества SP, которое команда может сделать за спринт.
Но есть куча «но», из-за которых спринт будет сорван (примеры в скобках):
Неожиданные и непредсказуемые технические проблемы (появился OOM из-за библиотеки, на которую рассчитывали);
Неправильная оценка задачи изначально (невнимательность оценщика);
Сотрудник выбыл (отпуск, заболевание, незапланированный выходной за сдачу крови);
Праздники влияют на рабочее время спринта и статистику SP за спринт;
Невозможность оценить заранее незапланированные срочные задачи (обнаружился memory leak в проде);
Невозможность оценки R&D-задачи.
Какой смысл набирать статистику по среднему количеству SP за спринт? SP всегда неточны, а рабочая сила меняется из спринта в спринт.
Какой смысл в том, чтобы ограничивать спринт временем? Всегда будет либо недобор, либо перебор задач — либо просадка производительности, либо переработки.
Эзотерика скрама
SCRUM не базируется на каких-либо исследованиях или замерах эффективности — исключительно на идеях и вере в то, что это работает. Обзоры статей вроде Scrum: A Systematic Literature Review не являются доказательством эффективности. Обычно SCRUM сопутствует внедрение CI/CD и разбиение на команды поменьше. Как знать, может только это и влияет положительно и перекрывает негативные стороны SCRUM.
Логика многих идей, используемых в SCRUM, мягко говоря, не сильна.
Например, спринты менять нельзя, но заложить время под срочные непредсказуемые задачи надо. Приходится заниматься гаданием, выделяя свободные слоты под задачи в следующем спринте.
Чтобы лучше успевать помещаться в спринты и на глаз давать верные оценки, придуманы приёмы, вроде оценки по Фибоначчи. То есть нельзя оценить задачу в 6 SP: можно в 5 или 8 — по золотому сечению. Оцениваешь в 8 и получаешь требование разбить задачу, потому что 8 — это слишком много.
Даже если задача действительно занимает 8 SP, придется делить на 3 и 5. То есть создавать ненужную работу:
Заводить дополнительную задачу в Jira и идти за кофе в ожидании загрузки страницы;
Делать 2 PR, 2 ветки или помечать один PR думя задачами (тут всё зависит от конкретных правил в команде);
Надо будет объяснить тестировщику, в какой задаче что сделано. Либо не забыть оставить комментарий, что одну из задач не надо тестировать.
И всё это ради принципов. Чем-то напоминает I.D.O.L.S. (подробнее в предыдущей статье). Повторюсь, никакой доказанной эффективности этих принципов нет, есть только вольные рассуждения, вроде того, что числа Фибоначчи запомнить легко (1,2,3,5,8) и не надо думать между промежуточными числами (4,6,7) для оценки. Делает ли это работу эффективнее, никто не знает.
Огромное количество бесполезных встреч
Стендапы являются пустой тратой времени и иллюзией контроля для менеджеров. Очень дорогой иллюзией, ведь теряем полчаса рабочего времени на каждого члена команды.
Зачем проводить стендап, если:
Статус по задачам можно посмотреть в Jira;
Если не скатываться в детали, то всё и так понятно: разработчики писали код, тестеры тестили, менеджеры сидели на встречах.
Если скатываться в детали, то все, кроме двух-трех человек, теряют время.
Если у кого-то есть проблемы, обычно он и так знает, к кому прийти с вопросом, все не нужны.
Планирование и груминг. Казалось бы, хорошо и нужно, но на практике — особенно на онлайн-встречах — люди отвлекаются и только 2-3 человека могут сохранять фокус в единицу времени. Чаще всего заранее понятно, кто будет какую фичу делать, и только он и может действительно оценить ее.
Разбор беклога обычно бесполезен, потому что когда что-то важно, об этом и так вспомнят.
Ретро может быть полезно, но только в одном случае — чтобы на нем решить, что надо отказаться от скрама.
Как бы выглядел процесс работы, если бы не анархисты
Практически все команды могут координироваться канбан-доской без потерь времени на церемонии скрама. Для убежденных скрам-теистов даже придумали scrumban (мне нравится вариант без спринтов).
Другой пример замены SCRUM описал в ТГ.
Давайте вольём уже работающий код
На позициях сеньора, тимлида, техлида, staff-инженера и СТО появляется легкий способ нанесения ущерба корпорации с видимостью зрелого умения размышлять о нуждах бизнеса.
Из заголовка уже понятно, о чем идёт речь, но важно учесть, что прием раскрывается в полной мере, когда у разработчика есть опыт, именно поэтому абзац и начался с высоких технических позиций. Если всегда говорить: «давайте вливать поскорее, пользователи ждут», — быстро потеряешь доверие.
Важно понимать, какие ошибки в коде нанесут наибольшее долгосрочное разрушение. Например, уметь предвидеть неконсистентность, которая возникнет из-за гонки. Как результат, в будущем придется добавлять флаги valid=false в таблицы, чтобы пометить сломанные данные. Это потребует изменения 1к мест, где таблицы уже используются. А еще не забывать про флаг valid в новых запросах.
Такие проблемы нужно уметь распознавать и тратить очки авторитета «с умом», настаивая на влитие PR как можно скорее. Так давайте вольём уже работающий код!
Увольнение вместо заключения
Братство уничтожения корпораций продолжит изобретать инструменты подпольного антимонопольного регулирования, уже сейчас вайб-кодинг внедряется в рабочую среду корпораций.
20-30% кода ... написано софтом. — Microsoft CEO
Догадливый читатель должен был распознать за пером подобных решений известный почерк. Братство хочет сокращений и внедрения ИИ, ведь ИИ можно учить говнокоду быстрее.
Мы плодотворно поработали, но настало время прощаться. Кто-то боролся с техно-анархизмом, а кто-то был на его стороне. Большинство же попало под влияние анархии бессознательно и оказалось инструментом в руках деструктивных кукловодов. Автор не раскрыл, на чьей стороне сам, но оставил подсказки в своём телеграме.
