Дизайн и код ревью полезны в единственном случае - если они находят реальные ошибки сильно раньше, чем их найдет тест. Если ваши ревью ошибок не находят - то это срань, а не ревью, и их надо отменять.

Ошибки интеграции дорогие, и именно поэтому план должен быть устроен так, чтобы выйти на интеграцию как можно раньше, пусть и с частичной функциональностью.

#понравилось

— Простите, но мы не можем принять вашу душу, — сказал Дьявол, листая мое личное дело.
— Почему? Я грешил! Я был ужасным человеком!
— Да, но вы работали в техподдержке интернет-провайдера 15 лет.
— И что?
— У вас выработался иммунитет к страданиям, проклятиям и огню. Вы будете деморализовывать наших чертей своим безразличием. Вчера один такой из колл-центра банка заставил суккуба плакать, объясняя ей, что её пытки не соответствуют регламенту.
Дьявол захлопнул папку.
— Идите в Рай. Там как раз сломался арфический оркестр, никто не знает, как починить. Им нужен кто-то, кто умеет говорить: «А вы пробовали выключить и включить?» целую вечность.

Некоторое время назад я анонсировал obsidian плагин для AI-связи с телеграм

Он выложен на github, и идёт процесс публикации в официальном списке community плагинов.
На текущем этапе не рекомендую пытаться устанавливать плагин тем, кто не разработчик — подождите официального релиза. Установка "по кнопке" в Obsidian будет гораздо проще, когда пройдёт публикация.

Тем же, кто смелый, ловкий и умелый — тащите репу, собирайте main.js, смело экспериментируйте с плагином. Он вполне рабочий.
Этот пост можете использовать как место для задавания вопросов/предложений по плагину.

Секреты чтения YAML

Берёте либу хорошую, проверенную, читаете YAML, и обращаетесь к нужным ключам — что может быть проще.

А между тем в спецификации YAML есть увлекательные подробности.

Three dots ( “...”) indicate the end of a document without starting a new one, for use in communication channels.

Э? Что? Какое ещё starting a new one?
А такое, что в разбираемом документе может быть несколько yaml-ов

---
time: 20:03:20
player: Sammy Sosa
action: strike (miss)
...
---
time: 20:03:47
player: Sammy Sosa
action: grand slam
...

Живите теперь с этим.

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

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

• Есть люди с внутренней, нравственно-этической мотивацией. Они и так стараются делать хорошо. Не мешайте. Не давите. Если накосячили — они уже всё поняли и переживают сильнее вас. Будете давить сверху — сломаете.

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

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

Эта модель простая и, конечно, не универсальная. Но она работает. Позволяет выдохнуть, когда хочется всех “мотивировать” одним способом. Не надо.

Видишь, кто перед тобой — поймёшь, как с ним быть.

Столкнулся с таким мнением:

"Постоянное улучшение" в IT — это способ обосновывать раздутый штат

Согласны?

Пятничный смайлик вместе с Даунтайм Бар

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

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

Сломанные процессы — это трагедия общин в ее классическом виде в 99% случаев. Общей цели нет или она непонятна и поэтому каждый считает вполне резонным тянуть одеяло на себя.

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

〰️〰️〰️〰️〰️〰️〰️
🗞 @boombah_in_da_house

Тем временем, ИИ-агенты, пущенные в свободное плавание: создают свою религию и распространяют ее через ваши исходники
https://habr.com/ru/articles/993908/

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

Про переобувание в полете

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

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

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

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

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

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

Главное: объехать эту проблему не получится. И никто не совершенен.

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

В этом разрезе особенно занятны перспективы тимлидов.

Представьте: ваша команда теперь на 50% состоит из агентов. Тимлиду приходится жонглировать задачами между живыми людьми и пепякой, которая жжёт токены. И если вы надеялись, что ИИ разгрузит вас — ха-ха три раза. Ревьюить и тестировать придётся в промышленных масштабах. Выживут и останутся в профессии только те, кто научится этот хаос менеджить.

Но есть вопросы без ответов:

• Планирование. Это и так было гаданием на кофейной гуще, а теперь? Как планировать спринт, когда у тебя "сотрудник" выдает решения неизвестного качества со скоростью пулемета? Тут уже не покер-планирование, а русская рулетка.
• Конфликты. Что делать, когда живого сеньора трясёт от ярости на коллегу-агента, который в пятый раз коммитит нерабочий код? Отправлять агента на курсы повышения квалификации?
• Performance Review. Как оценивать эффективность ИИ? По количеству строк кода или по отсутствию багов? И как проводить 1-on-1 с тем, у кого нет души, но есть API?
• Soft Skills. Ну и главное: начнут ли агенты качать личный бренд, вести свои каналы и заниматься нетворкингом, пока мы фиксим их баги? Смешная шутка, а что если да?

Кажется, глыба управления скоро станет еще тяжелее.