Прикольно, найденный 10 лет назад список полезнях для C++ до сих пор живет и поддерживается.
А значит это кому-то нужно 🤔

#видеозаписи

В программе Heisenbug блок «Инструменты и фреймворки» вечно оказывается одним из самых крупных.

Мы уже открывали видеозаписи некоторых таких докладов с весенней конференции, а сегодня в рубрике #ТестоваяСреда — плейлист со всем блоком сразу.

YouTube | VK Видео

"Ходим мы по краю, ходим мы по краю,
Ходим мы по краю р-о-одно-ому..."

Про стратегию и мидл-менеджмент в пятничных #it_memes

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

Опять же, для кого? Для подчиненных может быть одно "хорошо", для руководителей этого менеджера другое.

Да, есть букварные вещи, без которых ты точно будешь хреновым менеджером. Но даже их можно перекрыть другими качествами. Особенно это удобно, если руководитель менеджера сам так себе менеджер...

Я часто сталкивался с историями, когда, на мой взгляд, человек, как менеджер, хреновый. Но его сотрудники, на словах во всяком случае, его если не боготворили, то очень хорошо отзывались. И руководство компании его поддерживало. А потом, бумс-с, человек уходит и все, как бы неожиданно, видят "мусор заметенный по углам".

Короче, не бывает белого/черного одинакового для всех. Важно верить в свою палитру.

Good managers are hard to find and once you have them, they should be appreciated
#management #мысли_вслух

Работающие ценности: опираясь на них компания должна нанимать и увольнять людей независимо от их производительности.

Four Lessons on Culture and Customer Service from Zappos CEO, Tony Hsieh

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

Я как-то скептичен, хотя когда-то давно меня эта история цепанула.

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

Встречи 1:1 в формате TOTAL
PS подсмотрено у Бориса Вольфсона

#management

Интегрируем новую фичу в продукт и удаляем старую заглушку...

Было?

Конец рабочей недели в пятничных #it_memes

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

Ну а сами встречи 1:1- одна из практик, которая часто выставляется как обязательная, но редко проводится "по уму".

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

#management #ваши_вопросы

09.09
Говорят, сегодня день тех, кто профессионально не любит баги 🙂 Пусть ваша работа не перестает быть нескучной 🫣

10 признаков, что вы не подходите для работы тестировщиком:
1. Вы нервничаете из-за глючного ПО
2. Вы тестируете не зная ожиданий бизнеса
3. Вы устаете от объяснения того, как воспроизвести ошибку
4. Вы не читаете блоги, книги и не посещаете конференции по тестированию ПО
5. Вы стыдитесь своей роли в проекте
6. Вы знаете, как проверять, но не знаете, как исследовать
7. Вы не в курсе технических аспектов IT
8. Вы не любите общаться
9. Вы не знаете о жизненном цикле разработки приложений
10. Вы не можете забыть о найденных дефектах и страдаете, если их не исправляют

ЗЫ это вам немного романтики из прошлого... Эти советы давно уже игнорируются многими

#testing

Просто репост. База про то чем же они, млин, отличаются друг от друга :)

Logging, tracing and metrics are 3 pillars of system observability.

The diagram below shows their definitions and typical architectures.

ЗЫ подробнее в комментах

#observability

Хорошо, про то, как выделять время на "технику"

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

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

#процессы #мысли_вслух

Про аналогии

Из древних интернетов "Где та тонкая грань между "9 женщин не родят ребёнка за месяц" и "9 лесорубов срубят лес в 9 раз быстрее"?"

Всегда, когда вы пытаетесь придумать аналогию для описания какой-то истории или, кажется про то же, модель описывающую систему, вы должны понимать, что
1. это всегда упрощает и часто отбрасывает за пределы взгляда важные нюансы
2. Не всегда эта аналогия, хорошо применяемая для истории/команды/компании А, так же хорошо применима для Б

ЗЫ кстати, если лесорубы не договорятся, то лес может рубиться не так быстро, как может казаться в начале работ, а к концу леса лесорубов может стать меньше 9 (несчастные случаи, знаете ли)...

ЗЫ2 все выше написанное относится и к бест-практис...

По мотивам частых историй #все_крутые_компании_так_делают

сбивчивые #мысли_вслух

А у вас уже началось годовые планирование и бюджетирование?

Самое забавное конечно, это сравнивать то, что планировали в прошлом году, с тем, что делали.
Или как быстро закончились выделенные квоты на инфраструктурные ресурсы для разработки (типа стендов).

🤣 о, в прошлом году меня чуть позже бомбило.

#байки

Про "забагованность"

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

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

Хороший рассказ, вылез недавно в напоминалках

"Ignite the Fire - How Managers Can Spark New Leaders"

"Leaders and management are going to act in an organization in fundamentally different ways... Leadership is working with goals and vision, management is working with objectives"

#management

