Сложный пятничный ребус: расставь картинки в правильном порядке 😏
#it_memes

Коротко про фундаментальную проблему большинства технических собеседований: спрашивать фигню, которую вы знаете только потому, что используете ее для вопросов на собеседовании. (с) Камилла Фурнье

#собеседования

Мощная серия статей "Bottlenecks of Scaleups".
Я зацепился за онбординг, а там целая пачка полезностей.

• Accumulation of tech debt; experiments and shortcuts are core components
• Constrained by talent and struggling to attract top technologists
• Friction Between Product and Engineering; Lack of trust and collaboration slowing down product growth
• Surging cloud and managed services costs outpacing customer growth
• Service disruptions; production incidents reduce reputation and revenue
• Onboarding; Too long for new hires to reach full effectiveness

#management #процессы

Про ракурс.

Когда ты наблюдаешь какое-то событие, чье-то действие или бездействие - помни, что ракурс и контекст у всех может быть разным.
Поэтому перед тем как “отбомбиться”, никогда не бывает лишним выровнять ракурсы и контекст. А только потом уже…
ЗЫ Ну и про эмоции не забывайте.
ЗЫ2 картинка для примера важности ракурса.
#мысли_вслух

Ответственность – состояние, при котором человек является и признает себя причиной чего-либо.
Другими словами: ответственность - это «способность быть причиной».
И все, и никакого традиционного "принять на себя вину за свои действия"

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

#management #мысли_вслух

Есть мнение к одному из моих комментов:

Ой да всё намного проще. Айти расходник-ресурс для бизнеса, работаешь над направлением, а его закрыли, или косты режут, или команда меняется, или проект доделали и пока

и такая точка зрения тоже есть :)

Но я склонен думать, что в эту "игру" можно играть вдвоем (и играют): с одной стороны бизнес достаточно циничен, с другой сотрудники рассматривают свою работу, как работу. С которой можно просто уйти/уволиться не ориентируясь на текущие задачи/ахтунги и тдтп. Или просто пилить выданные задачи не вникая в их суть или ценность. Или втаскивать новую технологию, просто потому что это модно/полезная строчка в резюме и тд, но не несет никакой пользы продукту.

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

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

И снова #it_memes про любимую всеми #оценка за авторством Макса Дорофеева

Многие менеджеры/команды пытаются оградить новых людей от проблем, попытаться сделать все более приятным, а не напугать их… и т. д. Это классический случай, когда добрые намерения работают против люди. Вы нанимаете людей для решения проблем, поэтому сразу покажите им свои проблемы.

New Hires: Learn How The System Breaks

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

И всяко это лучше, чем подход "на собеседовании мы просим запускать ракеты в космос, а потом они приходят работать и картошку копают" из кулуаров HeisenbugConf
#management #собеседования

грустный мем Лайфхак для тех, кого утомили рекрутеры. Работает не только в LinkedIn, но есть нюансы.

#байки

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

И даже после этого ты еще не сеньор. По-настоящему сеньорность раскрывается только в тот момент, когда ты делишься знаниями с другими.
ЗЫ и кстати "благодаря" последнему замкнутая в себе команда из сеньоров быстро перестает быть сеньорной.

#мысли_вслух #развитие

Какой чудесный пример цикличности развития.
Подробнее тут (но бесплатно только первые 3 пункта описаны подробно).
Особенно интересно, когда ты сам, как пиксель на этом витке спирали :)

#it_философия

Когда смотришь на неделю в рукотворной табличке-расписании и пытаешься вкурить, почему выходные правильно расставлены, а рабочих дня всего 4.

Всех с 29 февраля.

#байки

Когда ты "починил" баг и отдал на проверку тестировщику...

традиционно-пятничные #it_memes

Большое эго и недостаток самосознания — проклятие хорошего лидера...

Так много великих вещей происходит из-за ошибок.
Когда мы ошибаемся, мы учимся.
Когда мы ошибаемся и признаемся в этом нашим командам - это показывает нашу уязвимость и укрепляет доверие.
Когда мы ошибаемся, наши команды понимают, что ошибаться — это нормально, и мы начинаем создавать психологическую безопасность. Быть неправым – это здорово.

Таки да.

#management

Так исторически сложилось, что мы херачим говнокод.
Так исторически сложилось, не разгребаем технодолг.
Так исторически сложилось, что тестить должен кто-то там.
Так исторически сложилось, разруха в наших головах...

ЗЫ из моего раннего
#анафора #мысли_вслух

Что интересно, OKR часто рекомендуют к использованию.
Но еще чаще вокруг него возникают надстройки, помогающие его использовать.
Получается, что сам по себе метод неудобный или сложный?
POMKRA
Understand the Goal - (PO)
Build an Operational Plan (MKRA)
• Problems
• Objectives
• Milestones
• Key Results
• Activities

#management

What if everybody did everything right?

Интересный совет для осмысления причин инцидента:

просто задайте вопрос: «Как этот инцидент произошел, если предположить, что все сделали все правильно?»
Что если все, чьи действия способствовали инциденту, приняли наилучшее решение, основываясь на имеющейся у них информации, с учетом наложенных ограничений и стимулов.

Рассмотрение инцидента с этой точки зрения приведет к совершенно разным выводам, поскольку порождает разные типы вопросов, например:
• Какую информацию знали люди в данный момент?
• В каких условиях действовали люди?

#процессы #management

И пока мы еще не определились, что лучше микросервисы или монолит, давайте посмотрим подробнее на эти самые μServices.

At the heart of microservices
• we're told we'll find...
• we find...
• we should find...
• we often find...
• we need... to start rethinking what we really need.
You Want Modules, Not Microservices

#tech_read

Есть такой способ передачи знаний, очень популярный в IT: фольклорный...

пятничные #it_memes

Тот момент, когда долго вынашиваешь пост хоть пару мыслей про автоматизацию тестирования и “автоматизаторов”, но сомневаешься: может это только мое искажение.
А потом приходит Алан Пейдж и просто рубит правду-матку “как оно есть”.

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

"...
Test Automation in 2024
Short story - it still sucks. In the last ten years, I’ve worked with a lot of development teams on improving velocity, and in every single case I’ve found that developers owning all test automation results in better tests, more testable code, faster deliver, and higher overall quality. Some of these teams don’t have dedicated testers, but on teams with dedicated testers, those folks do not write automated tests. They write tools to assist in testing or debugging, or work with the development team in order to improve testing knowledge across the team.
..."

(с) The "A" Word...revisited Alan Page

PS мои пару слов (10-летней давности) про The "A" Word

#test_automation #holywar

А кто-то у себя использует Zero Bug Policy?
Отличный подход, который позволяет сохранить беклог и голову в порядке. Меньше страданий от постоянно растущего количества багов, которые никто не фиксит, но которые постоянно фигурируют в отчетности, как "показатель зрелости продукта".

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

А ведь там все просто: если баг есть и мы оценили его как критичный - значит мы его берем и чиним, а не маринуем в беклоге. Если некритичный (или кажется таковым в настоящее время) - значит просто фиксируем проблему, обозначаем его как “won’t fix” и забываем про него до того момента, когда его критичность меняется (похожий запрос от клиента, новый сценарий эксплуатации проблемы и тдтп).

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

Статья по этой теме с рекомендациями по переходу на ZBP

#testing #процессы