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

Срочно обновляем UX-проработки, пятничных #it_memes не ждет.

Maker vs Multiplier

Короткое объяснение "на пальцах", в чем может быть ценность менеджера. И почему эту ценность может приносить не только менеджер.

PS особенно полезно для менеджеров-новичков: просто подумайте сегодня, что вам нужно сделать/делать, чтобы улучшить результаты команды.

#management

О хороших инженерах-программистах

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

• Отличные инженеры делают все вышеперечисленное, но проактивно.

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

PS и да, на всякий случай, ничего личного, legacy не равно плохой.

#management

Сначала изучаем/повторяем материал, потом проверяем знания на задачках (DevOps/Server Side)

Tutorials 📖
Deep dives into DevOps and Server Side topics where theory blends with hands-on examples. You can try out commands from each tutorial in the attached remote playground, either from the browser or via SSH access from your local terminal — no extra setup required.

Challenges 🏆
Focused hands-on problems designed to help you hone your DevOps or Server Side skills. Some challenges are more educational, while others are based on real-world scenarios. The platform provides hints and feedback for each challenge, including automated solution checks.

https://labs.iximiuz.com/

 #tech_read

Минутка ❤️ моим любимым девопсам (без сарказма, такие есть) в пятничных #it_memes

Scaling engineering teams in 2025 is about more than adding people. It’s about building habits that create focus, embed quality, and keep delivery predictable. Those are the choices that let teams grow without breaking.

- staying small avoids unnecessary complexity.
- embedding quality into everyday work enables speed at scale.
- disciplined release practices give teams the confidence to ship regularly without stress.

The Secrets to Scaling Engineering Teams (Lessons from Rails, Unity & WeTransfer)

ууу как ложится на мысли в голове... хотя реальность все как-то сложнее :)

#management

Про ошибки менеджера и умение их признавать

• Be specific about what you did wrong. Not “mistakes were made” or “things could have gone better.” But “I interrupted you three times in that meeting and dismissed your concerns. That was wrong.”
• Don’t make it about you. This isn’t the time for a long explanation of your stress levels or why you acted that way. Save that for your therapist or your own manager. The repair is about acknowledging the impact on the other person.
• Actually change the behavior. An apology without changed behavior is just empty words. If you keep making the same “mistake,” it’s not a mistake anymore; it’s a choice.
• Give it time. One conversation doesn’t instantly repair broken trust. It’s a starting point, not a finish line. You have to consistently show up differently.

#management

PS
1.Командир всегда прав.
2.Если командир неправ см. п.1 🫡

Немного воспоминаний и мыслей от Григорича.

Пока я 15 лет жил в уютном Windows-мире с Visual Studio, C++, COM/DCOM, NT сервисами, "тюнингом/хакингом" windows-реестра и прочими Windows-стеками/приложениями, упустил тот момент, когда рядом, параллельной жизнью, выросла история с вебом, докером, Linux-ом, кубами и тдтп.

ЗЫ до сих пор офигеваю от текущей сложности просто изменить настройки сервиса без его перезапуска или, прости господи, редеплоя. Уже 20! лет назад (на самом деле больше) на винде это спокойно решалось просто изменением реестра и правильно написанный сервис, сам перезачитывал свою конфигурацию, одновременно продолжая работу/обработку запросов.
Поменялась парадигма работы. Тут я готов принять несколько помидоров от знатоков/практиков, но для меня это до сих пор самый неприятный сюрприз.
Вообще, вспоминая то, что мы делали в 2015-2017, и глядя на текущие проблемы/решения, понимаю, что тогда мы (и точно не только мы) делали офигенно крутые вещи по обвеске собственно разработки для облегчения подключения тестирования. Еще всем известных Allure-отчетов не было, а у нас уже была такая штука. Спиралька, как она есть.

При этом, в то же время, я погружался в менеджмент и еще плотнее в тестирование. И тот же блог, большей своей частью, был именно про это. И вуаля - теперь я QA 😂 и чуть-чуть (на пол мизинца) DevOps (потому что туда тоже пришлось немного погрузиться). И вряд ли "настоящий" менеджер, потому что ... "сосны" 🙃

В чем мораль сих букв выше?

Смотрите вокруг, смотрите за тем, что творится в IT-мире, пробуйте, рефлексируйте и снова пробуйте. Не обустраивайте себе закрытый мирок, ибо мир вокруг меняется все быстрее. Не будьте, как Григорич.

Ну и глядя на ответы к моему вопрошающему посту (про долгое время работы на 1 месте). Про деньги/людей/отношением к жизни вокруг - понятно.
А вот с "интересными задачами" и "задачами по специализации" надо внимательнее. Потому что может случится так, что не будет задач и специализацию придется тюнить 😉

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

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

Но есть такая штука, как индивидуальное развитие, перф.ревью и прочие "индивидуализации" требующие "измерения" на уровне индивидума. Как это можно делать?

Варианты (порядок пунктов не является их приоритетом в применении):
1. Просто считать задачи за период. Вариант норм, если задачи требуют для решения +/- одинаковых усилий, то есть мы декомпозируем до понятного для оценки уровня, стараемся заводить односложные задачи.
Хахаха

Есть ложь, наглая ложь и "тут всего пара строчек, оценю задачу в половину сторипоинта"

Минусы: как считать ресечи/проектирование? Они часто сложно оцениваемы и иногда зависят от "смежников", а значит процессов:

Важно создавать процессы и организации, в которых взаимодействие будет выгоднее

2. Оценка 360 (опросы коллег), качественная метрика.
Минусы: большие трудозатраты, нужно покорпеть над вопросами, чтобы свести к минимуму межличностные отношения и субъективность.

