Ожидает прочтения

Wrong ways to use the database or decision pendulum Observing downsides of a particular technology - like a database - can force you to switch to a complete opposite, say picking up MongoDB after issues with scaling PostgreSQL. The problems start when the new tech is completely incapable of providing you even a fraction of necessary guarantees. But no more spoilers - grab an interesting story of one technical rewrite. #db #casestudy

https://habr.com/ru/articles/933090/

Кажется, про TDD давно всё известно: сперва тест — потом код — получаем покрытие. Но на деле его суть понимают неправильно — как критики, так и сторонники. Эта статья — не инструкция и не религиозная…

Гайд начинающего тимлида / Хабр https://habr.com/ru/articles/559394/

В данной статье хотелось бы помочь разобраться в профессии начинающим тимлидам, или тем, кто об этом только думает. Всё это я проговаривал на вебинаре в Хекслете тут . Однако я уверен, что есть такие…

Пятничное чтиво

Ссылки уходят в ежегодный летний отпуск на месяц с 1го августа (включительно). Увидимся с первого сентября. Спасибо что читаете и пишете комментарии ❤️

Также, сегодня спецвыпуск — три статьи о работе с техническим долгом.

Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.

—————————————

Техдолг. Большое руководство

Первая статья вводная в тему тех долга. Из текста узнаете что такое долг, каким бывает и как «выплачивать». Если с долгом работали только с помощью одной канбан доски — однозначный мастрид. Начинается текст с классификации 9 видов долгов. Тут как о коде, который стоит переписать, так и о секьюрити, «устаревших» технических решениях, людях и других видов. Причем, дается вторая классификация, основанная на влиянии на систему.

Дальше рассказывается о том, откуда долг возникает. Тут также две классификации, для каждой из которой найдете примеры:

• предумышленный/непредумышленный и безрассудный/благоразумный;
• предумышленный/непредумышленный и технические/организационные причины;

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

#tech_debt

—————————————

How Google Measures and Manages Tech Debt

Вторая статья рассказывает о конкретном подходе для работы с долгом. Текст основан на пейпере из гугла, в котором пытаются ответить на два вопроса: как отследить долг и как сделать так, чтобы разработка не встала во время «выплаты» долга.

В случае отслеживания, сначала придется категоризировать тех долг. У гугла получилось 10 категорий, которые не пересекаются с первой статьей. А для измерения, в компании, решили пойти по пути ежеквартальных опросов, где инженеры отвечают, что их замедляет в работе. Формулировка важна, так как цель не закрыть долг целиком, а закрыть только мешающий разработке. Но у опроса присутствует проблема с «лагом» и скептицизмом. Поэтому также используется наблюдение за кодом: количество TODO, терминов в ошибках и так далее. И благодаря этому нашли зависимость между «важностью» долга и контекстом, в котором компания варится. В случае менеджмента выделил отдельную команду, которая занималась только тех долгом. В статье найдете описание того, что команда делала. В конце найдете рассуждения о балансе между «выплатой» долга и разработкой фич. А также признаки, которые говорят о неуправляемости долга в компании.

#tech_debt

—————————————

Делать фичи или техдолг

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

• Выявление проблем;
• Определение противоречий между потребностями;
• Проверка адекватности между найденными требованиями и потребностями;
• Создание модели для определения причины проблем;
• Определение решений для причин изначальных проблем;
• Критика выбранного решения, для поиска «слабых мест». По сути, шаг связан с обработкой возможных рисков.

Единственное, статью лучше воспринимать как еще один инструмент (или как идею для вдохновения), а не как руководство к действию. Связано со спецификой теории ограничения и терминами ради терминов.

#tech_debt

Теория ограничений — это метод управления, разработанный Элияху Голдратом в 1980-х годах. Для популяризации своих идей он написал несколько книг в формате бизнес-романов, где на реальных кейсах…

Я принес. Деньги мотивируют или демотивируют? Финансовая мотивация сотрудников глазами IT-менеджера

Сегодня вам принес видос про деньги-денежки-деньжищи https://www.youtube.com/watch?v=Stpa2FfCP8c

Мне в нем понравился разбор разных исследований, теории справедливости и как вообще деньги влияют на удовлетворенность от работы. Особенно интересно смотрится эксперимент с капуцинами и история про абсолютные и относительные деньги. Например, удовлетворен человек своей зарплатой и всё ему хорошо. Но стоит ему узнать, что соседу платят за примерно (он не знает точно) то же самое на 5% больше, как уже просыпается праведный гнев и сильная дизмораль 🙂

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

