В IT чудес не бывает

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

"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

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

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

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

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

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

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

#байки

Про аналогии

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

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

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

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

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

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

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

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

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

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

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

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

The diagram below shows their definitions and typical architectures.

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

#observability

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

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

#testing

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

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

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

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

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

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

Было?

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

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

#management

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

YouTube | VK Видео

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

я понимаю, но решение, не упарываться = выбору метода, т.к. как это тоже имплементация

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

Хорошие уточнения про "что"

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

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

Просто уже начните писать тесты, а не переписывать "фреймворки".

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

В продолжение темы

The Product Engineer Mindset (Product Engineer Manifesto)
In our work as Product Engineers, we have come to value:

• Continuous delivery of working software over promises and estimations
• Asking why to deeply understand the customer problem before diving into code
• Customer collaboration and feedback over tickets and second-hand knowledge
• Teamwork and communication over picking up tasks and working in isolation
• Using the product ourselves over relying on others to test our software
• Strategic thinking and understanding the market and context you're operating in

#it_философия