3. Еще одна качественная метрика - соответствие зафиксированным (понятным и озвученным) ожиданиям от занимаемой сотрудником позиции.
Минусы: может иметь место субъективность со стороны лида/менеджера, если оценку он делает единолично. Ожидания могут меняться от лида к лиду. Здесь могут помочь (теоретически) те самые калибровки (которые я пока не встречал нормально работающими, но ходят былины, что такое есть)

4. Ваши варианты?
—————

Полезное:
- использовать это (или что-то другое) для сравнения разработчиков (тестировщиков и прочих) между собой - это путь в никуда.
- вот это еще посмотрите McKinsey Gets Developer Productivity Wrong.
- про качественные/количественные метрики.

#metrics

Measuring Software Engineering

Следить за производительностью системы/команды в целом более эффективно, чем делать то же самое на индивидуальном уровне.

Но есть нюансы, о которых в следующей серии...

#metrics

Оп-пачки, понеслась... Это неизбежно, как наступление зимы...
https://t.me/IT_without_miracles/309

Про модели или аватаров.

Любые способы типизации/классификации и прочей -ции людей - это лишь попытка представить человека, как модель отвечающую какой-то проблематике. Фактически способ "оцифровать" поведение человека в той или ситуации, построить его поведенческий аватар.

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

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

Женя вчера предложил хороший способ проверить это на себе.

Доживем ли мы до момента, когда все наши будущие действия смогут быть предсказаны ИИ-шечкой обученной на наших уже выполненных действиях? Шансы есть, но скорее всего только в том случае, если из людей сделают "Джонни-мнемоников", когда будут анализироваться не только действия, но и мысли в момент действия.

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

- какой ты менеджер, красный или черный?
- я божья коровка 😏

Red vs. Black

PS конечно все не так просто и черно/красно. Но мысль интересная.

#management

Базовая база
Top 12 Tips for API Security (в одной картинке)

#tech_read

Vibe Coding - еще один критерий для определения консерватора и новатора? 🤔
#it_memes, которые не про мемы

Moving from an orchestration-heavy to leadership-heavy management role

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

#management

How to delegate while maintaining high standards

• Delegating is not binary
• Identify your direct report’s task relevant maturity
• Resist the urge to “hide” behind doing stuff you’re already good at
• Take the time upfront to explain a project thoughtfully
• Avoid owning IC work

#management

Product Management for Engineering Managers

Think from idea to production — сфера интересов EM должна включать не только написание кода. Они должны интересоваться тем, как проблемы превращаются в идеи, как эти идеи формируются и реализуются. Это означает понимание процесса разработки продукта в вашей компании и влияние на него при необходимости.

Lower lead time means higher value — влияя на процессы вашей компании, сосредоточьтесь на сокращении времени выполнения от идеи до производства. Успех команды определяется не качеством работы инженеров, а тем, насколько быстро они могут предоставить своим клиентам высококачественную и эффективную работу. Это означает принятие решений, стимулирующих короткие циклы обратной связи, короткие итерации и тесное взаимодействие между подразделениями по всем направлениям.

Focus on early alignment — главное преимущество кросс-функциональных команд инженеров продукта заключается в том, что они имеют разные точки зрения на формирование продукта на всех этапах его разработки. Поэтому крайне важно стимулировать согласованность на раннем этапе между продуктом, дизайном и разработкой, гарантируя, что все понимают и согласны с тем, что они разрабатывают, почему они это разрабатывают и как они это будут делать. Практический метод, который я использовал для достижения этой цели, — это вводные встречи для планирования, гарантирующие всей команде возможность высказаться с самого начала.

Scope development in iterations of quality — самый простой способ избежать аврала - гарантировать, что всегда будет версия продукта, которая запущена или готова к запуску. Это превращает любой неудобный разговор о объеме работ «Почему эта функция ещё не запущена?» в более приемлемое бизнес-решение «Стоит ли выпускать версию 0.2, которая уже готова?». Лучший метод для этого — User Story Mapping, которое позволяет командам мыслить в рамках объема работ, а не переключателями «вкл/выкл».

Create space for challenging conversations — EMs должны убедиться, что другие специалисты понимают работу и компромиссы, которые необходимо принять, что позволит им участвовать в инженерном обсуждении. На практике это означает, что все объемы работ должны быть прописаны с точки зрения клиента, стимулировать конструктивные обсуждения объема работ и трудозатрат, а также позволять всем сторонам оценивать ценность любой работы, выполняемой в команде.

В конечном счете, инженерам и EMs необходимо сосредоточиться на влиянии, а влияние в команде разработчиков продукта определяется не только написанием кода — чем шире обсуждение этого вопроса EMs смогут организовать, тем лучших результатов они достигнут.

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

#процессы

А что все же делать с этими метриками?

The golden rule of metrics is this: any metric you maintain should directly drive action if outside expected bounds.

The reason this is an important rule is:

• Metrics are expensive to set up, so if you don’t use them, you’re wasting effort
• Metrics are expensive to maintain, so if you don’t use them, you’re wasting effort
• A metric that doesn’t drive action is a waste of time

#metrics

Чем дольше я работаю руководителем, тем больше убеждаюсь, что 80% дашбордов с метриками — это пустышки для взрослых менеджеров с плохим стратегическим чутьем и тревожными расстройствами.
Дашборды не предназначены для того, чтобы на них смотрели, они предназначены для того, чтобы их доставали в экстренной ситуации («кто-нибудь знает, что происходит с А? ").
Когда босс спрашивает, почему цифры плохие, часто полезно иметь дашборд, который сообщает, что они плохие из-за кого-то другого.

Не мое, но похоже на мое...😏 из тредика в X

#metrics