В IT чудес не бывает

В IT чудес не бывает pinned «Никогда не ждите чуда, чудите сами. Некоторые, особо внимательные и умеющие читать между строк, уже догадывались и приходили с вопросами. Но тем не менее, неожиданный контент. Я передаю дела в МойОфис, а сам открыт для предложений: позиции от Engineering…»

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

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

The Testing Techniques We Couldn't Afford (Until Now)

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

PS Я не так часто размышлял над этим вопросом в принципе, потому что все еще скептически ко всем этому отношусь: ибо вижу, как "весело" может поддерживаться код, который был написан тобой не вчера. Но видя, как та же ИИ может помочь "разбирать" старый код, может и не все так страшно?

#testing #ai

Вот и выросло поколение людей, которые не смотрели/не читали русские народные сказки и мультика про капитана Врунгеля с его "как вы лодку назовете, так она и поплывет"...

PS для тех кто не в теме: где-то в Мск провели презентацию нового робота со звучным названием idol, он вышел на сцену и упал... "Разработчики объяснили инцидент особенностями ускоренного обучения."

#мысли_вслух #байки

OWASP Top10:2025 RC1 (6 ноября 2025)
What's changed in the Top 10 for 2025

Напомню, что предыдущий Top 10 составлялся в 2021.

Обратите внимание, что Software Supply Chain Failures и корректная обработка ошибок (Mishandling of Exceptional Conditions) теперь тоже входят в этот список.

Ну и SSRF вошла в состав Broken Access Control, то есть неявно их теперь все же 11 :)

#security #tech_read

Немного про стоимость технических решений в картинках.
Когда вы идете в k8s - оцените свои силы и бизнес-потребности. Не надо это делать "для резюме" или "хотим быть cloud-native".

PS Ну и те, кому надо, надеюсь поймут, что дальше с кубами будет так же весело, как сейчас с ансиблом. Просто чуть-чуть по-другому 😉

ссылка на заскриненный пост

техно-бизнесовые #мысли_вслух

Продолжение этой истории нарисовалось, с моим скромным участием.

11.11 в 19.00.
Бесплатно, онлайн, регистрация по ссылке из оригинального сообщения от Heisenbug.

#вопросы_с_собесов
"Должен ли руководитель доверять команде"

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

Ну, сразу ответ, конечно должен (в моем понимании лидерства).

Но почему этого доверия может не быть:
- оно еще не установлено
- оно было чем-то нарушено

Установление доверия требует от менеджера:
- открытости и явности в своих ожиданиях/требованиях
- умения давать команде/людям право на ошибку или создавать среду для экспериментов, в которой можно ошибаться и на этом учиться
- не нарушения своих слов и обещаний
- умения слушать и слышать
- признания своих ошибок (для восстановления доверия - особенно)
- изучения людей в команде (общение, анализ их действий и результатов)

Итак, должен доверять. Но, не забываем про "доверяй, но проверяй".

PS дальше по этому вопросу не топтались, хотя там есть куда еще повертеть. Но обычно времени на "обсудить все" не хватает, поэтому редко идет углубление. Копают только если это тема "кандидатской" интервьюера (=его любимая тема).

PS2 Вообще, если сделать поиск по "доверие" в этом канале, можно убедиться, что разными словами там все про одно и то же. И да, как-то часто я это слово использую 🤔

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

Сейчас “AI” фигурирует уже везде: в стратегиях, продуктах, техрадарах, dora-ах, performance review и тдтп

Интересно, как быстро “AI” появится в гибком Scrum Guide как "член команды разработки"? 🙃

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

Алан умеет в такие заметки, а я люблю читать Алана.

Тут ранее уже было что-то подобное.

Вот недавнее, можно сказать, продолжение истории.

When Confidence Meets Vulnerability

Сказать «я не знаю» было слабостью, которую они не хотели показывать.
Конечно они ошибались. Этот инстинкт самозащиты, стремление контролировать ситуацию — это не сила. Это как крепкая оболочка.
Легко думать, что оболочка защищает.
Но это не так — она отделяет вас от других. Вы можете чувствовать себя защищённым, но вы также отрезали себя от общения.

Уязвимость неприятна, а иногда и пугает. Она означает, что вы открыты для осуждения или неудач. К сожалению, для многих лидеров чувство дискомфорта или страха — это полная противоположность тому, за что их награждали.

Я был на совещаниях, где руководитель высшего звена говорил: «Я был неправ» или «Я принял неправильное решение». Вы бы чувствовали, как меняется атмосфера. Напряжение спадало. Разговор снова становился искренним. В этом сила уязвимости — она создаёт пространство для честности.

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

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

#management

Вчера, в поисках нужной ссылки, которая точно должна была быть тут в канале, пришлось полистать по всему тегу #management.
Ну что я могу сказать… Если все перечитать (включая ссылки на статьи) и осознать, то получается неплохая теоретическая, а местами с примесью реальных кейсов, подготовка к собесам по менеджменту.
Ну или инфа для размышления над вопросом “а оно того стоит?” тем, кто подумывает о росте в эту сторону.
Приятно удивился.

PS ссылку нашел :)

в продолжение вчерашнего

