Пересмотрел еще раз спустя 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_философия

"20% теории управления достаточно для 80% результатов. Если конечно принцип Парето работает" Ryan Lilly

Вся мякотка в том, что далеко не все менеджеры знают и 5% этой теории. А если и знают, то не используют.

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

Есть ложь, наглая ложь и "тут всего пара строчек, оценю задачу в половину сторипоинта" (байки из интернетов)

#metrics #байки

Результат #codereview на 50 строк vs 100500 строк

Сделал дело и идешь смотреть пятничные #it_memes

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

Я тут не хочу писать подробности про сторипойнты (попугаев, слоников, чашки кофе, размеры маек), планинг-покер и тд. Очень много инфы по этой теме.

Тут будут просто советы, а завтра про собственно процесс, как я его вижу.

1. У всех, кто участвует в процессе, должно быть одинаковое понимание того, что именно они оценивают и с какой точностью эта оценка делается (подробнее смотри совет 1 отсюда )
2. Важно понимать, что ошибки оценки все равно будут. И поэтому должны быть:
• процесс работы над этими ошибками (расширяем базу знаний и подходы для следующих оценок) с тем, чтобы в следующий раз оценка была точнее
• процесс информирования о возникающих из-за этого рисках (не тянем до последнего)
3. При запуске/перестройке процесса оценки очень помогают эталонные (референтные) задачи, сравнивая с которыми мы пытаемся оценить наши текущие задачи
4. Оценка в сторипойнтах - это в том числе способ избежать необходимости точной оценки: когда оценивается, например, в часах, сразу возникает ситуация, когда было запланировано например 3 часа, а задача сделана за 3.5.
Это хорошая оценка или продолб? А 4 часа? А как это время измерялось и что в него входило?
5. Не бывает “копеечных” задач. Вообще не используйте это обозначение. Оно мешает запускать в голове комплексный процесс оценки задачи, зато помогает забыть про важные вещи.
6. БОльшая декомпозиция помогает точности оценки
7. Постепенный уход в сторону простого кол-ва задач, тогда можно просто считать кол-во задач и меньше думать про их оценивание.

Кстати, в очередной раз “эффект инфополя”: пишу заметку, а в рассылке в пятницу пришла хорошая статья по теме оценки.

И еще тут у меня было про этой теме.

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

#процессы #оценка

Если оценку задач делает не "специально обученный быть крайним человек" лид, а решение принимается на командной встрече, то предлагаю такой вполне рабочий процесс:

Работу над оценкой задач на следующий спринт начинаем в текущем спринте.
Встреча 1 (30-45 мин):
• смотрим на ожидаемый список историй/задач (формирует PO исходя из целей спринта, но возможно участие команды, особенно по техническим задачам)
• определяем задачи, по которым недостаточно информации для их оценки (по остальным сразу делаем оценку)
• у каждой такой задачи появляется ответственный, который до проведения следующей встречи собирает нужную для оценки информацию (корректность проработки, место(-а) в коде, которые надо изменить/дописать, синхронизация со смежной командой и тд) и делает на базе этого предварительную оценку* (см дальше пояснения)

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

Встреча планирования спринта (15 мин**):
• если за время после 2й встречи ничего нового не прилетело, то в спринт просто берутся задачи согласно текущей “скорости прожевывания сторипойнтов” (ака velocity) и их приоритетов
• если что-то прилетело и оно важно, то это обсуждается уже на планировании. Но лучше бы конечно это все же сделать предварительно, иначе оценка будет скорее “пальцем в небо”.

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

*По опыту, самая холиварная тема - это “а как я буду что-то ресечить, если у меня куча задач по текущему спринту?”. Все просто - время на ресеч “закладывается” при планировании через анализ текущей скорости прожевывания сторипойнтов командой. Речь не про то, что этим надо заниматься по ночам. Для трепетно относящихся к учету времени для такие ресечей на оценку можно заводить задачи с фиксированными значениям сторипойнтов.
** вторая по популярности тема "это ж нафига столько встреч?"
Ну, во-первых, суммарно по времени получается не больше, чем одна большая встреча планинга (где большей частью все "играют в покер", а не планируют). Во-вторых, обычно в этом случае мы получаем более осознанную и точную оценку, часто выясняются неочевидные вещи, требующие дополнительного ресеча и задача в этом случае просто не берется в работу в текущий спринт. Что, в конечном итоге, тоже экономит время. Ну и в третьих, первую встречу вполне можно проводить "заочно" и асинхронно.

