https://t.me/ruitunion/585

Судя по тому, что написано, один из программистов ЦЗ писал. Если уж решили вынести в СМИ (осуждаю, но понимаю), выбирайте что-нибудь не ЦИПСОное (осуждаю).

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

https://t.me/ProductBalance/431

Настоящие дзен-продуктологи одновременно делают и то, и то

Факторио учат нас, как полезны (нет) комментарии в коде. Сверху табличка «не загораживать», снизу построенный друзьями ровно на отводе под жд форт

Философия разработчика. Перефразированы и раскрыты популярные поговорки.
https://news.ycombinator.com/item?id=42920285

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

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

Но, к сожалению, в не зрелых командах у продуктового лидерства нет понимания, зачем продукту «не падать», у технического лидерства нет умения объяснить и обосновать свои задачи. В таких незрелых командах при едином беклоге все быстро скатывается в «фичи-фичи», а то и в «выполнение проектных обязательств» (а на самом деле просто не проработанных идей заказчика). В этих условиях разные беклоги, и знаменитое ЦИПовское 25% на техдолг это наименьшее из зол. Поэтому так и шли.

Свой канал завел Юра Пирогов, экс-лидер технарей-внедренцев ЦИП.
Начал он с душнейшего поста про разницу между https://t.me/work_and_scream/5 между отказом и сбоем.
Рекомендую.

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

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

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

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

Это и происходит сейчас с Rust for Linux. Торвальдс должен принять решение. Если ДА, то всем ментейнерам рано или поздно придется выучить второй язык. Если НЕТ, то пора начать сворачивать эксперимент.

https://news.ycombinator.com/item?id=42972062

В ту же степь: слышал как-то перл от большого руководителя в ЦИП (к счастью, соседнего подразделения) как то: зачем вы выносите на комитет несогласованное? Принесите мне параметры, полностью согласованные письменно с заказчиком.

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

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

Золотая середина в том, что на руководителя подлежат вынесению вопросы, проработанные, но не решённые. Мы обсудили вопрос, наши аргументы такие, вот предлагаемое решение (повезло). Мы обсудили вопрос, мои аргументы такие, его такие, контрагента такие, вот решения из которых надо выбрать (не повезло, приходится поработать).

Я: пет-проект это классно и здорово, развлекусь в свое удовольствие.

Dependabot: падает.
Yandex Managed k8s: рэндомные таймауты, когда пуллим с Github Container Registry

Все, больше не безработный. Впервые за свою жизнь работаю в бигтехе

https://opensource.microsoft.com/blog/2025/01/23/documentdb-open-source-announcement/

Microsoft зарелизила в опенсорс ЧАСТЬ своей реализации т.н. Azure Cosmos DB for Mongo (не путать с другими Azure Cosmos DB. Несмотря на то, что это все заявляется как API к одной БД, на самом деле это разные БД).

Это плагин к PostgreSQL, который расширяет поддержку BSON и позволяет читать и записывать в документном формате, полностью опенсорсный.

Этот плагин используется закрытой реализацией в Microsoft Azure, а также уже в опенсорсном клоне Монги FerretDB.

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

Вы прослушали байку про эффективность формальных KPI
https://t.me/istrkalkglk/5893

У Яндекса больше 3.5 часов лежит облачное логирование 😞
https://status.yandex.cloud/ru/incidents/1057

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

https://job.ozon.ru/vacancy/117557545

Не могу обещать, что в Озон Тех круто (я собственно не разобрался еще), но в одной из моих команд есть вакансия. Буду рад видеть кого-то из тех, с кем работал.

Реферальной премии в мои команды мне естественно не полагается, но рекомендовать могу, поэтому пишите мне наверное

Требования на загрузку логотипа есть? Есть! Загружается? Загружается.

Требования на то, чтобы он показывался именно загруженный логотип, а не дефолтный? Нет. Что вы от нас хотите?

(Основано на реальных событиях)

https://t.me/hedin_dev_lead/7

Хедин (Антон Жулитов) тоже завел телеграм канал. Вот достаточно банальное, но полностью разделяемое мной мнение про найм.

Сегодня получил письмо о том, что проекту ХХХ надо срочно выдать архитектора от автоматического робота ресурсного планирования.

Ответил примерно следующее. Коллеги, вероятно есть некоторая ошибка в генерации этого письма.

1. Я знаю ситуацию на этом проекте, архитектор там не нужен
2. За выдачу архитекторов этому проекту отвечаю не я, а Максим К
3. Проект давно закрыт
4. Это моя личная почта, а не рабочая
5. Я уволился три месяца назад

https://news.ycombinator.com/item?id=43332830

Компилятор Typescript перепишут на Go.
Вообще это крупнейшее поражение для Typescript в частности и фронтенда вообще. Написать компилятор на самом себе это знак взрослости языка; языки, которые не умеют это делать, не считают полноценными.

Фактически язык расписывается в том, что он недостаточно производителен.
Понятно, JIT компилируемые языки меряют себя по тому, что называется steady-state performance, по разогретому состоянию, а компилятору казалось бы важен быстрый старт (на самом деле нет, перформанс постоянно висящего в памяти language server важнее).

Имеем ли мы дело с давно чаемым многими закатом JS (виртуальной машины)? Ну и славно, хехе.

P.S. В комментариях на hacker news горят фанаты дотнета, что выбрали не C#. Топ 100 аниме предательств, на этот раз совершенное автором языка!

Кстати, вчерашний наброс на фронтенд вызвал, как и ожидалось, срач в комментах.
Если вы хотите поучаствовать, делайте это там, а нет под этим постом!