Короче, смотрите, составляйте свое мнение, делитесь им в комментариях.

Спасибо Вите Корейше, что мне это видео скинул. Похоже, нового альтернативного человека не из нашего пузыря открыл мне, которого можно посматривать. Самобытный такой персонаж, судя по всему. Люблю такое 🙂

Финансовая мотивация сотрудников - сложная и интересная тема. Пробежимся вместе по теории справедливости, теории ожиданий Врума, поговорим о связи денег с уд…

Я принес. Из чего состоит счастье?

Сегодня не про менеджмент, но каждому нужная тема на подумать о себе и для себя.

Алексей Марков снял ролик про счастье в своем стиле. А именно рассмотрел несколько разных книг, мнений, добавил своего, и получился небольшой, но насыщенный и полезный для рефлексии микс https://youtu.be/GiffWh05hEQ.

Лично мне понравилась идея, что радость и удовольствие — это разные вещи, ведущие к разному результату (а где-то — и к зависимости).

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

И контринтуитивно успокаивающая цитата – «Жизнь – это утомительный труд, и надо это признать. И осознать, что это у всех так. И мы не одни в этой ежедневной борьбе. И, парадоксально – от этого осознания мы станем счастливее»

00:00 Разбиваем счастье на компоненты01:40 Три составляющих счастья04:20 Не ждите радуги и веселья06:02 Древние истоки наслаждения07:50 Радость против удовол…

https://habr.com/p/909060/

Будучи подростком, я часто выступал парламентёром, который на школьных «стрелках» первым выходил и пытался разобраться, за что мы вообще пытаемся сейчас бить друг другу лица. Переговоры составляли…

https://youtu.be/QKt2BlKUwpk

Дима Бугайченко — CDS B2C в Сбере. Мы познакомились в Минске, где выступали на митапе по рекомендательным системам. Мне понравился его доклад, а после, на аф…

https://www.youtube.com/watch?v=Fkhk7hWLmaQ

Вы можете задать вопрос спикеру в телеграм-канале https://t.me/FrontendConfChannel или чате https://t.me/FrontendConfTalks---------Приглашаем на FrontendConf…

Performance Review: the good, the bad, the ugly

Я уже когда-то писал пост про перфревью. А потом еще один про калибровки. Тогда впервые проходил процесс, и казалось что цель — справедливость для всех и каждого.

Сейчас заканчивается мой седьмой цикл перфревью.

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

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

Сейчас первый цикл прохожу как руководитель кластера.

Теперь понимаю, что справедливость у каждого тимлида своя и в финансовый отчет её не положишь. Пришло время переосмыслить, зачем оно вообще нужно. Помог подкаст Бреслав и Ложечкин, выпуск «Как устроен карьерный рост в Корпорациях»

Вот к чему пришел.

1. Основная цель — управляемость компании как системы

В Бауманке у нас был курс ТАУ — Теории Автоматического Управления.

Управление – это такая организация технологического процесса, которая обеспечивает достижение поставленной цели.

Применительно к компании:

1. Сотрудники или команды — элементы системы, объекты управления
2. У каждого элемента есть вход, куда подаются сигналы — цели / KPI
3. И выход, откуда берется результат работы

Система преобразует сигнал с выхода «проделанная работа» и подаёт его на вход как сигнал «оценка перформанса».

Сигнал «оценка перформанса» влияет на выполнение следующей «работы».

Высокая оценка — сигнал развиваться дальше в том же направлении. Низкая — сигнал скорректировать курс.

Эта обратная связь — то, что обеспечивает управляемость системы.

Без нее система либо уйдет вразнос, либо затухнет. С ней — стремится к заданным параметрам.

Что до справедливости.. Это вторичный продукт. Абсолютной справедливости не существует, потому что это она субъективна и у каждого своя.

Звучит бездушно, но на больших числах по-другому не работает.

Когда у тебя 1000+ сотрудников, ты физически не можешь с каждым поговорить. Тебе приходится управлять через абстракции и метрики, прятать живых людей за цифрами.

2. Защита от ошибок и выравнивание стандартов

Если у вас классные люди и классный руководитель — можно жить и без ревью.

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

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

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

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

Перформанс ревью — это система-уравнитель.

