Большое эго и недостаток самосознания — проклятие хорошего лидера...

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

Таки да.

#management

Так исторически сложилось, что мы херачим говнокод.
Так исторически сложилось, не разгребаем технодолг.
Так исторически сложилось, что тестить должен кто-то там.
Так исторически сложилось, разруха в наших головах...

ЗЫ из моего раннего
#анафора #мысли_вслух

Что интересно, OKR часто рекомендуют к использованию.
Но еще чаще вокруг него возникают надстройки, помогающие его использовать.
Получается, что сам по себе метод неудобный или сложный?
POMKRA
Understand the Goal - (PO)
Build an Operational Plan (MKRA)
• Problems
• Objectives
• Milestones
• Key Results
• Activities

#management

What if everybody did everything right?

Интересный совет для осмысления причин инцидента:

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

Рассмотрение инцидента с этой точки зрения приведет к совершенно разным выводам, поскольку порождает разные типы вопросов, например:
• Какую информацию знали люди в данный момент?
• В каких условиях действовали люди?

#процессы #management

И пока мы еще не определились, что лучше микросервисы или монолит, давайте посмотрим подробнее на эти самые μServices.

At the heart of microservices
• we're told we'll find...
• we find...
• we should find...
• we often find...
• we need... to start rethinking what we really need.
You Want Modules, Not Microservices

#tech_read

Есть такой способ передачи знаний, очень популярный в IT: фольклорный...

пятничные #it_memes

Тот момент, когда долго вынашиваешь пост хоть пару мыслей про автоматизацию тестирования и “автоматизаторов”, но сомневаешься: может это только мое искажение.
А потом приходит Алан Пейдж и просто рубит правду-матку “как оно есть”.

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

"...
Test Automation in 2024
Short story - it still sucks. In the last ten years, I’ve worked with a lot of development teams on improving velocity, and in every single case I’ve found that developers owning all test automation results in better tests, more testable code, faster deliver, and higher overall quality. Some of these teams don’t have dedicated testers, but on teams with dedicated testers, those folks do not write automated tests. They write tools to assist in testing or debugging, or work with the development team in order to improve testing knowledge across the team.
..."

(с) The "A" Word...revisited Alan Page

PS мои пару слов (10-летней давности) про The "A" Word

#test_automation #holywar

А кто-то у себя использует Zero Bug Policy?
Отличный подход, который позволяет сохранить беклог и голову в порядке. Меньше страданий от постоянно растущего количества багов, которые никто не фиксит, но которые постоянно фигурируют в отчетности, как "показатель зрелости продукта".

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

А ведь там все просто: если баг есть и мы оценили его как критичный - значит мы его берем и чиним, а не маринуем в беклоге. Если некритичный (или кажется таковым в настоящее время) - значит просто фиксируем проблему, обозначаем его как “won’t fix” и забываем про него до того момента, когда его критичность меняется (похожий запрос от клиента, новый сценарий эксплуатации проблемы и тдтп).

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

Статья по этой теме с рекомендациями по переходу на ZBP

#testing #процессы

А давайте еще про "законы/закономерности/принципы" в IT.

