В комментах иногда цепляем больные (для меня) темы холивара🔥, которые потом хочется отдельно помусолить. Вчера, вспомнил про фулстек, но там был циничный юморок и в реальности я топлю за T-shape и надо будет подумать об вас на эту тему подробнее.
Сегодня будет про code review.
Если совсем коротко, то, на мой скромный взгляд, одна из самых переоцененных, но часто используемая практика, которой пытаются чего-то достичь. Почти никто не думает о реальных целях, форматах проведения, реальном ее влиянии на итоговое качество продукта и кода, скорость доведения фичи до прода, но все проводят. (Потом правда на каждом ретро обсуждают "почему у нас MR висят на ревью целыми днями")
Хотя на самом деле в большинстве своем, у многих, она сейчас больше мешает, чем помогает.
Имхо, популярность практики связана не с ее ценностью, а человеческой психологией: всегда удобно просто покритиковать кого-то.
С другой стороны, ревью кода в виде обозначения "экспертиза исходного кода программы" входит в ГОСТ по безопасной разработке, что как минимум требует формальной галки проведенного ревью, как максимум ожидает настроенного процесса. То есть вроде полезная штука, в чем же подстава?

Подстава в последовательности шагов ревью и квалификации команды. Остальное вторично.
Интуитивно: если мы делаем ревью чего-то, то мы предполагаем существование этого чего-то. То есть сначала пишем код, потом его анализируем. Потом, по комментам, код меняется и снова ревью. Кто-нибудь анализирует основные причины комментариев? Что заставляет сильно менять код? Как часто находятся проблемы? Могли бы эти проблемы найдены статическими анализаторами, линтерами и тестами (рядом с кодом)?
По моему опыту (давнему разработческому и текущему наблюдающему), если настроен автоматический анализ кода + пишутся тесты, то это намного эффективнее находит проблемы, чем глаз коллеги, особенно, если его экспертиза в разработке или доменной области решаемой кодом сильно разнятся от вашей.
Что нельзя отловить анализаторами и тестами? Ошибки проектирования (хотя считается, что юнит-тесты как-то помогают). Значит добавляем промежуточный шаг, когда разработчик предлагает сделать ревью не готового кода в 100500 изменений, а драфта возможного решения: набросок кода, схемы предполагаемого взаимодействия (data flow, межкомпонентного и тдтп). Это смотрится, обсуждается, дальше реализация, а потом уже или быстрое ревью, или только автоматизация.
Вот кажется, это единственно разумный вид процесса code review. Все остальное - бесполезная трата времени.

Полезные ссылки:
• Stop doing code reviews and try these alternatives (там хороший анализ с примерами исследований и возможных альтернатив)
• И снова про code review или новая единица измерения качества (WTF/minute) (самопис в мою бытность ревьювера)
#holywar #codereview

Чаще всего повышение получают, создавая что-то новое (новые фичи, новые сервисы). Редко его можно получить за счет упрощения/удаления. При этом осознание ценности упрощения - это шаг в сторону сеньорности. Решить проблему клиента не написав строчки кода, или, что круче, удалив кусок кода - сильно недооцененный навык в отрасли.

Самый быстрый код - это код, который никогда не выполняется.
Найди сегодня что-нибудь для удаления.
#мысли_вслух

Признаюсь, долго думал, ок/не ок картинка за пределами твиттера.
Но, честно, формат, в котором часто проходит code review, навевает эту аналогию.
Всем хорошего завершения рабочей недели.
#it_memes #codereview

Мысли про observability.
Как правильно на русском, не знаю: наблюдаемость(?), но так я еще ни разу не слышал. PS в комментах подсказали "Обозреваемость"
Очередная модная штука (ну последние лет 5-6), которую мало кто понимает (я признаться тоже скорее интуитивно), но базвордят ею активно.
Реперные точки, базис:
1. С помощью мониторинга мы узнаем, что проблема произошла, тогда как observability дает нам возможность узнать причину проблемы и точнее локализовать сбойнувшее место в системе.
2. Мониторим мы обычно то, про что знаем. Observability позволяет узнать то, что неизвестно (unknown unknowns).
3. Важнейшая характеристика наблюдаемости - это возможность понять поведение системы по артефактам ее функционирования.
4. И хотя логи сервисов являются одним из ценных артефактов, бездумное их расширение вносит проблемы в сам код и его эксплуатацию, не добавляя при этом им полезности.
5. Думайте про контекст. Именно контекст того, как пользователь взаимодействует с системой и что нас привело в конкретную точку и является тем, на чем базируется наблюдаемость.
Полезные ссылки:
• Observability: The 5-Year Retrospective
• Don't attempt to "monitor everything". You can't. Engineers often waste so much time doing this that they lose track of the critical path, and their important alerts drown in fluff and cruft"
• Framework for an Observability Maturity Model
• Monitoring vs Observability with Example
#observability

