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

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

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

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

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

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

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

Побеседовали с Мишей про эту "магическую" сущность, а он смог классно переработать содержимое нашей беседы и кучи других материалов. Я теперь даже не уверен, какие именно мысли мои :) Но там все по делу. Ну и самое главное про легаси: 1. это про то, что нужно (иначе бы выкинули) 2. это то, что с вами всегда* ** *если вы не меняете работу каждые полгода после написания нового кода **но уровень боли от легаси можно уменьшить - статья как раз про это