Почему такой процесс редко можно встретить в реале? :)
Да фиг его знает, я ставлю на "лень-матушка раньше нас родилась...". Всегда ведь проще погадать на планинге не делая предварительного исследования.

#процессы #оценка

Если в компании есть инженерные отделы, основной задачей которых является “как бы” помощь продуктовым командам делать/выпускать их продукт(ы), обеспечение процесса разработки и тп, а эти команды не пытаются выравнивать свои активности с релизами, продуктовыми задачами и проблемам, то рано или поздно (скорее рано) все они превращаются в “вахтеров” со своими правилами, регламентами, "best practices" и системой разрешений.
Работа продуктовых команд при этом превращается в увлекательное преодоление множества препятствий к релизу…

Что это могут быть за команды? Те самые “общие” devops, отдельные внешние команды тестирования, безопасники, разработчики типа “общих” компонентов.
И в итоге у каждого есть понимание смысла своего существования, целей и пользы, но на выходе сплошной output вместо outcome и, эммм, напряженные отношения….

Варианты "че с этим делать"

#байки #мысли_вслух #holywar

Понятно, что надо плясать вокруг "не пытаются выравнивать свои активности с релизами, продуктовыми задачами и проблемами".
1. Работающий вариант распространения контекста (в обе стороны, кстати говоря) - это "командировки" инженеров в продуктовые команды и наоборот.
2. Донесение мысли о том, что все они тут нужны не для того, чтобы свои задачи работать, а чтобы продукты деньги зарабатывали, кажется очевидным, но почему-то обычно самым сложным :)
3. Повышение прозрачности работы "общих" команд для всех остальных. Бывает такое, что они реально дело делают, а со стороны выглядит как... "херней страдают".
4. Распространение знаний/экспертизы в продуктовые команды

Но в целом, иногда основной причиной лежит недоверие всех ко всем :)
Разрабы не могут тестить, никто кроме безопасников не может давать апрув... ну и тдтп.
Это сложнее всего "чинить", а многие считают это чуть ли не фундаментом работы, а значит это в принципе нечинибельно.

Причиной ошибок является не то, что у нас мало автотестов.
Основной причиной проблем является то, что мы не понимаем, как работает наша система.
А автотесты - это всего лишь один из способов описания того, что мы попытались в ней понять.

#мысли_вслух #it_философия #test_automation

Тема недели в #it_memes

Cоревновательные моменты на работе.
Помогают, мешают?
Чему и как именно?
Что думаете?
#процессы #management

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

Продолжение про соревнования обязательно будет. Вы вчера хороших мыслей накидали. Спасибо 🤝

Хотя-я-я, как начинать день без умных мыслей из газет интернетов, поэтому вот:

"Хуяк-хуяк и в продакшен" - опасно,
"Семь раз отмерь, один раз отрежь" - долго.
"Семь раз хуяк, один в продакшен" - наш выбор 💪

#мысли_вслух #байки

Было ли это когда-то в реале или нет, никто уже и не скажет...
Где-то когда-то в какой-то давно несуществующей IT компании работал большой отдел разработки из нескольких команд.
У каждой команды был свой проект/продукт/задачи. Между собой никак не пересекались, кроме руководителя.
И вот однажды начались соревнования...
Каждая команда показывала свои тесты на ревью какой-нибудь другой. Кто-то ломал продакшен код, а команда-ревьвер по тестам должна была его восстановить.
И были какие-то условия по которым определялся победитель (кстати, кажется, что само по себе мероприятие очень полезно для распространения знаний, в том числе по написанию тестов): после восстановления кода побеждала то ли команда-ревьювер, что смогла код восстановить, то ли команда-автор за то, что тесты хорошие.
Суть не в этом, хотя, повторюсь идея таких встреч - огонь.

За каждую победу команде давали наклейку, которую клеили на дверь комнаты, где работала команда. Геймификация...

Одна из команд очень любила соревнования, а главное победу в них. Со временем большая часть ее двери была занята наклейками.
Сколько наклеек было на других дверях? Немного. И соревнования другие команды не очень любили, ну ходят такие легенды.

Были действительно ли все наклейки на всех дверях по делу, можно ли было без соревнований такое делать мы уже не узнаем.

Говорят, что некоторые из-за этого ни тестов писать не любят, ни в соревнованиях участвовать больше не хотят. Но это неточно, давно было...

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