четверг, 13 февраля 2020 г.

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

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

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

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

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

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

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



вторник, 11 февраля 2020 г.

Как Google от менеджеров пытался отказаться

На самом деле про попытку отказа от менеджеров я узнал раскручивая попавшуюся на глаза историю про проект Oxygen.
История на самом деле давняя, берет свое начало аж в 2002 году. Лари Пейдж и Сергей Брин решили, что менеджеры только мешают быстрой разработке, и решили их попробовать без них. Эксперимент закончился через несколько месяцев: число страждущих порешать проблемы напрямую через Пейджа (а другого способа не было) превысило его пропускную способность :)

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

Но вопрос в том, как понять, какой менеджер полезен, а какой так себе. В 2009 (по другим источникам в 2008) Google запустил проект Oxygen, целью которого стал ответ на вопросы "Зачем нужны менеджеры и какие". Вылилось это в исследование с анализом работы более 10000 менеджеров по 100 параметрам, на основе оценки их работы, обратной связи от сотрудников (пример такого фидбека можно посмотреть в этой статье) и других отчетов.

В 2012 результаты опубликовали:
A good manager (переводить не буду, кому надо пояснения, тому сюда):
  1. Is a good coach
  2. Empowers the team and does not micromanage 
  3. Expresses interest in and concern for team members’ success and personal well-being
  4. Is productive and results-oriented
  5. Is a good communicator—listens and shares information
  6. Helps with career development
  7. Has a clear vision and strategy for the team
  8. Has key technical skills that help him or her advise the team
Позже в этот список добавили еще 2 пункта, а два обновили:
  1. Is a good coach
  2. Empowers team and does not micromanage
  3. Creates an inclusive team environment, showing concern for success and well-being
  4. Is productive and results-oriented
  5. Is a good communicator — listens and shares information
  6. Supports career development and discusses performance
  7. Has a clear vision/strategy for the team
  8. Has key technical skills to help advise the team
  9. Collaborates across Google
  10. Is a strong decision maker
оригинал тут https://www.impraise.com/blog/google-project-oxygen-revisited-what-it-takes-to-be-a-great-manager
На основе проведенного анализа Google начал проводить регулярное обучение для всех менеджеров. Что про него думали менеджеры Гугла?
Вот отрывок отсюда
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. “Engineers hate being micromanaged on the technical side,” he observes, “but they love being closely managed on the career side.

В общем, интересная тема, есть над чем подумать и порефлексировать. У меня список неполный получился в 2014 году :)

Источники для почитать самому:
Для самообразования и рефлексии, серия видео про то как стать/быть менеджером от Стратоплан
«Как стать & Как быть менеджером»: А. Орлов
«Как стать & Как быть менеджером»: М. Завилейский
«Как стать & Как быть менеджером»: Олег М. Вайнберг

пятница, 30 августа 2019 г.

Про качество, тестирование и консерватизм

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

Ну а раз консерватор, то можно и побрюзжать...

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

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

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

Успокаивает, что я не один такой: "Is “QA” too narrow?"

А ведь еще в 2010 писали и предупреждали "if you really want to improve the quality of the code and think that you can, become a programmer". Но все грезят мыслями и заботой о качестве.

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

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

И пусть настоящих тестировщиков будет больше.

James Bach “We don’t break the software. We break illusions about the software.

среда, 14 августа 2019 г.

В гостях у SDCast

Сходил в гости к Константину в его подкаст "SDCast".

Вроде интересная получилась беседа, душевная. Чуть меньше 1.5ч возможностей узнать чуть больше про меня, SEMrush и моем отношении к процессу разработки с точки зрения качества.

Ссылки для послушать:
Основная https://sdcast.ksdaemon.ru/2019/07/sdcast-106/
Twitter https://twitter.com/SDCast_podcast/status/1156646125232885760
VK https://vk.com/ksdaemon?w=wall6753715_549
FB https://www.facebook.com/ksdaemon/posts/2462401727171916

вторник, 30 июля 2019 г.

Spotify Engineering Culture (Henrik Kniberg 2014)

Просто в закладки, рассказ про внутренние процессы разработки в Spotify на момент 2014 года.

Интересно, поменялось у них что-нибудь?




понедельник, 29 апреля 2019 г.

5 за 5 (история 11) It's all about technical management


1.  Sharing Our Engineering Ladder
"Creating an engineering ladder (that is, the job descriptions and levels of an engineering organization) is a daunting task. If you do a half-hearted job, you're likely to cause more problems than you solve."
"In addition to the ladder causing problems inside of my team, we were having a hard time evaluating candidates during interviews and determining what level to hire them into. Particularly at the more senior levels, it wasn't clear what the criteria for success really looked like. So, together with my tech leads and engineering managers, we rewrote the ladder to be more specific. It has been very helpful both for the process of reviews and promotion committees as well as for the process of hiring."

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

2. If Your Boss Could Do Your Job, You’re More Likely to Be Happy at Work
Анализ результатов исследования зависимости отношения подчиненных к своей работе от качеств руководителя: "The benefit of having a highly competent boss is easily the largest positive influence on a typical worker’s level of job satisfaction. Even we were surprised by the size of the measured effect. For instance, among American workers, having a technically competent boss is considerably more important for employee job satisfaction than their salary (even when pay is really high)."

3. Отличный keynote от Camille Fournier
The role of being technical in technical leadership
"This is a talk about engineering management, which I think is pretty important for building effective engineering teams and building good products. We’re going to talk about what actually what it means to put the engineer in engineering management."