Самый популярный - это закон Конвея (Conway's law):

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

Иногда звучит в такой интерпретации:

"Don’t ship the org chart!"

Похоже на то, что у вас?

Подробнее по теме:
• The Most Powerful Law in Software
• Conway’s Law in Team Topolgies: Did you really get it? (кстати, там упоминается прикольный "лайфхак": "we should design our teams (not the software yet) to “match” the required software architecture. That means reconfiguring the team intercommunications before the software is finished.")

#it_философия

Продолжая тему "менеджер и техника".

Еще несколько советов оставаться в технике будучи менеджером: Should you Stay Technical as an Engineering Manager?

PS жаль, что мои самые любимые - самые неэффективные 😒
PS2 кстати, вопросы поддержания необходимого тонуса в технике касаются не только менеджеров 😉

#management #развитие

IT Global Meetup #16
23 марта в Питере. Молодцы, оживили.
Даже интересно, сколько участников будет.
PS я тот еще социофобушек теперь, но все может быть...

Философское пятничное #it_memes ное от Макса Дорофеева

#it_философия

Пересмотрел еще раз спустя 9 лет.
Он все так же хорош. Но тогда был прямо в ❤️
Очень рекомендую.

Вадим Макишвили, доклад "36"

Следующий его доклад ("42") мне не так хорошо зашел, но думаю и он нашел свою аудиторию.

#it_философия

Лидерство - это искусство разочаровывать людей с такой скоростью, которую они могут выдержать.

(с) "кому только не приписывают"

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

И еще один доклад Вадима "55", для руководителей.

Почему-то вспомнил про эту книгу "Общаться с ребенком. Как?"
Мысли пересекаются.

Но задумался про казус: иногда возникают ситуации, когда хочется, чтобы сотрудники "стали" наконец взрослыми, а не "инфантилили"/не вели себя, как дети.
При этом же часто менеджерам рекомендуют книги про воспитание детей...
Что это? Намек на то, что такие люди разработчики не взрослеют?

#management

What's a distributed system?
It's not microservices exchanging messages and storing data in a DB.

Небольшая шпаргалка-затравка по теме распределенных систем. Скорее просто для того, чтобы оценить масштаб бедствия в голове по этой теме перед столь любимыми многими компаниями собесом по System Design.
#tech_read

Девиз "успешных" людей в пятничных #it_memes

ЗЫ тут должен был быть другой мем, но я вовремя заметил, что у меня стало много "жоп" по пятницам.

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

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

Я застал те времена, когда тестировщики в резюме писали "инженер по тестированию" и в вакансиях писали ровно это же.
Потом какие-то умники, глядя на "как там" начали активно форсить тему с QC, почти мгновенно переключившись на использование букв QA.

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

Потом та же история повторилась с DevOps (которые сначала просто админы с большими ЗП, а потом СИАЙ-админы и админа в КУБЕ). И снова раскрутка через вакансии и отражение в резюме.

Теперь вот та же фигня с цифрами по результатам в резюме, которая 100% пришла из резюме сейлзов/маркетологов и прочих продаванов.
Все рекрутеры теперь их ждут в резюме инженеров (и уж тем более инженерных менеджеров) и предлагают всем это использовать.
И все будут писать вот такую фигню, типа "разработал и успешно внедрил новую систему рекомендаций для e-commerce проекта, используя Python (Scikit-learn, NumPy, SciPy, PyTorch, Surprise), PostgreSQL, что позволило увеличить продажи на 15% за первые три месяца после запуска".

Что не так с такими циферками в резюме?
Есть риск попасть в анекдот "Это ребята курили. Я просто рядом стоял"
1. Если вы не знаете, как именно ваша работа повлияла на эти циферки - не надо это писать
2. Если вы не знаете, как эти циферки меряются - не надо это писать
3. Если вы не можете рассказать, сколько времени занял рост до этих циферок, сколько людей и как в этом участвовало - не надо это писать

И чем больше была команда - тем меньше вероятность, что это надо писать...

Что же можно писать вместо этого, чтобы сделать резюме более привлекательным?
Только про то, что сам сделал, предложил и протащил, а ты можешь объяснить ход истории этого проекта.

Примеры:
- обучил 100500 падаванов
- проработал изменение архитектуры, которое привело к ускорению (циферка), повышению RPS, повышение производительности и тдтп
- затащил новый подход к написанию тестов и скорость написания тестов увеличилась с X до Y
- ускорение выполнения тестов с N до M
- протащил проект изменений через X команд
- провел X собесов из них Y прошли испытательный срок (или заонбордил 100 чуваков)
- запустил 300 новых команд

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

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

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

Для тех, у кого могут быть вопросы, зачем такое в резюме в принципе.
Числа про деньги интересны с точки зрения:
1) косвенно показывают, что инженер знает про то, как меняются бизнес-метрики его продукта
2) можно предположить, что насколько человек вовлечен в культуру product engineering

#собеседования #про_резюме

Как часто мы огребаем от истории "мы всегда так делали", "у нас так принято"?
Уже давно никто не помнит, почему так делается, для чего и какую цель пытались достичь, когда это придумали.
Тут может быть и зашоренность, и "твердолобость" и просто низкая квалификация. А может просто лень что-либо менять...

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

"Roast Beef and Legos" by Alan Page

#it_философия

Лет 5 назад подсмотрел у Киры Кузьменко 2 лайфхака на тот случай, когда "текст никак не пишется” (она в свою очередь тоже откуда-то взяла, но те ссылки уже "мертвые"):

1. "...если не пишется и страх чистого листа. С 2008 года практикую: надо просто начать с "ну бля, короче..." — и дальше текст сам выстраивается без воды и вот этого всего."
2. Тексты не пишутся по вдохновению, да и дождаться его иногда месяцами невозможно. (...) Трудно, как говорят редакторы, только первые двадцать минут. Правда, эти двадцать минут приходится переживать несколько раз в день.

Моему блогу уже больше 12 лет, почти 250 заметок. По лайфхакам: оба рабочие. Но мне всегда нужен какой-то триггер, а самое главное: глобальная цель, типа нафига это все.
Многие рекомендуют писать по расписанию, типа дисциплинирует. Но у меня такой вариант только в телеге работает, и то, только потому, что я достаточно часто просто закидываю ссылки без своих букв.
#байки

В статье Алана есть интересная аббревиатура: TTWWADI.
А явной расшифровки нет, пришлось гуглить.
That’s the way we’ve always done it - вот что это значит.
И понятно, что это проблема не только IT.

#it_философия