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

Продолжаем про "средних". "The manager’s job is less to tell them what to do, but more to inspire them." The Middle Manager of the Future: More Coaching, Less Commanding Прям на базе исследования (для фанатов пруфов). #management

Часто обсуждают переходить ли на темную менеджерскую сторону карьерной лестницы или ну его нафиг. Реже встречаются обсуждения "а что там дальше, на менеджерском пути?" Прямо скажем, в топ-директора и прочие топы ведь мало кто попадет (совсем мало). И большая часть тех, кто не вернется в разработчики, подрастут на уровень выше лида и останутся "вечными майорами" middle manager-ами (менеджерами среднего звена). Это не хорошо, не плохо. Это жизнь. Но даже middle-менеджеры бывают разными. Как и собственно уровень "среднего звена" будет разным в разных организациях. Все ровно то же, что и с уровнями сеньоров и принципалов в разработке. А что по ожиданиям от менеджеров среднего звена? "Middle managers as *critical thinkers* are an indispensable part of today's organisations. They are responsible to create pictures of possible futures for those who report to them." (с) Dr Zahira Jaser На этой неделе будет серия статей по этой теме. По ссылке в день, все равно больше никто не прочитает :) "The Real Value of Middle Managers" #management

Аналитики подсчитали, что четверть от общего числа веб-страниц, которые существовали в период с 2013 года по 2023 годы, по состоянию на октябрь 2023 года уже недоступны. В большинстве случаев это связано с тем, что с течением времени страницы сайтов радикально корректируются или же попросту удаляются. Для более старого контента эта тенденция также актуальна. Около 38% веб-страниц, существовавших в 2013 году, недоступны в настоящее время. Если же рассматривать веб-страницы, существовавшие в 2023 году, то показатель недоступных в настоящее время составит 8%.

Давно заметил, что много страниц, на которые ссылался в первых статьях блога перестали открываться. Ненадежная история... When Online Content Disappears и перевод на 3dnews #байки

признавайтесь, кто-то так делал? 🫣 #it_memes по пятницам

Принес я вам сегодня чудесную историю, написанную уже очень давно, но все так же актуальную. Это #классика с "много букв", так уже никто не пишет, и она прекрасная.. Про автоматизацию, тестировщиков, качество и вот это все… “Good enough” так “good enough” (https://testitquickly.com/2013/06/03/good-enough/) PS Кстати, пошарьтесь по статьям Алексея, это самые "вкусные" статьи на русском про то, что можно назвать "теорией тестирования". #quality

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

М.Болтон 2016 Я уже писал как-то , что у меня есть фразы-триггеры. Так вот "это не баг - этого не было в проработке", тоже одна из них... Напомню, про возможные причины ошибок было тут: - сделали, но ошибка в коде (или настройках среды и тд) - сделали, но не то, что ожидалось - даже не делали, так как этот сценарий не предусмотрели - ошибка во “внешнем” коде (open-source) #quality

Лучшее время, чтобы что-то начать, — это когда дела идут хреново. Потому что если дела сейчас идут неплохо, а ситуация (после начала изменений) станет хуже, вы решите, что это причина, из-за которой стоит остановиться.

чужие #мысли_вслух А ведь что-то в этом есть... И это правда еще и потому, что начинать что-то менять, если сейчас типа все неплохо - это капец, как трудно. Типа "а нафига?" С другой стороны, "и так хреново, еще и эти изменения...". Можно и не вытянуть. В этом месте и времени важна поддержка команды, руководителя. ЗЫ я в вот иногда(?) занудничаю в последнее время(только ли?) в таких ситуациях и может даже мешаю... #рефлексия_без_гуглежа и чудес

No Wrong Doors. Про культуру коммуникации и направление/корректирование информационных потоков. Очень часто наблюдаю истории аналогичные первому примеру из статьи. Но есть и оборотная сторона медали: есть люди которые упорно не хотят запоминать "правильную" (более быструю с точки зрения получения ответа) точку входа для соответствующих вопросов, которую им указали. А раз за разом "лезут" туда, куда им удобнее. И спустя повторяющихся несколько раз заходов никакая эмпатия уже не помогает, хорошо если нафиг не посылают после этого. #процессы

Примерно так выглядит Confluence любой конторы старше 5 лет. (сперто) #it_memes

Тимлидам непросто: требуется строить отношения с коллективом, постоянно учиться, терпеть относительно невысокую зп. Есть только одно чувство, которое способно скрепить всё это вместе и помочь работать эффективно: искренне полюбить свою работу. Ты должен стать солнцем для всех.

#мысли_вслух из древних и забытых интернетов Что думаете? Имхо, лиды - самая геморройная работа из всех, с которой мне приходилось сталкиваться лично. Какие могут быть ожидания? #management

