Чудес не бывает или я ошибаюсь?

Про рост в лидов и то, что "даунгрейд" обратно - это не даугрейд

2025-07-25T11:20:00.002+03:00

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

Ссылка на статью на Хабре: Маршрут перестроен: исповедь лида о том, куда расти дальше (и всегда ли расти)

Для истории: блогу 13 лет (статистика)

2024-11-30T16:35:00.002+03:00

Наводил порядок в блоге (чистил умершие ссылки, картинки и тп), наткнулся на заметку про 5-летие блога.

Интересно было посмотреть на статистику спустя уже 13 лет.

Заходов из поисковых систем, других ресурсов и сайтов суммарно больше 160 тыс.

5 лет назад было 54тыс - практически линейно.

Как гугл насчитал без малого 800 тыс - скорее всего с ботам и прочими краулерами.

Самые популярные статьи (тут уже видимо просмотры с ботами).

В лидерах по популярности все те же 2 заметки про моки и ресурсы для тестировщиков (имхо далеко не самые интересные).

Mock vs Stub 83тыс (регулярно в топе выдачи по этому запросу в гугле, продолжительное время висела на 1 месте, не согласен с ее популярностью, но с названием угадал)
Полезные ресурсы для молодых (и не только) тестировщиков 61тыс - с апреля этого года снова стала посещаемой, видимо где-то на популярном ресурсе появилась, но по статистике не видно откуда.
Смешная история с "План "Б" или как прикольно провести субботний день" (30 тыс). Она была очень популярна в выдаче, видимо из-за удачного названия, потому что контент ни о чем. После смены названия - наконец-то ее перестали смотреть ))
Заметки на коленке - 3. Что еще делать, если ваши тесты уже "зеленые"? (12 тыс) - вот это порадовало, видать тоже куда-то залетела. Потому что название не seo-шное.
Тестирование в продакшене - миф или реальность? (8 тыс)
Автоматизация тестирования. С чего начинать, возможные проблемы. (7 тыс), старая статья перестали смотреть
Популярная психология в IT и не только (5 тыс)
Обычные и не очень вопросы к собеседованию на позицию Engineering Manager (5 тыс)
Как Google от менеджеров пытался отказаться (4 тыс)
Немного про наём, собеседование и испытательный срок от вашего КО (4 тыс)

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

Как меньше лажать с оценкой задач?

2024-04-23T22:53:00.001+03:00

Мое определение оценки:

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

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

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

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

2. Важно понимать, что ошибки оценки все равно будут. И поэтому должны быть:

• процесс работы над этими ошибками (расширяем базу знаний и подходы для следующих оценок) с тем, чтобы в следующий раз оценка была точнее

• процесс информирования о возникающих из-за ошибок рисках (не тянем до последнего)

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

4. Оценка в сторипойнтах - это в том числе способ избежать необходимости точной оценки: когда оценивается, например, в часах, сразу возникает ситуация, когда было запланировано например 3 часа, а задача сделана за 3.5. Это хорошая оценка или продолб? А 4 часа? А как это время измерялось и что в него входило?

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

6. БОльшая декомпозиция помогает точности оценки

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

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

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

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

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

Работу над оценкой задач на следующий спринт начинаем в текущем спринте.

Встреча 1 (30-45 мин):

• смотрим на ожидаемый список историй/задач (формирует PO исходя из целей спринта, но возможно участие команды, особенно по техническим задачам)

• определяем задачи, по которым недостаточно информации для их оценки (по остальным сразу делаем оценку)

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

Встреча 2 (30-45 мин), лучше через неделю после первой:

• каждый ответственный рассказывает про свою задачу

• информация обсуждается

• делаются итоговые оценки

• обсуждаются вновь прилетевшие (с момента встречи 1) задачи, которые хочется затащить в спринт. Если нужно, то по ним тоже запускается работа по их оценке

Встреча планирования спринта (15 мин**):

• если за время после 2й встречи ничего нового не прилетело, то в спринт просто берутся задачи согласно текущей “скорости прожевывания сторипойнтов” (ака velocity) и их приоритетов

• если что-то прилетело и оно важно, то это обсуждается уже на планировании. Но лучше бы конечно это все же сделать предварительно, иначе оценка будет скорее “пальцем в небо”.

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

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

** вторая по популярности тема "это ж нафига столько встреч?"

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

Почему такой процесс редко можно встретить в реале? :)

Да фиг его знает, я ставлю на "лень-матушка раньше нас родилась...". Всегда ведь проще погадать на планинге не делая предварительного исследования.

Подключайтесь к комментам в телеге

Про достижения в числах в резюме

2024-04-08T09:00:00.006+03:00

Копия поста в телеге (подключайтесь 🙂)

Навеяло постом в тви с советам для резюме для поиска работы за рубежом.

Я бы выбрал скорее выбрал 3 (и именно такое часто и вижу). Хотя и 4, и 5 тоже норм, но есть нюансы.

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

Но сначала небольшой экскурс в историю (ну, так принято в высших сферах).
*и да, еще раз, речь по отечественный 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

Про code review 9 лет спустя

2023-10-30T08:08:00.001+03:00

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

Почти никто не думает о реальных целях, форматах проведения, реальном ее влиянии на итоговое качество продукта и кода, скорость доведения фичи до прода, но все проводят. (Потом правда на каждом ретро обсуждают "почему у нас MR висят на ревью целыми днями")

Хотя на самом деле, в большинстве своем, у многих, она сейчас больше мешает, чем помогает.

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

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

Подстава в последовательности шагов ревью и квалификации команды. Остальное вторично.

Интуитивно: если мы делаем ревью чего-то, то мы предполагаем существование этого чего-то. То есть сначала пишем код, потом его анализируем. Потом, по комментам, код меняется и снова ревью. Кто-нибудь анализирует основные причины комментариев? Что заставляет сильно менять код? Как часто находятся проблемы? Могли бы эти проблемы найдены статическими анализаторами, линтерами и тестами (рядом с кодом)?

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

Что нельзя отловить анализаторами и тестами? Ошибки проектирования (хотя считается, что юнит-тесты как-то помогают). Значит добавляем промежуточный шаг, когда разработчик предлагает сделать ревью не готового кода в 100500 изменений, а драфта возможного решения: набросок кода, схемы предполагаемого взаимодействия (data flow, межкомпонентного и тдтп). Это смотрится, обсуждается, дальше реализация, а потом уже или быстрое ревью, или только автоматизация.

