tag:blogger.com,1999:blog-63461312984815356312024-03-16T21:51:32.110+03:00Чудес не бывает или я ошибаюсь?О разном в программировании, тестировании и руководстве командами в ITMaxim Shulga (aka MaxBeard12)http://www.blogger.com/profile/05615743910272666556noreply@blogger.comBlogger244125tag:blogger.com,1999:blog-6346131298481535631.post-54750843129827995432023-10-30T08:08:00.001+03:002023-10-30T08:08:41.511+03:00Про code review 9 лет спустя<p>Если совсем коротко, то, на мой скромный взгляд, одна из самых переоцененных, но часто используемая практика, которой пытаются чего-то достичь. И как в нее не умели, так и не умеют.</p><p>Почти никто не думает о реальных целях, форматах проведения, реальном ее влиянии на итоговое качество продукта и кода, скорость доведения фичи до прода, но все проводят. (<i>Потом правда на каждом ретро обсуждают "почему у нас MR висят на ревью целыми днями"</i>)</p><p>Хотя на самом деле, в большинстве своем, у многих, она сейчас больше мешает, чем помогает.</p><p>Имхо, популярность практики связана не с ее ценностью, а человеческой психологией: всегда удобно просто покритиковать кого-то.</p><p>С другой стороны, ревью кода в виде обозначения "экспертиза исходного кода программы" входит в ГОСТ по безопасной разработке, что как минимум требует формальной галки проведенного ревью, как максимум ожидает настроенного процесса. То есть вроде полезная штука, в чем же подстава?</p><p>Подстава в последовательности шагов ревью и квалификации команды. Остальное вторично.</p><p>Интуитивно: если мы делаем ревью чего-то, то мы предполагаем существование этого чего-то. То есть сначала пишем код, потом его анализируем. Потом, по комментам, код меняется и снова ревью. Кто-нибудь анализирует основные причины комментариев? Что заставляет сильно менять код? Как часто находятся проблемы? Могли бы эти проблемы найдены статическими анализаторами, линтерами и тестами (рядом с кодом)?</p><p>По моему опыту (давнему разработческому и текущему наблюдающему), если настроен автоматический анализ кода + пишутся тесты, то это намного эффективнее находит проблемы, чем глаз коллеги, особенно, если его экспертиза в разработке или доменной области решаемой кодом сильно разнятся от вашей.</p><p>Что нельзя отловить анализаторами и тестами? Ошибки проектирования (хотя считается, что юнит-тесты как-то помогают). Значит добавляем промежуточный шаг, когда разработчик предлагает сделать ревью не готового кода в 100500 изменений, а драфта возможного решения: набросок кода, схемы предполагаемого взаимодействия (data flow, межкомпонентного и тдтп). Это смотрится, обсуждается, дальше реализация, а потом уже или быстрое ревью, или только автоматизация. </p><p>Вот кажется, это единственно разумный вид процесса code review. Все остальное - бесполезная трата времени.</p><p>Полезные ссылки:</p><p>• <a href="https://qase.io/blog/code-review-alternatives/" target="_blank">Stop doing code reviews and try these alternatives</a> (там хороший анализ с примерами исследований и возможных альтернатив)</p><p>• <a href="https://www.maxshulga.ru/2014/08/dont-waste-time-on-code-review.html" target="_blank">И снова про code review или новая единица измерения качества (WTF/minute)</a> (самопис в мою бытность ревьювера)</p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgtZNmImuDs99CL-eGOadvGprMkB-v19dYe_QuBEQTdyRsswFmWjSPVso00tRRqC3wSTxDuChaM8_NgtYUe_SyaJrVvD9du5spNkd9Er_ASaqPBbW2h6v08viTLX5V63SXkRecTqJneT7fMh80hO6lAYbQjcP31vHV_UCFFiJFUF0n9mggiNe9DBHp_a6PX/s735/code%20review.jpeg" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="735" data-original-width="599" height="400" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgtZNmImuDs99CL-eGOadvGprMkB-v19dYe_QuBEQTdyRsswFmWjSPVso00tRRqC3wSTxDuChaM8_NgtYUe_SyaJrVvD9du5spNkd9Er_ASaqPBbW2h6v08viTLX5V63SXkRecTqJneT7fMh80hO6lAYbQjcP31vHV_UCFFiJFUF0n9mggiNe9DBHp_a6PX/w326-h400/code%20review.jpeg" width="326" /></a></div><p><br /></p>Maxim Shulga (aka MaxBeard12)http://www.blogger.com/profile/05615743910272666556noreply@blogger.com0tag:blogger.com,1999:blog-6346131298481535631.post-58269490414832891812023-10-23T09:17:00.002+03:002023-10-23T09:17:30.598+03:00Резюме - что в слове том?<p><i>Дисклеймер: знать, как правильно писать резюме, как быстро его читать и потом им пользоваться на собесе, не равно иметь правильное написанное свое резюме </i>🫠<br /><br /></p><p>Сейчас снова подключился к анализу резюме кандидатов и собесам (как ни странно, DevOps-в).</p><p>Что можно сказать? А то, что люди, как и раньше, как не “умели” писать резюме, так и не “умеют”.<br />Просто набор ключевых слов обрамленный глаголами “применял”, “настраивал”, “мониторил” и тп.</p><p>А что такое “уметь” писать резюме? Важный ли это навык? (<a href="https://t.me/IT_without_miracles/67" target="_blank">присоединяйтесь</a> к обсуждению в телеге)<span></span></p><a name='more'></a><p></p><p>Имхо, влияние качества резюме на итог поиска работы* сильно переоценено: в 80% случаев на собесе ты будешь его пересказывать и половина собеседующих его даже не прочитают. Важно пройти фильтр, тут помогут ключевые слова и, иногда, имена предыдущих компаний. Фсе. </p><p>*если речь про первую работу (джун), то не все так “просто”. Там придется потрудится сначала над тем, что ты сможешь описать (приобрести знания/умения), а потом, как это подать.</p><p>Тут вот статья "<a href="https://interviewing.io/blog/resumes-suck-heres-the-data" target="_blank">Resumes suck. Here's the data</a>" (автор ее недавно подкорректировал, раньше она была жестче и категоричней) с описанием эксперимента по качеству отбора по резюме, которая предвещала чуть ли не “смерть” резюме еще 9 лет назад. Но они все еще живее всех живых. </p><p>И это логично - это самый популярный и простой способ себя проиндексировать, классифицировать и отобраться в качестве кандидата на собес (я знаю только 3 способа: резюме, личный бренд, “по блату”)</p><p>Резюме сейчас - это просто набор метаданных к тебе, как соискателю. А дальше получается, что важен навык структуризации этих данных в удобочитаемом формате без синтаксических ошибок.</p><p>Само “умение писать резюме” в целом - это умение описать свои задачи и их результаты (это важнее) интересно, зацепить. Но на фоне дефицита опытных IT-шников спокойно приглашаешь даже просто по “ранжированию ключевых слов” из технологий, задач и прошлых компаний.</p><p>Давайте попробуем почитать резюме традиционного HeadHunter формата (у LinkedIn тоже есть свои приколы). Иногда складывается ощущение, что HH целенаправленно делает (ничего личного, бизнес: “дольше ищешь-дольше платишь”) критикуемый многими формат резюме, где раздел “обо мне” (который как раз можно сделать чуть ли не единственным), находится глубоко внизу. </p><p>В итоге до него мало кто и доходит, если вспомнить с какой частотой сегодня IT-шники меняют работу, а значит все смотрящие застревают на перечислении компаний с одинаковыми задачами. Обычно я быстро пролистываю до конца и смотрю, есть ли там в “обо мне” что-то обобщенное о кандидате, его задачах и предпочтениях. Это то, от чего отталкиваюсь.</p><p>Дальше смотрим последние пару мест работы: выполняемые задачи и какими инструментами (речь не только про инженеров, у менеджера тоже есть свои инструменты, и это не Jira 😃). Про достижения мало кто пишет, но если есть, дополнительный “+” к вопросу приглашения. Из остального формируются будущие вопросы на собесе.</p><p>Частота смены работ: я старовер, считаю, что ничего толкового за срок меньше чем за год-полтора (зависит от роли, у кого-то и дольше) сделать нельзя: просто задачеклепатель. Если товарищ регулярно меняет работу чаще, то дополнительный “?”.</p><p>Что очень редко смотрю в резюме: образование. Обычно на него смотрю, когда специалист начального уровня, дальше уже все равно. Были случаи, когда уже после выхода на работу и пары месяцев работы, я узнавал, что у новенького нет высшего образования. Знаю менеджеров, которые, наоборот, уделяют этому разделу большое внимание и ищут там любимые ВУЗы, которые по их мнению отражают квалификацию кандидата. И если нет таких вузов, значит кандидат не годится.</p><p>В Питере раньше была фишка, выпускники “ФМЛ 239” (очень продвинутая, но школа) всегда его писали в резюме. Есть подозрение, что это такая метка для своих 😉 Потому что я чаще всего триггерился в обратную сторону.</p><p>Ссылки на дополнительные ресурсы соискателя (GitHub, блог и тп) тоже люблю смотреть. Нужны ли они в принципе в резюме? Если там есть что-то, чем вы гордитесь и лично вам нравится - пишите. Если в гитхабе, кроме пары тестовых больше ничего нет, а в блоге все заброшено 3 года назад, то бесполезная затея (лично меня раздражает). </p><p>По собеседованиям меня могу сказать, что еще ни разу на собесах никто не сказал про мой блог, а многие еще и удивлялись, когда речь про него заходила, так что лично сам не переоцениваю важность этого ресурса в резюме.</p><p>Возраст. Смотрю только лишь для того, чтобы пресечь моменты игнора, эмм, возрастных кандидатов командами. Такое иногда бывало, к сожалению, и если в качестве отказа от рассмотрения фигурирует только возраст (а такое случается), то это повод пообщаться подробнее с тем, кто такое пишет.</p><p>И вот это все смотрится и читается через призму потенциальных задач, которые будет решать у нас кандидат, когда выйдет на работу. Через призму культуры и процессов в команде и ее состава. И если “+” перевесили “?“ - погнали общаться.</p><p>Полезные ссылки:<br /><a href="https://www.youtube.com/watch?v=856IAFo59LM" target="_blank">Стрим про резюме и подготовку к интервью </a><br /><a href="https://t.me/IT_without_miracles" target="_blank">В IT чудес не бывает (мой телеграмм-канал)</a></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjz-szqro2U_Ul6P216B7p84q-ENS5toWaFUGVTc1eOX2jgUen3MmTT1lbzJtDbZbyOdif-TpBecsPPsEOAjukU-ASrmz16G9iMFX8AYvsF5TZ1g1tm5BjfQu3dYlTBBsS_F9ADuNtWcQgi74kg6jUEqHpWRdfTY3bST-ZRzJmaxHHuQ01mtNB1f08p-SFx/s1099/resume.jpeg" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="826" data-original-width="1099" height="301" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjz-szqro2U_Ul6P216B7p84q-ENS5toWaFUGVTc1eOX2jgUen3MmTT1lbzJtDbZbyOdif-TpBecsPPsEOAjukU-ASrmz16G9iMFX8AYvsF5TZ1g1tm5BjfQu3dYlTBBsS_F9ADuNtWcQgi74kg6jUEqHpWRdfTY3bST-ZRzJmaxHHuQ01mtNB1f08p-SFx/w400-h301/resume.jpeg" width="400" /></a></div><br /><p></p>Maxim Shulga (aka MaxBeard12)http://www.blogger.com/profile/05615743910272666556noreply@blogger.com0tag:blogger.com,1999:blog-6346131298481535631.post-69022050515110659822023-10-16T09:33:00.000+03:002023-10-16T09:33:14.370+03:00Про юнит-тесты и не только<p>Собрал в кучку разбросанные по чертогам памяти мысли про юнит-(и не только)-тестирование (копия <a href="https://t.me/IT_without_miracles/59" target="_blank">недельного "марафона"</a> из телеги, присоединяйтесь).</p><p>TLTR: “Бей вперед - игра придет” (просто начните, если еще нет, хоть с какими-то автотестами).</p><p>Мне последние несколько лет нравится<a href="(https://ru.wikipedia.org/wiki/%D0%A1%D1%8E%D1%85%D0%B0%D1%80%D0%B8" target="_blank"> концепция сю-ха-ри</a>, основная мысль которой заключается в том, что ты не можешь нарушать правила, пока не изучил базу, идеи и мысли других, придумал свои правила, а только потом можешь освобождаться от любых правил.</p><p>Если спроецировать этот подход на автоматизацию проверок, то получается, что сначала ты должен научиться писать тесты, как их видят в отрасли, а только потом точить подходы под себя.</p><p>Но фишка в том, что подходов очень много.</p><span><a name='more'></a></span><p>Например, кто-то считает, что модульные тесты мешают (<a href="https://t.me/orgprog/37" target="_blank">недавние рассуждения Кирилла Мокевнина</a>), кто-то считает, что интеграционные (интегрированные?) тесты - фигня, а модульные тесты рулят (<a href="https://youtu.be/VDfX44fZoMc" target="_blank">JB Rainsberger Integrated Tests Are A Scam HD</a>).</p><p>Каждый подход и мнение имеет в своей основе мысли, с которыми можно согласиться, с какими-то поспорить, но потом все равно прийти к философскому "зависит от".</p><p>Начнем с того, что многие в принципе не считают такие тесты классическими тестами. Оно и правда, если юнит-тесты написаны по канонам: “проверяется лишь одна функция одного юнита”, “все строго изолированно” и тп, то это лишь скорее просто инструмент разработчика.</p><p>Что он дает? </p><p>1. возможность запускать части кода без запуска всей системы, что обеспечивает:</p><p>• быструю обратную связь от вносимых изменений</p><p>• уверенность в вносимых изменениях</p><p>2. документация к коду</p><p>3. помощь в проектировании</p><p>Разберем коротенько по пунктам (заметки Капитана Очевидность, но я как-то не хочу их проскакивать)</p><p>1. <b>Быстрый запуск кода</b> - тут речь как про возможность “засунуть датчик” непосредственно в кишочки кода, так и про скорость выполнения самой проверки.</p><p>Когда у тебя есть возможность здесь и сейчас, без дополнительного окружения и ресурсов проверить, как выполняет свои задачи свеженаписанный код - это то, что нужно. К примеру, если функция по бинарному блобу определяет тип данных в нем, то не нужно проверять эту функцию запуская и дергая API сервиса, который где-то внутри себя использует эту функцию. Банальность и очевидность, но сплошь и рядом наблюдается (о причинах не сегодня). А если функция вызывается внутри десктоп приложения? Там с проверкой функции ”через приложение” вообще будет веселый аттракцион. </p><p>2. <b>Документация</b>. Есть интересная особенность памяти среднестатистического разработчика - она обнуляется по отношению к коду буквально через месяц (+/-). Некоторые только по истории гита определяют, что какое-то конкретное изменение кода было сделано именно ими. А уж про то, что именно код делает и для чего, так и подавно не помнят. Так вот тесты расположенные близко к коду (чаще всего те самые юнит-тесты), как раз помогают быстрее восстановить понимание предназначения кода и логики его работы. И да, конечно, это можно сделать и просто читая код. Но читая юнит-тесты, тем более хорошо написанные тесты с правильными названиями, сделать это намного быстрее. Тем более, что обычную документацию то редко кто пишет, а еще реже обновляет.</p><p>3. <b>Проектирование</b>. Использование юнит-тестов способствует (но не гарантирует) тому, что проверяемый ими код будет написан удобно, понятно, расширяемо. Потому что способность кода быть удобно тестируемым (тестируемость) напрямую связана с такими характеристиками качества кода, как изменяемость и поддерживаемость.</p><p>В этом месте можно было бы ввернуть про TDD (и я таки ввернул), но забавно, что сейчас это буквосочетание куда-то исчезло (только из моей инфоленты?). А то ли дело ра-а-аньше, трава зеленее, "<a href="https://www.maxshulga.ru/2015/04/software-engineering-myth-busters-tdd.html" target="_blank">TDD помогает</a>" vs "<a href="http://reangdblog.blogspot.com/2015/05/tdd.html" target="_blank">TDD есть опиум для народа</a>" и такие батлы в комментариях (<a href="https://www.maxshulga.ru/2015/05/no-tdd.html#comment-2035303480" target="_blank">тут тоже есть</a>, если вы любитель попкорна).</p><p>Короче, юнит-тесты - это лишь инструмент разработчика: написал код так, чтобы потом его протестировать, проверил локально, остались какие-то артефакты имитирующие документацию. Работает в моменте здесь и сейчас. </p><p>Если юнит-тесты написаны канонично, то с вероятностью 99% их надо выкинуть (=сильно переписать) при изменении того кода, который они проверяют. И именно от последнего всех и бомбит.</p><p>Давайте немного вернемся к началу и поразмышляем на тему собственно юнита (модуля). <br />Что это такое? Какие тесты еще можно называть модульным, а какие уже не являются таковыми, потому что уже тестируют несколько юнитов?</p><p><a href="https://martinfowler.com/bliki/UnitTest.html" target="_blank">Обратимся к классику</a> (Мартин Фаулер) :</p><p>“Объектно-ориентированный подход рассматривает класс как юнит, процедурные или функциональные подходы могут рассматривать одну функцию как юнит. Но на самом деле команда решает, что такое юнит исходя из их понимания системы и ее тестирования" (вольный перевод, а статья кстати хорошая, почитайте)</p><p>Хмм, получается, что нет строгого определения, что считать юнитом?</p><p>Да, но есть нюансы.</p><p>Вы знали, что существует 2 школы<strike> боевого кунг-фу</strike> юнит-тестов?</p><p>Лондонская и Детройтская (она же Чикагская).</p><p>Что самое забавное, когда говорят про недостатки юнит-тестов, то чаще всего указывают на проблемы, которые возникают при лондонском подходе.</p><p>Чем же они отличаются?</p><p>Одно из отличий - это как раз определение размеров юнита. </p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEho55LbVXmKFVZDDB5WHlFJrtRaavL241VMcrMwoYgHzIB1DfifyGeIEe2uv3jDBOeneyS0keGZawjc0LvSKYkijCj44YfIKs6AWv7ASyWffchIzI0uNdfY7LASjaDasJ3o_LE5PU6AwgednW2lWs8Tu2G0rPr9OHhxAHFfXNrAvAirUm4Pg38sahRoBjlh/s1336/what's-unit.jpeg" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="764" data-original-width="1336" height="366" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEho55LbVXmKFVZDDB5WHlFJrtRaavL241VMcrMwoYgHzIB1DfifyGeIEe2uv3jDBOeneyS0keGZawjc0LvSKYkijCj44YfIKs6AWv7ASyWffchIzI0uNdfY7LASjaDasJ3o_LE5PU6AwgednW2lWs8Tu2G0rPr9OHhxAHFfXNrAvAirUm4Pg38sahRoBjlh/w640-h366/what's-unit.jpeg" width="640" /></a></div><p>Лондонская школа определяет юнит, как класс/функцию и предполагает изоляцию SUT (system under test) от всего того, с чем он взаимодействует через test doubles (тест-дублеры, на старославянском - моки, <a href="https://www.maxshulga.ru/2012/03/mock-vs-stub.html" target="_blank">что неправильно, но все привыкли</a>). То есть, мы проверяем строго то, как работает SUT ориентируясь на его публичный интерфейс и поведение нужное нам для реализации пользовательского сценария. А все его внешние зависимости замокированы. Это как раз и приводит к тому самому “цементированию” кода тестами, затрудняющего его модификацию.</p><p>В Детройтской школе юнит может быть любого размера, от класса до компонента из нескольких связанных между собой классов, при написании тестов избегают использования тест-дублеров и ориентируются в первую очередь на проверку состояния SUT.</p><p>Считается, что это "кунг-фу" несет риск появления кода, который потом не будет использоваться (нарушение принципа YAGNI), потому что мы не отталкиваемся от пользовательского сценария. </p><p>Но на моей практике, при сильном желании и достаточном умении, накостылить лишнего кода можно при любом подходе. </p><p>Мне больше импонирует детройтский подход, в первую очередь из-за низкой связности тестов с кодом (в сравнении с лондонским вариантом).</p><p>Итого: если отбросить в сторону #holywar со школами, то <b>юнитом можно считать минимальное логическое объединение кода ориентированного на реализацию конкретной функциональности, которое мы хотим и можем проверить отдельно от других таких объединений</b>.</p><p>При этом проектировать код нужно так, чтобы иметь возможность вносить нужную нам для тестов реализацию его зависимостей.</p><p>Заканчиваем.</p><p><b>Вредные советы</b>:</p><p>• пишите юнит-тесты на чужой код после того, как код написан, просто для покрытия (мероприятие искажающее ценность таких тестов)</p><p>• не пишите юнит-тесты на чужой код (если тестов нет) перед тем, как меняешь код (зависит от объема изменений, возможно нужно писать другого уровня тесты)</p><p>• активно используйте привычные и традиционные программерские приемы типа удаления дублирования (приводит к ухудшению читаемости тестов, хотя пункт ооочень холиварный)</p><p>• продолжайте игнорировать книги по юнит-тестам и тестированию вообще</p><p>• открывайте вакансию “Unit Test Writer” (клянусь - реальность, погуглите, я рыдал, особенно над требованиями)</p><p><b>Полезные советы</b>:</p><p>• почитать про мутационное тестирование</p><p>• всегда думать, какие тесты для чего лучше* подходят </p><p>• всегда думать (всех обнимаю)</p><p>*Критерии “лучшести”: скорость написания, скорость обратной связи (запуск, скорость выполнения и диагностика проблем)</p><p>По опыту: надо меньше зацикливаться на том, как тесты называются. А больше над тем, сколько они выполняются, как стабильно, какое окружение требуется и как быстро можно найти проблему, если что-то пошло не так.</p><p>Поэтому сильно плюсую к <a href="https://t.me/heisenbugconf/27646" target="_blank">этому автору</a>: </p><p>“Вообще мне кажется, что разделение на юнит, интеграционные, е2е и т.п. тесты устарело. Сейчас стоит придерживаться другой таксономии: тесты, которые можно прогонять при каждом пулл реквесте, и тесты, которые можно прогонять только собрав релиз.</p><p>И <a href="https://testcontainers.com/" target="_blank">тестконтейнерс</a> - один из способов перетащить часть тестов из второй категории в первую.”</p><p>Ну и уже от меня, само по себе разделение на “слои” провоцирует на разделение зон ответственности и появление вопроса “кто пишет”: типа разрабы это только юнит-тесты, а e2e - автоматизаторы. Еще один из примеров закона Конвея.</p><p>Полезные ссылки:</p><p>• <a href="https://youtu.be/_S5iUf0ANyQ" target="_blank">Are You Chicago Or London When It Comes To TDD? </a></p><p>• <a href="https://devlead.io/DevTips/LondonVsChicago" target="_blank">London vs Chicago</a></p><p>• <a href="https://zone84.tech/architecture/london-and-detroit-schools-of-unit-tests/" target="_blank">London and Detroit schools of unit tests</a> (похоже недоступно из РФ, есть <a href="https://webcache.googleusercontent.com/search?q=cache:FFSlL9beVJAJ:https://zone84.tech/architecture/london-and-detroit-schools-of-unit-tests/&cd=12&hl=ru&ct=clnk&gl=ru" target="_blank">копия из кэша</a>)</p><p>• <a href="https://www.maxshulga.ru/2022/10/notes-testing-books.html" target="_blank">Литература по тестированию (с акцентом на разработку)</a>. </p><p>• Если кому-то нужно <a href="https://pragprog.com/titles/lotdd/modern-c-programming-with-test-driven-development/" target="_blank">про юнит-тесты на C++ (ну вдруг), то вот эта норм</a>, я ее в свое время даже переводить собирался, так понравилась.</p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgd2NjjwivsXeebyBLAj9RFWSR0waPMyTW67D0TBYovGqpID8gk-TsVRNLRRJYPXOs4Cwcvjz4Y7s24S5zkHghh3T9eqqhIXsoMe7X7nOzjv9qGtUFuxa9pzQHHGavGSuJcbJO2sjpR9a5GJvmHYoCgmmFLMqVKG92UaNYHy8wG68MZDKK82lUGR5cDjjxh/s280/UnitTests.gif" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="204" data-original-width="280" height="291" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgd2NjjwivsXeebyBLAj9RFWSR0waPMyTW67D0TBYovGqpID8gk-TsVRNLRRJYPXOs4Cwcvjz4Y7s24S5zkHghh3T9eqqhIXsoMe7X7nOzjv9qGtUFuxa9pzQHHGavGSuJcbJO2sjpR9a5GJvmHYoCgmmFLMqVKG92UaNYHy8wG68MZDKK82lUGR5cDjjxh/w400-h291/UnitTests.gif" width="400" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Не забывайте, ради чего все тесты пишутся</td></tr></tbody></table><br /><div><br /></div>Maxim Shulga (aka MaxBeard12)http://www.blogger.com/profile/05615743910272666556noreply@blogger.com0tag:blogger.com,1999:blog-6346131298481535631.post-91002526904735745032023-09-15T08:08:00.001+03:002023-09-15T08:08:22.278+03:00Мой канал в телеграмме, тоже без чудес<p>В блог стал меньше писать, потому что он в моей голове предполагает сейчас какую-то долгую предварительную работу со статьей. Черновики у меня годами лежат.<br />Поэтому, встречайте телеграмм-канал, лайт-версию блога: появилась мысль - отправляется в канал.<br /><br />Тематика та же самая, <a href="https://t.me/IT_without_miracles" target="_blank">Подключайтесь</a>.<br /><br />Из мариновавшегося годами тут, но уже появившееся в телеге:<br /><br /><a href="https://t.me/IT_without_miracles/29" target="_blank">Team- vs TechLead</a></p><p><a href="https://t.me/IT_without_miracles/13" target="_blank">Ошибки приводящие к проблемам в IT</a></p><p>Про календари <a href="https://t.me/IT_without_miracles/15" target="_blank">менеджера</a> и <a href="https://t.me/IT_without_miracles/17" target="_blank">инженера</a></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhWEnNZgSAaSNYJpH8IVmkLbspz-clfTbepOrqHMNmowVndb3_HgQOiXpEUlT15DYqDr5XAVX3psngUjt0tXfmsWfRpkvFl2qRddgDKoKwSd47LitA5D_ppDOFVW2roKlVxlC3Cyxwb7tHAZ20AfzdKHb6nk-uD6cX6jQ-s0BIw4xdNqLEoXu2Pxjh79Taq/s640/IT-without-miracles.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="640" data-original-width="640" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhWEnNZgSAaSNYJpH8IVmkLbspz-clfTbepOrqHMNmowVndb3_HgQOiXpEUlT15DYqDr5XAVX3psngUjt0tXfmsWfRpkvFl2qRddgDKoKwSd47LitA5D_ppDOFVW2roKlVxlC3Cyxwb7tHAZ20AfzdKHb6nk-uD6cX6jQ-s0BIw4xdNqLEoXu2Pxjh79Taq/s320/IT-without-miracles.jpg" width="320" /></a></div><br /><p><br /></p>Maxim Shulga (aka MaxBeard12)http://www.blogger.com/profile/05615743910272666556noreply@blogger.com0tag:blogger.com,1999:blog-6346131298481535631.post-81486427504585604532023-09-04T13:30:00.000+03:002023-09-04T13:30:01.591+03:00Legacy code and tests<p><a href="https://qameta.io/blog/legacy-code/" target="_blank">Побеседовали</a> с Мишей про эту "магическую" сущность, а он смог классно переработать содержимое нашей беседы и кучи других материалов.</p><p>Я теперь даже не уверен, какие именно мысли мои :) Но там все по делу.</p><p>Ну и самое главное про легаси:</p><p>1. это про то, что нужно (иначе бы выкинули)</p><p>2. это то, что с вами всегда* **</p><p>*если вы не меняете работу каждые полгода после написания нового кода</p><p>**но уровень боли от легаси можно уменьшить - статья как раз про это</p>Maxim Shulga (aka MaxBeard12)http://www.blogger.com/profile/05615743910272666556noreply@blogger.com0tag:blogger.com,1999:blog-6346131298481535631.post-68965761204814219762023-04-07T14:49:00.011+03:002023-04-09T14:43:24.184+03:00Заметки на коленке - 3. Что еще делать, если ваши тесты уже "зеленые"?<p>"Lately I find I'm working on automated tests that return non-binary results. Tests that neither pass nor fail" by <a href="https://twitter.com/noahsussman/status/715984409892143104" target="_blank">@noahsussman</a><br /><br />Отличная мысль, которую я ретвитил еще в 2016. Но давайте вместе подумаем, что за этим может скрываться? (<i>кстати, не знаю, что при этом думал Noah</i>)<br /><br />Ваши тесты прошли и прошли "успешно". Все хорошо или все же есть, куда еще посмотреть? <br /><br />Дальше то, что использовал я лично и то, что еще можно прикрутить дополнительно. Естественно все шаги ниже должны быть автоматизированны.<br /><br />1. Контролируйте время выполнения тестов. Если набор проверок не меняется (а такое часто бывает, к сожалению), то рост времени выполнения может говорить о проблемах в продакшен коде (чаще всего) или проблемах с окружением.<br /><br />2. Контроль за количеством выполняемых тестов. "Все зеленое" не значит, что сегодня выполняли те же Х тестов, что и вчера. Смешно(нет), но случается такое, что какие-то проверки "исчезают" из запуска из-за того, что у кого-то "дрогнула рука" и про это узнают только после разбора прод бага.<br /><br />3. Контроль за занимаемыми SUT (system under test) ресурсами во время выполнения тестов:<br />• оперативка = утечки<br />• место на диске = резкий рост размера БД, большие логи, "забытые" временные файлы<br />• другие технические метрики<br /><br />4. Тесты запускаемые всегда в одном и том же порядке могут работать успешно только "благодаря" этому порядку. И не работать, если просто начать их запускать в условно произвольном порядке*. "Война тестов" помогает найти проблемы в продакшене.<br />*с учетом настроек SUT и окружения.<br /><br />5. Если у вас в SUT есть, например, http-запросы между клиентом и сервером, то встройте между ними, например, <a href="https://zaproxy.org/docs/api/#overview" target="_blank">OWASP Zed Attack Proxy</a>. Получите возможность дополнительной секьюрити проверки вашего API (как в пассивном, так и активном режиме)<br /><br />6. Тест который сегодня "зеленый", а вчера был "красный" и никто его вчера не чинил, скорее всего предвестник "веселой" регулярной активности "а давайте его перезапустим". <a href="https://www.maxshulga.ru/2021/04/flaky-tests-or-random-success.html" target="_blank">Подробнее про flaky tests</a><br /><br />7. Если ваши тесты "вечнозеленые", проверьте не видите ли вы результаты одного и того же запуска, а тесты на самом деле не запускаются 🤣<br /><br />Ну и подумайте, а стоит ли их запускать вообще. А может просто запускать реже.<br /><br />Какие еще пункты <a href="https://twitter.com/maxbeard12/status/1644228857581404160" target="_blank">можно добавить?</a></p><p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiSoqfHISwa3CiiSfpX8sziIC7kieQmi-QvzZS0LW3mZhNroG3E6esr2KStNi_SKOVk93awFNHvpftgZR_ZnW6ycVA_HbWKYqxj2bqmNQKh3Ms1iVM6DRq8gy0QJfBZC3HBqyCYkKAPSHooOcDzcbiMct_FOPG6q9QMNcqNVq1tk3b3x6pOXaIfQGQhHg/s713/green%20tests.jpeg" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="713" data-original-width="499" height="400" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiSoqfHISwa3CiiSfpX8sziIC7kieQmi-QvzZS0LW3mZhNroG3E6esr2KStNi_SKOVk93awFNHvpftgZR_ZnW6ycVA_HbWKYqxj2bqmNQKh3Ms1iVM6DRq8gy0QJfBZC3HBqyCYkKAPSHooOcDzcbiMct_FOPG6q9QMNcqNVq1tk3b3x6pOXaIfQGQhHg/w280-h400/green%20tests.jpeg" title="А тесты прошли успешно..." width="280" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">А тесты прошли успешно...<br /></td></tr></tbody></table><a href="https://www.maxshulga.ru/search/label/%D0%B7%D0%B0%D0%BC%D0%B5%D1%82%D0%BA%D0%B8" target="_blank">Все заметки этой серии.</a><a href="https://twitter.com/maxbeard12/status/1644228857581404160" target="_blank"><br /></a><br /></p>Maxim Shulga (aka MaxBeard12)http://www.blogger.com/profile/05615743910272666556noreply@blogger.com0tag:blogger.com,1999:blog-6346131298481535631.post-71791088419195834522022-12-23T17:21:00.005+03:002022-12-24T09:28:32.479+03:00О чем подумать при разделении команды<p><br /></p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj7bJ81aCZy4uSQq-3KCJ6IKUKPyOGtZVztUsHxAQ-AlhI3ML7lyKfawOwAcCosmqOkFGx_roqLYBVkdn4LkIwnr1M_9rv55y1bsZVBVtsnpKrPkt8KX2Oqn2siJmSMTvyIs8npr_N1lWOb-7T0g9AnZzTwzFzt-kYb_2eIafnSIzrPeXAH6GkY6SwqEg/s3579/%D0%9C%D0%B8%D1%82%D0%BE%D0%B7.png" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="1532" data-original-width="3579" height="171" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj7bJ81aCZy4uSQq-3KCJ6IKUKPyOGtZVztUsHxAQ-AlhI3ML7lyKfawOwAcCosmqOkFGx_roqLYBVkdn4LkIwnr1M_9rv55y1bsZVBVtsnpKrPkt8KX2Oqn2siJmSMTvyIs8npr_N1lWOb-7T0g9AnZzTwzFzt-kYb_2eIafnSIzrPeXAH6GkY6SwqEg/w400-h171/%D0%9C%D0%B8%D1%82%D0%BE%D0%B7.png" width="400" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Митоз <strike>клетки</strike> команды</td></tr></tbody></table><div class="separator" style="clear: both; text-align: left;"><div class="separator" style="clear: both;"><br /></div><div class="separator" style="clear: both;">Если продукт или набор сервисов, которым занимается команда, успешно развивается, задач становится все больше, размер команды растет, рано или поздно вы приходите к мысли о трансформировании команды в несколько команд. </div><div class="separator" style="clear: both;">Иногда это происходит "органически" - в продукте есть свободно отделяемая часть, которую можно передать новой команде. Иногда все сложнее - продукт разделить тяжело и само разделение драйвится тем, что просто людей становится много (или нужно больше) и текущие процессы становятся неэффективными, а результат работы сложно прогнозируемым. </div><div class="separator" style="clear: both;"><br /></div><div class="separator" style="clear: both;">Я наблюдал 3 варианта "рождения" новой дополнительной команды для существующих задач (речь здесь и дальше не про запуск нового продукта, а про дополнительный импульс в развитии существующего):<br />- команда формируется с нуля. Самый сложный вариант, который скорее всего подойдет, когда процесс работы уже заточен под "многокомандность" и новая команда - это лишь еще одна шестеренка в настроенной машине успешно перемалывающей бэклог задач.</div><div class="separator" style="clear: both;">- команда формируется на базе какого-то человека из "старой" команды. </div><div class="separator" style="clear: both;">- N новых команд получаются в результате разделения "старой".</div><div class="separator" style="clear: both;"><br /></div><div class="separator" style="clear: both;">Мне, чаще всего, приходилось заниматься третьим вариантом, поэтому ниже немного вопросов/тезисов, про которые надо подумать при разделении команд:</div><div class="separator" style="clear: both;"><br /></div><div class="separator" style="clear: both;"><b>Если делиться, то как? </b>Это все влияет на новые процессы работы и их формат</div><div class="separator" style="clear: both;">- функционально (у каждой команды свой кусок функциональности, свой бэклог и код).</div><div class="separator" style="clear: both;">- кроссфункционально (беклог остается общим, команды работают над одной кодовой базой). </div><div class="separator" style="clear: both;"><br /></div><div class="separator" style="clear: both;"><b>Как делить людей (кого в какую команду)?</b> </div><div class="separator" style="clear: both;">По желанию, "насильно", будет ли возможность перехода между новыми командами. У меня в опыте были все эти варианты. Каких ролей не хватает в новых командах и какой план по закрытию потребности в них.</div><div class="separator" style="clear: both;"><br /></div><div class="separator" style="clear: both;"><b>Код, скорее всего, сейчас общий, что дальше?</b></div><div class="separator" style="clear: both;">- остаемся в одном репозитории: кто в итоге "владелец кода" и какие правила работы с ним?</div><div class="separator" style="clear: both;">- если репу/репы нужно таки разделять репу/репы, то как, сколько может занять?</div><div class="separator" style="clear: both;"><br /></div><div class="separator" style="clear: both;"><b>Тот же вопрос по тест-кейсы и прочие артефакты разработки.</b></div><div class="separator" style="clear: both;"><br /></div><div class="separator" style="clear: both;"><div class="separator" style="clear: both;"><b>Что с каналами коммуникаций?</b> </div><div class="separator" style="clear: both;">Обычно у команды есть один канал для внешних запросов и нужно в первую очередь подумать, как он будет функционировать дальше, будут ли создаваться новые каналы для новых команд, как про это узнают все заинтересованные.</div><div class="separator" style="clear: both;"><br /></div></div><div class="separator" style="clear: both;"><b>Кто ответственен за внешние запросы в команду/команды и обработку мониторинговых алертов, если разделение кода/сервисов не произошло?</b></div><div class="separator" style="clear: both;">Какая из команд, в каком порядке, за что именно отвечает?</div><div class="separator" style="clear: both;"><br /></div><div class="separator" style="clear: both;"><b>К чему нужно быть готовым?</b></div><div class="separator" style="clear: both;">- шторминг команд. Даже если люди давно работали в одной старой команде, есть большая вероятность, что новую все равно поштормит.</div><div class="separator" style="clear: both;">- персональная неудовлетворенность некоторых членов команд.</div><div class="separator" style="clear: both;"><br /></div><div class="separator" style="clear: both;"><b>Советы от КО</b>:</div><div class="separator" style="clear: both;">- Обратиться за опытом к коллегам. Скорее всего кто-то из коллег или знакомых уже <strike>огребал от разделений</strike> сталкивался с этим вопросом и готов поделиться с вами своими опытом и попоболями.</div><div class="separator" style="clear: both;">- <a href="https://teamtopologies.com/key-concepts" target="_blank">Концепт топологии команды на команды/группы </a>. Кстати, возможно, ваш вариант не отдельные команды, а рабочие группы в рамках одной команды.</div><div class="separator" style="clear: both;">- Посмотреть <a href="https://www.youtube.com/watch?v=pw686Oyeqmw" target="_blank">Why Your Software Team CAN’T Scale</a>.</div><div class="separator" style="clear: both;">- Учесть, что уже есть применяемые многими процессы для организации совместной работы команд (<a href="https://www.scrum.org/resources/scaling-scrum" target="_blank">Nexus</a>, <a href="https://scrumtrek.ru/blog/enterprise-agility/355/less-scrum-na-bolshih-masshtabah/" target="_blank">LeSS</a>). Возможно не нужно придумывать свои "велосипеды".</div><div class="separator" style="clear: both;">- в <a href="https://twitter.com/IgorKurochkin/status/1606443450554937344" target="_blank">комментах</a> в тви подкинули интересную концепцию по этой теме: "<a href="https://www.heidihelfand.com/dynamic-reteaming/" target="_blank">Dynamic Reteaming</a>". По описанию очень укладывается в обсуждаемый тут вопрос.</div></div>Maxim Shulga (aka MaxBeard12)http://www.blogger.com/profile/05615743910272666556noreply@blogger.com0tag:blogger.com,1999:blog-6346131298481535631.post-35461056222314611342022-12-02T11:29:00.000+03:002022-12-02T11:29:00.607+03:00Как это - работать с коллегами возраста твоих детей?<p>Возрастной философии <a href="https://twitter.com/maxbeard12/status/1359434685869359104" target="_blank">твиттер-тред</a>, который я решил переложить в статью, заодно попытавшись поправить правописание. Ну и ссылку на заметку сейчас удобнее отправлять, чем ссылку на твиттер. А желание ее кому-нибудь отправить по-прежнему иногда возникает.<br /> <br />Уже даже не помню, чем было навеяно. В лучших традициях твиттерского жанра "дед ноет". Все как положено: нытье, без конкретных примеров действий и противодействий. </p><p>Где-то плюс/минус несколько дней в это время 20 лет назад (тред писался в феврале 2021) заканчивалась моя военная служба и я уже официально (а не в самоволку, как было несколько месяцев до этого) ходил писать новые компоненты для Delphi-библиотек. С тех пор много чего (все?) поменялось в IT-отрасли, но речь сегодня пойдет не про технику. </p><p>А будет про людей. Даже скорее про конкретного человека в моем лице, как и что менялось во мне за эти 20 лет, отношение к возрасту, возрастные фобии если хотите :)</p><p>После увольнения, наверное около 10 лет кряду, возраст коллег не заставлял чувствовать себя "белой вороной". Все плюс/минус "из одной песочницы", с похожим эмоциональным развитием и ожиданиями от жизни. Потом постепенно и как-то неожиданно для меня, картина начала меняться.</p><p>Коллеги становились все моложе, у меня начала пробиваться седина, а вместе с ней и мысли "а как это работать с коллегами возраста твоих детей"? Сначала это были просто мысли, реально таких коллег не было. Но пару лет назад такое случилось в первый раз, а теперь это уже постоянная реальность.</p><p>И дальше немного из моей текущей реальности, когда мои рабочие будни иногда выглядят, как начало анекдота про молодого и старого быков на вершине холма. </p><p>Анекдот скабрезный, но хорошо отражает ситуацию, когда часто все бегут в одну сторону, потом в другую, а ты просто ждешь, когда они все вернутся обратно и мы вернемся к обсуждению проблемы. Которая, как часто выясняется, и не проблема вовсе, а настоящая проблема у нас в другом.</p><p>В этот момент сложно не упрекать себя в отсутствии активной позиции, когда "надо пробовать, чего боятся". А ты просто это уже много раз пробовал, и каждый следующий раз, когда пробовал говорил себе "но может в прошлый раз ты не все предусмотрел, плохо подготовились, контекст другой был, люди другие". А во-о-от сейча-а-ас то все пучком, люди заряжены, кони запряжены. И не хочется даже добавлять сомнений в эту идиллическую картину.</p><p>Кстати, про сомнения. Самое сложное, что лично мне приходится постоянно контролировать в себе, это не выдавать сомнения в лоб. Часто это воспринимают, как негатив. Особенно, если у тебя нет никаких других аргументов, кроме как "мы так пробовали, тогда не сработало". Вроде неконструктивно.</p><p>Иногда, когда прошлый опыт сильно отдается в заднице, начинаешь спорить. И тут уже забываешь про конструктивные аргументы и здравствуй, "токсик-дед".<br />ЗЫ интересно, как часто меня так называют? :)<br /></p><p>-----</p><p>Иногда спорить бесполезно, юношеская страсть и "вот это все". Люди в принципе не учатся на чужих ошибках, поэтому в этот момент ты просто проверяешь, что грабли лежат под правильным углом, поэтому ебанет сильно, но не смертельно. И ждешь момента, когда к тебе придут с шишкой и "а че ты там говорил про...". </p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg44ATWrAZY1wfQQlrtmNJJsSV2Ku8U6uvVpIg83VKlJEWn-5K3nIFYaS-brXox0vee-2TFXDDnvk6PmpvexkGg9nqyXj1nO_UONQVEIyRnTY3C8nlOyelurA6l2yeefH-W4Jqzl6Ww6syYt2VuyJYYyrQvgkqJkloNgobXlNXbcm6xwhDVn_pI7vfSoA/s554/dobrota.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="492" data-original-width="554" height="178" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg44ATWrAZY1wfQQlrtmNJJsSV2Ku8U6uvVpIg83VKlJEWn-5K3nIFYaS-brXox0vee-2TFXDDnvk6PmpvexkGg9nqyXj1nO_UONQVEIyRnTY3C8nlOyelurA6l2yeefH-W4Jqzl6Ww6syYt2VuyJYYyrQvgkqJkloNgobXlNXbcm6xwhDVn_pI7vfSoA/w200-h178/dobrota.png" width="200" /></a></div><br /><p></p><p>В особо сложных случаях, цинично крепишь к граблям топор, потому что патологии не лечатся, а свои нервы дороже. Опять же возраст, себя беречь надо.</p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEguws0e4L9S7LDnDKN_LQou9EO3AEvGTPFGZUW2WFkb8e-QyrOFHUi5fYOrpYZxFUEH9JsrJqHnbVEMcKBXo7PM1BtdcaibYTPmeKsML_xyjtC2ElkHCLYPdvba8KKMwkaUdObh7CWg3gFaWrjcvxWDVqXLIuiOIYtEpmjJF1OEcuerei0GNVr5-SHT2g/s800/grable-topor.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="800" data-original-width="579" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEguws0e4L9S7LDnDKN_LQou9EO3AEvGTPFGZUW2WFkb8e-QyrOFHUi5fYOrpYZxFUEH9JsrJqHnbVEMcKBXo7PM1BtdcaibYTPmeKsML_xyjtC2ElkHCLYPdvba8KKMwkaUdObh7CWg3gFaWrjcvxWDVqXLIuiOIYtEpmjJF1OEcuerei0GNVr5-SHT2g/s320/grable-topor.png" width="232" /></a></div><br /><p><i>Лирическое отступление: "юность" сейчас для меня это, простите, до 30 точно, иногда и позже продолжается</i>. </p><p>Я часто пишу "опыт", а начинал ведь про "возраст". Как это между собой коррелирует? Теоретически богатый опыт можно получить в условиях "год за два", по ускоренной программе. Но жизненный опыт, скорее мудрость, приходит именно с возрастом, когда у тебя что-то меняется в мозгах. ХЗ что именно, надо порефлексировать.</p><p>При этом очень хорошо, как мне кажется, срабатывает история, когда к тебе самостоятельно приходят за советом. В этот момент человек открыт и твой опыт и слова ему ценны. Последнее время такие сеансы часто заканчиваются словами "это было здорово, прям мотивирующе", "получил дозу мотивации". Ну и сам весь такой замотивировался, есть еще "порох в пороховницах".</p><p>Получается, что работа "деда" быть в балансе между "добиться, чтобы человек был готов внимать совету" и "все развалилось к херам, пока ты тут воспитанием занимался". Ну и самому кукухой не уехать раньше времени. Но это уже совсем другая история... И кажется я тут про менеджера, а не про деда. Хотя воспитание детей, которым уже условно сильно больше 15 лет, <a href="https://www.maxshulga.ru/2013/03/blog-post.html" target="_blank">тоже где-то про это</a>.</p><p>----</p><p>Есть еще психологический момент связанный именно с возрастом. Я уже привык общаться с коллегами ровесниками сына и не думать про возраст. Иногда правда "стреляет" в мозгах и очень хочется "сделать а-я-я-яй, ремнем по попе". Но непонятно, что про это общение думает коллега и что он вообще про тебя думает, "про пенса" :)</p><p>Еще одна штука про возраст и опыт. Ожидания от тебя. Ведь ты так долго работаешь, много знаешь (наверное), ты просто должен взять и просто уххх, как хорошо все сделать. А если ты так не делаешь, то...<br /><br />Или наоборот, "че от него уже можно ожидать, он же уже давно код не пишет, все IT-психологией балуется"</p><p>А может такая картинка ожиданий только у тебя в голове. И то, что тебе говорят коллеги, это просто уважительное отношение, простите, к возрасту :)</p>Maxim Shulga (aka MaxBeard12)http://www.blogger.com/profile/05615743910272666556noreply@blogger.com0tag:blogger.com,1999:blog-6346131298481535631.post-35945511441666361662022-11-17T13:13:00.008+03:002022-12-22T16:25:55.502+03:00Встречи 1:1<p>На базе <a href="https://twitter.com/maxbeard12/status/1492080422725066766" target="_blank">треда</a> в тви.</p><p>Признаться, я давно не провожу "каноничные" 1:1. </p><p>В 1-ю очередь из-за того, что "каноничность" предполагает регулярность. Практика скорее полезная, но эффективность зависит от многих факторов. Например, количества тех, с кем надо проводить, процессов в командах и твоем в них участии.</p><p>А я не люблю делать то, что просто "общепринято", но пользы не несет или ее меньше, чем затрат хотя бы времени. </p><p>Ну или просто терпения не хватает дождаться реальной пользы.</p><p>Чаще получаются не классические 1:1, а встречи по онбордингу новичков, обсуждению планов развития, беседы с ребятами, которые сами приходят с запросом. Моя "дверь" для такого всегда открыта и я всем постоянно и везде про это напоминаю.</p><p>Тем не менее, всегда полезно иметь списочек вопросов, которые можно обсудить:</p><p>1. <a href="https://larahogan.me/blog/first-one-on-one-questions/" target="_blank">Вопросы</a> для первой встречи </p><p>2. Хорошая замена традиционного вопроса "<a href="https://twitter.com/lilykonings/status/1460337455782006786" target="_blank">How's everything going?" -> "What's one thing that could be better?</a>"</p><p>3. <a href="https://codecapsule.com/2021/09/09/how-to-get-your-silent-1-on-1s-back-on-track/" target="_blank">Что делать</a>, если 1:1 начинается с "мне нечего рассказать" или "с моей стороны ничего нового"</p><p>4. <a href="https://github.com/sharovatov/teamlead/blob/master/articles/1-1.md" target="_blank">Мысли</a> Виталия Шароватова (его <a href="https://twitter.com/vsharovatov1" target="_blank">тви</a>) про рационализацию регулярных 1-1 (кстати у него <a href="https://github.com/sharovatov/teamlead" target="_blank">много полезной инфы</a> для лидов)</p><p>5. вишенка 🍒 для тех, кому хочется новых вопросов - <a href="https://getlighthouse.com/blog/one-on-one-meeting-questions-great-managers-ask/" target="_blank">132 One on One Meeting Questions Great Managers Use to Create High Performing Teams</a> </p><p>В любом случае, имхо, лучше общаться на "неправильных" 1:1, чем не общаться совсем. Но не будьте как я, попробуйте все же делать это регулярно, <b>не реже раза в месяц</b>.</p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiN8d3ekls3UUzTuvOTiYnwfUjga3XyLoKzZIxWHzHDWsUoV-869BG1_4k8FxpMhVpCWdN6gAZTwTkigw8ohxZGzc9u-AEmYMHax0OaCFZBXpnUCYdumSnx_FipDZ1nJv27iF_5TbfR4CRYQ2orx8BisWuZQSk0OI-MwfHvie1tbBYPKIfD2Epj2ohgog/s546/1_1.jpeg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="546" data-original-width="487" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiN8d3ekls3UUzTuvOTiYnwfUjga3XyLoKzZIxWHzHDWsUoV-869BG1_4k8FxpMhVpCWdN6gAZTwTkigw8ohxZGzc9u-AEmYMHax0OaCFZBXpnUCYdumSnx_FipDZ1nJv27iF_5TbfR4CRYQ2orx8BisWuZQSk0OI-MwfHvie1tbBYPKIfD2Epj2ohgog/s320/1_1.jpeg" width="285" /></a></div><br /><div class="separator" style="clear: both; text-align: center;"><br /></div><br /><p><br /></p>Maxim Shulga (aka MaxBeard12)http://www.blogger.com/profile/05615743910272666556noreply@blogger.com0tag:blogger.com,1999:blog-6346131298481535631.post-495006088513198862022-10-20T17:28:00.000+03:002022-10-20T17:28:08.542+03:00Развитие в IT: начало, менеджерская развилка, повседневность (беседа на HeisenbugConf)<p> Про то, что менеджмент - это не единственный путь развития :)</p>
<iframe allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen="" frameborder="0" height="380" src="https://www.youtube.com/embed/mmf0bep2Plc?list=PLsVTVVvrKX9vNh2Yu0k6W1yoLWXpJdIbI" title="Максим Шульга — Развитие в IT: начало, менеджерская развилка, повседневность" width="760"></iframe>Maxim Shulga (aka MaxBeard12)http://www.blogger.com/profile/05615743910272666556noreply@blogger.com0tag:blogger.com,1999:blog-6346131298481535631.post-4183911971368853072022-10-18T10:18:00.005+03:002023-06-16T18:58:10.167+03:00Заметки на коленке - 2. Книжки про тестирование для разрабовЕсть <a href="https://twitter.com/maxbeard12/status/1582253519071248384" target="_blank">тред</a> в твиттере, но пусть тут для удобства тоже будет.<div><br /><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhiitqJkx-n23DnFvHhxYa42H7Y2hgUC0cVmPzQ9sLh1tyCkrhca-hu3fUwjtjAVxadAmjmbea31qHSjhTUTRhubCz3KPMDsJAmZIdnN3rE5Peog8SAC2keCwvCnAathhjKoxxYmByBk7UxkR92XJPdhYq2aKtdx-cXztpNB1-X-jwdXBw6VMheboDmww/s500/read-the-books.gif" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="208" data-original-width="500" height="166" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhiitqJkx-n23DnFvHhxYa42H7Y2hgUC0cVmPzQ9sLh1tyCkrhca-hu3fUwjtjAVxadAmjmbea31qHSjhTUTRhubCz3KPMDsJAmZIdnN3rE5Peog8SAC2keCwvCnAathhjKoxxYmByBk7UxkR92XJPdhYq2aKtdx-cXztpNB1-X-jwdXBw6VMheboDmww/w400-h166/read-the-books.gif" width="400" /></a></div><div><br />Книги большей частью достаточно "возрастные", у некоторых есть свежие переиздания, где добавлены "свежие" темы, типа мобилок и тп. Из-за "возраста" сравнительно легко ищутся не только в магазинах.<br /><br /><b>Вводная по "разработческому" тестированию</b><br />Про тестирование обзорно для разработчика<div><a href="http://developertesting.rocks/book/">Developer Testing</a></div><div><a href="http://developertesting.rocks/book/"><br /></a>The Art of Unit Testing (лучшая, на мой взгляд, книга по юнит-тестам)<br /><a href="https://www.manning.com/books/the-art-of-unit-testing-second-edition" target="_blank">С примерами на С#</a> <br /><a href="https://www.manning.com/books/the-art-of-unit-testing-third-edition" target="_blank">С примерами на JS</a> <br />Применимо и к другим языкам<br /><br />Паттерны для хороших тестов (практически любых)<br /><a href="http://xunitpatterns.com/" target="_blank">xUnit Test Patterns: Refactoring Test Code</a> (есть книга)<br /><br /><b>То, что мало кто из тестировщиков читал:</b><br />Теория тестирования<br /><a href="https://www.amazon.com/Lessons-Learned-Software-Testing-Context-Driven/dp/0471081124" target="_blank">Lessons Learned in Software Testing: A Context-Driven Approach</a><br /><br />Букварь по тест-дизайну<br /><a href="https://www.amazon.com/Practitioners-Guide-Software-Test-Design/dp/158053791X" target="_blank">A Practitioner's Guide to Software Test Design</a><br /><br />Гибрид двух предыдущих<br /><a href="https://www.amazon.com/Software-Testing-Analysis-Principles-Techniques/dp/0471455938" target="_blank">Software Testing and Analysis: Process, Principles and Techniques: Process, Principles, and Techniques</a><br /><br />Еще один гибрид<br /><a href="https://www.amazon.com/Art-Software-Testing-Glenford-Myers/dp/1118031962" target="_blank">The Art of Software Testing</a><br /><br /><b>Факультативно</b>:</div><div>Теория автоматизации, термины, практики (без упора в стек, можно просто пролистать)<br /><a href="https://www.amazon.com/Automated-Testing-Handbook-Linda-Hayes/dp/0970746504" target="_blank">Automated Testing Handbook</a><br /><br />Философия автоматизации<br /><a href="https://leanpub.com/TheAWord" target="_blank">The "A" Word </a><br /><a href="https://www.maxshulga.ru/2014/09/the-a-word.html" target="_blank">Мои пару слов про нее</a> <br /><br />"Achieving Software Quality With Testing Coverage Measures"<br />Для желающих почитать немного "теорию" покрытия тестами. Просто можно погуглить по названию, там небольшая статья<br /><br />И немного "философии" и истории от меня. Практически моя "инженерная лебединая песня" :)</div><div>"<a href="https://www.maxshulga.ru/2016/10/autotests-is-sweat-blood-tears.html" target="_blank">Автоматизация тестирования - это пот, кровь и слезы</a>"<br /></div><div><br /></div><div><a href="https://www.maxshulga.ru/search/label/%D0%B7%D0%B0%D0%BC%D0%B5%D1%82%D0%BA%D0%B8" target="_blank">Все заметки этой серии.</a></div></div></div>Maxim Shulga (aka MaxBeard12)http://www.blogger.com/profile/05615743910272666556noreply@blogger.com0tag:blogger.com,1999:blog-6346131298481535631.post-39294895804883284762022-08-26T13:10:00.006+03:002023-04-09T14:41:21.624+03:00Заметки на коленке: про тестирование (базисы для разрабов)<i><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgcFiWatm5VGjj1_sV7rTFrVGf7dHExJsAbEBDVfejpJftATs3XUxPOz-FVC38X8rXQjMosHGCsRdnMO5sP9Gc0apUfuMZFIQxM6IFEXn-U54NZN7kQ7wpyTZ5QF3hNENYqq_WxZyMQW7P86zQ0YeTWEyEFW9ip3H95funcvMhppiDJ2wEvPi9UdapRFw/s501/whyDevDry.jpg" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="298" data-original-width="501" height="190" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgcFiWatm5VGjj1_sV7rTFrVGf7dHExJsAbEBDVfejpJftATs3XUxPOz-FVC38X8rXQjMosHGCsRdnMO5sP9Gc0apUfuMZFIQxM6IFEXn-U54NZN7kQ7wpyTZ5QF3hNENYqq_WxZyMQW7P86zQ0YeTWEyEFW9ip3H95funcvMhppiDJ2wEvPi9UdapRFw/s320/whyDevDry.jpg" width="320" /></a></div><br />Лет 5 назад наваял на коленке для рассказа разработчикам про тестирование в команде без тестировщиков.</i><br /><br /><b>Что такое качество?</b><br />С точки зрения пользователя:<br />Качество — это пригодность к использованию. Делает ли данный продукт то, в чем я нуждаюсь, облегчает ли он мою работу, могу ли я его использовать так, как мне удобно.<br /><br /><div>С точки зрения разработчика:<br />Качество — это соответствие специфицированным и собранным требованиям. Делает ли данный продукт все то, что указано в требованиях.<span><a name='more'></a></span><span></span><br /><br />Характеристики качества программного продукта:<br /><ul style="text-align: left;"><li>Функциональность</li><li>Производительность</li><li>Стабильность</li><li>Удобство использования</li><li>Безопасность</li></ul>Но, есть еще, например, качество программного кода:<br /><ul style="text-align: left;"><li>Понятность</li><li>Изменяемость</li><li>Тестируемость</li><li>Поддерживаемость</li></ul>Поэтому всегда учитывайте, что "качество" - это многовекторная штука.<br /><br /><b>Checking|Testing / QC / QA</b><br /><ul style="text-align: left;"><li><a href="https://www.maxshulga.ru/2016/04/checking-in-testing.html">Checking in Testing</a></li><li><a href="https://www.maxshulga.ru/2017/05/qa-in-job-title.html">Накуа тебе QA в написании тайтла?</a></li><li><a href="https://www.maxshulga.ru/2015/12/switch-between-roles.html">Где грань между программистом и тестировщиком?</a></li></ul>В каждой еще и статье набор ссылок напочитать.<br /><br /><b>Что такое тестирование:</b><br /><ul style="text-align: left;"><li>Тестирование - сервис по предоставлению информации о качестве продукта</li><li>Тестирование - поиск ошибок</li></ul><b>Причины ошибок</b>:<br /><ul style="text-align: left;"><li>сделали, но ошибка в коде (или настройках среды и тд)</li><li>сделали, но не то, что ожидалось </li><li>даже не делали, так как этот сценарий не предусмотрели</li><li>ошибка во “внешнем” коде (open-source)</li></ul>Полезно разбирать причину возникновения, позволяет не наступать на них снова.<br /><br /><b>Как предотвратить и не повторить?</b><br />Вопросы: <br /><ul style="text-align: left;"><li>как мы проверим, что мы это сделали</li><li>какие сценарии надо проверить и в каких условиях</li></ul><b>Верификация</b> (сделали то, что планировали|хотели) vs <b>Валидация</b> (сделали то, что нужно | это решает проблему)<br /><br /><b>Пирамиды тестирования</b>:<br /><a href="https://www.maxshulga.ru/2012/04/blog-post_21.html">тут</a> про пирамидки и вообще вопрос автоматизации<br /><br /><b>UI-тесты</b>:<br /><ul style="text-align: left;"><li>Тесты основной функциональности “через UI” (такое нужно минимизировать)</li><li>Тесты бизнес-логики в UI</li><li>Визуальное тестирование</li></ul><b>Техники тест-дизайна</b><br /><a href="http://www.protesting.ru/testing/testdesign_technics.html">http://www.protesting.ru/testing/testdesign_technics.html</a><br /><ul style="text-align: left;"><li>Эквивалентное Разделение</li><li>Анализ Граничных Значений</li><li>Причина / Следствие</li><li>Предугадывание ошибки</li><li>Исчерпывающее тестирование</li><li>PairWise</li></ul><a href="https://testitquickly.com/2017/10/23/simplitudinea-complexitatii/">Простота и понятность тест-дизайна</a><br /><br /><b>Тест-стратегия</b><br /><ul style="text-align: left;"><li><a href="https://www.testerschoice.pro/single-post/2019/07/06/Testing-strategy-in-system-level">Testing strategy in system level</a> </li><li><a href="https://www.satisfice.com/download/heuristic-test-strategy-model">Heuristic Test Strategy Model</a></li></ul><b>Тесты в проде</b><br /><a href="https://www.maxshulga.ru/2018/03/testing-in-production.html">Мое мнение по тестам в проде</a><br /></div><div><br /></div><div>Следуюшие заметки:</div><div><a href="https://www.maxshulga.ru/2022/10/notes-testing-books.html" target="_blank">Книги по тестированию для разработчиков</a><br /><a href="https://www.maxshulga.ru/2023/04/notes-green-test-results.html" target="_blank">Что делать, если ваши тесты уже "зеленые"?</a></div>Maxim Shulga (aka MaxBeard12)http://www.blogger.com/profile/05615743910272666556noreply@blogger.com0tag:blogger.com,1999:blog-6346131298481535631.post-82080536800786016772022-04-28T11:24:00.009+03:002022-07-19T11:24:54.410+03:00Зайти в IT, подумать и не выйти<p><strike>Часто мимо пролетают вопросы "как начать с IT с нулевого уровня", "как понять, что IT мое".<br />Отвечая, собрал набор ссылок.</strike></p><p>Кого я обманываю, просто собирал, потому что люблю собирать полезные штуки. Но некоторым действительно уже помогло :)</p><p>Ссылки с упором на backend-разработку с нуля. По тестированию ищите <a href="https://www.maxshulga.ru/2016/06/useful-testers-resources.html" target="_blank">тут</a></p><p><b>Начало</b></p><a href="https://ru.hexlet.io/courses/introduction_to_programming" target="_blank">Введение в программирование</a><br /><a href="https://ru.hexlet.io/courses/prog-life" target="_blank">Жизнь программиста</a><br /><a href="https://ru.hexlet.io/courses/intro_to_git" target="_blank">Введение в Git</a><div><a href="https://ru.hexlet.io/courses/cli-basics" target="_blank">Основы командной строки</a><p><a href="https://ru.hexlet.io/blog/posts/kak-reshit-zadachu-esli-neponyatno-s-chego-voobsche-nachat-sovety-ot-heksleta" target="_blank">Как решать задачу, если непонятно с чего начать</a> (Хекслет)</p><p><b>Планы развития</b></p><a href="https://roadmap.sh/roadmaps" target="_blank">Developer Roadmaps (тут не только бек, там много)</a></div><div><a href="https://github.com/bzick/oh-my-backend" target="_blank">Oh My BackEnd</a></div><div><br /></div><div>------<br /><p><b>Основы Python </b>(там еще и Java есть)</p><p style="text-align: left;"><a href="https://ru.hexlet.io/courses/python-basics" target="_blank">Python: Основы программирования</a></p><p style="text-align: left;">------</p><p>Неплохой ресурс про IT, но уже на английском</p><p style="text-align: left;"><a href="https://www.freecodecamp.org/learn/" target="_blank">freeCodeCamp</a> (<a href="https://www.youtube.com/freecodecamp" target="_blank">https://www.youtube.com/freecodecamp</a>)</p><p style="text-align: left;">------</p><p><b>Алгоритмы и структуры данных</b> (английский)</p><a href="https://www.coursera.org/specializations/algorithms" target="_blank">Algorithms Specialization</a></div><div><a href="https://www.coursera.org/specializations/data-structures-algorithms" target="_blank">Data Structures and Algorithms Specialization</a><p><b>Аналоги на русском</b></p><a href="https://stepik.org/course/217/promo" target="_blank">Алгоритмы: теория и практика. Методы</a></div><div><a href="https://stepik.org/course/1547/promo" target="_blank">Алгоритмы: теория и практика. Структуры данных</a></div><div><a href="https://www.youtube.com/c/ViktorKarpovCodes/videos" target="_blank">Разбор задач LeetCode и вопросов по алгоритмам</a></div><div><br /></div><div>------<br /><p><b>Про ОС</b></p><p style="text-align: left;"><a href="https://stepik.org/course/1780/promo" target="_blank">Операционные системы (Stepik)</a></p><p style="text-align: left;">------</p><p><b>Про резюме, собесы и тп</b></p><p><a href="https://twitter.com/maxbeard12/status/1514976337714462723" target="_blank">Стрим с рекомендациями</a></p></div>Maxim Shulga (aka MaxBeard12)http://www.blogger.com/profile/05615743910272666556noreply@blogger.com0tag:blogger.com,1999:blog-6346131298481535631.post-72785403946313583432021-11-17T13:41:00.005+03:002023-10-24T09:15:14.123+03:00Рекомендации начинающему докладчику<p>Последнее время статьи в блоге появляются только благодаря тому, что хочется как-то изложить письменно то, что приходится часто повторять устно.</p><p>Сегодня подошла очередь к рекомендациям начинающим докладчикам. Будет немного про сам контент и про оформление презентации. Ничего уникального, просто те давно известные моменты, которые кажутся мне ценными и полезными.</p><p>Так получилось, что уже как 4 года я приобщился к такому процессу, как ревью докладов. Началось это благодаря моему участию в работе программного комитета конференции <a href="https://heisenbug.ru/" target="_blank">Heisenbug</a>, а потом продолжилось уже на обычной работе, когда мы у себя в Semrush <a href="https://vc.ru/semrush/267448-kak-my-provodim-it-mitapy-dlya-svoih-i-chem-eto-pomogaet-kompanii" target="_blank">замутили техническое демо</a>. Поэтому приходится частенько повторять одни и те же мысли, а я переживаю, что что-то полезное забываю сказать. Пусть будет тут, заодно может кому еще пригодится.</p><p>Итак, погнали.</p><h3 style="text-align: left;">Про что рассказывать и зачем оно вообще нужно?</h3><p>В этом месте воспользуюсь помощью зала и просто отправлю вас к хорошим материалам других.</p><p>Рома Поборчий "Как найти в своей работе то, о чём не стыдно рассказать" (<a href="https://youtu.be/3FDp_rJg6f0" target="_blank">ссылка на видео</a>, <a href="https://techleadconf.ru/2021/abstracts/7541" target="_blank">ссылка на слайды</a>).<br />Если коротко и в одно предложение: смотрите на то, какие задачи делаете, какими инструментами, в какие процессы все это завернуто и как можно развиваться самому или развивать других.</p><p>Рома Неволин "<a href="https://habr.com/ru/company/skbkontur/blog/577576/" target="_blank">Как и зачем делать доклады?</a>". Откровенно говоря, эта статья практически аналог того, что вы читаете здесь. Поэтому можно на ней и остановиться :)<br /><br /><b>Главное, помните, гораздо интереснее слушать не про ваши успехи, а про ваши ошибки: доверия больше :) </b> От успехов других очень легко отмахнуться: "у нас так нельзя будет сделать", "у нас другие процессы, продукты, стек, команды, начальники". А ошибки всегда находят отклик: "блин, у нас так же было" или "хахаха, как же можно было в это наступить", вовлекает :)</p><p>Кому интересно дальше, поехали дальше.</p><h3 style="text-align: left;">Кажется вы нащупали возможную тему, что дальше?</h3><div>Теперь ее нужно "повертеть" и ответить себе на следующие вопросы:</div><div><ul style="text-align: left;"><li>кого вы видите слушателями своего доклада, какими компетенциями они должны обладать?</li><li>для чего им ваш рассказ? Или для чего вам (это тоже важно)?</li><li>как поймете, что доклад получился?</li><li>что могут/должны будут сделать слушатели после доклада, когда вернутся к рабочим задачам?</li></ul></div><p>Задача этого упражнения - помочь вам с контентом, структурой и выводами. </p><h3 style="text-align: left;">Запускаем в работу</h3><div>Я видел разные форматы подготовки и тут кажется, каждый делает так, как ему удобно. Для тех, кто делает первый доклад, я бы посоветовал следующие шаги:</div><div><ul style="text-align: left;"><li>подготовить скелет доклада (про что/зачем, основная часть/мясо тезисно, выводы).</li><ul><li>зачем - тут про то, о чем будет доклад, фактически заготовка выводов, как ни странно :) </li><li>план рассказа</li><li>"мясо" - содержательная часть, которая приведет нас к выводам</li><li>выводы - то, про что новички чаще всего забывают. Тут должна быть квинтэссенция доклада, могут быть рекомендации слушателям, ваши дальнейшие планы по этой теме (если они есть) и тп</li><li>все именно тезисно, без попыток оформления, расписывания пунктов и картинок</li><li>но картинки могут заменить собой часть тезисов (какие-то графики, диаграммы, скриншоты исходников и тп)</li></ul><li>если есть возможность, обсудите результаты с кем-то. Это может быть коллега из вашей команды, ПК конференции, специально обученный человек у вас в компании. <a href="https://twitter.com/maxbeard12" target="_blank">Да хоть я</a> ;) (мы иногда ищем докладчиков снаружи на наши митапы) Основная цель - получить первую обратную связь и оценить интерес к теме доклада. Шаг необязательный, но полезный - тему можно довернуть в более интересную сторону на раннем этапе.</li><li>готовим презентацию, насыщая ее контентом (рекомендации по презам будут ниже).</li><li>прогоны, прогоны, прогоны (самостоятельно или с напарником). Важно наговорить текст, речь не про запомнить наизусть, а про "установить связи между слайдом и той информацией, которую хочется озвучить".</li></ul><h3 style="text-align: left;">Рекомендации по слайдам</h3></div><div><ol style="text-align: left;"><li>Текст на слайдах должен максимально лаконично отражать то, что вы хотите сказать голосом. Если текста много и он занимает весь слайд - плохо (слушатели превратятся в читателей, а вас перестанут слушать). Понятно, что речь именно про "много читать", а не про "одно слово большим шрифтом на весь слайд".</li><li>Иногда текст лучше заменить картинкой со схемой, они лучше воспринимаются с озвучкой.</li><li>Про картинки - если на слайде только она, то самым правильным будет максимально занять весь слайд этой картинкой, без полей, хедеров и футеров. Следите за качеством картинки (иногда лучше словами без картинок рассказать, чем на "замылки" смотреть).</li><li>Если у вас есть слайд с пунктами, например, последовательность шагов, которые нужно предпринять или перечисление плюсов/минусов, то воспользуйтесь или последовательным показом этих пунктов по ходу рассказа (анимация), или сделайте отдельные слайды для каждого рассказа по каждому из подпунктов. Почему? Потому что, снова, много текста - слушатели превращаются в читателей.</li><li>Тут можно посмотреть <a href="https://www.slideshare.net/LookAtMySlides/codeware" target="_blank">рекомендации по показу исходников на слайдах</a></li><li>Хорошо помогает и в структурировании, и в ориентации слушателей по ходу доклада привязка слайда к плану: например, в заголовке или в расставленных по презентации слайдах, возвращающих нас к плану и тому, где мы сейчас находимся. Хороший пример в <a href="https://2018.heisenbug-moscow.ru/2018/msk/talks/2l8hdnhhzs0sgkc8q4k4k4/" target="_blank">презентации Вадим Пуштаева</a>, правда сложно реализуемый без помощников. </li><li>Если по ходу рассказа вам хочется на что-то показать указкой, например, обратить внимание на код в исходниках, акцентировать какое-то место на схеме, воспользуйтесь "хардкод-ом": выделите нужное место или размером/цветом шрифта, или просто цветным прямоугольником. Это поможет слушателям сориентироваться на том, о чем вы сейчас рассказываете, а вам - не отвлекаться на показ.</li></ol><div>Кажется пока все. Как обычно пункты неокончательные, буду стараться прикладывать хорошие примеры. Но потом...</div></div><div><br /></div><div><a href="https://www.maxshulga.ru/2012/02/prepare-to-presentation.html">Тут</a> есть еще немного ссылок и про подготовку, и про само выступление.</div>Maxim Shulga (aka MaxBeard12)http://www.blogger.com/profile/05615743910272666556noreply@blogger.com0tag:blogger.com,1999:blog-6346131298481535631.post-47509894229372485962021-05-28T14:59:00.012+03:002022-12-23T12:57:59.414+03:00Нетехническое собеседование - зачем, полезные вопросы<p>Что может быть целью такого собеседования (или такой части в общем собесе): знакомство с командой, оценка того, насколько человек подойдет в культуру команды и ее процессы, как развивается, что его драйвит, что угнетает.<br /></p><p>Но подход можно использовать и для затравки на технической части собеседования, когда отмечают себе вопросы для дальнейшей беседы.</p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg1IOAc2fDDX6LRcR0d_TgXAIIPtOOOk6tgOj0-MtCv85Pgg77gZJzl9vuAY6HkjT1o20S2y3v5z4QW6Cn88pWMr_idwsKRC2v-DVkXS_q0nOIOf8Zb8GzB9BlZzLrytijCFd3FNHJQqIcf/s660/ikea-interview.jpeg" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="446" data-original-width="660" height="270" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg1IOAc2fDDX6LRcR0d_TgXAIIPtOOOk6tgOj0-MtCv85Pgg77gZJzl9vuAY6HkjT1o20S2y3v5z4QW6Cn88pWMr_idwsKRC2v-DVkXS_q0nOIOf8Zb8GzB9BlZzLrytijCFd3FNHJQqIcf/w400-h270/ikea-interview.jpeg" width="400" /></a></div><p>Простой алгоритм:</p><ul style="text-align: left;"><li>просим кандидата рассказать про текущие задачи/проекты/команду</li><li>внимательно слушаем, записываем полезные для дальнейших вопросов штуки</li></ul><p></p><p>Что может быть полезными штуками (примеры):</p><p></p><ul style="text-align: left;"><li>использование им “терминов” ("отвечаю за качество", "я - devops инженер", "настраиваю CI/CD" и тп)</li><li>части рабочего процесса ("описываю все в документации", "менторю новичков", "помогаю команде")</li><li>рассказ о элементах взаимодействия, поставки задач ("сам себе пишу баги, чтобы не забыть", "задачи на описывание кейсов использования")</li></ul><p></p><p>Дальше по этим записям задаем вопрос начиная с "а вот ты упоминал про...", "как ты это делал<i> (для процессов)</i>" или "что такое..., как ты это понимаешь?" <i>(для терминов)</i></p><p>Не должно быть "закрытых" вопросов, на которые можно ответить "да/нет/социально ожидаемо". Если такие задаются, то только для того, чтобы попросить раскрыть детали дальше.</p><p>Пример:</p><p></p><ul style="text-align: left;"><li>Как менторишь? (лучше через пример в виде "Расскажи, как ты помог коллеге вырасти профессионально.")</li><li>Как пишешь документацию, если времени не хватает</li><li>Как помогаешь команде</li><li>Что такое DevOps для тебя?</li><li>и тп</li></ul><p></p><p>Этот способ еще хорош и тем, что во-первых все вопросы открытые, а во-вторых показывают, что вы внимательно слушаете его рассказ</p><p>Если сам человек плохо про себя рассказывает (такое тоже часто происходит), то вопросы выше все равно хорошо подходят "менторили ли коллег? как?"</p><p>Еще хорошо получаются вопросы о важности человека в команде/bus-factor:</p><p></p><ul style="text-align: left;"><li>Не боишься ли ты уходить в отпуск? Часто ли тебя дергают там?</li><li>Как принимаются решения в команде, какая твоя роль? Какое из последних решений ты предложил? Все ли были согласны с решением? Какие аргументы ты приводил для обоснования решения?</li></ul><p></p><p>Попробуйте задать вопрос на основе ваших текущих задач. </p><p>Примеры для девопса:</p><p></p><ul style="text-align: left;"><li>было ли у вас разное окружение для тестирования? Как вы его делали? Как используется?</li><li>Мониторинги, алерт - как?</li><li>Если сам не делал, то “Как бы делали, с чего бы начали”</li></ul><p></p><p>Если есть какие-то моменты, которые вам очень важны для дальнейшей работы (тут лучше самим определиться какие), то на это обязательно должны быть вопросы. </p><p>По развитию:</p><p></p><ul style="text-align: left;"><li>как ты понимаешь, что вырос профессионально?</li><li>что из того последнего, что узнал нового, удалось применить? </li></ul><p>Есть еще такой список вопросов от одной команд, с которыми работаю:</p><p></p><ul style="text-align: left;"><li>Как привык работать? Как хочется работать? — процессы/команда/коммуникации</li><li>Как приходят задачи? А как хочется и почему? </li><li>Что ты делаешь когда не можешь решить задачу?</li><li>Как решаешь конфликты или спорные моменты в команде? <i>Можно зайти через код-ревью или принятие решений, если кандидат говорит, что нет конфликтов.</i></li><li>Как ты видишь работу в команде? С какими людьми тяжело работать?</li><li>Что нравится/хочется/интересно делать? Почему?</li><li>Что точно не хочется делать/видеть? Что было бы стоп фактором для выхода на работу?</li><li>Есть ли планы по развитию? Как ты изучаешь новое? Что последнее изучил? Как это применил?</li></ul><p></p><p><i><b>Маленькая хитрость: </b>надо научиться встраивать интересующие вопросы в канву диалога, чтобы не было ощущения видеоанкеты, особенно на онлайн-интервью.</i></p><p>Еще <a href="https://www.maxshulga.ru/search/label/%D1%81%D0%BE%D0%B1%D0%B5%D1%81%D0%B5%D0%B4%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F" target="_blank">полезные ссылки</a> на тему интервью.<br />Рекомендую также "<a href="https://www.litres.ru/konstantin-evgenevich-b/brat-ili-ne-brat-ili-kak-sobesedovat-razrabotchika/" target="_blank">Брать или не брать? или Как собеседовать разработчика</a>"<br />Неплохая <a href="https://sandark7.github.io/404Fest2021/" target="_blank">презентация</a> про soft-skills и то, какими вопросами их оценить и <a href="https://youtu.be/M_KyAqPamME" target="_blank">запись этого доклада</a></p>Maxim Shulga (aka MaxBeard12)http://www.blogger.com/profile/05615743910272666556noreply@blogger.com0tag:blogger.com,1999:blog-6346131298481535631.post-34182029111107464802021-04-29T17:48:00.004+03:002022-11-16T18:59:48.308+03:00Flaky тесты (они же моргающие или "случайно успешные")<p>Недавно поучаствовал в Heisenbug Piter 2021 в роли эксперта на <a href="https://heisenbug-piter.ru/2021/spb/talks/4wcc3dephlxuzc87wgwkk7/" target="_blank">очередной серии доклада</a> <a href="https://twitter.com/asolntsev" target="_blank">Андрея Солнцева </a>про flaky тесты.</p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjTlJaw8ahU8R-tyHgKYoJLVxM9cvBzfL5f9zfRkjqla2Y1seBpw_IQSbrEay_8qkusHfnCi3kIdzyEossKdFFCQfhT4SB33NEUAvzIir4MctN6ccMieHTnBn2ErNT8yDlXfG7E9fYKG_Iq/s720/green-lamp.jpeg" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="600" data-original-width="720" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjTlJaw8ahU8R-tyHgKYoJLVxM9cvBzfL5f9zfRkjqla2Y1seBpw_IQSbrEay_8qkusHfnCi3kIdzyEossKdFFCQfhT4SB33NEUAvzIir4MctN6ccMieHTnBn2ErNT8yDlXfG7E9fYKG_Iq/s320/green-lamp.jpeg" width="320" /></a></div><p>Люблю эту тему. Кажется, это своего рода "дебаг", только для тестов. Иногда расследование похлеще приключений Шерлока.<br /></p><p>Тема flaky тестов древняя, как сама отрасль. Первое найденное упоминание термина в традиционных интернетах (типа блогов, твиттеров) в <a href="https://testing.googleblog.com/2008/04/tott-avoiding-flakey-tests.html" target="_blank">2008 году в блоге гугла</a>. Мне больше нравится называть их “моргающие” или, что четче отражает проблему, случайно успешные.</p><p>Давайте еще раз зафиксируем то, что поможет меньше попадать в историю, когда тесты у нас "случайно успешные" и что делать, если уже "вляпались".</p><p>Итак, что делать, чтобы "моргающих" тестов было меньше:</p><p></p><ul style="text-align: left;"><li><b>тесты должны быть написаны в правильном слое</b> "<a href="https://www.maxshulga.ru/2012/04/blog-post_21.html" target="_blank">той самой пирамиды</a>": чем ближе слой к модульным тестам (а лучше именно в них), тем меньше шансов на моргания, потому что зависимостей меньше.</li><li>в ту же тему: чем меньше UI-тестов, тем лучше. Открывая в очередной раз файл с UI-тестами, помни, что <b>тестировать надо "UI", а не "через UI"</b>.</li><li><b>основные причины "моргания"</b> это асинхронные операции (async wait), многопоточность (concurrency), порядок тестов, утечка ресурсов, проблемы с зависимостями (сеть, время). Поэтому, чем меньше этого в тестах, тем они стабильнее.</li><li>основной объем бизнес-логики проверяем максимально близко к месту логики (см.пункт про слои) и с максимальным количеством <a href="https://www.maxshulga.ru/2012/03/mock-vs-stub.html" target="_blank">замокированных зависимостей</a> (но не переусердствуйте, а то <a href="https://www.maxshulga.ru/2013/06/mockoveruse.html" target="_blank">будут другие проблемы</a>)</li></ul><div>К сожалению, полностью избавиться от flaky тестов сложно (окружение, сложные сценарии, много зависимостей), а местами просто дорого (по времени и ресурсам).</div><div><br />Что делать, если они появились?<br /><ul style="text-align: left;"><li>разбирайтесь с проблемой падения максимально быстро. Не надо держать в наборе запускаемых тестов тот, доверия к результатам которого нет.<br /></li><li>если сейчас нет возможности разобраться с ошибкой, <a href="https://martinfowler.com/articles/nonDeterminism.html" target="_blank">переместите этот тест в "карантин"</a>, чтобы позже с ним разобраться. <i>Не надо держать в наборе запускаемых тестов тот, доверия к результатам которого нет - 2.</i></li><li>если вы тестировщик, смотрите код тестируемого приложения. Часто проблемы с "морганиям" проще понять и поправить именно там. По <a href="http://mir.cs.illinois.edu/lamyaa/publications/fse14.pdf" target="_blank">статистике</a> (2014 год) до 25% исправлений моргающих тестов делается в продакшен коде приложения.</li><li>привлекайте разработчиков, если сами не можете разобраться в коде.</li><li>активно используйте трейсинг (логирование) в тестах и продакшен-коде для того, чтобы воспользоваться ими при расследовании. <i><b>Совет</b>: здорово, если у вас есть возможность "объединить" логи тестируемой системы с логами тестов. Мы активно использовали запись меток о начале/завершении теста в продакшен логах приложения. Очень помогало.</i></li><li>для UI-тестов (<i>помните про "через UI"?</i>) имейте возможность включить запись видео или скриншоты в момент проверки</li><li>попробуйте переместить моргающую проверку на другой слой пирамидки</li><li>если тест не поддается и продолжает моргать, подумайте, может стоит его удалить? Все равно смысла от него немного, особенно если думать про него не "случайно упавший", а "<a href="https://www.thoughtworks.com/insights/blog/no-more-flaky-tests-go-team" target="_blank">случайно успешный</a>". Ну и в целом "<a href="https://twitter.com/alanpage/status/527152298238439424" target="_blank">Flaky tests are worse than _no_ tests</a>".</li><li>иногда <a href="https://twitter.com/maxbeard12/status/1377921544287092741" target="_blank">советуют перезапускать упавшие </a>тесты в надежде на удачу. В целом рабочий способ, но не надо им злоупотреблять. Он хорошо помогает с подтверждением проблемы и поиском test war. Но обнаруженные проблемы, например, с медленной инфраструктурой/сетью, особенностями фреймворков важно всегда фиксировать и планировать время на исправление.</li></ul></div><p></p><p>Полезные ссылки:</p><p></p><ul style="text-align: left;"><li><a href="http://goblingame.blogspot.com/2013/02/blog-post.html" target="_blank">Про перезапуск тестов</a></li><li><a href="https://www.maxshulga.ru/2016/12/gtac-2016-how-flaky-tests-in-continuous.html" target="_blank">Про моргающие тесты в Gmail</a></li><li><a href="http://mir.cs.illinois.edu/lamyaa/publications/fse14.pdf" target="_blank">An Empirical Analysis of Flaky Tests</a></li><li><a href="https://www.thoughtworks.com/insights/blog/no-more-flaky-tests-go-team" target="_blank">No more flaky tests</a></li><li><a href="https://martinfowler.com/articles/nonDeterminism.html" target="_blank">Eradicating Non-Determinism in Tests</a></li><li><a href="http://artkoshelev.github.io/posts/flaky-tests" target="_blank">Один из вариантов работающего подхода</a> по исправлению "моргающих" тестов</li><li><a href="https://engineering.fb.com/2020/12/10/developer-tools/probabilistic-flakiness/" target="_blank">How do you test your tests? (probabilistic flakiness score)</a></li></ul><p></p>Maxim Shulga (aka MaxBeard12)http://www.blogger.com/profile/05615743910272666556noreply@blogger.com0tag:blogger.com,1999:blog-6346131298481535631.post-61547701887314394292021-02-22T15:02:00.005+03:002024-03-16T20:59:19.699+03:00Через призму менеджера про "Никаких правил. Уникальная культура Netflix."<div style="text-align: left;"><div>Последовал <a href="https://twitter.com/eao197/status/1362813354813882373" target="_blank">совету</a>. Пусть это будет очередным отзывом, но точно не рассказом про концепцию"рок-звезд". Я нашел в <a href="https://www.amazon.com/No-Rules-Netflix-Culture-Reinvention/dp/1984877860" target="_blank">книге</a> ответы на те вопросы-сомнения, что вертелись в голове практически с того момента, как я стал менеджером.</div><div><br /></div><div>Или может быть даже не ответы, а подкрепление верности своих действий, своего поведения или просто подтверждения факта, что "я не один такой".</div><div><br /></div><div>После прочтения <a href="https://habr.com/ru/company/ruvds/blog/541994/" target="_blank">статьи с Хабра</a> первой мыслью, которая меня посетила была "а ведь вся эта история держится только на хороших менеджерах (лидерах?)". </div><div>Книга добавила ясности и деталей в эти размышления и позволила порефлексировать.</div><div><br /></div><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgt8H7L0NaU-s2NK1x9Ua9NH3K7R0zD6ZLOpm7_HWnYv9rgr1NKlSoC7LSLBEK1pt4jgsoeN5uhd2eVwsaRtKntDOvAh8ORwMFD6_WN3z_ldB6aM9CoghRwNFPvQznGH9j-3t3ATEzPzGTJ/s1220/%25D1%2587%25D0%25B5%25D1%2581%25D1%2582%25D0%25BD%25D0%25BE%25D1%2581%25D1%2582%25D1%258C+-+%25D0%25B2%25D1%2581%25D0%25B5%25D0%25B3%25D0%25B4%25D0%25B0.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="704" data-original-width="1220" height="231" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgt8H7L0NaU-s2NK1x9Ua9NH3K7R0zD6ZLOpm7_HWnYv9rgr1NKlSoC7LSLBEK1pt4jgsoeN5uhd2eVwsaRtKntDOvAh8ORwMFD6_WN3z_ldB6aM9CoghRwNFPvQznGH9j-3t3ATEzPzGTJ/w400-h231/%25D1%2587%25D0%25B5%25D1%2581%25D1%2582%25D0%25BD%25D0%25BE%25D1%2581%25D1%2582%25D1%258C+-+%25D0%25B2%25D1%2581%25D0%25B5%25D0%25B3%25D0%25B4%25D0%25B0.png" width="400" /></a></div><div><br /></div><div>Далеко не каждый менеджер может быть честным, откровенным и открытым. Это сложно. А нужно еще и своих сотрудников учить быть такими. И, что немаловажно, эти все понятия и принципы тесно связаны и хорошо работают именно в комплексе и в обоюдном применении.</div><div><br /></div><div>В итоге, если менеджер <strike>говно</strike> не справляется, то с его сотрудниками будет ровно то, про что писали в комментах к Хабро-статье: выгорание, давление от дамоклова меча увольнения, "бешеные галеры" и тдтп.</div><div><br /></div><div>В своей работе всегда старался быть максимально честным. Всегда думал, что это, эммм, мой недостаток, как менеджера. В книге есть тесты на открытость. Все мои ответы совпали с мнением основателя Netflix. Значит не все так плохо. Плохо то, что сложно быть честным и открытым там, где остальные к этому не готовы. Не готовы слушать/слышать правду, могут одним говорить то, что не готовы высказать всем. Приходится постоянно держать в голове эти моменты и фильтровать свои посылы.</div><div><br /></div><div>Немного интересных фактов из книги и то, как это "стрельнуло" у меня.</div><div><br /></div><div><b>Про пересмотр ЗП</b></div><div>"<i><span style="color: #0b5394;">«прибавочные» фонды и зарплатные вилки оправдывали себя в те времена, когда текучка кадров была очень низкой, а индивидуальная рыночная стоимость сотрудника крайне редко взлетала до потолка всего за несколько месяцев. Однако в современных условиях это, очевидно, уже неактуально — если учесть, как стремительно меняется экономическая ситуация и с какой легкостью профессионалы в наши дни меняют работу.</span></i>"</div><div><br /></div><div>"<i><span style="color: #0b5394;">В 2018 году средняя прибавка зарплаты в США составила около 3% (для особо ценных сотрудников — 5%). Те же, кто решил сменить место работы, в среднем стали получать на 10–20% больше. Верность работодателю плохо сказывается на состоянии финансов.</span></i>"</div><div><br /></div><div>Бывшие, и, думаю, некоторые нынешние коллеги, могут подтвердить, что всегда спокойно относился к рассказам про походы на собесы в другие компании. Некоторых даже уговаривал сходить на собесы, потому что так проще себя оценить. А иногда это еще и единственный способ повысить себе зп, потому что мало где к зп относятся так, как в Netflix.</div><div><br /></div><div><i>"<span style="color: #0b5394;">любой разговор с потенциальным членом команды призван донести до него два ключевых момента: работодатель хорошо осведомлен, сколько этому сотруднику могут заплатить в других компаниях, и готов предложить больше</span>"</i></div><div>Жаль, что далеко не всегда в наших реалиях, ты можешь решить вопрос с пересмотром только потому, что считаешь, что сотрудник должен получать больше. Помниться однажды мне пришлось угрожать своим уходом, чтобы повысить зп одному из разработчиков в своей команде. </div><div><br /></div><div>"<span style="color: #0b5394;"><i>Он мысленно отрепетировал, как будет уходить от ответов на вопросы о зарплате. Однако во время собеседования он все равно выложил опытному рекрутеру, сколько зарабатывает сейчас и сколько хотел бы получать</i>.</span>" - Хахаха, да это ж я.</div><div><br /></div><div><b>Немного про критику и откровенность</b></div><div>"<span style="color: #0b5394;"><i>Слышать критические замечания в свой адрес неприятно и некомфортно, но, после того как отпустит изначальный стресс, они идут на пользу</i>". "<i>Мало кому нравится критика в свой адрес. Когда ругают нашу работу, нас накрывает чувство собственной никчемности.</i></span>"</div><div><br /></div><div>Несмотря на то, что в Netflix декларируется отсутствие правил, на самом деле правила есть, есть инструкции, где прописано, что такое эффективная и конструктивная критика.</div><div><br /></div><div><div>"<span style="color: #0b5394;"><i>Принцип откровенности вовсе не означает, что можно произносить все, что придет в голову, не заботясь о чувствах собеседника. Напротив, он требует неукоснительно и скрупулезно </i><i>соблюдать четыре правила здоровой критики. Для этого необходимо тщательно взвешивать формулировки, а иногда заранее готовиться, прежде чем высказать критическое замечание, </i><i>и учить тому же весь персонал.</i></span>"</div></div><div><br /></div><div><b>Четыре правила откровенности/критики (</b>в этом месте ничего необычного, это то, что всегда называют конструктивной критикой<b>)</b></div><div><i>Для критика</i></div><div>1. Стремись помочь. </div><div>2. Предлагай конкретные меры.</div><div>3. Чтобы получить нужный результат, адаптируй формулировки и учитывай культурный контекст (<i>здесь речь про национальные культурные особенности</i>).</div><div><i>Для адресата</i></div><div>4. Будь благодарен.</div><div>5. Прими или отклони.</div><div><br /></div><div>"<span style="color: #0b5394;"><i>В Netflix вы получите множество замечаний и соображений. Их необходимо внимательно выслушать, обдумать сказанное, принять к сведению. Но вы не обязаны принимать их все как </i><i>руководство к действию. Вежливо и искренне поблагодарите критика. Но и вы, и он должны понимать: следовать его советам или нет — ваше и только ваше решение.</i></span>"</div><div><br /></div><div>"<i><span style="color: #0b5394;">Провозгласить, что в компании ценится откровенность, — одно. Следовать этому принципу, когда организация растет, когда постоянно приходят новые люди и сеть отношений в коллективе становится все гуще и сложней, — совсем другое.</span></i>"</div><div><br /></div><div><b>Свободные отпуска</b></div><div>Первая моя мысль про "свободные отпуска" - да они же там или вообще не ходят, или наоборот "все дружно ушли, работать некому". В итоге действительно было и, видимо, есть и то, и то.</div><div><br />И здесь опять важна роль менеджера, который должен подавать правильный пример. В тех отделах, которые не ходят в отпуск, как правило <b>менеджер тоже не ходит</b>. Это лишний раз подтверждает тезис, что при плохом менеджере будут проблемы.</div><div><br /></div><div>При этом, в отсутствие четко прописанных правил и графиков отпусков, каждый руководитель должен регулярно объяснять команде, какие решения и поступки можно считать оправданными и допустимыми, например «в отпуск можно уходить только по очереди и только в такое время, когда это не подведет всю команду». Океей, ну то есть заменили общие правила на ожидания менеджера. И снова качество применения принципов зависит от менеджера.</div><div><br /></div><div>"<b>Если я задумаюсь о смене работы, вы будете меня удерживать?</b>"</div><div>Хороший вопрос. Интересно, как много руководителей готовы на него ответить. И сколько способов/инструментов удержания будет у тех, кто ответит "Да". </div><div><br /></div><div><b>Стоит ли руководителю открыто говорить про свои ошибки?</b></div><div>"<span style="color: #0b5394;"><i>Здоровая самокритика укрепляет доверие; обращаясь за помощью, мы учимся новому; признавая ошибки, мы получаем прощение, а честно рассказывая о неудачах, побуждаем других </i><i>действовать смелее.</i></span>"</div><div>Всегда спокойно говорю о своих продолбах. Но, допускаю, что слишком часто. А если к вам, как к руководителю относятся с недоверием, то признание в своих ошибках может сыграть в отрицательную сторону. Интересно, как часто я своими признаниями только усугублял дело.</div><div><br /></div><div>"<span style="color: #0b5394;"><i>Эта тенденция восприятия так и называется: эффект оплошности. Психологи отметили, что привлекательность человека в наших глазах может либо вырасти, либо понизиться после </i><i>допущенной им ошибки — в зависимости от того, как этот человек зарекомендовал себя в целом.</i></span>"</div><div><br /></div><div>Вот пожалуй и все, что цепануло. Еще была интересная глава про национальные культурные различия и то, что пришлось менять, как подстраивать принципы Netflix из-за этого. Но тут у меня мало личных примеров.</div><div><br /></div><div>Интересно было бы узнать, как в Netflix занимаются развитием менеджеров. Есть ли там что-то типа <a href="https://www.maxshulga.ru/2020/02/google-oxygen-project.html" target="_blank">активностей у Google</a>?</div><div><br /></div><div>Стоит ли читать книгу, если все ценности и принципы <a href="https://www.slideshare.net/MikePritula/netflix-71827693" target="_blank">описаны на слайдах</a>? Скорее да. Лучше доходит через примеры, которые взяты из рассказов нынешних и бывших сотрудников Netflix.</div></div>Maxim Shulga (aka MaxBeard12)http://www.blogger.com/profile/05615743910272666556noreply@blogger.com0tag:blogger.com,1999:blog-6346131298481535631.post-7326655320232281532020-08-10T20:07:00.003+03:002020-08-11T09:49:54.186+03:00"The Ongoing Revolution in Software Testing" by Cem Kaner (2004) - разбор общепринятых утверждений о тестировании/тестировщиках<div>Благодаря давнишнему твиту <a href="https://twitter.com/alanpage/status/1215843723075964930" target="_blank">Alan Page</a> узнал про <a href="http://www.kaner.com/pdfs/TheOngoingRevolution.pdf" target="_blank">чудесную статью Cem Kaner</a>, который еще в 2004 году разобрал популярные утверждения (мифы?) про тестирование и роль тестировщиков.</div><div><br /></div><div><div>Что именно так разбирается:</div><div><br /></div><div><b>The Role of Testers</b></div><div>• The primary reason to test is to find bugs?</div><div>• The primary reason to test is to prove the program works correctly?</div><div>• Testers are THE advocates of quality on a project.</div><div>• Test groups should evolve into quality assurance groups.</div><div>• The test group should have the power to block release if product quality is too low.</div><div>• Testers and programmers have conflicting interests.</div><div>• The test group should work independently of the programmers.</div><div>• Testers should push their project teams to follow "appropriately professional</div><div>development models," like the Waterfall, that require people to THINK before they act.</div></div><div>• 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. </div><div>• The primary reason to test is to find bugs. </div><div>• The primary reason to test is to prove the program works correctly.</div><div><br /></div><div><b>Test Planning and Documentation</b></div><div>• Testers should specify the expected result of every test, in advance.</div><div>• Exploratory testing, if done at all, should be done only by experts.</div><div>• There should be at least one thoroughly documented test for every requirement item or</div><div>specification item.</div><div>• Testers should design most or all tests early in development.</div><div>• Testers should design all tests for reuse as regression tests.</div><div>• Testers should document manual tests in great procedural detail so that they can be</div><div>handed down to less experienced or less skilled testers.</div><div>• Testers should document each test case individually, ideally storing them in a test case</div><div>management system that describes the preconditions, procedural details, postconditions,</div><div>and basis (such as trace to requirements) of each individual test.</div><div><br /></div><div><div><b>The Practice of Testing</b></div><div>• Testers should assume that the programmers did a light job of testing and so should</div><div>extensively cover the basics (such as boundary cases for every field).</div><div>• Testers should develop automated tests at the user interface level.</div><div>• Testers should design tests without knowledge of the underlying code.</div><div>• Testers should design the build verification tests, even the ones to be run by</div><div>programmers.</div><div>• Most testers don't need to be programmers, because they only have to specify how the</div><div>external program will behave in their tests. Testing tools will allow business experts to</div><div>develop automated tests without having to program.</div><div>• The pool of tests should cover every line and branch in the program, or perhaps every</div><div>basis path.</div><div>• All failures must be reported into a bug tracking system and carefully counted.</div><div>• We can measure the individual effectiveness of software testers by counting how many</div><div>bugs they find, perhaps with an adjustment for bug severity.</div><div>• We can tell how close we are to release of the product by examining the bug curve that</div><div>shows bug finds per week.</div></div><div><br />Все тут обсуждать/переводить не буду, оставлю только то, что очень зацепило. Но вы обязательно почитайте все остальное тоже, если интересуетесь организацией процесса тестирования или вашем местом в этом процессе.</div><div><br /></div><div><b>QA - точно про assurance?</b></div><div>Попробуйте ответить на эти вопросы и еще раз подумать действительно ли вы сейчас QA-инженер?<br /></div><div>• Do testers have the authority and cash to provide training for programmers who need it?</div><div>• Do testers have the authority to settle customer complaints? Or to drive the handling of</div><div>customer complaints?</div><div>• Do testers have the ability and authority to fix bugs?</div><div>• Do testers have the ability and authority to either write or rewrite the user manuals?</div><div>• Do testers have the ability to study customer needs and design the product accordingly?</div><div><br /></div><div><b>"Каждый тест должен иметь ожидаемый результат"</b></div><div><div>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.</div></div>Maxim Shulga (aka MaxBeard12)http://www.blogger.com/profile/05615743910272666556noreply@blogger.com0tag:blogger.com,1999:blog-6346131298481535631.post-21571700730663211542020-08-05T09:00:00.038+03:002023-06-30T18:00:17.513+03:00Обычные и не очень вопросы к собеседованию на позицию Engineering ManagerНавеяно <a href="https://twitter.com/mipsytipsy/status/1286485343370276866" target="_blank">тредом под вопросом Charity Majors</a>, своими собеседованиями и собеседованиями меня :)<br /><br />Может кто найдет что-нибудь интересного себе. Кстати, многие из этих вопросов можно задавать нанимающему менеджеру.<div><br /><i><b>Disclaimer:</b></i></div>Порядка, приоритета в вопросах ниже нет. <br />Необходимость и момент их вопрошания зависит от течения беседы. <br />На полноту и ценность для вас список определенно не претендует.<div>Этот список не значит, что на собеседовании со мной вы услышите именно эти вопросы.<br /><div><div><br /></div><div>1. Что мотивирует людей вообще (немного теории, а-ля Маслоу, Герцберг, <a href="https://www.gamified.uk/gamification-framework/the-intrinsic-motivation-ramp/" target="_blank">RAMP</a> и тдтп в том числе просто "своими словами"). Что мотивирует вас? Ну и дальше про то, как использовалось в работе. Как работали с так называемыми "underperformance" товарищами?</div><div><br /></div><div>2. Лидерство vs "быть начальником" - что это для вас? Как вы определяете лидерство?<div><br /></div><div>3. Карьерный рост для разработчиков в ваших командах. Как они растут? Что для вас этот рост, что вы думаете о грейдах (уровнях)? Какой процесс оценки уровня разработчика? Опишите последний случай, когда вы повлияли на карьерный рост вашего сотрудника.</div><div><br /></div><div>4. Как у вас устроен процесс онбординга, есть ли менторинг для новичков/всех сотрудников?</div><div><br /></div><div>5. Что такое техническое качество? Что такое качество? Как вы его оцениваете? Какие метрики используете?</div><div><br /></div><div>6. Как принимаются технические решения в вашей команде (командах)? </div><div><br /></div><div>7. Что такое технический долг, как с ним бороться? Как соблюдать баланс между "быстро делать" и "делать хорошо", имеет ли право на жизнь такой вопрос в принципе? Чем может отличаться подход на разных стадиях развития проекта/продукта.</div><div><br /></div><div>8. Как было устроено планирование, как вы работаете с приоритезацией?</div><div><br /></div><div>9. Как учиться на ошибках? </div><div><br /></div><div>10. Самая большая ваша ошибка, как менеджера. Чему вы из нее научились?<br /><div><br /></div></div><div>11. Как вы понимаете, как обстоят дела в команде (то что называют "healthy state"), насколько она продуктивна, есть ли развитие?<br /><br /></div><div>12. На сколько вы умножаете ответ разработчика в вопросе оценки сроков? (кстати, а вы знаете <a href="https://twitter.com/bobuk/status/636252417089212416" target="_blank">про формулу Бобука</a>?)</div><div><br /></div><div>13. Опишите ваш обычный рабочий день.</div><div><br /></div><div>14. Почему вы не хотите быть менеджером?</div><div><br /></div><div>15. С какими конфликтными ситуациями вам приходилось сталкиваться и как вы их решали?</div><div><br /></div><div>16. Какой у вас формат встречи 1:1?<br /></div><div><br /></div><div>17. Как вы поймете, что ваша работа выполняется хорошо? </div><div><br /></div><div>18. Как вы взаимодействовали с другими менеджерами на одном с вами уровне?</div><div><br /></div><div>19. Как был организован обмен знаниями между разработчиками?</div><div><br /></div><div>20. За что бы вы сразу уволили сотрудника? Приходилось ли увольнять и почему?</div><div><br /></div><div>Еще немного ссылок:<br /><ul><li><a href="https://rushabhdoshi.com/2019/11/04/hiring-engineering-leaders.html" target="_blank">Hiring Engineering Leaders</a></li><li><a href="https://a16z.com/2017/05/26/hiring-vp-engineering-why-what/" target="_blank">Hire a VP of Engineering</a></li><li><a href="https://karimfanous.substack.com/p/how-do-you-interview-a-vp-of-engineering" target="_blank">How to interview a VP of Engineering</a></li><li><a href="https://chelseatroy.com/2018/05/04/questions-for-prospective-managers/" target="_blank">Questions for Prospective Managers</a></li><li><a href="https://www.maxshulga.ru/2017/12/hiring-interview-probation.html" target="_blank">Немного про наём, собеседование и испытательный срок от вашего КО</a> (меня)</li><li><a href="https://www.maxshulga.ru/2020/07/who-is-teamlead.html" target="_blank">Тут можно почитать немного про ресурсы</a>, которые могут помочь вам в работе (или на собесе)</li></ul></div><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhG5E9gGaCjfvq0vExsb8jBsbPzqoUV8ZJexhsAYRco3u4dt3Z-BUprPhmA2z8TuDnXBDNDRxdFVehX_2Tf18FTKmX8Srsq0KsyEeBjowDFJgyKdtaSv55hJNLe2a-Ni9VelSQl2pQyg89-/s960/%25D1%2581%25D0%25BE%25D0%25B1%25D0%25B5%25D1%2581%25D0%25B5%25D0%25B4%25D0%25BE%25D0%25B2%25D0%25B0%25D0%25BD%25D0%25B8%25D0%25B5-%25D0%25B2%25D1%258B+%25D0%25BF%25D1%2580%25D0%25B8%25D0%25BD%25D1%258F%25D1%2582%25D1%258B.jpeg" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="960" data-original-width="720" height="640" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhG5E9gGaCjfvq0vExsb8jBsbPzqoUV8ZJexhsAYRco3u4dt3Z-BUprPhmA2z8TuDnXBDNDRxdFVehX_2Tf18FTKmX8Srsq0KsyEeBjowDFJgyKdtaSv55hJNLe2a-Ni9VelSQl2pQyg89-/s640/%25D1%2581%25D0%25BE%25D0%25B1%25D0%25B5%25D1%2581%25D0%25B5%25D0%25B4%25D0%25BE%25D0%25B2%25D0%25B0%25D0%25BD%25D0%25B8%25D0%25B5-%25D0%25B2%25D1%258B+%25D0%25BF%25D1%2580%25D0%25B8%25D0%25BD%25D1%258F%25D1%2582%25D1%258B.jpeg" /></a></div><div><br /></div><div><br /></div></div><div><br /></div></div></div>Maxim Shulga (aka MaxBeard12)http://www.blogger.com/profile/05615743910272666556noreply@blogger.com0tag:blogger.com,1999:blog-6346131298481535631.post-54910664575913051642020-07-27T20:19:00.037+03:002023-04-09T14:00:05.026+03:00Тимлид - таинственная роль в реальном мире или фантастические твари среди нас<div style="text-align: right;"><i>Черновик с набором ссылочек долго мариновался и вот дождался потребности в себе. </i></div><div style="text-align: right;"><i>Пусть теперь лежит публично.</i></div><div><br /></div><div><br /></div><div>История <a href="https://www.facebook.com/maxim.shulga.777/posts/2653792614633643" target="_blank">началась год назад</a> (твою ж дивизию, вот я торопыга...) с обсуждения в комментах того, что это за роль/должность такая "тимлид". Пересказывать обсуждение тут смысла не вижу, кому интересно - <a href="https://www.facebook.com/maxim.shulga.777/posts/2653792614633643" target="_blank">велком в тред.</a></div><div><br /></div><div>Спустя год тема получила свое продолжение в твиттере Никиты Макарова</div><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh9spxNBduIoGz-9IHa-L80LWOPBLih6C4YOIw00WJvQL2sCesbXcT70-na00_tEa2QGl3ErX25J9bcyIOLIJg4vI-949_f9zguTgShczSnus1DucNNFJWEoRRfZovdkj1sfHMqzPtxdkKt/s1160/%25D1%2582%25D0%25B8%25D0%25BC%25D0%25BB%25D0%25B8%25D0%25B4+-+%25D1%258D%25D1%2582%25D0%25BE+%25D0%25BB%25D0%25B8%25D1%2587%25D0%25B8%25D0%25BD%25D0%25BA%25D0%25B0+%25D0%25BC%25D0%25B5%25D0%25BD%25D0%25B5%25D0%25B4%25D0%25B6%25D0%25B5%25D1%2580%25D0%25B0.png" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="588" data-original-width="1160" height="203" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh9spxNBduIoGz-9IHa-L80LWOPBLih6C4YOIw00WJvQL2sCesbXcT70-na00_tEa2QGl3ErX25J9bcyIOLIJg4vI-949_f9zguTgShczSnus1DucNNFJWEoRRfZovdkj1sfHMqzPtxdkKt/w400-h203/%25D1%2582%25D0%25B8%25D0%25BC%25D0%25BB%25D0%25B8%25D0%25B4+-+%25D1%258D%25D1%2582%25D0%25BE+%25D0%25BB%25D0%25B8%25D1%2587%25D0%25B8%25D0%25BD%25D0%25BA%25D0%25B0+%25D0%25BC%25D0%25B5%25D0%25BD%25D0%25B5%25D0%25B4%25D0%25B6%25D0%25B5%25D1%2580%25D0%25B0.png" width="400" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;"><span style="text-align: start;"><a href="https://twitter.com/PapaMinos/status/1256895390961545216" target="_blank">лайкни оригинальный твит</a></span></td></tr></tbody></table><div><br /></div><div>Я думал описать свое видение этой роли, но кому это может быть интересно: жизнь не черно-белая, у всех разные ситуации, забил короче. А вот полезных ресурсов чуток накопилось, поэтому пусть нанесут пользу кому-нибудь. Но какой либо системности просьба не ожидать.</div><div><br /></div><div><i><b>Disclamer</b></i>: если вы только рассматриваете для себя роль лида, технического менеджера и тп, подумайте, оно вам действительно надо, обратно пути может не быть. Ну и опять же, я б учитывал такой забавный момент:</div><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhCcnVF8Y6353H4nKATbEeKD6pFPS4OrWt59DPARK1rOWWLRRXZh__hOhPfj1iVO-TEsdHftMvCo0la4XOnpoJfrbcSD7lFHocQ7kE9FPTsf0jaOkYF72LMP71l60XkmWacEIcfP7A3qZxZ/s1180/%25D0%25BC%25D0%25B5%25D0%25BD%25D0%25B5%25D0%25B4%25D0%25B6%25D0%25BC%25D0%25B5%25D0%25BD%25D1%2582+-+%25D0%25BE%25D0%25B6%25D0%25B8%25D0%25B4%25D0%25B0%25D0%25BD%25D0%25B8%25D1%258F+vs+%25D1%2580%25D0%25B5%25D0%25B0%25D0%25BB%25D1%258C%25D0%25BD%25D0%25BE%25D1%2581%25D1%2582%25D1%258C.png" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="824" data-original-width="1180" height="279" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhCcnVF8Y6353H4nKATbEeKD6pFPS4OrWt59DPARK1rOWWLRRXZh__hOhPfj1iVO-TEsdHftMvCo0la4XOnpoJfrbcSD7lFHocQ7kE9FPTsf0jaOkYF72LMP71l60XkmWacEIcfP7A3qZxZ/w400-h279/%25D0%25BC%25D0%25B5%25D0%25BD%25D0%25B5%25D0%25B4%25D0%25B6%25D0%25BC%25D0%25B5%25D0%25BD%25D1%2582+-+%25D0%25BE%25D0%25B6%25D0%25B8%25D0%25B4%25D0%25B0%25D0%25BD%25D0%25B8%25D1%258F+vs+%25D1%2580%25D0%25B5%25D0%25B0%25D0%25BB%25D1%258C%25D0%25BD%25D0%25BE%25D1%2581%25D1%2582%25D1%258C.png" width="400" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;"><a href="https://twitter.com/GoblinGame/status/1258671872859832320" target="_blank">лайкни оригинальный твит</a><br /></td></tr></tbody></table><div><br /></div><div>Ну, если не передумали, то начнем.</div><div><br /></div><div>А начинать я бы рекомендовал с этой книги, очень хорошо все описано. </div><div>Камиль Фурнье (<a href="https://twitter.com/skamille" target="_blank">Camille Fournier</a>) “<a href="https://www.mann-ivanov-ferber.ru/books/ot-razrabotchika-do-rukovoditelya/" target="_blank">От разработчика до руководителя</a>” (<a href="https://www.amazon.com/Managers-Path-Leaders-Navigating-Growth/dp/1491973897" target="_blank">оригинал</a>)</div><div><br /></div><div>Из недостатков книги: кажется в "СНГ" IT-мире, все же есть отличие в понимании роли от условно-западного мира. </div><div>Но медленно все смещается в правильную сторону, а именно:</div><div>"<b>Team leader</b>: <i>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</i>." (<a href="http://www.businessdictionary.com/definition/team-leader.html" target="_blank">ссылка на определение</a>). </div><div><br /></div><div>Ну, то есть вроде действительно не менеджер, а личинка. Чтобы превратится в менеджера, нужно потрудиться над собой. А может в процессе и выяснится, что это вам не интересно.</div><div><br /></div><div>Что почитать еще (литературы для менеджеров вагон и еще 10к вагонов, поэтому тут просто то, что нравится мне):</div><div><ul style="text-align: left;"><li>“<a href="https://www.theengineeringmanager.com/book/" target="_blank">Become an Effective Software Engineering Manager</a>” James Stanier (у автора еще и интересный <a href="https://www.theengineeringmanager.com/" target="_blank">блог</a>)</li><li>"Драйв. Что на самом деле нас мотивирует" Дэниел Пинк</li><li>"Руководство Джоэла Спольски по подбору программистов и управлению ими" Джоэл Х. Спольски</li><li>"Эффективный руководитель" Питер Друкер</li><li>"Одноминутный менеджер и обезьяны" Кеннет Бланшар</li><li>"<a href="https://www.litres.ru/konstantin-evgenevich-b/brat-ili-ne-brat-ili-kak-sobesedovat-razrabotchika/chitat-onlayn/" target="_blank">Брать или не брать? Как собеседовать разработчиков</a>"</li><li>"<a href="https://stratoplan-school.com/Storage/books/pdf/stratoplan_black_book.pdf" target="_blank">Черная книга менеджера</a>" Вячеслав Панкратов (мозговстрях)</li></ul></div><div><br /></div><div>Статьи (в том числе пару моих, с ревью книг):</div><div><ul style="text-align: left;"><li>“<a href="https://charity.wtf/2019/01/04/engineering-management-the-pendulum-or-the-ladder/" target="_blank">Engineering management: the pendulum or the ladder</a>”</li><li>“<a href="https://blog.pragmaticengineer.com/how-to-to-become-an-engineering-manager/" target="_blank">How Can I Prepare to Eventually Move into Engineering Management?</a>”</li><li>“<a href="https://angelariggs.github.io/articles/advice-for-new-managers" target="_blank">Advice for New Managers</a>”</li><li>“<a href="https://www.maxshulga.ru/2013/03/blog-post.html" target="_blank">Отзыв-конспект "Общаться с ребенком. Как?</a>"</li><li>“<a href="https://www.patkua.com/blog/the-definition-of-a-tech-lead/" target="_blank">The Definition of a Tech Lead</a>”</li><li>“<a href="https://www.thekua.com/atwork/2015/06/tech-lead-circles-of-responsibility/" target="_blank">Tech Lead – Circles of Responsibility</a>”</li><li>“<a href="https://www.patkua.com/blog/5-engineering-manager-archetypes/" target="_blank">5 Engineering Manager Archetypes</a>”</li><li>“<a href="https://www.forbes.ru/karera-i-svoy-biznes/371541-naprasnye-slova-kak-davat-obratnuyu-svyaz-s-uchetom-raboty-mozga" target="_blank">Напрасные слова. Как давать обратную связь с учетом работы мозга</a>”</li><li>“<a href="https://www.maxshulga.ru/2014/09/ideal-it-team.html" target="_blank">Обзор-неконспект "Идеальная IT-компания. Как из гиков создать команду программистов</a>”</li><li>“<a href="https://habr.com/ru/company/oleg-bunin/blog/456512/" target="_blank">Мотивация, делегирование и автоматизация: рецепт создания суперкоманды</a>“ (текстовка очень полезного доклада) и материалы от докладчика:</li></ul></div><div><ul style="text-align: left;"><ul><li><a href="https://goo.gl/3asJCu" target="_blank">Презентация</a></li><li><a href="https://hackmd.io/s/r1PmSwIw4" target="_blank">Наши принципы</a></li><li><a href="https://hackmd.io/s/rJFGNEYP4" target="_blank">Алгоритм тех. ревью</a></li><li><a href="https://goo.gl/MrMUvo" target="_blank">Шаблон демо</a></li><li><a href="https://justpaste.it/6uptv" target="_blank">Правила канала</a></li></ul></ul></div><div>Та самая "<a href="https://tlroadmap.io/" target="_blank">карта компетенций тимлида</a>", с которой все началось. Отлично подойдет для начальной систематизации того, чем возможно придется заниматься, в зависимости от понимания роли в компании.</div><div><br /></div><div>Интересная шпаргалка "<a href="https://techlead-maturity-model.github.io/" target="_blank">Модель зрелости техлида</a>".</div><div><br /></div><div>Неожиданная ссылка, особенно с учетом того, что тимлидов предпочитают выращивать внутри компании, <a href="https://www.youtube.com/watch?v=ulYP1V4BzII" target="_blank">доклад про шаги человека пришедшего в команду снаружи</a>.</div><div><br /></div><div>Ну и нельзя не посоветовать доклады <a href="https://twitter.com/bunopus" target="_blank">Жени Кота</a>:</div><div><ul style="text-align: left;"><li>"<a href="https://www.youtube.com/watch?v=7fnY8WVtElY" target="_blank">Теперь я - тимлид, но почему мне так плохо? Практические советы</a>"</li><li>"<a href="https://www.youtube.com/watch?v=vkw_vr3dbH0" target="_blank">Про инженерный шовинизм: отвратительно быть менеджером</a>"</li></ul><div>Еще один хороший доклад для начинающих и сомневающихся</div></div><div><ul style="text-align: left;"><li><a href="https://youtu.be/1mIcdj_ZXT8" target="_blank">Почему не надо становиться руководителем, Андрей Смирнов</a></li></ul></div><div><br /></div><div>Получилось очень лаконично, точно несистематизированно и разношерстно. </div><div>Но, если у кого будут вопросы по конкретике - пишите (<a href="https://twitter.com/maxbeard12" target="_blank">twitter</a>, <a href="https://t.me/maxbeard12" target="_blank">telegram</a>), с удовольствием пообщаюсь.</div><div><br /></div><div>Update: рекомендации от <a href="https://twitter.com/pankratov">Славы Панкратова</a> (одного из учредителей онлайн-школы менеджмента Стратоплан)</div><div><blockquote class="twitter-tweet"><p dir="ltr" lang="ru">• Ицхак Адизес: Идеальный руководитель. Почему им нельзя стать и что из этого следует<br />• Михаил Литвак: Командовать или подчиняться? Психология управления<br />• Эрик Берн: Лидер и группа<br />PS вообще у дяди Славы уже 2ю неделю полезные м минутные зарисовки про менеджмент <a href="https://t.co/oYAtlygdqG">https://t.co/oYAtlygdqG</a></p>— Maxim Shulga (@maxbeard12) <a href="https://twitter.com/maxbeard12/status/1297925079653847041?ref_src=twsrc%5Etfw">August 24, 2020</a></blockquote><p> И вишенка на торте про вопрос, готовы вы или нет стать менеджером</p> <script async="" charset="utf-8" src="https://platform.twitter.com/widgets.js"></script></div> <blockquote class="twitter-tweet"><p dir="ltr" lang="en">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.<a href="https://twitter.com/hashtag/engineeringmanager?src=hash&ref_src=twsrc%5Etfw">#engineeringmanager</a> <a href="https://twitter.com/hashtag/management?src=hash&ref_src=twsrc%5Etfw">#management</a> <a href="https://t.co/2fY9XIj0zL">pic.twitter.com/2fY9XIj0zL</a></p>— Isabel Nyo (@eisabai) <a href="https://twitter.com/eisabai/status/1404675291503542272?ref_src=twsrc%5Etfw">June 15, 2021</a></blockquote><p>И закончим все цитатой из уже мертвого твитт-аккаунта<br />"Тимлидам непросто: требуется строить отношения с коллективом, постоянно учиться, терпеть относительно невысокую зп. Есть только одно чувство, которое способно скрепить всё это вместе и помочь работать эффективно: искренне полюбить свою работу. <b>Ты должен стать солнцем для всех.</b>" (с)@backendsecret</p> <script async="" charset="utf-8" src="https://platform.twitter.com/widgets.js"></script>Maxim Shulga (aka MaxBeard12)http://www.blogger.com/profile/05615743910272666556noreply@blogger.com0tag:blogger.com,1999:blog-6346131298481535631.post-79041598175014724162020-02-13T12:48:00.005+03:002020-05-19T17:28:30.475+03:00Короткой строкой: новости про Heisenbug с промо и полезные ссылки<div dir="ltr" style="text-align: left;" trbidi="on">
Глянул, что уже есть в программе <a href="https://heisenbug-piter.ru/2020/spb/schedule/" target="_blank">Heisenbug Piter 2020</a>: так как я сейчас не в ПК, то интересно, что там у ребят с программой получается. И я вам скажу, что <b>интересно</b> получается :)<br />
<br />
Во-первых там есть <a href="https://heisenbug-piter.ru/2020/spb/talks/4qagnuoav5gdzzjgdwvtlk" target="_blank">доклад Адама Торнхила</a>, одного из авторов инструмента <a href="https://codescene.io/about" target="_blank">CodeScene</a>, которого я рекомендовал пригласить. Очень хочется послушать про жизнь кода.<br />
<br />
Во-вторых в <a href="https://heisenbug-piter.ru/2020/spb/talks/nrbnu4pt76idix5bosvy0" target="_blank">программе Иван Крутов</a>, один из авторов Aerokube. Еще <a href="https://heisenbug-piter.ru/2020/spb/talks/3tlyk1qd1u0jthjdqdeo56/" target="_blank">Аня Чернышова про возможное решение</a> проблемы падучих UI-тестов.<br />
<br />
Что бы я еще посмотрел:<br />
<ul style="text-align: left;">
<li><a href="https://heisenbug-piter.ru/2020/spb/talks/12ej1sekogb8tqkxd8cwlc/" target="_blank">Effective unit testing</a></li>
<li><a href="https://heisenbug-piter.ru/2020/spb/talks/3zpglszvpewgzjxr9tgcp8/" target="_blank">Тестирование производительности клиентской части React/Redux-приложения с использованием Enzyme</a></li>
<li><a href="https://heisenbug-piter.ru/2020/spb/talks/6ds4dsuuzwr6uq76ynyztb/" target="_blank">Demystifying Cross Browser testing</a> (от бывшего автора Puppeteer)</li>
</ul>
<br />
В общем, еще раз вам <a href="https://heisenbug-piter.ru/2020/spb/schedule/" target="_blank">ссылка на программу</a>, смотрите-думайте. Если созреете и ваша компания-редиска и не оплачивает вам конфу, промокод на <a href="https://bit.ly/3cxeq4P" target="_blank">персональный билет</a> <b>shulga2020pc</b>.<br />
<br />
Еще интересных вам ссылок, местами философских, но про тестирование:<br />
<ul style="text-align: left;">
<li><a href="https://twitter.com/noahsussman/status/1115662910104186881?s=03" target="_blank">Interaction Resiliency (iXR) is the practice of Software QA (aka #testing)</a></li>
<li><a href="https://labs.spotify.com/2018/01/11/testing-of-microservices/" target="_blank">Testing of Microservices</a> (Spotify)</li>
<li><a href="https://www.ministryoftesting.com/dojo/lessons/testing-in-production-the-mad-science-way" target="_blank">Testing In Production The Mad Science Way: Circuit Breakers & Science Experiments</a></li>
</ul>
<br />
<br />
<br /></div>
Maxim Shulga (aka MaxBeard12)http://www.blogger.com/profile/05615743910272666556noreply@blogger.com0tag:blogger.com,1999:blog-6346131298481535631.post-33677564157309068832020-02-11T16:24:00.003+03:002022-11-16T19:02:24.311+03:00Как Google от менеджеров пытался отказаться<div dir="ltr" style="text-align: left;" trbidi="on">
<div dir="ltr" style="text-align: left;" trbidi="on">
На самом деле про попытку отказа от менеджеров я узнал раскручивая попавшуюся на глаза историю про <a href="https://rework.withgoogle.com/blog/the-evolution-of-project-oxygen/" target="_blank">проект Oxygen</a>.<br />
История на самом деле давняя, берет свое начало <a href="https://hbr.org/2013/12/how-google-sold-its-engineers-on-management" target="_blank">аж в 2002 году</a>. Лари Пейдж и Сергей Брин решили, что менеджеры только мешают быстрой разработке, и решили их попробовать без них. Эксперимент закончился через несколько месяцев: число страждущих порешать проблемы напрямую через Пейджа (а другого способа не было) превысило его пропускную способность :)<br />
<br />
В итоге менеджеров вернули, потому что они все-таки приносили пользу: помощь в приоритезации проектов, фасилитации взаимодействия, поддержка в карьере сотрудников и направление процессов и систем в соответствии с целями компании.<br />
<br />
Но вопрос в том, как понять, какой менеджер полезен, а какой так себе. В 2009 (по другим источникам в 2008) Google запустил проект Oxygen, целью которого стал ответ на вопросы "Зачем нужны менеджеры и какие". Вылилось это в исследование с анализом работы более 10000 менеджеров по 100 параметрам, на основе оценки их работы, обратной связи от сотрудников (пример такого фидбека можно посмотреть в <a href="https://hbr.org/2013/12/how-google-sold-its-engineers-on-management" target="_blank">этой статье</a>) и других отчетов.<br />
<br />
В 2012 результаты опубликовали:<br />
A good manager (переводить не буду, кому надо пояснения, тому <a href="https://hr-portal.ru/story/v-google-popytalis-dokazat-chto-rukovoditeli-ne-nuzhny-vmesto-etogo-oni-otkryli-10" target="_blank">сюда</a>):<br />
<ol style="text-align: left;">
<li>Is a good coach</li>
<li>Empowers the team and does not micromanage </li>
<li>Expresses interest in and concern for team members’ success and personal well-being</li>
<li>Is productive and results-oriented</li>
<li>Is a good communicator—listens and shares information</li>
<li>Helps with career development</li>
<li>Has a clear vision and strategy for the team</li>
<li>Has key technical skills that help him or her advise the team</li>
</ol>
</div>
Позже в этот список добавили еще 2 пункта, а два обновили:<br />
<ol style="text-align: left;">
<li>Is a good coach</li>
<li>Empowers team and does not micromanage</li>
<li><b>Creates an inclusive team environment, showing concern for success and well-being</b></li>
<li>Is productive and results-oriented</li>
<li>Is a good communicator — listens and shares information</li>
<li><b>Supports career development and discusses performance</b></li>
<li>Has a clear vision/strategy for the team</li>
<li>Has key technical skills to help advise the team</li>
<li><b>Collaborates across Google</b></li>
<li><b>Is a strong decision maker</b></li>
</ol>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhjoCUIwVkrTGUIW936KPtoixwRDdCjfMGVNffhpzz92ERGWTdLndAnP3GXieNQptAlWE42WqoFBJF7DrDE_9olL_25qxFsGoVa8wGWTGQiEbSiaAlBvO4Ud_nlFc-NhyphenhyphenmA9_DvOXwqJmRS/s1600/oxygen.png" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="797" data-original-width="1600" height="318" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhjoCUIwVkrTGUIW936KPtoixwRDdCjfMGVNffhpzz92ERGWTdLndAnP3GXieNQptAlWE42WqoFBJF7DrDE_9olL_25qxFsGoVa8wGWTGQiEbSiaAlBvO4Ud_nlFc-NhyphenhyphenmA9_DvOXwqJmRS/s640/oxygen.png" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;"><span style="font-size: 12.8px;">оригинал тут </span><a href="https://www.impraise.com/blog/google-project-oxygen-revisited-what-it-takes-to-be-a-great-manager" style="font-size: 12.8px;">https://www.impraise.com/blog/google-project-oxygen-revisited-what-it-takes-to-be-a-great-manager</a></td></tr>
</tbody></table>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div>
На основе проведенного анализа Google начал проводить регулярное обучение для всех менеджеров. Что про него думали менеджеры Гугла?</div>
Вот отрывок <a href="https://hbr.org/2013/12/how-google-sold-its-engineers-on-management" target="_blank">отсюда</a><br />
Managers have expressed few concerns about signing up for the courses and going public with the changes they need to make. Eric Clayberg, for one, has found his training invaluable. A seasoned software-engineering manager and serial entrepreneur, Clayberg had led teams for 18 years before Google bought his latest start-up. But he feels he learned more about management in six months of Oxygen surveys and people ops courses than in the previous two decades. “For instance,” he says, “I was worried about the flat organizational structure at Google; I knew it would be hard to help people on my team get promoted. I learned in the classes about how to provide career development beyond promotions. I now spend a third to half my time looking for ways to help my team members grow.” And to his surprise, his reports have welcomed his advice. “<b>Engineers hate being micromanaged on the technical side,</b>” he observes, “<b>but they love being closely managed on the career side.</b>”<br />
<br />
В общем, интересная тема, есть над чем подумать и порефлексировать. У меня <a href="https://www.maxshulga.ru/2014/06/manager-skills.html" target="_blank">список неполный</a> получился в 2014 году :)<br />
<br />
Источники для почитать самому:<br />
<ul style="text-align: left;">
<li><a href="https://hbr.org/2013/12/how-google-sold-its-engineers-on-management" target="_blank">How Google Sold Its Engineers on Management</a></li>
<li><a href="https://www.nytimes.com/2011/03/13/business/13hire.html" target="_blank">Google’s Quest to Build a Better Boss</a></li>
<li><a href="https://rework.withgoogle.com/blog/the-evolution-of-project-oxygen/" target="_blank">Great managers still matter: the evolution of Google’s Project Oxygen</a></li>
<li><a href="https://www.impraise.com/blog/google-project-oxygen-revisited-what-it-takes-to-be-a-great-manager" target="_blank">Google Project Oxygen revisited: What it takes to be a great manager</a></li>
<li><a href="https://www.inc.com/michael-schneider/google-didnt-always-appreciate-its-managers-now-it-relies-on-them-for-these-10-things.html" target="_blank">Google Got Rid Of Its Bosses--And Then Brought Them Back For These 10 Reasons</a></li>
<li>(русский перевод) <a href="https://hr-portal.ru/story/v-google-popytalis-dokazat-chto-rukovoditeli-ne-nuzhny-vmesto-etogo-oni-otkryli-10" target="_blank">В Google попытались доказать, что руководители не нужны. Вместо этого они открыли 10 характеристик лучших из них</a></li>
</ul>
Для самообразования и рефлексии, серия видео про то как стать/быть менеджером от <a href="https://stratoplan.ru/" target="_blank">Стратоплан</a><br />
<a href="https://www.youtube.com/watch?v=5idPmpACdok" target="_blank">«Как стать & Как быть менеджером»: А. Орлов</a><br />
<a href="https://www.youtube.com/watch?v=0tbdh7paU4k" target="_blank">«Как стать & Как быть менеджером»: М. Завилейский</a><br />
<a href="https://www.youtube.com/watch?v=MHAkR0TUK2I" target="_blank">«Как стать & Как быть менеджером»: Олег М. Вайнберг</a><br />
<br /></div>
Maxim Shulga (aka MaxBeard12)http://www.blogger.com/profile/05615743910272666556noreply@blogger.com0tag:blogger.com,1999:blog-6346131298481535631.post-86775609132962583452019-08-30T16:09:00.001+03:002022-11-16T19:02:56.981+03:00Про качество, тестирование и консерватизм<div dir="ltr" style="text-align: left;" trbidi="on">
Мне тут недавно "прилетело", что я "склонен использовать консервативные подходы в работе с ожидаемым результатом в итоге." <br />
Да, чего уж там, похоже на правду. Именно потому, что мне нравится"ожидаемый результат".<br />
<br />
Ну а раз консерватор, то можно и побрюзжать...<br />
<br />
"Новшества и инновации" - это, чаще всего, то что благополучно забыли или даже не пытались узнать, и переизобрели заново. Мой брошенный английский блог так и назывался "Все новое - это хорошо забытое старое".<br />
<br />
В этом плане, из всех "новшеств" касающихся тестирования, меня больше всего волнует (<a href="https://www.maxshulga.ru/2017/05/qa-in-job-title.html" target="_blank">да-да, все еще волнует</a>) эта магическая комбинация "QA".<br />
<br />
Я помню те времена, когда тестировщиков в вакансиях "обзывали" инженерами по тестированию, потом появились QC, сейчас все сплошь QA. Расшифровку теперь все знают, но результат работы при этом не поменялся.<br />
<br />
Успокаивает, что я не один такой: "<a href="https://gerg.dev/2019/07/is-qa-too-narrow/" target="_blank">Is “QA” too narrow?</a>"<br />
<br />
А ведь еще в 2010 писали и предупреждали "<a href="https://www.developsense.com/blog/2010/05/testers-get-out-of-the-quality-assurance-business/" target="_blank">if you really want to improve the quality of the code and think that you can, become a programmer</a>". Но все грезят мыслями и заботой о качестве.<br />
<br />
Хороший тестировщик тот, что может сказать "у нас тут вот и тут все херово". И важным критерием "хорошести" может быть скорость, с которой мы об этих хероновостях узнаем.<br />
А тут помогут только голова и хорошие инструменты. Процессы тоже помогают. И если о процессах в явном виде на <a href="https://heisenbug-moscow.ru/" target="_blank">Heisenbug</a>-е сложно что-либо найти, то про инструменты и практики очень много. Про процессы можно поспорить лично :) Так же как и про тестирование без тестировщиков, да простят меня духи холивара. Кстати, в этом месте, я вроде не такой уж и консервативный...<br />
<br />
Если у вас есть что рассказать,<a href="https://heisenbug-moscow.ru/callforpapers/" target="_blank"> заявку еще можно успеть подать</a>. Если есть желание поучаствовать, что есть скидка на <a href="https://heisenbug-moscow.ru/registration/personal/" target="_blank">персональные билеты</a>. Используйте промокод <b>MaxHeisenbugMsk19.</b><br />
<br />
И пусть настоящих тестировщиков будет больше.<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj2Tx38XLC-_6RHJXGAnyox-v3zoiWJqw-daDbuSRWftJJKKh_z7me7he16E_0RCM41jdiNY0-suZCVQ9xgNUZ3A4gs7YP_BhT_Tc-47ckuanP0C-QM2JI3kP6Qwd0IMFL8g5kUcBxADEhN/s1600/we-dont-break-software.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="520" data-original-width="407" height="400" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj2Tx38XLC-_6RHJXGAnyox-v3zoiWJqw-daDbuSRWftJJKKh_z7me7he16E_0RCM41jdiNY0-suZCVQ9xgNUZ3A4gs7YP_BhT_Tc-47ckuanP0C-QM2JI3kP6Qwd0IMFL8g5kUcBxADEhN/s400/we-dont-break-software.jpg" width="312" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;"><span style="font-size: small; text-align: left;">James Bach “</span><a href="https://www.developsense.com/blog/2015/02/very-short-blog-posts-25-testers-dont-break-the-software/comment-page-1/" style="font-size: medium; text-align: left;" target="_blank">We don’t break the software. We break illusions about the software.</a><span style="font-size: small; text-align: left;">”</span></td></tr>
</tbody></table>
<div>
</div>
</div>
Maxim Shulga (aka MaxBeard12)http://www.blogger.com/profile/05615743910272666556noreply@blogger.com0tag:blogger.com,1999:blog-6346131298481535631.post-40043693965276008662019-08-14T14:50:00.002+03:002019-08-14T14:50:44.275+03:00В гостях у SDCast<div dir="ltr" style="text-align: left;" trbidi="on">
Сходил в гости к <a href="https://twitter.com/KSDaemon" target="_blank">Константину</a> в его подкаст "<a href="https://twitter.com/SDCast_podcast" target="_blank">SDCast</a>".<br /><br />Вроде <a href="https://sdcast.ksdaemon.ru/2019/07/sdcast-106/" target="_blank">интересная получилась беседа</a>, душевная. Чуть меньше 1.5ч возможностей узнать чуть больше про меня, SEMrush и моем отношении к процессу разработки с точки зрения качества.<br /><br />Ссылки для послушать:<br />Основная <a href="https://sdcast.ksdaemon.ru/2019/07/sdcast-106/">https://sdcast.ksdaemon.ru/2019/07/sdcast-106/</a><br />
Twitter <a href="https://twitter.com/SDCast_podcast/status/1156646125232885760">https://twitter.com/SDCast_podcast/status/1156646125232885760</a><br />
VK <a href="https://vk.com/ksdaemon?w=wall6753715_549">https://vk.com/ksdaemon?w=wall6753715_549</a><br />
FB <a href="https://www.facebook.com/ksdaemon/posts/2462401727171916">https://www.facebook.com/ksdaemon/posts/2462401727171916</a><br />
<br /></div>
Maxim Shulga (aka MaxBeard12)http://www.blogger.com/profile/05615743910272666556noreply@blogger.com0tag:blogger.com,1999:blog-6346131298481535631.post-15687054075144318492019-07-30T11:02:00.002+03:002023-11-05T21:24:04.785+03:00Spotify Engineering Culture (Henrik Kniberg 2014)<div dir="ltr" style="text-align: left;" trbidi="on">
Просто в закладки, рассказ про внутренние процессы разработки в Spotify на момент 2014 года.<br />
<br />
Интересно, поменялось у них что-нибудь? </div><div dir="ltr" style="text-align: left;" trbidi="on"><br /></div><div dir="ltr" style="text-align: left;" trbidi="on">А вот и <a href="https://www.jeremiahlee.com/posts/failed-squad-goals/" target="_blank">ответ 1</a>, <a href="https://bitcask.live/2020/10/21/17-spotify-model/" target="_blank">ответ 2</a>, <a href="https://teamleadconf.ru/spb/2018/abstracts/3827" target="_blank">ответ 3</a>:) <br />
<br />
<iframe allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen="" frameborder="0" height="480" src="https://www.youtube.com/embed/Yvfz4HGtoPc" width="768"></iframe>
<br />
<br />
<br />
<iframe allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen="" frameborder="0" height="480" src="https://www.youtube.com/embed/vOt4BbWLWQw" width="768"></iframe></div>
Maxim Shulga (aka MaxBeard12)http://www.blogger.com/profile/05615743910272666556noreply@blogger.com0