Кода кода

Радио «Виктор»: Почему компании тупят?
Чем больше компания или даже конкретная команда, тем больше возникает регламентов и «глупых» правил. А в инженерной части все больше «квадратно-гнездового» и меньше ситуативно-эффективного.

Инженеру непонятно, почему ему запрещают использовать тригеры в СУБД, если это решает его задачу. Почему линтер блокирует пайплайн с устаревшей библиотекой, хотя новая версия ничем не лучше. Почему требуют использовать Kafka только как Pub/Sub, и не использовать как распределенный лог или буффер, хотя Kafka «вообще-то для этого и создавалась». Такие вопросы я слышу почти каждый день, и они всегда заставляют меня задуматься: действительно ли предлагаемое решение более эффективно? Не всегда. Но бывает, что это действительно так. А прав ли инженер, утверждая, что эффективность в конкретном кейсе оправдывает исключение? В большинстве случаев — нет.

Пример из управленческой плоскости: человек с зарплатой X увольняется из-за денег, а на его место после долгих поисков берут человека с зарплатой (X+20%) и меньшей квалификацией. Причины могут быть разными, но обычно они в плоскости того, что правила не позволяют повысить зарплату в этот период, для этого сотрудника, в этой стране (если компания международная) и так далее. Такие ситуации часто возникают, и на первый взгляд они кажутся нелогичными. Однако эти «неэффективности» тоже имеют своё объяснение.

В обеих ситуациях, мы действуем не эффективно. Но почему?
А все из-за того, что почти невозможно управлять крупной командой, регулировать крупную систему ситуационно. От случая к случаю. Вместо этого, есть два пути: дробить систему на более мелкие или придумывать общие правила, которые работают хорошо в большинстве случаев, но часто оказываются неэффективными в исключительных ситуациях. Каждое исключение из правил — это всегда риск. А риски на бесконечном горизонте «стреляют» всегда.

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

Но без исключений нельзя
Хотим мы того или нет, но совсем без исключений тоже не получается. Иногда неэффективность становится настолько чудовищной, что важно сделать иначе, не смотря на риски. А еще есть легаси системы, есть внедренные «сбоку», есть переданные из других команд. И каждое из таких исключений висит, как Дамоклов меч. Или, если хотите, как Чеховское ружье.

Вот и получается, что есть три стула:
1. Дробить систему и изобретать велосипед в каждой части — это приведёт к потерям времени и ресурсов.
2. Загонять всех в рамки и заставлять всех работать по одному сценарию — это создаст внутренние конфликты и снизит гибкость.
3. Делать исключения и страдать от их последствий. Вас ждет неочевидное поведение и аварии.

Любая крупная компания выбирает сразу все три. Но разные компании, в разных пропорциях.

Радио «Виктор»: Не думай за других людей

Эволюция научила Homo sapiens эмпатии. Мы стараемся понять чувства других, даже когда только готовимся к разговору. Дети копируют эмоции родителей, а затем учатся сопереживать. Эмпатия — это ключевой навык для жизни в обществе. Но она же — встроенный «бэкдор» для манипуляций.

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

Мы начинаем предсказывать не только эмоции, но и мысли, а затем — решения других людей. Чем ближе мы знаем человека, тем чаще предположения верны. Но даже если вероятность точности 99%, каждая дополнительная ступень умозаключений снижает её. Это как в шахматах: хороший игрок видит 2–3 хода вперёд, гроссмейстер — 5–7, но никто не просчитывает всю партию.

Почему это важно в инженерной среде?
Инженеры часто опираются не на эмоции, а на опыт: что раньше подводило, что чаще ломалось, что приходилось срочно чинить. Однако у разных инженеров опыт сильно различается, что делает их подходы менее предсказуемыми.

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

Истории из практики
Недавно коллега попросил решить проблему. Он обратился к дежурному из нашей команды с задачей. Тот задал уточняющий вопрос. В голове коллеги уже построилась длинная цепочка: «он ответил, ему отказали, он пошёл доказывать…». Но вопрос был чисто прикладным и необходим для выполнения задачи.

Другой случай — инструмент для тестирования функциональности с использованием топиков кафки. Мы не учли, что за запись и чтение могут отвечать разные команды, и синхронизация между ними не всегда возможна. Пока мы поняли это, успели выслушать много критики. Коллеги обвиняли команду во всхе смертных грехах — и что пытаемся запретить кафку, что делаем все сложнее, что не даем использовать проверенный инструмент as-is. Требовали срочно запретить использовать этот инструмент. В итоге, были добавлены новые режимы работы и все стали счастливы.