Вот кажется, это единственно разумный вид процесса code review. Все остальное - бесполезная трата времени.

Полезные ссылки:

• Stop doing code reviews and try these alternatives (там хороший анализ с примерами исследований и возможных альтернатив)

• И снова про code review или новая единица измерения качества (WTF/minute) (самопис в мою бытность ревьювера)

Резюме - что в слове том?

2023-10-23T09:17:00.002+03:00

Дисклеймер: знать, как правильно писать резюме, как быстро его читать и потом им пользоваться на собесе, не равно иметь правильное написанное свое резюме 🫠

Сейчас снова подключился к анализу резюме кандидатов и собесам (как ни странно, DevOps-в).

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

А что такое “уметь” писать резюме? Важный ли это навык? (присоединяйтесь к обсуждению в телеге)

Имхо, влияние качества резюме на итог поиска работы* сильно переоценено: в 80% случаев на собесе ты будешь его пересказывать и половина собеседующих его даже не прочитают. Важно пройти фильтр, тут помогут ключевые слова и, иногда, имена предыдущих компаний. Фсе.

*если речь про первую работу (джун), то не все так “просто”. Там придется потрудится сначала над тем, что ты сможешь описать (приобрести знания/умения), а потом, как это подать.

Тут вот статья "Resumes suck. Here's the data" (автор ее недавно подкорректировал, раньше она была жестче и категоричней) с описанием эксперимента по качеству отбора по резюме, которая предвещала чуть ли не “смерть” резюме еще 9 лет назад. Но они все еще живее всех живых.

И это логично - это самый популярный и простой способ себя проиндексировать, классифицировать и отобраться в качестве кандидата на собес (я знаю только 3 способа: резюме, личный бренд, “по блату”)

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

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

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

В итоге до него мало кто и доходит, если вспомнить с какой частотой сегодня IT-шники меняют работу, а значит все смотрящие застревают на перечислении компаний с одинаковыми задачами. Обычно я быстро пролистываю до конца и смотрю, есть ли там в “обо мне” что-то обобщенное о кандидате, его задачах и предпочтениях. Это то, от чего отталкиваюсь.

Дальше смотрим последние пару мест работы: выполняемые задачи и какими инструментами (речь не только про инженеров, у менеджера тоже есть свои инструменты, и это не Jira 😃). Про достижения мало кто пишет, но если есть, дополнительный “+” к вопросу приглашения. Из остального формируются будущие вопросы на собесе.

Частота смены работ: я старовер, считаю, что ничего толкового за срок меньше чем за год-полтора (зависит от роли, у кого-то и дольше) сделать нельзя: просто задачеклепатель. Если товарищ регулярно меняет работу чаще, то дополнительный “?”.

Что очень редко смотрю в резюме: образование. Обычно на него смотрю, когда специалист начального уровня, дальше уже все равно. Были случаи, когда уже после выхода на работу и пары месяцев работы, я узнавал, что у новенького нет высшего образования. Знаю менеджеров, которые, наоборот, уделяют этому разделу большое внимание и ищут там любимые ВУЗы, которые по их мнению отражают квалификацию кандидата. И если нет таких вузов, значит кандидат не годится.

В Питере раньше была фишка, выпускники “ФМЛ 239” (очень продвинутая, но школа) всегда его писали в резюме. Есть подозрение, что это такая метка для своих 😉 Потому что я чаще всего триггерился в обратную сторону.

Ссылки на дополнительные ресурсы соискателя (GitHub, блог и тп) тоже люблю смотреть. Нужны ли они в принципе в резюме? Если там есть что-то, чем вы гордитесь и лично вам нравится - пишите. Если в гитхабе, кроме пары тестовых больше ничего нет, а в блоге все заброшено 3 года назад, то бесполезная затея (лично меня раздражает).

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

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

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

Полезные ссылки:
Стрим про резюме и подготовку к интервью
В IT чудес не бывает (мой телеграмм-канал)

Про юнит-тесты и не только

2023-10-16T09:33:00.000+03:00

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

TLTR: “Бей вперед - игра придет” (просто начните, если еще нет, хоть с какими-то автотестами).

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

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

Но фишка в том, что подходов очень много.

Например, кто-то считает, что модульные тесты мешают (недавние рассуждения Кирилла Мокевнина), кто-то считает, что интеграционные (интегрированные?) тесты - фигня, а модульные тесты рулят (JB Rainsberger Integrated Tests Are A Scam HD).

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

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

Что он дает?

1. возможность запускать части кода без запуска всей системы, что обеспечивает:

• быструю обратную связь от вносимых изменений

• уверенность в вносимых изменениях

2. документация к коду

3. помощь в проектировании

Разберем коротенько по пунктам (заметки Капитана Очевидность, но я как-то не хочу их проскакивать)

1. Быстрый запуск кода - тут речь как про возможность “засунуть датчик” непосредственно в кишочки кода, так и про скорость выполнения самой проверки.

Когда у тебя есть возможность здесь и сейчас, без дополнительного окружения и ресурсов проверить, как выполняет свои задачи свеженаписанный код - это то, что нужно. К примеру, если функция по бинарному блобу определяет тип данных в нем, то не нужно проверять эту функцию запуская и дергая API сервиса, который где-то внутри себя использует эту функцию. Банальность и очевидность, но сплошь и рядом наблюдается (о причинах не сегодня). А если функция вызывается внутри десктоп приложения? Там с проверкой функции ”через приложение” вообще будет веселый аттракцион.

2. Документация. Есть интересная особенность памяти среднестатистического разработчика - она обнуляется по отношению к коду буквально через месяц (+/-). Некоторые только по истории гита определяют, что какое-то конкретное изменение кода было сделано именно ими. А уж про то, что именно код делает и для чего, так и подавно не помнят. Так вот тесты расположенные близко к коду (чаще всего те самые юнит-тесты), как раз помогают быстрее восстановить понимание предназначения кода и логики его работы. И да, конечно, это можно сделать и просто читая код. Но читая юнит-тесты, тем более хорошо написанные тесты с правильными названиями, сделать это намного быстрее. Тем более, что обычную документацию то редко кто пишет, а еще реже обновляет.

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

В этом месте можно было бы ввернуть про TDD (и я таки ввернул), но забавно, что сейчас это буквосочетание куда-то исчезло (только из моей инфоленты?). А то ли дело ра-а-аньше, трава зеленее, "TDD помогает" vs "TDD есть опиум для народа" и такие батлы в комментариях (тут тоже есть, если вы любитель попкорна).

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

