Quant Valerian

https://telegra.ph/FAQ-chto-takoe-superyachejka-08-15 FAQ: что такое суперячейка? То чувство, когда сел отвечать на вопрос подписчика в комментарии и случайно написал самый подробный материал о суперячейках на русском языке. Признаться честно, за эти две недели работы над статьей я сам намного лучше стал понимать внутренние механизмы суперячейковых гроз (какие они все-таки удивительные!). Надеюсь, что для вас этот материал будет полезным! В будущем этот FAQ можно будет дополнять, к примеру более подробно написать о мультиячейковых грозах и линиях шквалов в частности (одно bow echo чего стоит) или добавить больше информации о торнадо. Если вам понравился этот материал и вы хотели бы поддержать автора, то можете сделать это по ссылке: ko-fi.com/nenevreme

Очень интересная статья про грозы с картинками и фотографиями. Люблю такое

Ооооо! 500! Нас пятьсот! Это целых пять сотен или пятьдесят десятков! Невероятно! Я вообще зашёл токсичный пост написать, но теперь обрадовался и не буду ❤️

У Брукса есть повторяющийся тезис о том, что всегда нужен один человек, принимающий решения. Иначе будет долго. Один архитектор, один главный программист и т.д. И, чёрт возьми, это так. Однако, как водится, абсолют не работает и тут. Если решение не продать команде, это влияет на мораль, скорость и качество решения. Вплоть до саботажа. И здесь снова нужно ловить баланс между выйгрышем времени от скорости принятия решения и проигрышем в скорости из-за падающей производительности исполнителей. Я бы сказал, что нужно стараться продать каждое решение, искать кворум (а лучше консенсус), но так вы рискуете погрязнуть в обсуждениях типа в какое время команда ходит на обед по четвергам. В таком случае вы не сделаете не то, что поздно, вы никогда ничего не сделаете. Ищите баланс.

Я ПРОШЁЛ ТИМЛИДА 🤡🤡🤡 по метрикам У нас в компании замутили пилот оценки руководителей их сотрудниками по восьми показателям. Вот тут наша HR директор Даша рассказывала. Свойства красивые и задумка классная: типа команда анонимно закидывает лиду за воротник, а тот понимает, куда ему расти, какие навыки развивать. На оценку это не влияет (в этот раз по крайней мере), поэтому не должно быть эффекта "похвалю начальника, он добрее будет". По идее. Наверное. Не знаю. Может и есть. На самом деле есть. Мои ребята там наотвечали так, что я всесторонне развит на максималки. Как в анекдоте с Физтеха. Почему ты лежишь и нихрена не делаешь? МЫ НА ПЕРЕДНЕМ КРАЕ НАУКИ, ДАЛЬШЕ НИЧЕГО НЕТ. Короче, приходите ко мне в команду программировать процессинг на golang'е. Метрики говорят, что я идеальный руководитель. https://yandex.ru/jobs/vacancies/разработчик-процессинга-платежей-golang-15169

Сербская культура проникает в меня, видимо, поэтому я почти перестал пить чай. Кофе-кофе-кофе, целыми днями кофе. Нагружу вам и сюда чего-то с кофейным вайбом. Автоматизации двигания задачек туды-сюды. У нас не джира, а Трекер, поэтому готовых рецептов не будет, но вот идеи могут быть полезны. Какую проблему решаем? Разработчики хотят программирование программировать, а не тикеты между колонками двигать. Менеджеры хотят видеть актуальные статусы проектов. Лид хочет мониторить проблемные места в процессах (например, долгое код-ревью или залеживающиеся решения, не уезжающие в прод после мёржа). Типовые решения - Синхронные дейлики (в лучшем случае виклики), где вся команда сидит и смотрит, как менеджер под диктовку двигает карточки в правильные статусы. - Карательные меры. Лид наказывает разработчиков за неактуальные статусы. Например, запрещает неделю смотреть мультики или не поручает важные задачи. - Асинхронная ежедневная многократная долбежка в личку, где мы выясняем "ну чо там с задачей?". - Продать всем ценность двигания тикетов, завести будильники на реактуализацию статусов, поощрять за щепитильность. Всё фигня, по-моему. Лучше заставить машину двигать тикеты за людей. 1. Идентифицируем проблемные места Обычно, если человек что-то поделал в тикете, то он не забывает нажать кнопку "я закончил". Поэтому статусы вроде "закончил писать тех дизайн" или "закончил ревьюить дизайн" можно не автоматизировать. А вот закончил писать код, закончил ревьюить код, выложил в тестинг, выложил в прод -- тут, зачастую, нужно сделать ментальное усилие, чтобы вспомнить про тикет. 2. Переносим действие в ту систему, где человек совершает действие В нашем случае, система контроля версий, код-ревью, ci/cd -- всё в одном месте, в Аркануме. Настраиваем его так, что на создание пулл-реквеста тикет двигается в статус "пора смотреть", а при мёрже в статус "смёржено". Для гита есть гит-хуки, которые могут точно так же дергать таск-трекер за веб ручки (наверное). Собственно, события сборки и деплоя тоже в идеале должны двигать статусы тикетов. 3. Если не переносится Тогда есть такой способ последней мили: пинать исполнителя, если тикет дольше нормы в каком-то статусе. У нас это просто джоба, которая раз в час ходит собирает подходящие тикеты и раз в n дней пинает в них исполнителя в комментариях с призывом Ещё есть проблема с тем, что нужно заполнять какие-то там поля в этих ваших тикетах! Тут тоже спасают напоминалки (проставь исполнителя или оценку), автоматические значения (текущий спринт или дашборда с задачами в работе), калькуляторы полей (у нас CD3 считается автоматом при изменении оценок). Отдельная форма боли нормального человека -- создавать задачи. Меня тоже ломает каждый раз. Тут есть две штучки в помощь: автосоздание тикетов и формы. Если можно создавать тикеты автоматически, то нужно это делать обязательно. У нас, например, при создании фича-тикета создается автоматом подзадача на декомпозицию -- мелочь, а приятно. А формочки помогают заполнить всё, что нужно, умеют валидировать типы (например, календарик для дедлайнов нарисуют), заставляют писать обязатльные поля, но так же и дают подсказки по формулировкам и контенту. Чтобы ты ничего не забыл, дорогой. Кстати, про ничего не забыл. У нас всё обложено чек-листами, как у пилотов. Очень удобно эти чек-листы подсовывать по ходу движения тикетов по статусам. Например, на этапе тех дизайна мы напоминаем, что нужно не забыть про схему бд, изменения в API, изменения в нагрузке и т.п., а на этапе раскатки в прод надо вспомнить, на какие графики посмотреть (бизнесовые, железячные, всяких там очередей и т.п.). Иногда для чек-листа текста получается многовато, поэтому можно научить робота присылать комментарии в тикет. А в них можно уже и ссылочки на нужные графики приложить, например. Рассказывайте про свою борьбу с рутиной!

