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

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

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

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