Если юнит-тесты написаны канонично, то с вероятностью 99% их надо выкинуть (=сильно переписать) при изменении того кода, который они проверяют. И именно от последнего всех и бомбит.

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

Обратимся к классику (Мартин Фаулер) :

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

Хмм, получается, что нет строгого определения, что считать юнитом?

Да, но есть нюансы.

Вы знали, что существует 2 школы ~~боевого кунг-фу~~ юнит-тестов?

Лондонская и Детройтская (она же Чикагская).

Что самое забавное, когда говорят про недостатки юнит-тестов, то чаще всего указывают на проблемы, которые возникают при лондонском подходе.

Чем же они отличаются?

Одно из отличий - это как раз определение размеров юнита.

Лондонская школа определяет юнит, как класс/функцию и предполагает изоляцию SUT (system under test) от всего того, с чем он взаимодействует через test doubles (тест-дублеры, на старославянском - моки, что неправильно, но все привыкли). То есть, мы проверяем строго то, как работает SUT ориентируясь на его публичный интерфейс и поведение нужное нам для реализации пользовательского сценария. А все его внешние зависимости замокированы. Это как раз и приводит к тому самому “цементированию” кода тестами, затрудняющего его модификацию.

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

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

Но на моей практике, при сильном желании и достаточном умении, накостылить лишнего кода можно при любом подходе.

Мне больше импонирует детройтский подход, в первую очередь из-за низкой связности тестов с кодом (в сравнении с лондонским вариантом).

Итого: если отбросить в сторону #holywar со школами, то юнитом можно считать минимальное логическое объединение кода ориентированного на реализацию конкретной функциональности, которое мы хотим и можем проверить отдельно от других таких объединений.

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

Заканчиваем.

Вредные советы:

• пишите юнит-тесты на чужой код после того, как код написан, просто для покрытия (мероприятие искажающее ценность таких тестов)

• не пишите юнит-тесты на чужой код (если тестов нет) перед тем, как меняешь код (зависит от объема изменений, возможно нужно писать другого уровня тесты)

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

• продолжайте игнорировать книги по юнит-тестам и тестированию вообще

• открывайте вакансию “Unit Test Writer” (клянусь - реальность, погуглите, я рыдал, особенно над требованиями)

Полезные советы:

• почитать про мутационное тестирование

• всегда думать, какие тесты для чего лучше* подходят

• всегда думать (всех обнимаю)

*Критерии “лучшести”: скорость написания, скорость обратной связи (запуск, скорость выполнения и диагностика проблем)

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

Поэтому сильно плюсую к этому автору:

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

И тестконтейнерс - один из способов перетащить часть тестов из второй категории в первую.”

Ну и уже от меня, само по себе разделение на “слои” провоцирует на разделение зон ответственности и появление вопроса “кто пишет”: типа разрабы это только юнит-тесты, а e2e - автоматизаторы. Еще один из примеров закона Конвея.

Полезные ссылки:

• Are You Chicago Or London When It Comes To TDD?

• London vs Chicago

• London and Detroit schools of unit tests (похоже недоступно из РФ, есть копия из кэша)

• Литература по тестированию (с акцентом на разработку).

• Если кому-то нужно про юнит-тесты на C++ (ну вдруг), то вот эта норм, я ее в свое время даже переводить собирался, так понравилась.

Не забывайте, ради чего все тесты пишутся

Мой канал в телеграмме, тоже без чудес

2023-09-15T08:08:00.001+03:00

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

Тематика та же самая, Подключайтесь.

Из мариновавшегося годами тут, но уже появившееся в телеге:

Team- vs TechLead

Ошибки приводящие к проблемам в IT

Про календари менеджера и инженера

Legacy code and tests

2023-09-04T13:30:00.000+03:00

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

Я теперь даже не уверен, какие именно мысли мои :) Но там все по делу.

Ну и самое главное про легаси:

1. это про то, что нужно (иначе бы выкинули)

2. это то, что с вами всегда* **

*если вы не меняете работу каждые полгода после написания нового кода

**но уровень боли от легаси можно уменьшить - статья как раз про это

Заметки на коленке - 3. Что еще делать, если ваши тесты уже "зеленые"?

2023-04-07T14:49:00.011+03:00

"Lately I find I'm working on automated tests that return non-binary results. Tests that neither pass nor fail" by @noahsussman

Отличная мысль, которую я ретвитил еще в 2016. Но давайте вместе подумаем, что за этим может скрываться? (кстати, не знаю, что при этом думал Noah)

Ваши тесты прошли и прошли "успешно". Все хорошо или все же есть, куда еще посмотреть?

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

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

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

3. Контроль за занимаемыми SUT (system under test) ресурсами во время выполнения тестов:
• оперативка = утечки
• место на диске = резкий рост размера БД, большие логи, "забытые" временные файлы
• другие технические метрики

4. Тесты запускаемые всегда в одном и том же порядке могут работать успешно только "благодаря" этому порядку. И не работать, если просто начать их запускать в условно произвольном порядке*. "Война тестов" помогает найти проблемы в продакшене.
*с учетом настроек SUT и окружения.

5. Если у вас в SUT есть, например, http-запросы между клиентом и сервером, то встройте между ними, например, OWASP Zed Attack Proxy. Получите возможность дополнительной секьюрити проверки вашего API (как в пассивном, так и активном режиме)

6. Тест который сегодня "зеленый", а вчера был "красный" и никто его вчера не чинил, скорее всего предвестник "веселой" регулярной активности "а давайте его перезапустим". Подробнее про flaky tests

7. Если ваши тесты "вечнозеленые", проверьте не видите ли вы результаты одного и того же запуска, а тесты на самом деле не запускаются 🤣

Ну и подумайте, а стоит ли их запускать вообще. А может просто запускать реже.

Какие еще пункты можно добавить?

А тесты прошли успешно...

Все заметки этой серии.

О чем подумать при разделении команды

2022-12-23T17:21:00.005+03:00

Митоз ~~клетки~~ команды

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

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

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

- команда формируется на базе какого-то человека из "старой" команды.

- N новых команд получаются в результате разделения "старой".

Мне, чаще всего, приходилось заниматься третьим вариантом, поэтому ниже немного вопросов/тезисов, про которые надо подумать при разделении команд:

Если делиться, то как? Это все влияет на новые процессы работы и их формат

- функционально (у каждой команды свой кусок функциональности, свой бэклог и код).