3. Защита от инфляции грейдов и хаоса при ротациях

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

Если убрать перформанс ревью и калибровки — то будет очень обычная ситуация «что-то Вася загрустил, дадим ка ему повышение».

Когда все знают, что промо — это не «руководитель захотел», а часть системы, у людей появляется ощущение прозрачности. Хотя это не всегда делает систему справедливой.

Итог

Можно не любить ревью. Я сам часто не люблю. Оно отнимает время, вызывает споры, и почти всегда есть кто-то недовольный.

Но альтернатива — хаос, в котором компания обречена, потому что не может повернуть руль.

Если ты сотрудник — не воспринимай оценку как вердикт. Это не суд, это сигнал.

Если ты менеджер — старайся быть тем, кто переводит сигналы в человеческий язык.

Поговорили про системы мотивации и performance management в корпорациях: что такое все эти level’ы, grade’ы, уровни, promotions, performance reviews, калибровки и т.д. Зачем они нужны, какие у них есть плюсы и минусы и как вообще их правильно готовит

https://kode.mave.digital/ep-29

Проекты закрываются, работа заканчивается, мир вокруг рушится — но кто-то в этот момент находит новые смыслы и запускает крутые инициативы. В чём их секрет? В новом эпизоде обсуждаем, как IT-специалистам смотреть на кризис не как на катастрофу, а как

Конкурентность в Go наглядно

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

#golang

https://kodikapusta.ru/news/k76n-konkurentnost-v-go-nagliadno

В этом выпуске Кирилл Мокевнин поговорил с Егором Бугаенко — автором «Elegant Objects» и сторонником «честного» ООП-мышления. Он раскрыл, почему классическое объектно-ориентированное программирование — это не архитектура, а иллюзия порядка, за которой скрывается хаос.

Разобрали, почему null, static и наследование — главные разрушители систем, как мышление «в классах» ведёт к техдолгу, и почему ORM прячет от нас реальные ошибки в работе с данными. Егор настаивает: код должен быть сконструирован, а не написан, иначе система становится неуправляемой — особенно в эпоху LLM, когда ИИ сыплет автопатчами и код перестаёт быть осмысленным.

💬 Также обсудили:

• Почему композиция объектов — основа устойчивой архитектуры
• Как мыслить модулями, а не строками кода
• Что такое Fail Fast и зачем системе «падать» сразу
• Почему архитектурное мышление — навык разработчика будущего
• Как LLM усиливают хаос, если нет модели
• Роль дизайн-долга и как он убивает бизнес-процессы

Принцип Ставок Энни Дьюк

Где-то месяц назад прочитал книгу и она прямо мега невероятный кайф.

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

Жизнь - это неопределенность. Каждый ваш выбор имеет некую вероятность на успех. Однако, 100% успех никто не гарантирует. Выбирая новую работу, вы делаете ставку, на то, что вам там будет лучше. Может ли что-то пойти не так? 100%

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

Вы не можете ничего гарантировать. Вы можете утверждать, что с вероятностью 80% проект будет сдан в срок. Но гарантировать? Точно нет.

Каждое ваше решение - это ставка. Вы делаете ставку вашими ресурсами: время, деньги, внимание.

Как и в покере или на бирже, важно не просто «угадать», а оценить: Какова вероятность успеха? Какова ценность выигрыша? Какова стоимость проигрыша? 6. EV-мышление (ожидаемая ценность) Даже если исход неудачен, ставка может быть хорошей, если на длинной дистанции она выигрывает. Это принцип, по которому мыслят профессионалы: “Я проиграл конкретную сделку, но принял правильное решение, потому что EV был положительным.” 7. Дисциплина важнее уверенности Лучшие игроки не уверены на 100%, но они дисциплинированы в ставках. Они знают, когда не ставить вообще. Это применимо в продуктах, инвестициях, найме, выборе фичи, да хоть в личной жизни.

Примеры применения:

• Фичи в продукте: «Есть 30% шанс, что эта фича взлетит, но если взлетит — увеличит выручку на 20%. EV — положительная ставка.»
• Хайринг: «Кандидат спорный, но upside высокий. Стоит рискнуть, если стоимость ошибки невысока.»
• Личная жизнь: «Не уверен, стоит ли идти в стартап. Вероятность успеха 20%, но рост X10. Если нет обязательств — ставка разумная.» Выводы: “Принцип ставок” — это не про азарт. Это про осознанные, аналитические, прагматичные решения. Про культуру «решений под вероятности», а не «правильных ответов».