Я забуксовал на чтении Канемана примерно на четверти книги. Возможно, потому что пытаюсь читать на отдельном устройстве, возможно, что текст не мой -- не знаю. Но мне понравился эффект от прочтения книг в предыдущие периоды, поэтому нужен был способ мотивации себя. Очень кстати я набрел в интернетиках на идею профессионального книжного клуба. Сначала, я хотел предложить ребятам читать в командах всякие книжки с кабанчиками, но потом понял, что можно читать еще и управленческую литературу в таком формате. Всё ещё считаю, что разработчикам надо организоваться и тоже вместе что-то читать или проходить курсы. Но тут жду инициативы от лидов -- им виднее, чего там в командах не хватает. Мы же уже провели первую встречу книжного клуба. А читать мы начали не абы что: классику айтишного управления, книгу, на которую ссылалось вообще всё, что я читал хотя бы косвенно связанное с управлением, великий и ужасный The Mythical Man-Month Брукса. Пока мы прочли только первые три главы, но я уже кайфанул. Книге 50 лет, а сутёво ничего не поменялось. Всё те же причины любить программирование, всё те же причины не любить. Мимоходом всё тот же МЕТОД критической цепи (всегда удивлялся, что это прям особый метод, а не что-то очевидное), всё та же история про коммуникации и ресурсы на них, всё те же ошибки в оценках сроков (никто никогда не думает, что будет тетсировать код в три раза дольше, чем будет его писать, но все всегда так и делают). Отдельно отмечу главу про операционную. Метафора, как обычно, сомнительная, но есть несколько моментов. Во-первых, кросс-функциональная команда (эджайл тренеры до сих пор думают, что это они придумали). Во-вторых, есть явно выделенный лидер, за которым последнее слово, на котором ответственность (это такая борьба с долгим принятием решений и срачами, какой фреймворк болие лудший). В-третьих, в команде специалисты разного уровня! У них там разные функции. Есть самый главный программист, он ДУМАЕТ и принимает решения. Есть copilot (надеюсь, что современная тула это пасхалка), который в целом такой же крутой, но менее опытный. Он челленджит, об него думает главный, он ищет всякие проблемные места, а еще ходит на встречи, где нужна экспертиза в системе. Еще есть чувак, который просто набивает код (на перфокарты, но чем питон лучше?). Еще один чел пилит вспомогательный софт: всякие библиотечки, тулы, окружение (короче, программки масштабом поменьше основного продукта). И отдельно есть language lawyer, человек, который умеет на этих ваших алголах красивые конструкции делать, чтобы код был круче. Остальные там не программисты. Это, кстати, типовая история для хорошей команды и сегодня, если почитать интернет и посмотреть, каких людей ищут в команды. Обычно нужен какой-то крутой убер-архитектор, какой сеньор, который будет всех учить жизни и учиться у архитектора, тот парень, который просто херачит код от забора до обеда и ходит к сеньору на ревью, студент, который притащит очередную прикольную библиотеку или обновит вам джаву с восьмой версии уже, а еще меценат, который будет автоматизировать всякую мерзкую рутину для всей команды. Бывают и еще пожелания, но идея всё та же. Мы, к сожалению, не как пацаны из тинька, на ютуб свой книжный клуб пока не выложим. Но я буду держать вас в курсе, как там прогресс. А вообще книжку можете почитать и сами. Там независимые эссе, которые Брукс с первого издания не менял. Только дописывал в конец новые. Поэтому в целом вам подойдет любое издание.