- кроссфункционально (беклог остается общим, команды работают над одной кодовой базой).

Как делить людей (кого в какую команду)?

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

Код, скорее всего, сейчас общий, что дальше?

- остаемся в одном репозитории: кто в итоге "владелец кода" и какие правила работы с ним?

- если репу/репы нужно таки разделять репу/репы, то как, сколько может занять?

Тот же вопрос по тест-кейсы и прочие артефакты разработки.

Что с каналами коммуникаций?

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

Кто ответственен за внешние запросы в команду/команды и обработку мониторинговых алертов, если разделение кода/сервисов не произошло?

Какая из команд, в каком порядке, за что именно отвечает?

К чему нужно быть готовым?

- шторминг команд. Даже если люди давно работали в одной старой команде, есть большая вероятность, что новую все равно поштормит.

- персональная неудовлетворенность некоторых членов команд.

Советы от КО:

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

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

- Посмотреть Why Your Software Team CAN’T Scale.

- Учесть, что уже есть применяемые многими процессы для организации совместной работы команд (Nexus, LeSS). Возможно не нужно придумывать свои "велосипеды".

- в комментах в тви подкинули интересную концепцию по этой теме: "Dynamic Reteaming". По описанию очень укладывается в обсуждаемый тут вопрос.

Как это - работать с коллегами возраста твоих детей?

2022-12-02T11:29:00.000+03:00

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

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

Где-то плюс/минус несколько дней в это время 20 лет назад (тред писался в феврале 2021) заканчивалась моя военная служба и я уже официально (а не в самоволку, как было несколько месяцев до этого) ходил писать новые компоненты для Delphi-библиотек. С тех пор много чего (все?) поменялось в IT-отрасли, но речь сегодня пойдет не про технику.

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

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

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

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

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

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

Кстати, про сомнения. Самое сложное, что лично мне приходится постоянно контролировать в себе, это не выдавать сомнения в лоб. Часто это воспринимают, как негатив. Особенно, если у тебя нет никаких других аргументов, кроме как "мы так пробовали, тогда не сработало". Вроде неконструктивно.

Иногда, когда прошлый опыт сильно отдается в заднице, начинаешь спорить. И тут уже забываешь про конструктивные аргументы и здравствуй, "токсик-дед".
ЗЫ интересно, как часто меня так называют? :)

-----

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

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

Лирическое отступление: "юность" сейчас для меня это, простите, до 30 точно, иногда и позже продолжается.

Я часто пишу "опыт", а начинал ведь про "возраст". Как это между собой коррелирует? Теоретически богатый опыт можно получить в условиях "год за два", по ускоренной программе. Но жизненный опыт, скорее мудрость, приходит именно с возрастом, когда у тебя что-то меняется в мозгах. ХЗ что именно, надо порефлексировать.

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

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

----

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

Еще одна штука про возраст и опыт. Ожидания от тебя. Ведь ты так долго работаешь, много знаешь (наверное), ты просто должен взять и просто уххх, как хорошо все сделать. А если ты так не делаешь, то...

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

А может такая картинка ожиданий только у тебя в голове. И то, что тебе говорят коллеги, это просто уважительное отношение, простите, к возрасту :)

Встречи 1:1

2022-11-17T13:13:00.008+03:00

На базе треда в тви.

Признаться, я давно не провожу "каноничные" 1:1.

В 1-ю очередь из-за того, что "каноничность" предполагает регулярность. Практика скорее полезная, но эффективность зависит от многих факторов. Например, количества тех, с кем надо проводить, процессов в командах и твоем в них участии.

А я не люблю делать то, что просто "общепринято", но пользы не несет или ее меньше, чем затрат хотя бы времени.

Ну или просто терпения не хватает дождаться реальной пользы.

Чаще получаются не классические 1:1, а встречи по онбордингу новичков, обсуждению планов развития, беседы с ребятами, которые сами приходят с запросом. Моя "дверь" для такого всегда открыта и я всем постоянно и везде про это напоминаю.

Тем не менее, всегда полезно иметь списочек вопросов, которые можно обсудить:

1. Вопросы для первой встречи

2. Хорошая замена традиционного вопроса "How's everything going?" -> "What's one thing that could be better?"

3. Что делать, если 1:1 начинается с "мне нечего рассказать" или "с моей стороны ничего нового"

4. Мысли Виталия Шароватова (его тви) про рационализацию регулярных 1-1 (кстати у него много полезной инфы для лидов)

5. вишенка 🍒 для тех, кому хочется новых вопросов - 132 One on One Meeting Questions Great Managers Use to Create High Performing Teams

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

Развитие в IT: начало, менеджерская развилка, повседневность (беседа на HeisenbugConf)

2022-10-20T17:28:00.000+03:00

Про то, что менеджмент - это не единственный путь развития :)

Заметки на коленке - 2. Книжки про тестирование для разрабов

2022-10-18T10:18:00.005+03:00

Есть тред в твиттере, но пусть тут для удобства тоже будет.

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

Вводная по "разработческому" тестированию
Про тестирование обзорно для разработчика

Developer Testing

The Art of Unit Testing (лучшая, на мой взгляд, книга по юнит-тестам)
С примерами на С#
С примерами на JS
Применимо и к другим языкам

Паттерны для хороших тестов (практически любых)
xUnit Test Patterns: Refactoring Test Code (есть книга)

То, что мало кто из тестировщиков читал:
Теория тестирования
Lessons Learned in Software Testing: A Context-Driven Approach

Букварь по тест-дизайну
A Practitioner's Guide to Software Test Design

Гибрид двух предыдущих
Software Testing and Analysis: Process, Principles and Techniques: Process, Principles, and Techniques

Еще один гибрид
The Art of Software Testing

Факультативно:

Теория автоматизации, термины, практики (без упора в стек, можно просто пролистать)
Automated Testing Handbook

Философия автоматизации
The "A" Word
Мои пару слов про нее

"Achieving Software Quality With Testing Coverage Measures"
Для желающих почитать немного "теорию" покрытия тестами. Просто можно погуглить по названию, там небольшая статья

И немного "философии" и истории от меня. Практически моя "инженерная лебединая песня" :)

"Автоматизация тестирования - это пот, кровь и слезы"

Все заметки этой серии.

Заметки на коленке: про тестирование (базисы для разрабов)

2022-08-26T13:10:00.008+03:00

Лет 5 назад наваял на коленке для рассказа разработчикам про тестирование в команде без тестировщиков.