Я уже признавался в симпатиях к DORA-метрикам.
Добрался наконец-то до отчета 2023 года.
Какие-то интересные штуки буду сюда закидывать.
Начнем с традиционного, с самих метрик для оценки скорости поставки изменений. Первые 2 отвечают за пропускную способность, следующие 2 за стабильность поставки:
• Change lead time - время от комита до завершения его поставки
• Deployment frequency - как часто изменения попадают в прод (задача со * в “коробочных” продуктах с релизами раз в квартал)
• Change failure rate - как часто деплой в прод требует вмешательства, когда что-то пошло не так
• Failed deployment recovery time - какое время требуется для восстановления после неудачного деплоя
И тут уже видим первое изменение: теперь "Mean Time to Recover" обзывается "Failed deployment recovery time" для более точной привязки проблем именно к деплою. Обновите чек-листы для собесов 🙂
Ну а какими, по мнению экспертов, должны быть цифры для этих метрик, смотрите картинку в комментах.

Полезные ссылки:
• Сам отчет Accelerate State of DevOps Report 2023 (ссылка на него традиционно доступна в открытом виде на форме, где тебя просят ввести свои контакты, чтобы ее скачать, надо лишь просто посмотреть ее исходники)
• Про метрики инцидентов (в том числе про то, зачем переименовали MTTR)
#metrics #tech_read

ахаха, смотрю, дора тяжело идет ))
Ну вот вам внеплановых мемчиков в честь вечера нечисти
#it_memes #test_automation

А про удаление ненужного думают не только в этой тележке.
Вчера кучно прилетело про проекты, которые разрабатываются в больших корпорациях для того, чтобы автоматически находить и удалять ненужный код и связанные с удаленными сервисами данные: SCARF (оригинальные ссылки есть внутри этой транскрипции) и Sensenmann (кстати, в гугле таким образом удалили уже 5% старого С++ кода).
Так как реализация обоих механизмов завязана на внутряшку текущей реализации проектов в FB и Google, то вряд ли мы дождемся чего-то открытого и доступного остальным. Но подходы интересные.
#tech_read

Нумерология для менеджеров:
0 - сколько раз вам можно соврать
1 - сколько раз вы можете делать контр-оффер одному человеку (я вообще их не люблю)
2 – минимальное количество прямых подчиненных, которое должно быть у менеджера
3 – минимальное количество кандидатов, с которыми вам следует провести собеседование перед принятием решения
4 - сколько минут можно потратить на болтовню в начале встречи
5 - количество комментариев к документу, после которого вам нужно попросить рассказать о проблеме
6 - число, которое вам говорят люди при вопросе оценить свое удовлетворение работой в шкале от 1 до 10, когда они не удовлетворены ей
7 - дней для первого MR после выхода на работу
8 - процент людей, которых следует оценивать как неэффективных в быстрорастущей компании
10 – максимальный процент, который вам следует рассчитывать при обсуждении оффера
30 – количество дней, прежде чем небольшая проблема из саппорта станет большой проблемой
50 - количество MR, которые хороший инженер должен смержить за 6 месяцев
90 - количество дней, за которое открытая вакансия должна закрыться
100 - раз ты должен прочитать все эти цифры
200 - максимальное количество записей для small data
500 - количество сотрудников компании до того, как ваш генеральный директор станет политической фигурой
1000 - размер компании, при котором вы рискуете прийти в состояние, когда сотрудники начнут думать, что от них ничего не зависит в успехе компании
#management

Крафтотесты... я тоже так раньше называл, потом как-то затерялось.
А звучит ведь волшебно...
#it_memes #testing

Про ясность ваших мыслей и отсутствие вранья

“Одна из наиболее распространенных ошибок управления — отсутствие ясности в случае, когда люди ошибаются в отношении важных, вложенных усилий.”
…
“многие проблемы управления возникают из-за ,попытки быть «хорошим» там, где вам следует ясно выражать свои мысли”
…
“Вы не должны говорить людям, что они неправы, каждый раз, когда они совершают небольшую ошибку. Однако чем больше времени было потрачено, то есть, чем больше ошибка - тем яснее вам нужно быть.”
#management