Что такое EV (Expected Value) и зачем он тебе? Спасибо чатГПТ за отличное определение😁 EV (ожидаемая ценность) — это способ оценить, насколько ставка (решение) выгодна в среднем, если повторять её много раз. Формула: EV = (вероятность успеха × выигрыш) – (вероятность провала × потери) Примеры: Запускаем новую фичу Вероятность успеха: 30% Потенциальный рост выручки: +1 млн ₽ Вероятность провала: 70% Потери (время команды, отвлечение): –200 тыс ₽ EV = (0.3 × 1 000 000) – (0.7 × 200 000) = 300 000 – 140 000 = +160 000 ₽ Даже если «на глаз» кажется рискованным — ставка положительная. На длинной дистанции такие решения приносят прибыль. Хайринг рискованного кандидата Шанс, что кандидат выстрелит: 40% Его вклад: +X10 к команде Потери при фейле: несколько месяцев времени и ресурсов Если EV > 0 — ставка стоящая. Даже если проиграешь конкретный раз, решение было правильным.

Главное: EV не говорит, что произойдёт. Он говорит, что имеет смысл делать снова и снова. Это как профессиональный спорт: не угадывать, а делать +EV ставки и жить с результатом.

🔥 - если уже читал и зашло ❤️ - добавил в бэклог 💅 - если читал и не зашло

@badtechproject

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

Пятничное чтиво

Ссылки уходят в ежегодный летний отпуск на месяц с 1го августа (включительно). Увидимся с первого сентября. Спасибо что читаете и пишете комментарии ❤️

Также, сегодня спецвыпуск — три статьи о работе с техническим долгом.

Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.

—————————————

Техдолг. Большое руководство

Первая статья вводная в тему тех долга. Из текста узнаете что такое долг, каким бывает и как «выплачивать». Если с долгом работали только с помощью одной канбан доски — однозначный мастрид. Начинается текст с классификации 9 видов долгов. Тут как о коде, который стоит переписать, так и о секьюрити, «устаревших» технических решениях, людях и других видов. Причем, дается вторая классификация, основанная на влиянии на систему.

Дальше рассказывается о том, откуда долг возникает. Тут также две классификации, для каждой из которой найдете примеры:

• предумышленный/непредумышленный и безрассудный/благоразумный;
• предумышленный/непредумышленный и технические/организационные причины;

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

#tech_debt

—————————————

How Google Measures and Manages Tech Debt

Вторая статья рассказывает о конкретном подходе для работы с долгом. Текст основан на пейпере из гугла, в котором пытаются ответить на два вопроса: как отследить долг и как сделать так, чтобы разработка не встала во время «выплаты» долга.

В случае отслеживания, сначала придется категоризировать тех долг. У гугла получилось 10 категорий, которые не пересекаются с первой статьей. А для измерения, в компании, решили пойти по пути ежеквартальных опросов, где инженеры отвечают, что их замедляет в работе. Формулировка важна, так как цель не закрыть долг целиком, а закрыть только мешающий разработке. Но у опроса присутствует проблема с «лагом» и скептицизмом. Поэтому также используется наблюдение за кодом: количество TODO, терминов в ошибках и так далее. И благодаря этому нашли зависимость между «важностью» долга и контекстом, в котором компания варится. В случае менеджмента выделил отдельную команду, которая занималась только тех долгом. В статье найдете описание того, что команда делала. В конце найдете рассуждения о балансе между «выплатой» долга и разработкой фич. А также признаки, которые говорят о неуправляемости долга в компании.

#tech_debt

—————————————

Делать фичи или техдолг

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

• Выявление проблем;
• Определение противоречий между потребностями;
• Проверка адекватности между найденными требованиями и потребностями;
• Создание модели для определения причины проблем;
• Определение решений для причин изначальных проблем;
• Критика выбранного решения, для поиска «слабых мест». По сути, шаг связан с обработкой возможных рисков.

Единственное, статью лучше воспринимать как еще один инструмент (или как идею для вдохновения), а не как руководство к действию. Связано со спецификой теории ограничения и терминами ради терминов.

#tech_debt

Меня зовут Андрей Никольский, я Head of Platform в Банки.ру. Сегодня хочу обсудить не самую приятную, но важную тему: технический долг и как с ним работать. По мотивам Любой разработчик или…

???