‣ Почему для перехода в другую компанию нужно тренировать навыки, никак не относящиеся к работе?
‣ Почему вместо работы мы ходим на встречи, а вместо принятия рисков занимаемся гаданием?
‣ Почему нам говорят: «владейте продуктом», но прибылей от продукта не достается?

На все вопросы легко находятся ответы, если перестать притворяться, что братства техно-анархистов не существует.

Статья является последней в цикле «Заговора разработчиков»:

  1. Тактика работы с кодовой базой.

  2. Тактика работы с архитектурой.

  3. Тактика работы с коллективом (эта статья).

На каждом этапе жизненного цикла разработчика — собеседование, знакомство с корпоративной культурой, работа в скраме — подпольная организация анархистов пытается саботировать процесс, и ниже мы разберем используемые приемы и стратегии в хронологически верном для жизненного цикла порядке.

Собеседования спроектированы для унижения

Братство технического терроризма душит техно-гигантов, навязывая бесполезные стратегии отбора. Когда кандидат с релевантным опытом и навыками должен тратить время на «зарешивание» до дыр синтетических (бесполезных) задачек, иначе как унижением это назвать нельзя.

Автор и сам был вынужден решить более 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 будет тормозить бесполезными церемониями и ограничениями. Если вы занимаетесь ресёрчем задачи, которую еще никто не делал, то последнее, что вам нужно — это стендапы, ретро, планирование и ограниченные по времени спринты.

Спринты несут больше проблем, чем пользы

Зачем используют спринты? Давайте для начала перечислим плюсы:

  1. Давление к переработкам. Разработчик сам оценил задачу и возможная задержка будет на его совести.

  2. Гибкость. Быстрая обратная связь в сравнении с waterfall, можно в следующий спринт взять другие задачи, если поменялись приоритеты.

  3. Координация команд. К концу спринта будут готовы нужные фичи как раз к началу спринта другой команды, которая от них зависит.

Критика пунктов выше:

  1. Перегорания из-за постоянных переработок не приводят ни к чему хорошему долгосрочно.

  2. Обход процесса. Срочное и важное дадут, минуя спринт. То етсь гибкости SCRUM часто недостаточно для реальной разработки.

  3. Нет гарантий выполнения сроков, особенно когда речь о больших командах или R&D-задачах. Поэтому и координировать не всегда получится.

Автор был не только разработчиком, но и тимлидом небольшой команды. А когда команда небольшая, легко и без спринтов контролировать фокус, понимая, кто чем должен заниматься. Если команда большая — ее придётся разбивать по тому же скраму.

По методологии хорошо успевать выполнять за спринт все задачи. Но где бы я ни работал за последние 10 лет, всегда были проблемы со сроками и часто приходилось перерабатывать. Команды играли в оценки задач в story point (SP), где никто не знает, что такое SP, но все как бы приспосабливаются оценивать в SP (либо просто говорят, что 1SP — это час).

Спустя какое-то время должно сложиться понимание некоего справедливого количества SP, которое команда может сделать за спринт.

Сорвали спринт, стыдно за burndown, нет времени на ретро. На первом плане — scrum-мастер.
Сорвали спринт, стыдно за burndown, нет времени на ретро. На первом плане — scrum-мастер.