4. Сейчас читаю "The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change" by Camille Fournier. Мне эта книга очень бы помогла на заре моей менеджерской карьеры. Сейчас у меня уже набиты мозоли и местами некорректные мои действия трудно менять. Но стараюсь.
Есть в русском переводе "От разработчика до руководителя"

5. Engineering management: the pendulum or the ladder
"It’s primarily aimed at new managers, who aren’t sure what their career options look like or how to evaluate the opportunities that come their way, or how it may expand or shrink their future opportunities."


понедельник, 22 апреля 2019 г.

5 за 5 (история 10)

Давно ничего не писал себе и вам в полезные заметки. А их накопилось.
Продолжим цикл, хотя он теперь и не "5 за 5 (дней)".
1. Статья из 1995.
Сколько времени прошло, а ничего не меняется.
Но именно такие мысли я называю классикой и философией промышленной программной разработки:
"Задачи условно делятся на три категории — соответственно квалификации.
Низшая — ты можешь запрограммировать предложенный кем-то алгоритм.
Средняя — по предложенной спецификации функции или программы ты можешь предложить алгоритм ее реализации и запрограммировать его.
Высшая — ты можешь предложить способ решения задачи, написать спецификацию программы, ее решающей, и запрограммировать ее."

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

2. "Chaos Engineering: the history, principles, and practice" - отличное введение в тему от компании, которая занимается инструментами для Chaos Engineering.

3. Интересный доклад про "монолиты и микросервисы"

4. И еще статья на эту же тему "Build a Monolith before Going for Microservices"

5. И чуток для soft-skills от Ани Обуховой "Напрасные слова. Как давать обратную связь с учетом работы мозга".

пятница, 26 октября 2018 г.

Heisenbug 2018 Москва - скоро для всех тестировщиков и не только

Приближается уже традиционная зимняя версия Heisenbug Conference в Москве.

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

В этом году в программе традиционно как старожилы, так и новички. В роли старожилов выступают Артем Ерошенко и Виталий Фридман, любой доклад которых, это качественно сделанная и полезная для слушателей работа. "Новичков" (для нашей конфы) сильно больше, например очень хочется увидеть "в бою"  результаты работы Людмилы Мжачих и Антона Усманского, которых объединяет тема визуального тестирования.

Неожиданным "новичком" нашей конфы стал известный многим по конференциям Joker и Devoops Барух Садогурский с провокационным докладом-покушением на тестировщиков.

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

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

Ведь учиться только по книгам - это сложно:

Для дочитавших до конца небольшой бонус в виде промокода на Heisenbug: MaxShulgaPromo.

Вбивайте его в форму регистрации и готовьтесь к конференции :)

вторник, 23 октября 2018 г.

Site Reliability Engineering (SRE) - источники знаний по теме

Тема модная, имхо отпочковалась от DevOps, а скорее стало ее развитием (хотя считается, что развивались темы параллельно и одновременно).

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

По теме 3 основные книги (в порядке даты издания):
В первой книге про концепцию и базовые вещи. Вторая про внедрение на примерах. Третья похожа на вторую, но в виде примеров (в тч best practices) из разных компаний.

Обзоры первой книги:

Видео-рассказ одного из SRE-инженеров Google (на русском) "Как я научился не волноваться и полюбил пейджер"

Видео про одну из фундаментальных вещей SRE: "SLIs, SLOs, SLAs"

"Бесконечный список материалов по SRE" (цитата @asatarin) - это ссылкой можно было бы и обойтись, но Андрей прислал ее уже после публикации статьи :)

пятница, 31 августа 2018 г.

5 за 5 (история 9)

Вот не поймешь, хвалят коллеги или ругаются... (с)
1. "Punishing failure makes it worse. Unshared failures are the experience of one individual. They are not institutional learning." ( by Jessica Kerr tweet)

2. The problem with root cause analysis is there’s always going to be another root cause.
Robustness happens at a higher level. And resilience at a higher level still. (by Jessica Kerr tweet)

3. Очередная история про Git от Сергея Сергеева, беседа в подкасте "Подлодка". Напомню ссылку на отличную лекцию Сергея.

4. "Тимлид — это сержант в IT-подразделении" - хорошее интервью с Романом Ивлиевым.

5. Неплохая панелька тимлидов с инсайдами из известных компаний.  Отлично смотрится на скорости х1.5


пятница, 17 августа 2018 г.

5 за 5 (история 8)

И снова с вами рубрика "что интересного было в ленте на этой неделе".

1. Building and Testing Resilient Web Applications with Toxiproxy.
Статья, видео.
"A resilient system is one that functions with one or more components being unavailable or unacceptably slow. Applications quickly become intertwined with their external services if not carefully monitored, leading to minor dependencies becoming single points of failure.
For example, the only part of Shopify that relies on the session store is user sign-in - if the session store is unavailable, customers can still purchase products as guests. Any other behaviour would be an unfortunate coupling of components. This post is an overview of the tools and techniques we used to make Shopify more resilient in preparation for the holiday season."

2. What is Soak Testing?
"Soak testing (otherwise known as endurance testing, capacity testing, or longevity testing) involves testing the system to detect the performance-related issues such as stability and response time by requesting the designed load on a system."

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

4. Тред в твиттере про то, что для влияния инженеру не нужно становиться менеджером.

5. Небольшой тред-слайды в твиттере "Chaos Engineering is about engineering around the chaos inherent in the system".