Как-то потерял Ивана Селиховкина в своей ленте, а он хорошие вещи пишет.
Когда-то занимался у него на курсе PMP, благодаря чему понял, что PrjM-ство не мое (кто-то бы знал, кто-то бы знал, чем придется заниматься спустя 10 лет…)
Рекомендую посмотреть его статью “Как измерять эффективность в ИТ-компании?” про три группы метрик:
• Метрики работы (TTM, CT, FE, Through Output, milestone deviation, etc)
• Метрики комфорта (NPS, текучка)
• Метрики продукта (MAU, DAU, retention, chun, LTV, ARPU)
#management

Статья про “архитекторов”, но как это часто бывает, все скатилось к философии специализации. А именно к тому, как ее правильно использовать.
Небольшой кусочек оттуда, который меня (думаю понятно почему) триггернул:

«Уместен пример история QA. Когда-то в каждой технической компании был отдел контроля качества, который тестировал код и “обеспечивал” (простите, это мои кавычки, я эту фразу даже в переводе написать не могу) качество.
От инженеров-программистов не требовалось писать тесты на своей код — это была работа отдела контроля качества. В конце концов мы поняли, что пишем программное обеспечение лучше, когда на самих инженеров возлагается ответственность за написание собственных тестов и тестирование собственного кода.

Разработчики выли и жаловались: “мы не успеваем!”, “у нас нет времени писать новое!”. Но постепенно стало ясно, что, хотя написание и тестирование кода может занять больше времени на начальном этапе, в долгосрочной перспективе это сэкономило гораздо больше времени и усилий, поскольку код стал намного лучше, а проблемы обнаруживались гораздо раньше.

Мы не избавились от QA - отделы QA все еще существуют, особенно в некоторых отраслях, но они больше похожи на экспертов-консультантов. Они пишут наборы тестов и программное обеспечение для тестирования, но, что более важно, они являются ресурсом, позволяющим убедиться, что все пишут хорошие тесты и поставляют качественное программное обеспечение.
…
Специалисты здесь не для того, чтобы делать работу за вас, а для того, чтобы помочь вам сделать ее лучше...»

PS а саму статью обязательно почитайте, особенно те, кто верит в архитекторов, как отдельную роль.
#testing #it_философия

Традиционное, пятничное.
Всем сегодня без говнокода!
#it_memes

Нетрадиционное, непятничное :)
Я тут влез в дискуссию в одном из популярных каналов (по сути дискуссии уже в понедельник) + наблюдаю за своими активными комментаторами и багами телеги.
Итого: комменты в телеге реализованы через одно место (зато, чувствую, сделано было быстро) :)

Давайте попробуем вот так: группу для комментов я публичной делать не буду, но по ссылке туда можно будет вступить, читать/писать оторванные от моих постов комменты.

Короче, все кому заходит контент, но телега мешает его обсуждать, велком https://t.me/+eVSMX4QvqvxlNjcy

Я люблю воспоминания, благо чертоги памяти уже достаточно обширные. Хотя, как часто выясняется в разговорах с женой, на самом деле я плохо помню детали событий более чем 20-летней давности (+/-). И чем мне нравится мордокнига - это раздел “Воспоминания”.
На днях она напомнила про 10-летие видео И.Павличенко “10 причин почему лучше не строить распределенную команду” .
Посмотрел снова, всплакнул, посмеялся…
Помню еще в начале 2019 обсуждали на работе “А ведь плохо, когда часть команды работает из Праги, а другая из Питера. Получается как бы 2 команды, не де-е-ело. Нельзя так релоцировать.” (Хотя все же стоит различать полностью распределенную команду или кучкообразно-распределенную, есть нюансы, да).
Ну и потом пфф, 2020 год - “подержи мое пиво”. Тыдыщ, 2022 год - “и мой десяток бокальчиков”.
Да, на самом деле, проблемы из видео никуда не делись. Да, можно долго спорить про то, насколько команда сидящая в одной комнате продуктивнее распределенной и действительно ли это так. Но жизнь просто раз и поменяла правила игры. Подтянулось качество инструментов и да, как и прогнозировал Илья, мы стали их заложниками, а я дико скучаю по доскам в кабинетах. Поменялись ли сами люди и их отношение к работе? Нет 🙂
Если вернуться к видео и причинам по которым лучше "не делать распределенную команду":
1. Распределенная - это не команда. Хмм, нууу я скорее соглашусь.
2. Всё ресурсы - есть такое. Например, стал проще относится к факту расставания, связано с п1
3. Запутывание проекта - и такое есть.
4. Уходит самоорганизация - ну тут от людей зависит, если локально не было проблем у человека, то и с распределением не будет. Ну и да, не бывает самоорганизации у команды, есть организующие все люди внутри команды.
5, Продуктивность распределенной vs локальной команды - спорно, но-о-о, иногда такие мысли возникают.
6. Зависимость от инструментов и процессов - о даа. 100%. И инструменты, и процессы.
7. Разные таймзоны - в целом понятное ограничение
8. Тюнинг кросс-функциональности - не согласен. Оно или работает в хорошей команде, или не работает, от распределенности не зависит. Хотя фольклорно, в “курилке”, знания “всегда” лучше передаются, это почти факт 🙂
9. “Мы и они” - согласен
10. Где будет скрам-мастер? - ну это фигня, хотя при кучкообразной распределенности могут быть проблемы, да.