Что такое качество?
С точки зрения пользователя:
Качество — это пригодность к использованию. Делает ли данный продукт то, в чем я нуждаюсь, облегчает ли он мою работу, могу ли я его использовать так, как мне удобно.

С точки зрения разработчика:
Качество — это соответствие специфицированным и собранным требованиям. Делает ли данный продукт все то, что указано в требованиях.

Характеристики качества программного продукта:

Функциональность
Производительность
Стабильность
Удобство использования
Безопасность

Но, есть еще, например, качество программного кода:

Понятность
Изменяемость
Тестируемость
Поддерживаемость

Поэтому всегда учитывайте, что "качество" - это многовекторная штука.

Checking|Testing / QC / QA

В каждой еще и статье набор ссылок напочитать.

Что такое тестирование:

Тестирование - сервис по предоставлению информации о качестве продукта
Тестирование - поиск ошибок

Причины ошибок:

сделали, но ошибка в коде (или настройках среды и тд)
сделали, но не то, что ожидалось
даже не делали, так как этот сценарий не предусмотрели
ошибка во “внешнем” коде (open-source)

Полезно разбирать причину возникновения, позволяет не наступать на них снова.

Как предотвратить и не повторить?
Вопросы:

как мы проверим, что мы это сделали
какие сценарии надо проверить и в каких условиях

Верификация (сделали то, что планировали|хотели) vs Валидация (сделали то, что нужно | это решает проблему)

Пирамиды тестирования:
тут про пирамидки и вообще вопрос автоматизации

UI-тесты:

Тесты основной функциональности “через UI” (такое нужно минимизировать)
Тесты бизнес-логики в UI
Визуальное тестирование

Техники тест-дизайна
http://www.protesting.ru/testing/testdesign_technics.html

Эквивалентное Разделение
Анализ Граничных Значений
Причина / Следствие
Предугадывание ошибки
Исчерпывающее тестирование
PairWise

Простота и понятность тест-дизайна

Тест-стратегия

Тесты в проде
Мое мнение по тестам в проде

Следуюшие заметки:

Книги по тестированию для разработчиков
Что делать, если ваши тесты уже "зеленые"?

Зайти в IT, подумать и не выйти

2022-04-28T11:24:00.009+03:00

Часто мимо пролетают вопросы "как начать с IT с нулевого уровня", "как понять, что IT мое".
Отвечая, собрал набор ссылок.

Кого я обманываю, просто собирал, потому что люблю собирать полезные штуки. Но некоторым действительно уже помогло :)

Ссылки с упором на backend-разработку с нуля. По тестированию ищите тут

Начало

Введение в программирование
Жизнь программиста
Введение в Git

Основы командной строки

Как решать задачу, если непонятно с чего начать (Хекслет)

Планы развития

Developer Roadmaps (тут не только бек, там много)

Oh My BackEnd

------

Основы Python (там еще и Java есть)

Python: Основы программирования

------

Неплохой ресурс про IT, но уже на английском