Но есть куча «но», из-за которых спринт будет сорван (примеры в скобках):

  • Неожиданные и непредсказуемые технические проблемы (появился 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

Догадливый читатель должен был распознать за пером подобных решений известный почерк. Братство хочет сокращений и внедрения ИИ, ведь ИИ можно учить говнокоду быстрее.

Мы плодотворно поработали, но настало время прощаться. Кто-то боролся с техно-анархизмом, а кто-то был на его стороне. Большинство же попало под влияние анархии бессознательно и оказалось инструментом в руках деструктивных кукловодов. Автор не раскрыл, на чьей стороне сам, но оставил подсказки в своём телеграме.

Комментарии (18)


  1. Oeaoo
    11.05.2025 15:21

    С нами делают ровно то, с чем мы согласны, даже внешне.


    1. igornem
      11.05.2025 15:21

      А у нас есть выбор?


      1. Oeaoo
        11.05.2025 15:21

        Будто бы нет, но на самом же деле да!


        1. igornem
          11.05.2025 15:21

          Кмк больше выглядит, что да, но на самом деле нет)


  1. ardythe
    11.05.2025 15:21

    Работодателю же выгодно держать всех в неведении, чтобы низкооплачиваемые сотрудники не просили больше.

    Это работает, когда у вас в стране инфляция 2-3%, а разрыв в зарплатах не слишком заметен.

    У нас в стране подобная политика больше похожа на карго-культ и работает в обратную сторону, все думают, что их коллегам платят намного больше, а их недооценивают.


    1. Griggon
      11.05.2025 15:21

      Когда в действительности вообщем-то так и есть. У нас в компании даже запрещено делится своими задачами и зарплатами).

      Работодатели экономят таким образом, создавая сложные системы мотивации - затрудняющие определить настоящую зарплату и меняют подобные мотивации для каждого конкретного работника в силу его незнания ТК или незаинтересованности в борьбе за зп.


  1. nicknamenull
    11.05.2025 15:21

    Невозможность оценки R&D-задачи.

    А мне говорили, что хороший исследователь всегда знает, сколько займёт то или иное исследование, а если не знает, то может сказать, через сколько он это узнает. Это что же, мне врали, получается? /s

    Кроме шуток, я правда с таким сталкивался.


    1. svz
      11.05.2025 15:21

      Как ни странно, RnD задачи тоже можно и нужно оценивать. Не в терминах "я найду решение за 4 дня", а в терминах "мы готовы выделить на исследование 4 дня". Во втором случае по истечении этого времени должны быть зафиксированы промежуточные результаты и принято решение о продолжении или отказе от дальнейшего RnD. В противном случае такое исследование рискует превратиться в бесконечную задачу по итогам которой будет сказано: "не шмогла я".


    1. i360u
      11.05.2025 15:21

      Хороший исследователь знает, сколько, примерно, времени нужно на то, чтобы проверить "есть ли на участке золото". Также, он может, примено, оценить вероятность успеха, чтобы не искать там, где шансов совсем мало. Но он не знает, есть ли оно там фактически, и сколько участков нужно будет проверить, пока не найдется тот, на котором оно есть. Поэтому, если исследователь говорит вам, что найдет золото за 2 недели - это не исследователь, это мошенник.


  1. nvantropov
    11.05.2025 15:21

    Спринты не так уж и плохи, если нет необходимости соблюдать бюрократические формальности с закрытием всех задач в конце и чрезмерным разбиением на подзадачи. Они структурируют процесс планирования в проектных командах: вместо абстрактной задачи "распланировать реализацию такой-то информационной системы", можно верхнеуровнево распределить задачи по выведению различного функционала и детально расписать только ближайшие поставки. Короче – это удобный фреймворк для планирования методом набегающей волны.

    А без самого планирования в проектной разработке никак – PM должен выбить бюджет на заранее определенный срок.


    1. arturdumchev Автор
      11.05.2025 15:21

      Они (спринты) структурируют процесс планирования ... детально расписать только ближайшие поставки.

      А без самого планирования в проектной разработке никак

      А не получится это решить канбан-доской, когда задачи нужно брать по приоритету? Менеджер может планировать и детально расписать только самые приоритетные задачи.


      1. nvantropov
        11.05.2025 15:21

        На мой взгляд, в планировании должен участвовать разработчик, чтобы не получилась ситуация, когда сроки спускают сверху, а команда должна перерабатывать, чтобы в них уложиться. Менеджер не может знать все тонкости разработки. Много раз встречал такую ситуацию: руководство считает, что "надо всего одну проверку поменять", а на самом деле это требует создания совершенно нового функционала. В итоге для внедрения изменения надо все сроки сдвинуть каскадом или заставить команду работать сверхурочно. По моему опыту выбирают второе.

        Но разработчика лучше на планирование слишком часто не отвлекать, так что делать его стоит по заранее оговоренному расписанию. А в качестве такого расписания как раз подходят спринты.

        Канбан-доска – хорошее решение, но немного для других целей. Она хороша для синхронизации людей внутри команды и распределения задач. А планирование, как мне кажется, должно синхронизировать команду и менеджмент.


        1. arturdumchev Автор
          11.05.2025 15:21

          Мне в планированиях, грумингах и спринтах не нравится, что сидят человек 10-15, а слушают и вовлекаются в моменте обычно не больше 2-3 человек. Но в целом везде свои плюсы и минусы. Я пока в сторону скрамбан склоняюсь.


  1. mxelgin
    11.05.2025 15:21

    Сотрудники амазон, лучшие из лучших
    Сотрудники амазон, лучшие из лучших


  1. andrikeev
    11.05.2025 15:21

    Хочется высказаться в защиту спринтов. Люди подсознательно не любят бесконечные процессы. Нам всегда нужны какие-то точки отсчёта. Поэтому существуют месяцы, кварталы и Новый Год — чтобы прерываться и начинать "с нуля".


    1. arturdumchev Автор
      11.05.2025 15:21

      Как вариант, можно было бы работать над релизом, а после делать “отдых“, готовя доклады для команды, занимаясь рефакторингом и техдолгом какое-то время — 20% времени от того, сколько занял релиз, например.


  1. SolidSnack
    11.05.2025 15:21

    Не знаю на счёт культа, меня тоже, как видимо многих, вводит в ступор собеседования и вообще отбор в компании. Но мне кажется тут все прозаичнее, бизнес боится нового из-за убытков, вот и шлепают как у всех, от собеседований до рабочего процесса.


  1. mrozov
    11.05.2025 15:21

    Вообще-то, Канбан это куда больше и сложнее, чем просто "берём приоритетные задачи с доски", это нулевой уровень зрелости, так сказать. По сути, он и есть "скрам без спринтов", с соответствующими ритуалами даже.

    Просто планирование работ осуществляется для отдельной стори, а не по принципу "нужно полностью набить спринт", а периодичность глобальных ритуалов, типа ретро, выбирается исходя из разумности и необходимости, а не искусственно прибивается гвоздями к спринту.

    Впрочем, скрам тоже в последние годы стал более разумным, впитав некоторые идеи Канбана (цель спринта, к примеру).