Или история с интеграционными тестами. Коллеги неожиданно попросили срочно перейти на моки вместо тестов с их «ручками». Это вызвало конфликт и непонимание. Спор шел несколько дней вокруг того, как правильно строить тестирование. А причина оказалась простой: их система тратила огромные ресурсы на поддержание идемпотентности, которая была нужна только для этого кейса. В итоге, был найден способ, как не аффектить ее.

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

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

Радио «Виктор»: Конфликт интересов

Бо́льшую часть своей жизни я думал, что конфликт интересов — это всегда связано с мошенничеством или грязными схемами. Или, по крайней мере, с сложным моральным выбором. Например, как тимлид, я хочу удержать сотрудника, а как друг — посоветовать ему двигаться дальше. Такие дилеммы я всегда решал одним способом: увеличением горизонта планирования. На длинной дистанции «морально правильное» почти всегда оказывается выгодным для всех сторон.

Например, если сотрудник «вырос» из своей позиции в команде, то всем лучше помочь ему найти место, где он сможет развиваться. Это полезно для него, для команды и для компании.

Но этот подход не всегда работает. Особенно когда на выбор влияет нерациональный актор. Это может быть не человек, а, например, формальные правила компании. Допустим, компании и тимлиду выгодно взяться за задачу прямо сейчас. Но скрам-процессы компании, моя лень или нежелание «прогибаться» заставляют отложить задачу на следующий спринт. Это тоже конфликт интересов. И здесь увеличение горизонта планирования не помогает: компаниям важно соблюдать процессы, но иногда команде выгоднее действовать быстрее.

Со временем количество ролей, которые я исполняю, увеличилось. И конфликты интересов начали возникать чаще. Я понял, что скрывать их, как делают многие, — это создает дополнительную когнитивную нагрузку, ведь любая попытка что-то скрыть или недосказать забирает силы. Я решил заявлять о таких конфликтах открыто. Да, это может быть неприятно прямо сейчас. Но зато я чувствую себя честным человеком и больше не трачу энергию на внутренние противоречия.

Я не считаю, что «вторая работа» или сайд-проекты — это плохо. Напротив, это ценный опыт. Но они неизбежно вызывают конфликты интересов. Поэтому я считаю важным говорить о них открыто. Лучший способ — обсудить это лично, в доверительной атмосфере. Если же у вас нет доверия к своей компании или руководителю, то стоит ли тратить на них свои силы и время? Мой выбор — работать с теми, кому я доверяю, и заявлять о конфликте интересов.

Три года я вел подкаст «ТехноЛогично» от Газпромбанка. Это была важная часть моей жизни. В отличие от моего подкаста «Кода кода», я сразу получал обратную связь от независимых людей. Эта обратная связь, в том числе, выражалась в том, что мне продолжали платить как приглашенному ведущему. Я чувствовал поддержку и одобрение, а еще мне нравились гости и темы.

Но со временем я начал ощущать внутренний конфликт. Вы знаете, я работаю в Озоне, открыто и много про это говорю. И хотя формально ничего не нарушал, мне было некомфортно. Я заявлял об этом конфликте интересов и раньше, но перед новым сезоном вопрос встал ребром: я был готов продолжать, только явно обозначая, кто я и чем занимаюсь. Одна из компаний была готова дать мне такую возможность, вторая — нет. Больше я этот подкаст вести не буду. Это ударило по кошельку и самолюбию, но я чувствую, что поступил правильно.

Больно, но свою позицию я не поменял. Буду рад, если вы в комментариях поделитесь своей.

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

Во-первых, потому, что такие доклады шире — далеко не каждому придется переводить проект с webpack на vite или писать собственный s3-сервер. Зато каждый из нас сталкивался с необходимостью договариваться с теми, с кем не хочется договариваться; выстраивать собственную карьеру; разбираться что не так с идеей work-life balance. Во-вторых, потому, что эти навыки более долговечны. Технологии приходят и уходят, необходимость общаться с коллегами остается всегда.

Мой хороший друг, Андрей Смирнов, автор подкаста Frontend Weekend собрал клевых ребят, большинство из которых я знаю лично. И в эту субботу, 23 ноября, проведут конфу исключительно про софты: Soft Weekend. Обещали без рекламных стендов от компаний и агрессивного тыканья HR-брендами в лицо. Зато с 14ю полезными докладами и всякими нетворк-активностями.

Стоимость билета - 7к рублей за одного и 12к за двоих. На такую движуху вполне можно взять супруга/супругу и устроить семейный уикэнд. Для вас промокодик KODAKODA — скидка 10%. Купить можно здесь