freeCodeCamp (https://www.youtube.com/freecodecamp)

------

Алгоритмы и структуры данных (английский)

Algorithms Specialization

Data Structures and Algorithms Specialization

Аналоги на русском

Алгоритмы: теория и практика. Методы

Алгоритмы: теория и практика. Структуры данных

Разбор задач LeetCode и вопросов по алгоритмам

------

Про ОС

Операционные системы (Stepik)

------

Про резюме, собесы и тп

Стрим с рекомендациями

Простой алгоритм:

просим кандидата рассказать про текущие задачи/проекты/команду
внимательно слушаем, записываем полезные для дальнейших вопросов штуки

Что может быть полезными штуками (примеры):

использование им “терминов” ("отвечаю за качество", "я - devops инженер", "настраиваю CI/CD" и тп)
части рабочего процесса ("описываю все в документации", "менторю новичков", "помогаю команде")
рассказ о элементах взаимодействия, поставки задач ("сам себе пишу баги, чтобы не забыть", "задачи на описывание кейсов использования")

Дальше по этим записям задаем вопрос начиная с "а вот ты упоминал про...", "как ты это делал (для процессов)" или "что такое..., как ты это понимаешь?" (для терминов)

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

Пример:

Как менторишь? (лучше через пример в виде "Расскажи, как ты помог коллеге вырасти профессионально.")
Как пишешь документацию, если времени не хватает
Как помогаешь команде
Что такое DevOps для тебя?
и тп

Этот способ еще хорош и тем, что во-первых все вопросы открытые, а во-вторых показывают, что вы внимательно слушаете его рассказ

Если сам человек плохо про себя рассказывает (такое тоже часто происходит), то вопросы выше все равно хорошо подходят "менторили ли коллег? как?"

Еще хорошо получаются вопросы о важности человека в команде/bus-factor:

Не боишься ли ты уходить в отпуск? Часто ли тебя дергают там?
Как принимаются решения в команде, какая твоя роль? Какое из последних решений ты предложил? Все ли были согласны с решением? Какие аргументы ты приводил для обоснования решения?

Попробуйте задать вопрос на основе ваших текущих задач.

Примеры для девопса:

было ли у вас разное окружение для тестирования? Как вы его делали? Как используется?
Мониторинги, алерт - как?
Если сам не делал, то “Как бы делали, с чего бы начали”

Если есть какие-то моменты, которые вам очень важны для дальнейшей работы (тут лучше самим определиться какие), то на это обязательно должны быть вопросы.

По развитию:

как ты понимаешь, что вырос профессионально?
что из того последнего, что узнал нового, удалось применить?

Есть еще такой список вопросов от одной команд, с которыми работаю:

Как привык работать? Как хочется работать? — процессы/команда/коммуникации
Как приходят задачи? А как хочется и почему?
Что ты делаешь когда не можешь решить задачу?
Как решаешь конфликты или спорные моменты в команде? Можно зайти через код-ревью или принятие решений, если кандидат говорит, что нет конфликтов.
Как ты видишь работу в команде? С какими людьми тяжело работать?
Что нравится/хочется/интересно делать? Почему?
Что точно не хочется делать/видеть? Что было бы стоп фактором для выхода на работу?
Есть ли планы по развитию? Как ты изучаешь новое? Что последнее изучил? Как это применил?

Маленькая хитрость: надо научиться встраивать интересующие вопросы в канву диалога, чтобы не было ощущения видеоанкеты, особенно на онлайн-интервью.

Еще полезные ссылки на тему интервью.
Рекомендую также "Брать или не брать? или Как собеседовать разработчика"
Неплохая презентация про soft-skills и то, какими вопросами их оценить и запись этого доклада

Flaky тесты (они же моргающие или "случайно успешные")

2021-04-29T17:48:00.004+03:00

Недавно поучаствовал в Heisenbug Piter 2021 в роли эксперта на очередной серии доклада Андрея Солнцева про flaky тесты.

Люблю эту тему. Кажется, это своего рода "дебаг", только для тестов. Иногда расследование похлеще приключений Шерлока.

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

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

Итак, что делать, чтобы "моргающих" тестов было меньше:

тесты должны быть написаны в правильном слое "той самой пирамиды": чем ближе слой к модульным тестам (а лучше именно в них), тем меньше шансов на моргания, потому что зависимостей меньше.
в ту же тему: чем меньше UI-тестов, тем лучше. Открывая в очередной раз файл с UI-тестами, помни, что тестировать надо "UI", а не "через UI".
основные причины "моргания" это асинхронные операции (async wait), многопоточность (concurrency), порядок тестов, утечка ресурсов, проблемы с зависимостями (сеть, время). Поэтому, чем меньше этого в тестах, тем они стабильнее.
основной объем бизнес-логики проверяем максимально близко к месту логики (см.пункт про слои) и с максимальным количеством замокированных зависимостей (но не переусердствуйте, а то будут другие проблемы)

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

Что делать, если они появились?

разбирайтесь с проблемой падения максимально быстро. Не надо держать в наборе запускаемых тестов тот, доверия к результатам которого нет.
если сейчас нет возможности разобраться с ошибкой, переместите этот тест в "карантин", чтобы позже с ним разобраться. Не надо держать в наборе запускаемых тестов тот, доверия к результатам которого нет - 2.
если вы тестировщик, смотрите код тестируемого приложения. Часто проблемы с "морганиям" проще понять и поправить именно там. По статистике (2014 год) до 25% исправлений моргающих тестов делается в продакшен коде приложения.
привлекайте разработчиков, если сами не можете разобраться в коде.
активно используйте трейсинг (логирование) в тестах и продакшен-коде для того, чтобы воспользоваться ими при расследовании. Совет: здорово, если у вас есть возможность "объединить" логи тестируемой системы с логами тестов. Мы активно использовали запись меток о начале/завершении теста в продакшен логах приложения. Очень помогало.
для UI-тестов (помните про "через UI"?) имейте возможность включить запись видео или скриншоты в момент проверки
попробуйте переместить моргающую проверку на другой слой пирамидки
если тест не поддается и продолжает моргать, подумайте, может стоит его удалить? Все равно смысла от него немного, особенно если думать про него не "случайно упавший", а "случайно успешный". Ну и в целом "Flaky tests are worse than _no_ tests".
иногда советуют перезапускать упавшие тесты в надежде на удачу. В целом рабочий способ, но не надо им злоупотреблять. Он хорошо помогает с подтверждением проблемы и поиском test war. Но обнаруженные проблемы, например, с медленной инфраструктурой/сетью, особенностями фреймворков важно всегда фиксировать и планировать время на исправление.

Полезные ссылки:

Про перезапуск тестов
Про моргающие тесты в Gmail
An Empirical Analysis of Flaky Tests
No more flaky tests
Eradicating Non-Determinism in Tests
Один из вариантов работающего подхода по исправлению "моргающих" тестов
How do you test your tests? (probabilistic flakiness score)

Через призму менеджера про "Никаких правил. Уникальная культура Netflix."

2021-02-22T15:02:00.005+03:00

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

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

После прочтения статьи с Хабра первой мыслью, которая меня посетила была "а ведь вся эта история держится только на хороших менеджерах (лидерах?)".

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

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

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

В своей работе всегда старался быть максимально честным. Всегда думал, что это, эммм, мой недостаток, как менеджера. В книге есть тесты на открытость. Все мои ответы совпали с мнением основателя Netflix. Значит не все так плохо. Плохо то, что сложно быть честным и открытым там, где остальные к этому не готовы. Не готовы слушать/слышать правду, могут одним говорить то, что не готовы высказать всем. Приходится постоянно держать в голове эти моменты и фильтровать свои посылы.

Немного интересных фактов из книги и то, как это "стрельнуло" у меня.

Про пересмотр ЗП

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

"В 2018 году средняя прибавка зарплаты в США составила около 3% (для особо ценных сотрудников — 5%). Те же, кто решил сменить место работы, в среднем стали получать на 10–20% больше. Верность работодателю плохо сказывается на состоянии финансов."

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

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

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

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

Немного про критику и откровенность

"Слышать критические замечания в свой адрес неприятно и некомфортно, но, после того как отпустит изначальный стресс, они идут на пользу". "Мало кому нравится критика в свой адрес. Когда ругают нашу работу, нас накрывает чувство собственной никчемности."

Несмотря на то, что в Netflix декларируется отсутствие правил, на самом деле правила есть, есть инструкции, где прописано, что такое эффективная и конструктивная критика.

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

Четыре правила откровенности/критики (в этом месте ничего необычного, это то, что всегда называют конструктивной критикой)

Для критика

1. Стремись помочь.

2. Предлагай конкретные меры.

3. Чтобы получить нужный результат, адаптируй формулировки и учитывай культурный контекст (здесь речь про национальные культурные особенности).

Для адресата

4. Будь благодарен.

5. Прими или отклони.

"В Netflix вы получите множество замечаний и соображений. Их необходимо внимательно выслушать, обдумать сказанное, принять к сведению. Но вы не обязаны принимать их все как руководство к действию. Вежливо и искренне поблагодарите критика. Но и вы, и он должны понимать: следовать его советам или нет — ваше и только ваше решение."

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

Свободные отпуска

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

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

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

"Если я задумаюсь о смене работы, вы будете меня удерживать?"

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

Стоит ли руководителю открыто говорить про свои ошибки?

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

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

"Эта тенденция восприятия так и называется: эффект оплошности. Психологи отметили, что привлекательность человека в наших глазах может либо вырасти, либо понизиться после допущенной им ошибки — в зависимости от того, как этот человек зарекомендовал себя в целом."

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

Интересно было бы узнать, как в Netflix занимаются развитием менеджеров. Есть ли там что-то типа активностей у Google?

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

"The Ongoing Revolution in Software Testing" by Cem Kaner (2004) - разбор общепринятых утверждений о тестировании/тестировщиках

2020-08-10T20:07:00.003+03:00

Благодаря давнишнему твиту Alan Page узнал про чудесную статью Cem Kaner, который еще в 2004 году разобрал популярные утверждения (мифы?) про тестирование и роль тестировщиков.

Что именно так разбирается:

The Role of Testers

• The primary reason to test is to find bugs?

• The primary reason to test is to prove the program works correctly?

• Testers are THE advocates of quality on a project.

• Test groups should evolve into quality assurance groups.

• The test group should have the power to block release if product quality is too low.

• Testers and programmers have conflicting interests.

• The test group should work independently of the programmers.

• Testers should push their project teams to follow "appropriately professional

development models," like the Waterfall, that require people to THINK before they act.

• Testers should base test cases on documented characteristics of the program. If the software documentation is inadequate for this, testers should assert a quality control function and demand better specification and requirements documentation.

• The primary reason to test is to find bugs.

• The primary reason to test is to prove the program works correctly.

Test Planning and Documentation

• Testers should specify the expected result of every test, in advance.

• Exploratory testing, if done at all, should be done only by experts.

• There should be at least one thoroughly documented test for every requirement item or

specification item.

• Testers should design most or all tests early in development.

• Testers should design all tests for reuse as regression tests.

• Testers should document manual tests in great procedural detail so that they can be

handed down to less experienced or less skilled testers.

• Testers should document each test case individually, ideally storing them in a test case

management system that describes the preconditions, procedural details, postconditions,

and basis (such as trace to requirements) of each individual test.

The Practice of Testing

• Testers should assume that the programmers did a light job of testing and so should

extensively cover the basics (such as boundary cases for every field).

• Testers should develop automated tests at the user interface level.

• Testers should design tests without knowledge of the underlying code.

• Testers should design the build verification tests, even the ones to be run by

programmers.

• Most testers don't need to be programmers, because they only have to specify how the

external program will behave in their tests. Testing tools will allow business experts to

develop automated tests without having to program.

• The pool of tests should cover every line and branch in the program, or perhaps every

basis path.

• All failures must be reported into a bug tracking system and carefully counted.

• We can measure the individual effectiveness of software testers by counting how many

bugs they find, perhaps with an adjustment for bug severity.

• We can tell how close we are to release of the product by examining the bug curve that

shows bug finds per week.

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

QA - точно про assurance?

Попробуйте ответить на эти вопросы и еще раз подумать действительно ли вы сейчас QA-инженер?

• Do testers have the authority and cash to provide training for programmers who need it?

• Do testers have the authority to settle customer complaints? Or to drive the handling of

customer complaints?

• Do testers have the ability and authority to fix bugs?

• Do testers have the ability and authority to either write or rewrite the user manuals?

• Do testers have the ability to study customer needs and design the product accordingly?

"Каждый тест должен иметь ожидаемый результат"

One fundamental problem with this idea is that it is misguided. Every test has many results. No one specifies them all. An "expected result" points the tester at one or a few of these results, but away from the others.

Обычные и не очень вопросы к собеседованию на позицию Engineering Manager

2020-08-05T09:00:00.038+03:00

Навеяно тредом под вопросом Charity Majors, своими собеседованиями и собеседованиями меня :)