Есть тут менеджеры с хай-перформерами? Как вы их, менеджите или не менеджите? OK, but how do I manage high performers?” The answer is simple — you don’t!

These types of people need rock-solid communication, a good framework of rules and boundaries and your trust, a lot of trust. They will manage themselves as long as they understand the expectations.

vs Manage Them!

Weak managers let high performing reports do whatever they want.

PS на самом деле статьи пересекаются по идеям, вопрос лишь в том, что понимать под "менеджментом". PS2

there’s no such thing as a “high performer”, only people who are high performing at a given time. “High performer” is used as a shorthand for “people who are currently performing exceptionally well in their role.”

#management

"Все покрыть тестами мешает рынок: конкуренты напишут без тестов дешевле, а глупый заказчик не поймет, что хуже..." #мысли_вслух из древних интернетов... Сначала не поймет, а потом как пойме-е-е-т. Но это неточно. И потом это будет уже совсем другая история. Хотя есть и другая версия, версия тех, кто верит, что с тестами быстрее и в каком-то смысле дешевле. #test_automation

What we talk about when we talk about ‘root cause’ Автор пытается ответить на вопрос о причине использования этого термина? Почему мы применяем его только в случае проблем, но не успеха?

“There is no root cause. The problem with this term isn't just that it's singular or that the word root is misleading: there's more. Trying to find causes at all is problematic...looking for causes to explain an incident limits what you'll find and learn. And the irony is that root cause analysis is built on this idea that incidents can be fully comprehended. They can't. We already have a better phrase for this, and it sounds way cooler: it's called a perfect storm. In this way, separating out causes and breaking down incidents into their multiple contributing factors, we're able to see that the things that led to an incident are either always or transiently present. An incident is just the first time they combined into a perfect storm of normal things that went wrong at the same time.”

....

A challenge for readers and listeners I’ll offer a few questions to consider the next time you read or hear the term ‘root cause’: • What is the author (or speaker) trying to convey by using the term? • What agenda(s) might the author (or speaker) have in their version of the story, other than providing the richest description they can? • What else can you imagine is influencing the outcome of the story being told, besides what is deemed the ‘root cause’? • What details seem to be noticeably absent in the story you’re being told? • What questions can you imagine being dismissed or discounted by the storyteller, if you had the chance to ask them? Questions like these are garden-variety critical thinking exercises. But they might help us explore what the story doesn’t tell us, or what might be missing in the story.

#процессы #it_философия

И вроде уже далеко не в первый раз, но каждый раз он удивляет... #it_memes в картине "Релиз - ты умеешь удивлять"

Интересный пример (подходом) трансформации достаточно традиционной "лестницы" в разработке. #management

"Разрабатываем без нянек" (с) или как минимизировать участие тестировщиков в вашей работе ЗЫ умел я раньше в почти лонгриды. Там, при желании, можно найти ответ на вопрос, смогут ли разработчики тестировать. #классика #testing

Да будет срачик. Вот интересно. Какое соотношение проблем продукта от незнания каких-то алгоритмов или там паттернов системного дизайна к проблемам "мы все знаем, но просто не подумали в момент реализации", "не написали тестов/не до конца проверили фичу", "не предусмотрели такой вариант использования", "у нас не было времени" (это мое любимое) и тдтп. Ну то есть пока, за все время (долгое, очень долгое время), я о-о-очень редко сталкивался с проблемами того, что применили не тот алгоритм (хотя вот буквально недавно было что-то похожее). Зато проблем от того, что просто бездумно (так кажется) фигачим все, что только можно, в базу и так же все пачкой запрашиваем из базы, от того, что куски ранее работающей функциональности в какой-то момент времени перестают вызываться (рефакторинг, ептеть), запросы в базу/в бек не профилируются и тому подобных приколов - громадье. Или "мы не продумали архитектуру". Да не можете вы продумать архитектуру навека, у вас требования к продукту меняются каждые полгода. Все что можно и нужно попытаться "продумать" - это то, как быстро менять реализацию. А быстро - это только с тестами получится, но на них часто забивают (времени много ведь занимают)... Я тешу себя надеждой, если делать все, как учат в паттернах системного дизайна, то менять тоже можно будет быстро. Но в реальности такого чуда ни разу не встречал. Было ли с кем-то такое чудо? #holywar

“Тестирование никогда не покажет того, что ошибок нет. Только то, что они есть.”

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

Когда ты подготовил письмо о релизе, и тут приходят очередные результаты секьюрити сканов со свежими базами уязвимостей... #it_memes

А как же эту архитектуру ПО лучше описывать? The Ultimate Guide To Software Architecture Documentation • Why should we document software architecture? • How should we structure software architecture documentation? • How should we visualize software architecture? • How do we write and manage software architecture documentation? Еще полезного из прошлых постов: • Про полезные практики фиксации принятых решений по реализации фичей. • Как принимать архитектурные решения? #tech_read