Делал несколько заходов, хотел написать красиво…
Тьфу, это ж телега, много букоф никто читать не будет. Поэтому просто выгружаю мысли.
Был в комментах вопрос про то, как можно “мерять” качество. Оставив при этом за рамками определение “качества” (я тут немного пробовал потоптаться, но там с ним бесконечная история).

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

Нельзя посмотреть на циферки и сказать “теперь мы качественные”. Но можно взять некоторые циферки и начать размышлять, глядя на них.

На что можно смотреть, окромя всеми любимых отчетов по багам (подробнее про баги, их подсчет и использование надо отдельно написать написал тут. А скорее просто оформить то, что обмусолили IT-дедами в ТвиКсе 2 года назад).

В комментах упоминали DORA-метрики. Очень правильные метрики: ибо, имхо, например, скорость фикса (включая скорость его поставки) важнее 100% покрытия.

Редко анализируемая штука: стабильность автотестов.
Автотест грустные новости приносящий - это не гонец, которого надо убить (выключить из прогонов). Это повод к разбору, потому что “автотест моргают = в проде все будет моргать”. Хотя бы, потому что если мы не можем диагностировать проблему в тестовом окружении, то ровно то же самое будет и в проде. Шансы на то, что проблема в написании проверок, а не в продакшен коде, конечно есть. Но часто реальность может быть суровее.
Вообще писал когда-то про "что делать, когда автотесты зеленые". Но так как стабильные тесты - это фантастика, никто и не страдает этим вопросом 😂

Но это все про условно техничку и процессы. А что в реальном мире?

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

Качество для пользователя - это деньги 🙂
Зарабатывает продукт деньги - значит он достаточно качественный. Не зарабатывает - проблема может быть не только в его качестве.

#quality #ваши_вопросы

Про то, как число Данбара (Dunbar's number) можно учитывать в работе и даже в фичах своих продуктов.

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

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

Интересно, что получилось бы сейчас, в современном обществе соцсетей, с новыми технологиями и способами коммуникации. Я почему-то ставлю на то, что это число (реальных связей) уменьшилось бы, как ни странно.

PS еще один пост в копилку менеджерской нумерологии.

#management

Про жуков и их подсчеты
Очередным утром, собрав в баночку с бензином очередную порцию колорадских жуков с картофельной делянки, дед Григорич открыл свой ноутбук “Правда” и обнаружил в новостях статью про то, как одна известная компания, занимается учетом жуков, которых сначала разводят, а потом отлавливают. А так как бизнес требует учета и оценки эффективности тех, кто жуков разводит, и тех, кто жуков потом отлавливает, то компания предложила свой вариант того, как этот учет можно вести.
"И тут жуки… ' - с усмешкой подумал Григорич, наливая чашечку утреннего кофея.

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

Григорич, когда-то давно, когда седая борода еще не закрывала кнопки в его ноутбуке, был таким энтомологом-программистом, из под его пальцев тоже рождались жуки. На дезинсекторов компания деньги не хотела тратить, поэтому пришлось самому влезать в тему поиска жуков. Но поиск - это интересно, а учет - неинтересно, поэтому Григорич не любил считать жуков, проще было переставить 0 и 1 в правильной последовательности или отпустить жуков на волю и забыть про них до очередного крика клиента, которому прямо на экран выползал когда-то помилованный жук. Сейчас Григорич жуков уже не разводил, а пытался (в своих мечтах) сделать так, чтобы подшефные энтомологи-программисты делали это меньше, а дезинсекторы скучали без работы (да, вот такой наивный мечтатель).

Но мы отвлеклись, вернемся к нашему рассказу. Так вот, открыл Григорич свою “Правду“ за утренним кофеем, а там статья про ненавистный ему учет жуков…

“Тьфу, качество они меряют…Картошка целая должна быть, а не 100500 жуков собрано” - с философским сожалением подумал дед. Отодвинул чашечку, подвинул ноут ближе, зашел в соцсеть “НаЗавалинке” и решил побухтеть.

Продолжение когда-то следует…

#григорич

Иногда спрашивают, что я делаю на работе.
Обычно как-то так...

И да, со стороны это смешнее, чем на самом деле.
#it_memes

И еще про метрики
"Missed Targets / sometimes the best things aren't bright and shiny"

You’re on a team that is absolutely crushing the four key metrics. Lead time is measured in days, you’re deploying several times a day, failures in production are rare, and when there are failures, they are fixed quickly. Your manager brags to his peers constantly about how the team is “elite”.

But the metrics are lying, and the team is dying.

Your lead time is in days because you don’t start tracking items until they’re almost done. You’re deploying several times a day, but only minor or superficial changes, as everything else is in long-running branches. You don’t have errors in production because the team is afraid to report errors in production - instead they patch them quietly when needed. But hey - you’ve nailed the metrics.

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

#metrics