Иногда натыкаюсь на руководителей (технических и не очень), которые дают охуенные, блять, советы. Убогие как по форме, так и по содержанию. Как-то по итогам инцидента:
- я бы получше продумал архитектуру, уточнил бы всё что надо, и уделил бы внимание безопасности
- можно провести анализ узких мест и провести тестирование, чтобы обнаружить баг
- может быть стоит прогнать тесты, это могут быть разные проблемы, и возможно в процессе анализа станет понятнее

Почему меня бомбит? Потому что эти советы пустые. Экспертиза Тони Роббинса, делайте хорошо, не делайте плохо.
Утекли данные — значит надо уделить внимание безопасности. Большое потребление ресурсов — надо искать, куда они уходят. Для нахождения бага действительно нужно его локализовать.
Берёшь на себя ответственность — говори конкретно когда и что ты сделаешь.
Помогаешь своими знаниями — сужай поле поисков, уменьшай объём предстоящей коллегам работы.
Не готов вникать, не разбирался в проблематике — молчи, сука, в тряпочку! Тебе не платят за количество произнесённых слов.

Принимай решения. Бери ответственность.

Если даже руководители не могут дать конкретные и полезные советы, то как мне верить в то, что я работаю в команде профессионалов?

KnowledgeConf — про управление знаниями

Следующая конференция будет этой осенью, 30 ноября и 1 декабря, на одной площадке с TeamLead Conf и TechLead Conf. На мой взгляд — бомбическое сочетание технологий, процессов и людей!

Уже открыт приём заявок на доклады: https://cfp.knowledgeconf.ru/ — на странице всё подробно прописано и про условия, и про аудиторию, и про темы.
А для тех, кто не знает о чём конкретно рассказать / не уверен буквально через час (в 17:00 Мск) будет встреча с ПК. Записаться и получить ссылку можно тут: https://conf.ontico.ru/event/join/open_kc2023.html

Корпоративный поиск на коленке

Люблю тему поиска, особенно в контексте управления знаниями. Посвятил ей пару-тройку лет.
А вот и опубликовали мой рассказ о том, как на коленке построить свой корпоративный поиск и как это сделать с минимумом возможной боли:
https://www.youtube.com/watch?v=q9TMFdRFK2Q

С развитием LLM и ChatGPT, с одной стороны, ситуация изменилась, а с другой — если нам важна точность в ответах — не особо 🙂 Так что интересующимся концептуальной стороной вопроса построения поиска, думаю, будет интересно. Старался отразить основы, которые вряд ли будут меняться.

Видео писалось во время болезни, прошу понять и простить заминки и прокашливания.

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

Наболело.

🤬 МЫ НЕ РЕЛИЗИМСЯ В ПЯТНИЦУ!!!!

Правило не релизиться в пятницу — это суеверие.

Я убеждён, у сломанных релизов есть объективные причины: плохое тестирование, неучёт рисков, отсутствие плана отката, отсутствие мониторинга, отсутствие нужных людей поблизости, чудовищный техдолг, сбой во внешнем софте или оборудовании.
Мне оппонируют — “Игорь, ты о каких-то космических штуках пишешь, у нас люди говнокод пишут и задачи не успевают закрывать, нам некогда!”. Поэтому, мол, будем писать как можем, а в пятницу релизить — нельзя.

Тем не менее:
Если релизы систематически ломаются и люди закрывают проблемы переработками, то “не релизиться в пятницу” — это не решение, это манипуляция-суеверие, чтобы защититься от бесконтрольных овертаймов.

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

Есть ситуации, в которых релизы в пятницу сомнительны, но они не связаны со страхом потерять выходные, например:
- в пятницу/выходные сложно достучаться до людей, необходимых для решения инцидентов (админы на подряде не работают по выходным; менеджер в выходные на рыбалке и плевал на всё)
- в пятницу/выходные — повышенный трафик и авария принесёт огромные потери (у многих бизнесов есть сезонность: праздники, новый год, 1 сентября, 8 марта и т.п.)

Если же изменение не протестировано, не готово, плана отката нет, но мы всё равно катим его на прод, потому что “надо” — будет больно что в выходные, что в будни, и дело в болевом пороге, а не в замедляющем развитие суеверии.

👀 невербалики пост

Поговорим об информации, получаемой не через слова, но через невербальные сигналы. От 60 до 70 процентов информации мы получаем через зрение: мимика, жесты, позы, движения глаз, интонации голоса, ассоциации и тональность голоса. Всё это влияет на понимание собеседника.