Может кто найдет что-нибудь интересного себе. Кстати, многие из этих вопросов можно задавать нанимающему менеджеру.

Disclaimer:

Порядка, приоритета в вопросах ниже нет.
Необходимость и момент их вопрошания зависит от течения беседы.
На полноту и ценность для вас список определенно не претендует.

Этот список не значит, что на собеседовании со мной вы услышите именно эти вопросы.

1. Что мотивирует людей вообще (немного теории, а-ля Маслоу, Герцберг, RAMP и тдтп в том числе просто "своими словами"). Что мотивирует вас? Ну и дальше про то, как использовалось в работе. Как работали с так называемыми "underperformance" товарищами?

2. Лидерство vs "быть начальником" - что это для вас? Как вы определяете лидерство?

3. Карьерный рост для разработчиков в ваших командах. Как они растут? Что для вас этот рост, что вы думаете о грейдах (уровнях)? Какой процесс оценки уровня разработчика? Опишите последний случай, когда вы повлияли на карьерный рост вашего сотрудника.

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

5. Что такое техническое качество? Что такое качество? Как вы его оцениваете? Какие метрики используете?

6. Как принимаются технические решения в вашей команде (командах)?

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

8. Как было устроено планирование, как вы работаете с приоритезацией?

9. Как учиться на ошибках?

10. Самая большая ваша ошибка, как менеджера. Чему вы из нее научились?

11. Как вы понимаете, как обстоят дела в команде (то что называют "healthy state"), насколько она продуктивна, есть ли развитие?

12. На сколько вы умножаете ответ разработчика в вопросе оценки сроков? (кстати, а вы знаете про формулу Бобука?)

13. Опишите ваш обычный рабочий день.

14. Почему вы не хотите быть менеджером?

15. С какими конфликтными ситуациями вам приходилось сталкиваться и как вы их решали?

16. Какой у вас формат встречи 1:1?

17. Как вы поймете, что ваша работа выполняется хорошо?

18. Как вы взаимодействовали с другими менеджерами на одном с вами уровне?

19. Как был организован обмен знаниями между разработчиками?

20. За что бы вы сразу уволили сотрудника? Приходилось ли увольнять и почему?

Еще немного ссылок:

Hiring Engineering Leaders
Hire a VP of Engineering
How to interview a VP of Engineering
Questions for Prospective Managers
Немного про наём, собеседование и испытательный срок от вашего КО (меня)
Тут можно почитать немного про ресурсы, которые могут помочь вам в работе (или на собесе)

Тимлид - таинственная роль в реальном мире или фантастические твари среди нас

2020-07-27T20:19:00.037+03:00

Черновик с набором ссылочек долго мариновался и вот дождался потребности в себе.

Пусть теперь лежит публично.

История началась год назад (твою ж дивизию, вот я торопыга...) с обсуждения в комментах того, что это за роль/должность такая "тимлид". Пересказывать обсуждение тут смысла не вижу, кому интересно - велком в тред.

Спустя год тема получила свое продолжение в твиттере Никиты Макарова

лайкни оригинальный твит

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

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

лайкни оригинальный твит

Ну, если не передумали, то начнем.

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

Камиль Фурнье (Camille Fournier) “От разработчика до руководителя” (оригинал)