PS да, тут намешано все в кучу, “удаленка”, “распределенка”, “расчле...” (простите, питерское вырвалось).
Но воспоминания - это прикольно…
#байки #management

"Люди часто говорят говорят о «нестабильных (flaky)» тестах/проверках. Хочется аккуратно отметить, что это не проверка нестабильна, это наше понимание ситуации таково" (с) Michael Bolton
PS хорошая аналогия, но мне больше нравится определение "случайно успешные" для моргающих тестов

#мысли_вслух #testing #test_automation

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

#байки #собеседования

Интересный пример того, как можно обойтись без менеджера. И все будет работать, якобы масштабироваться и развиваться.

Немного контекста:
«Обязанности менеджера распределены между тремя отдельными ролями: инженерами, лидами групп и коучами.

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

PS почитал, улыбнулся, где-то по чертогам памяти вспышкам пробежала аналогичная история из моего опыта...
НИХЕРА оно не масштабируется 😂
Там нюансов до одного места и самый важный из них - люди. Инженеров, которые будут готовы работать и умеют работать в такой парадигме очень мало. И как только компания решит расти, все мгновенно вернется к традиционной модели управления.
#management #байки #процессы

"Code freeze & release - ставки сделаны, ставок больше нет" (c) мое

Простите, сегодня без фотомемов.
Башка пустая после релиза...

#it_memes #байки

Самая известная структура компании (модель масштабирования) имени компании: Spotify model.
Многие до сих пор пытаются внедрить то, что рассказывал Книберг в 2014 не особо вдаваясь в детали, причины и подноготную этого устройства. А между тем в Spotify уже давно все не так, как все привыкли себе представлять. И сложности ровно такие же, как у нас всех: менеджмент, синхронизация команд, развитие людей.
И неважно как у вас называются команды, их менеджеры, как команды объединены, важно как в работе учитываются эти моменты:
•Поставка ценности – все улучшения системы следует проверять, задавая вопрос: помогает ли это улучшение/эксперимент нам обеспечить ценность?
•Обеспечение ценности продукта – требует проведения экспериментов и выяснения того, что работает для реальных конечных пользователей.
•Автономия важнее управления и контроля – без автономии невозможно обучение, совершенствование, инновации или способность адаптироваться к меняющимся обстоятельствам.
•Синхронизация — вместо того, чтобы указывать людям, что делать как с функциями продукта, так и с архитектурой продукта, сосредоточьтесь на том, чтобы команды согласовывали свои планы с общей целью продукта.
•Кросс-функциональные продуктово-ориентированные команды (фиче-тимы) — вместо функциональных команд (база данных, бизнес-логика, пользовательский интерфейс).
•Инженерная культура, ориентированная на обеспечение качества и простоты: создайте конвейер непрерывной поставки, который позволит командам создавать ценность независимо друг от друга. По сравнению с конвейером, который требует ожидания, пока команда DevOps выполнит развертывание. Во многих организациях DevOps — это команда, следующая за функциональной командой, которая развертывает приложение. Это известный антипаттерн.
•Психологическая безопасность – ключевым элементом дружелюбности к эксперименту является создание среды, в которой мы можем признать, что рискуем и извлекаем уроки из этого процесса. Причудливое название этого явления – «психологическая безопасность».
•Постоянное совершенствование как особенность системы: команды никогда не перестают совершенствоваться. Нам необходимо создать культуру, которая будет способствовать такому мышлению.
•Моральный дух – готовность и настойчивость членов команды работать ради общего блага.
•Улучшение потока работы через систему — инструменты включают ограничение незавершенной работы, перекрестную профессиональную переподготовку и устранение узких мест. Вы можете измерить успех этого как с помощью Cycle Time и Lead Time.
Что еще почитать:
Spotify doesn’t use “the Spotify model” and neither should you.

#процессы

Если вы хотите быстро улучшить результаты тестирования, замените «проверить X» на «ищите проблемы, связанные с X» М.Болтон
#мысли_вслух #testing