Однако, мозг не всегда умеет анализировать все эти сигналы и связывать их со смыслом слов, произносимых собеседником. Иногда нас могут клинить какие-то незначительные детали, например, тональность голоса или интонация. Всё это влияет на наше восприятие и оценку происходящего.
И поскольку это — интерпретации, они могут быть искажены нашими предрассудками, настроением или даже здоровьем.

Поэтому для себя я выработал два правила:
1. не было сказано — значит не было
2. чувствуете, что что-то не так — лучше взять небольшой перерыв, сформулировать невербальные сигналы словами и спросить у собеседника, правильно ли вы понимаете его реакцию или поведение.

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

Модерация сообществ

https://vas3k.blog/notes/moderation/
vas3k сделал отличный лонгрид про подводные камни модерации сообществ и влияния оной модерации на жизнь онлайн-коммьюнити. Многое говорит о проблемах формулировки командных правил вообще.
Особенно рекомендовано читать людям от мира управления знаниями, мечтающим сделать платформу, и чтобы оно дальше как-то само происходило и люди сами делились знаниями.

Почему не пишется лог?

Подумайте над этим пару минут, какие могут быть варианты. Ну или напишите в комментарии — порассуждаем вместе!
А потом посмотрите увлекательный ответ под спойлером ниже ⬇️

Потому что стектрейс настолько большой, что либа логгирования падает.

Давным-давно работал я в компании, занимавшейся заказной разработкой. Будем откровенны, для заказной разработки один из важных моментов — разделение ответственности и быстрое решение конфликтов. Потому что никому не хочется разбираться с множеством исправлений за свой счёт. Плюсом к этому в компании не хватало внутренних коммуникаций: договорённости фиксировались плохо, а словам верить было не принято.
И созрел план — наладить коммуникацию через написание архитектурной документации, фиксировать в ней договорённости, возникающие между разными ветвями разработки и менеджментом. Разработали шаблоны, чтобы было проще фиксировать мысли. Обучили разработчиков новому и встроили практики в рабочий процесс. На мой сегодняшний вкус — возможно чрезмерно жёстко, по принципу "нет архитектурного описания — нет задачи", но это работало.

Ну… Как работало… )

Первые полгода-год меня поносили всеми немыслимыми словами и менеджеры, и разработчики. Добавил работы на пустом месте.
А потом люди начали понимать плюсы, особенно когда проект зарелизили и полезли баги в production. Когда благодаря зафиксированным знаниям разработчикам удавалось быстро влезать в незнакомые сервисы, а менеджеры сами могли диагностировать проблемы с помощью Postman и хорошего описания API.


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

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

Счастливой отладки :)

Давайте будем документировать архитектурные решения!

Хороший лозунг, понятно из какой боли он произрастает. Сложно онбордить, сложно поддерживать, сложно дорабатывать, сложно рефакторить. Хочется общую картинку.

Я часто видел, как в результате команды приходили к идее сделать какой-то вид ADR (Architecture Decision Record) — фиксировать каждое архитектурное решение в виде этакой блогозаметки.
На мой взгляд это хорошее решение и это ужасное решение.

Хорошее — потому что это лучше чем ничего, и даже внедрение подобного подхода требует мощного волевого усилия. Вот, кстати хорошая статья с самым простым шаблоном: https://infraeng.dev/decision-log/