Из недостатков книги: кажется в "СНГ" IT-мире, все же есть отличие в понимании роли от условно-западного мира.

Но медленно все смещается в правильную сторону, а именно:

"Team leader: A team member who may not have any authority over other members but is appointed on permanent or rotating basis to represent the team to the next higher reporting level, make decisions in the absence of a consensus, resolve conflict between team members, and coordinate team efforts." (ссылка на определение).

Ну, то есть вроде действительно не менеджер, а личинка. Чтобы превратится в менеджера, нужно потрудиться над собой. А может в процессе и выяснится, что это вам не интересно.

Что почитать еще (литературы для менеджеров вагон и еще 10к вагонов, поэтому тут просто то, что нравится мне):

“Become an Effective Software Engineering Manager” James Stanier (у автора еще и интересный блог)
"Драйв. Что на самом деле нас мотивирует" Дэниел Пинк
"Руководство Джоэла Спольски по подбору программистов и управлению ими" Джоэл Х. Спольски
"Эффективный руководитель" Питер Друкер
"Одноминутный менеджер и обезьяны" Кеннет Бланшар
"Брать или не брать? Как собеседовать разработчиков"
"Черная книга менеджера" Вячеслав Панкратов (мозговстрях)

Статьи (в том числе пару моих, с ревью книг):

“Engineering management: the pendulum or the ladder”
“How Can I Prepare to Eventually Move into Engineering Management?”
“Advice for New Managers”
“Отзыв-конспект "Общаться с ребенком. Как?"
“The Definition of a Tech Lead”
“Tech Lead – Circles of Responsibility”
“5 Engineering Manager Archetypes”
“Напрасные слова. Как давать обратную связь с учетом работы мозга”
“Обзор-неконспект "Идеальная IT-компания. Как из гиков создать команду программистов”
“Мотивация, делегирование и автоматизация: рецепт создания суперкоманды“ (текстовка очень полезного доклада) и материалы от докладчика:

Та самая "карта компетенций тимлида", с которой все началось. Отлично подойдет для начальной систематизации того, чем возможно придется заниматься, в зависимости от понимания роли в компании.

Интересная шпаргалка "Модель зрелости техлида".

Неожиданная ссылка, особенно с учетом того, что тимлидов предпочитают выращивать внутри компании, доклад про шаги человека пришедшего в команду снаружи.

Ну и нельзя не посоветовать доклады Жени Кота:

Еще один хороший доклад для начинающих и сомневающихся

Почему не надо становиться руководителем, Андрей Смирнов

Получилось очень лаконично, точно несистематизированно и разношерстно.

Но, если у кого будут вопросы по конкретике - пишите (twitter, telegram), с удовольствием пообщаюсь.

Update: рекомендации от Славы Панкратова (одного из учредителей онлайн-школы менеджмента Стратоплан)

• Ицхак Адизес: Идеальный руководитель. Почему им нельзя стать и что из этого следует
• Михаил Литвак: Командовать или подчиняться? Психология управления
• Эрик Берн: Лидер и группа
PS вообще у дяди Славы уже 2ю неделю полезные м минутные зарисовки про менеджмент https://t.co/oYAtlygdqG
— Maxim Shulga (@maxbeard12) August 24, 2020

И вишенка на торте про вопрос, готовы вы или нет стать менеджером

Somehow, in our heads, we have this illusion that once you’ve mastered the technical skills required for your roles and you have been senior engineers for a few years, the next step for you is to become an engineering manager.#engineeringmanager #management pic.twitter.com/2fY9XIj0zL
— Isabel Nyo (@eisabai) June 15, 2021

И закончим все цитатой из уже мертвого твитт-аккаунта
"Тимлидам непросто: требуется строить отношения с коллективом, постоянно учиться, терпеть относительно невысокую зп. Есть только одно чувство, которое способно скрепить всё это вместе и помочь работать эффективно: искренне полюбить свою работу. Ты должен стать солнцем для всех." (с)@backendsecret

Короткой строкой: новости про Heisenbug с промо и полезные ссылки

2020-02-13T12:48:00.005+03:00

Глянул, что уже есть в программе Heisenbug Piter 2020: так как я сейчас не в ПК, то интересно, что там у ребят с программой получается. И я вам скажу, что интересно получается :)

Во-первых там есть доклад Адама Торнхила, одного из авторов инструмента CodeScene, которого я рекомендовал пригласить. Очень хочется послушать про жизнь кода.

Во-вторых в программе Иван Крутов, один из авторов Aerokube. Еще Аня Чернышова про возможное решение проблемы падучих UI-тестов.

Что бы я еще посмотрел:

Effective unit testing
Тестирование производительности клиентской части React/Redux-приложения с использованием Enzyme
Demystifying Cross Browser testing (от бывшего автора Puppeteer)

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

Еще интересных вам ссылок, местами философских, но про тестирование:

Чудес не бывает или я ошибаюсь?

Про рост в лидов и то, что "даунгрейд" обратно - это не даугрейд

Для истории: блогу 13 лет (статистика)

Как меньше лажать с оценкой задач?

Про достижения в числах в резюме

Про code review 9 лет спустя

Резюме - что в слове том?

Про юнит-тесты и не только

Мой канал в телеграмме, тоже без чудес

Legacy code and tests

Заметки на коленке - 3. Что еще делать, если ваши тесты уже "зеленые"?

О чем подумать при разделении команды

Как это - работать с коллегами возраста твоих детей?

Встречи 1:1

Развитие в IT: начало, менеджерская развилка, повседневность (беседа на HeisenbugConf)

Заметки на коленке - 2. Книжки про тестирование для разрабов

Заметки на коленке: про тестирование (базисы для разрабов)

Зайти в IT, подумать и не выйти

Рекомендации начинающему докладчику

Про что рассказывать и зачем оно вообще нужно?

Кажется вы нащупали возможную тему, что дальше?

Запускаем в работу

Рекомендации по слайдам

Нетехническое собеседование - зачем, полезные вопросы

Flaky тесты (они же моргающие или "случайно успешные")

Через призму менеджера про "Никаких правил. Уникальная культура Netflix."

"The Ongoing Revolution in Software Testing" by Cem Kaner (2004) - разбор общепринятых утверждений о тестировании/тестировщиках

Обычные и не очень вопросы к собеседованию на позицию Engineering Manager

Тимлид - таинственная роль в реальном мире или фантастические твари среди нас

Короткой строкой: новости про Heisenbug с промо и полезные ссылки