Возвращаясь к пирамидам, поговорим о снеговиках.

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

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

И вот именно понимание этих ограничений и своего контекста даст вам ответ на вопрос, какую именно автоматизацию тестирования делать: что, на каком уровне, какими инструментами и кем?

А, про снеговики:
тут The Test Automation Snowman описан "правильный".

А на заглавном фото тот, что мы часто видим у себя.

#test_automation

PS что-то сложно получилось... 😏 "дед опять забыл таблетки принять"
Мысль на самом деле все та же: решаем проблему, и эта проблема не "у нас нет автоматизации" или "у нас тесты не на тех уровнях пишутся".

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

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

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

Письменное бубубу про автоматизацию 13-летней давности 👨🏻‍🦳

ЗЫ слайд/картинка, которую комментировал, будет в комментах.

Небольшое продолжение.

#test_automation

Секреты корпоративного выживания роста!...
Гибче надо быть, гибче. Без этих ваших эмоций.

Понятно, что редко кто делает фигню просто так (ну или я не встречал). Все происходит из благих побуждений. Просто реализация может страдать.

PS отсюда

#все_крутые_компании_так_делают

Ставим 🎉 кто узнал себя на работе и ⚡️те, кто пользователи 🫣


ЗЫ простите, у меня 🎉 в пятничных #it_memes
ЗЫ2 А вообще ставьте что хотите, что это я указываю 🙂

Не увольнял - не менеджер
Не увольнял десятками - не директор

#мысли_вслух, которые многим кажутся правдой...

Новая рубрика #вопросы_с_собесов - интересные вопросы с собесов меня, которые я не встречал раньше или уже забыл 😃

Кейс “команда предложила решение, но оно кажется вам неправильным - что будете делать?”

Подумайте перед тем, как читать дальше мой вариант ответа.

1. Подумать над предложенным вариантом, смущающие моменты зафиксировать в виде уточняющих вопросов.
Подготовить вопросы на проверку прочности, вида “а что будете делать, если…”, “а помните, что…”.
2. Собираем встречу и обсуждаем смутившие моменты, попутно проверяя решение на прочность (см вопросы из п1) и добавляя упущенный командой контекст.
3. Если ответы команды на мои вопросы не развеяли моих сомнений или команда не скорректировала свое решение, а я сам не могу предложить и, главное, объяснить свое решение (сомнения на уровне “чуйки” или “неосознанной компетентности”), то дальше развилка:
- если вы доверяете команде, то сразу запускается решение предложенное командой
- если не доверяете команде (тут я попался на 2й вопрос, он будет попозже в рамках рубрики), то пробуете опираться на мнение эксперта (где его найти - это уже 3й вопрос, но мы не будем его обсуждать), которому доверяете, с тем, чтобы или развеять свои сомнения, или получить подтверждение своей чуйки и необходимые аргументы для разговора с командой. Если ваши расширенные аргументы тоже не сработали, то запускаем решение команды.

Это то, как я ответил (+/-).

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

ЗЫ у меня еще ни разу не было необходимости запускать в работу решение, которое я не признавал бы “своим”, то есть, обычно, в результате обсуждений или корректируется решение команды на основе моих комментов, или все мои сомнения развеиваются командой.

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

Ну, вы поняли...

—————
#it_memes

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

Я передаю дела в МойОфис, а сам открыт для предложений: позиции от Engineering Manager до руководителя направления (зависит от размера компании и совпадения наших c вами ожиданий). TPM тоже интересно.

Готов вписаться в любые темы с техническим менеджментом разработки/тестирования, по всему жизненному циклу ПО. Опыт в процессах, техничке и главное - людях (я все-таки больше "пролюдовик" ).
Продуктовая разработка (не заказная), РФ.
Любые форматы работы, но гибрид понятней и интересней (Питер).

Если у вас в компании есть что-то интересное по техническому менеджменту - маякните мне пожалуйста (@maxbeard12).
Буду благодарен за рекомендации:
LinkedIn
HH (эта ссылка откроется только у рекрутеров).

В целом в резюме около 15 лет разработки (до сеньора) и 15 лет менеджмента (с пересечением разработки и лидства конечно) до позиций технический руководитель направления/head of engineering.
PDF могу выслать при необходимости.

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

не мои #мысли_вслух

Stop Avoiding Politics

Here’s what good politics looks like in practice:
• Building relationships before you need them. That random coffee with someone from the data team? Six months later, they’re your biggest advocate for getting engineering resources for your data pipeline project.
• Understanding the real incentives. Your VP doesn’t care about your beautiful microservices architecture. They care about shipping features faster. Frame your technical proposals in terms of what they actually care about.
• Managing up effectively. Your manager is juggling competing priorities you don’t see. Keep them informed about what matters, flag problems early with potential solutions, and help them make good decisions. When they trust you to handle things, they’ll fight for you when it matters
• Creating win-win situations. Instead of fighting for resources, find ways to help other teams while getting what you need. It doesn’t have to be a zero-sum game.
• Being visible. If you do great work but nobody knows about it, did it really happen? Share your wins, present at all-hands, write those design docs that everyone will reference later.

#процессы