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

Наводил порядок в блоге (чистил умершие ссылки, картинки и тп), наткнулся на заметку про 5-летие блога . Интересно было посмотреть на статистику спустя уже 13 лет. Заходов из поисковых систем, других ресурсов и сайтов суммарно больше 160 тыс.  5 лет назад было 54тыс - практически линейно. Как гугл насчитал без малого 800 тыс - скорее всего с ботам и прочими краулерами. Самые популярные статьи (тут уже видимо просмотры с ботами). В лидерах по популярности все те же 2 заметки про моки и ресурсы для тестировщиков (имхо далеко не самые интересные). Mock vs Stub 83тыс  (регулярно в топе выдачи по этому запросу в гугле, продолжительное время висела на 1 месте, не согласен с ее популярностью, но с названием угадал) Полезные ресурсы для молодых (и не только) тестировщиков   61тыс - с апреля этого года снова стала посещаемой, видимо где-то на популярном ресурсе появилась, но по статистике не видно откуда. Смешная история с " План "Б" или как прикольно провести субботний день ...

Мое определение оценки : “Процесс в рамках которого, мы разбираемся, что от нас ждут, что нам для этого надо сделать и в каких частях нашего приложения, какие у нас зависимости, готовы ли они к нашим задачам, какие риски и тдтп. А "оценка времени" - это лишь один из артефактов процесса оценки.” Я тут не хочу писать подробности про сторипойнты (попугаев, слоников, чашки кофе, размеры маек), планинг-покер и тд. Очень много инфы по этой теме.  Тут будут просто советы и немного про собственно процесс, как я его вижу. 1. У всех, кто участвует в процессе, должно быть одинаковое понимание того, что именно они оценивают и с какой точностью эта оценка делается (подробнее смотри совет 1 отсюда ) 2. Важно понимать, что ошибки оценки все равно будут. И поэтому должны быть:    • процесс работы над этими ошибками (расширяем базу знаний и подходы для следующих оценок) с тем, чтобы в следующий раз оценка была точнее   • процесс информирования о возникающих из-за ошибок рисках (не тя...

Копия поста в телеге  (подключайтесь 🙂) Навеяло постом  в тви с советам для резюме для поиска работы за рубежом. Я бы выбрал скорее выбрал 3 (и именно такое часто и вижу). Хотя и 4, и 5 тоже норм, но есть нюансы. Совет Киры (см. детали в комментах) касался в первую очередь поиска работы в международных компаниях, а я смотрю через призму отечественных, но думаю, что мои советы ниже могут быть полезны для всех. Но сначала небольшой экскурс в историю (ну, так принято в высших сферах). *и да, еще раз, речь по отечественный IT, я хз че там происходит сейчас в других интернетах, но подозреваю, что люди в культуре могут отличаться, но в своей сути похожи. Я застал те времена, когда тестировщики в резюме писали "инженер по тестированию" и в вакансиях писали ровно это же. Потом какие-то умники, глядя на "как там" начали активно форсить тему с QC, почти мгновенно переключившись на использование букв QA. При этом никто даже не парился над тем, чтобы люди в головах осознали, ч...

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

Дисклеймер: знать, как правильно писать резюме, как быстро его читать и потом им пользоваться на собесе, не равно иметь правильное написанное свое резюме 🫠 Сейчас снова подключился к анализу резюме кандидатов и собесам (как ни странно, DevOps-в). Что можно сказать? А то, что люди, как и раньше, как не “умели” писать резюме, так и не “умеют”. Просто набор ключевых слов обрамленный глаголами “применял”, “настраивал”, “мониторил” и тп. А что такое “уметь” писать резюме? Важный ли это навык? ( присоединяйтесь к обсуждению в телеге)

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

В блог стал меньше писать, потому что он в моей голове предполагает сейчас какую-то долгую предварительную работу со статьей. Черновики у меня годами лежат. Поэтому, встречайте телеграмм-канал, лайт-версию блога: появилась мысль - отправляется в канал. Тематика та же самая, Подключайтесь . Из мариновавшегося годами тут, но уже появившееся в телеге: Team- vs TechLead Ошибки приводящие к проблемам в IT Про календари менеджера и инженера