Плохое — потому что начиная записей с 30 разобраться в этом становится невозможно. Мне кажется, что тут лучше подход wiki: выделить абстрактные сущности (например, такие: https://youtu.be/NGiN3df_YGc?t=571) и с каждым решением — обновлять описания каждой из сущностей, затрагиваемых изменением (методы API, компоненты, фунциональные/не функциональные требования, бизнес-возможности пользователей и т.п.) и аккуратно пролинковывать зависимости.
Это сложнее, требует сурового онбординга для новичков, но гораздо прозрачнее в использовании. Причём изучение можно начать с того места, которое тебя волнует здесь и сейчас — меняя сущность ты от неё можешь размотать все взаимосвязи.

😌 Управление ожиданиями, кейс №1

У тебя есть две задачи А (30 часов) от Васи и Б (10 часов) от Екатерины на ближайший недельный спринт. К тебе приходит менеджер Виссарион и просит сделать задачу Д (20 часов). При этом ты точно знаешь, что Д — супер-срочная. Что будешь делать с задачами?

Условно считаем, что у нас реально есть 40 часов в неделю, встречи-оффтопики для простоты как бы включены в оценку времени.
Вы сами решаете кем быть — формалистом, карьеристом или полезным человеком, насколько зрелая ваша компания и т.п. Ответ формулируем с позиции исполнителя, а не руководителя команды.

Мой ответ с объяснением позиции — через несколько дней.

Счастье — есть, скоро в obsidian

Obsidian 1.4 будет позволять оперировать frontmatter-полями через удобный формо-подобный интерфейс.

Frontmatter — это такая шапка в виде yaml-а, которую можно (согласно спецификации) вставлять в любой markdown файл наверху. Долгое время obsidian позволял работать с этой шапкой сугубо как с текстом, что начисто отсекало неопытных пользователей не умеющих в эти ваши ямлы, и в целом было мерзко.
Особенно мерзко было работать с выбором из списка, датами и тому подобным.
Ситуация меняется и в версии 1.4 завозят удобные интерфейсы из коробки.

Вот видос: https://www.youtube.com/watch?v=RrxqkIhh9L8&t=108s

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

Игнорировать задачу Д, мол, спринт утверждён — путь отдельных самураев, внедривших бескомпромиссный скрам. Встречал такие команды, но ИМХО, так далеко не уедешь. У команды должно быть capacity на срочные задачи: либо через возможность менять скоуп задач, либо через "дежурного по срочным задачам".

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

Кто должен разруливать ситуацию с изменившимися договорённостями — исполнитель или менеджер?
А фиг его знает 🙂 Я видел самые разные конфигурации: "мой непосредственный руководитель", "рандомный менеджер проекта", "исполнитель сам" и даже "жира автоматически".
Мне больше нравится вариант, где исполнитель сам занимается оповещением. Это защищает нас от менеджеров-врунишек-"я-согласовал-давай-делай" (а на самом деле — ничерта не согласовал), и в целом способствует карьерному росту самого исполнителя. Это хороший выбор для адекватных команд, где всё нормально с доверием исполнителям.

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

Трудно решить инцидент тогда, когда инцидента нет

Один из топовых способов въебать кучу времени в расследование инцидента, поднять кучу людей, несколько раз прийти в тупик и бессистемно потыкаться в поисках проблем — забыть сформулировать в чём проблема.

Когда я говорю “в чём проблема”, я не имею ввиду такие вещи, как:
- рост потребления памяти
- троттлинг цпу
- потери пакетов
- высокий уровнь ошибок
Это — симптомы, наблюдения, факты. Они помогают нам подтвердить, опровергнуть или придумать гипотезы о происходящем. Но они не являются проблемой сами по себе.

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

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

Условный высокий уровень 502-ых может продолжаться столько угодно, если он не мешает пользователя делать заказы (потому что есть retry или fallback-механизм).

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

😌 Управление ожиданиями, кейс №2

Ты начал работать по задачам в спринте. И пять задач требуют работы других подразделений и пока те не закончат — тебе делать нечего. У тебя есть сомнения, что коллеги успеют в этом спринте вовремя закончить свою часть. Что будешь делать?

Вы сами решаете кем быть — формалистом, карьеристом или полезным человеком, насколько зрелая ваша компания и т.п. Ответ формулируем с позиции исполнителя, а не руководителя команды.

Мой ответ с объяснением позиции — через несколько дней.

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

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

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


Тем не менее, мне кажется, что вообще не напрягаться — это не путь самурая. Конечно, планирование — забота менеджмента, но только работая вместе можно прийти к чему-то лучшему.

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

Договориться о том, чтобы вас держали в курсе — это прекрасно и нужно, но когда сроки будут сорваны пенять на то, что вас не предупредили, будет бессмысленно. Так же как и варианте, где вы обозначаете кому-то (исполнителям или руководителям) сроки, приоритеты и грозно стучите тапком по столу.

Пожалуй, лучшее что можно сделать — вспомнить арифметику. Взять оценку сроков с задач, от которых вы зависите, прибавить своё время, докинуть погрешность рисков. Полученные числа транслировать тому, кто поставил задачи вам. Это, конечно, прогноз погоды, который обладает суровой погрешностью, но единственное что понимают люди — это язык цифр. Только имея конкретику, в числах (а не абстрактные разговоры о беспокойстве), можно сдвинуть глыбу планирования в сторону конструктивного разговора и рефлексии.