Меня часто спрашивают: «Как ты всё успеваешь? Преподавание, ТризТех (PT), конференции, канал...».
Отвечу честно: никакой магии. Просто система. И работает она не всегда, но чаще да.
Пост по следам моего спикера Анастасии «Приготовления зелий продуктивности», ей отдельная благодарность за отличное выступление. Делюсь своей системой — и новыми ингредиентами.
✅ Списки — база
Каждый день 10–17 задач и встречи в календаре. Не в голове — меньше стресса. Как выполнила или вечером проставляю галочки и выдыхаю.
🐸 Лягушка на завтрак
Самую противную задачу — первой. Сегодня это был сложный отзыв на ВКР. Сделала — и день пошёл.
⏱️ Правило 10 минут
Не идёт задача? Завожу таймер на 10 минут и просто начинаю. Через 10 минут спрашиваю себя: «Хочу продолжать?».
Часто — да. А если нет, значит, задача реально не сегодня. Но первые 10 минут ломают лёд.
✂️ Дробление задач
Вместо «Написать отзывы на ВКР»: «Найти старый шаблон отзыва» → «Обновить шаблон отзыва» → «Написать отзыв на ВКР студента А» → «Написать отзыв на ВКР студента Б». Маленькие шаги не пугают.
🚫 WIP Limits — не брать много
Work In Progress Limits — правило: одновременно не больше 2–3 задач. Иначе мозг перегружается, и ни одна не делается до конца.
❌ Что не зашло (на данный момент)
Геймификация — превращать работу в игру не люблю.
Прогрессивная нагрузка — мой ритм и так хаотичный.
Парное присутствие — если собака спящая рядом не считается, то мне никто не нужен для работы.
Метод помодоро — с моим количеством задач и переключений 25-минутные интервалы только сбивают. Заменила на правило 10 минут + дробление.
🎓 Моё резюме
Тайм-менеджмент — это не магия. Это набор приёмов. Берите то, что работает для вас.
Мой набор сейчас: списки + лягушка + правило 10 минут + дробление задач + WIP Limits.
Какие техники помогают вам? 👇
#Карьера #Инструменты
Please open Telegram to view this post
VIEW IN TELEGRAM
👍8🔥7❤1🥰1🤓1
📄TypeSpec: новый язык для API или очередная мода?
На Analyst Days 22 Руслан Папенко рассказывал про TypeSpec от Microsoft. Тема действительно горячая, но в индустрии любят волны хайпа — был RAML, был API Blueprint, теперь вот TypeSpec.
Я послушала, сравнила с OpenAPI и альтернативами. Делюсь выжимкой для прагматиков.
🧐 Что такое TypeSpec
TypeSpec — это предметно-ориентированный язык (DSL) для описания API. Он не заменяет OpenAPI напрямую, а компилируется в него (и не только). Релиз — апрель 2024, Microsoft, открытый исходный код.
Синтаксис напоминает TypeScript. Вы описываете модели данных, операции, а генератор выдаёт:
➖ спецификацию OpenAPI (YAML/JSON)
➖ документацию (например, HTML/Markdown)
➖ клиентские SDK на нескольких языках (основная поддержка TypeScript, .NET, Java, Python)
➖ генерация серверных заглушек (ограничена в основном .NET и JavaScript)
Звучит круто. Но давайте по фактам.
⚔️ Почему OpenAPI уже не торт
Презентация Руслана на Analyst Days и мнения инженеров со всего мира сходятся: OpenAPI, при всей своей популярности, доставляет много боли.
❌ Проблема №1: Нечеловеческий синтаксис
OpenAPI использует YAML или JSON — форматы, удобные для машин, но не для людей. Описания получаются многословными, часто похожими на «спагетти» из вложенных блоков. А разработчики с усталостью вспоминают, что им постоянно приходится подсматривать в документацию даже для простых вещей.
❌ Проблема №2: Сложность на масштабе
Если в проекте больше пары десятков эндпоинтов, спецификация превращается в гигантский файл (условно на 2000-3000+ строк). Отладка и поддержка такой простыни становятся крайне трудоёмкими.
❌ Проблема №3: Design-First страдает
OpenAPI создавался как формат документации готового API, не спорю, что далее он уже развивалась как формат для Design first. Если мы говорим про объёмные enterprise-системы, то вносить точечные изменения в разросшиеся YAML-файлы — пытка, да — есть визуальные редакторы...
💡 Чем TypeSpec лучше
Если взять простой пример (приводить не буду, был на конференции и полно в "интернетах"), то разница очевидна, разница будет раза в 3 по количеству строк.
✅ Композиция без боли
✅ Не привязан к REST
Описав модели, можно сгенерировать не только OpenAPI, но и gRPC (protobuf), AsyncAPI для сообщений, даже GraphQL.
✅ Один источник правды
Меняете модель — перегенерировали клиента, документацию, моки. Забыли обновить документацию вручную — не ваш случай.
🔄 Полная картина: какие есть альтернативы
Вопрос рёбром: инновация или тренд? Хочу расширить контекст. TypeSpec — не единственный игрок на поле «API как код».
1️⃣ Design First
Платформы вроде Apidog или Stoplight Studio отходят от сырого YAML . Они предлагают визуальные редакторы, схемы перетаскиванием, авто-моки и документацию на лету.
Плюсы: GUI понятен даже нетехническим специалистам. Минусы: GitHub не всегда удобен для ревью тяжелых PNG.
2️⃣ Code First
Инструменты вроде Swaggo (Go) или SpringDoc (Java) парсят комментарии в коде и генерируют OpenAPI.
Плюсы: Документация всегда соответствует коду. Минусы: Код обрастает аннотациями, сложно охватить всю систему целиком.
3️⃣ Альтернативные DSL и Protocol Buffers
Если TypeSpec от Microsoft, то Smithy от Amazon (используется в AWS) существует дольше.
Protocol Buffers (protobuf) от Google — вообще тяжёлая артиллерия для микросервисов.
Плюсы: Скорость, строгая типизация, поддержка в любом языке. Минусы: Бинарный протокол, REST вы получаете через транзакцию.
🎓 Моё резюме
Инструмент действительно зрелый, но ещё не полностью готов для промышленного использования всеми командами в любом масштабе.
Пробовали уже TypeSpec? Или всё ещё на YAML? 👇
#Инструменты
На Analyst Days 22 Руслан Папенко рассказывал про TypeSpec от Microsoft. Тема действительно горячая, но в индустрии любят волны хайпа — был RAML, был API Blueprint, теперь вот TypeSpec.
Я послушала, сравнила с OpenAPI и альтернативами. Делюсь выжимкой для прагматиков.
🧐 Что такое TypeSpec
TypeSpec — это предметно-ориентированный язык (DSL) для описания API. Он не заменяет OpenAPI напрямую, а компилируется в него (и не только). Релиз — апрель 2024, Microsoft, открытый исходный код.
Синтаксис напоминает TypeScript. Вы описываете модели данных, операции, а генератор выдаёт:
➖ спецификацию OpenAPI (YAML/JSON)
➖ документацию (например, HTML/Markdown)
➖ клиентские SDK на нескольких языках (основная поддержка TypeScript, .NET, Java, Python)
➖ генерация серверных заглушек (ограничена в основном .NET и JavaScript)
Звучит круто. Но давайте по фактам.
⚔️ Почему OpenAPI уже не торт
Презентация Руслана на Analyst Days и мнения инженеров со всего мира сходятся: OpenAPI, при всей своей популярности, доставляет много боли.
❌ Проблема №1: Нечеловеческий синтаксис
OpenAPI использует YAML или JSON — форматы, удобные для машин, но не для людей. Описания получаются многословными, часто похожими на «спагетти» из вложенных блоков. А разработчики с усталостью вспоминают, что им постоянно приходится подсматривать в документацию даже для простых вещей.
❌ Проблема №2: Сложность на масштабе
Если в проекте больше пары десятков эндпоинтов, спецификация превращается в гигантский файл (условно на 2000-3000+ строк). Отладка и поддержка такой простыни становятся крайне трудоёмкими.
❌ Проблема №3: Design-First страдает
OpenAPI создавался как формат документации готового API, не спорю, что далее он уже развивалась как формат для Design first. Если мы говорим про объёмные enterprise-системы, то вносить точечные изменения в разросшиеся YAML-файлы — пытка, да — есть визуальные редакторы...
💡 Чем TypeSpec лучше
Если взять простой пример (приводить не буду, был на конференции и полно в "интернетах"), то разница очевидна, разница будет раза в 3 по количеству строк.
✅ Композиция без боли
✅ Не привязан к REST
Описав модели, можно сгенерировать не только OpenAPI, но и gRPC (protobuf), AsyncAPI для сообщений, даже GraphQL.
✅ Один источник правды
Меняете модель — перегенерировали клиента, документацию, моки. Забыли обновить документацию вручную — не ваш случай.
🔄 Полная картина: какие есть альтернативы
Вопрос рёбром: инновация или тренд? Хочу расширить контекст. TypeSpec — не единственный игрок на поле «API как код».
1️⃣ Design First
Платформы вроде Apidog или Stoplight Studio отходят от сырого YAML . Они предлагают визуальные редакторы, схемы перетаскиванием, авто-моки и документацию на лету.
Плюсы: GUI понятен даже нетехническим специалистам. Минусы: GitHub не всегда удобен для ревью тяжелых PNG.
2️⃣ Code First
Инструменты вроде Swaggo (Go) или SpringDoc (Java) парсят комментарии в коде и генерируют OpenAPI.
Плюсы: Документация всегда соответствует коду. Минусы: Код обрастает аннотациями, сложно охватить всю систему целиком.
3️⃣ Альтернативные DSL и Protocol Buffers
Если TypeSpec от Microsoft, то Smithy от Amazon (используется в AWS) существует дольше.
Protocol Buffers (protobuf) от Google — вообще тяжёлая артиллерия для микросервисов.
Плюсы: Скорость, строгая типизация, поддержка в любом языке. Минусы: Бинарный протокол, REST вы получаете через транзакцию.
🎓 Моё резюме
Инструмент действительно зрелый, но ещё не полностью готов для промышленного использования всеми командами в любом масштабе.
Пробовали уже TypeSpec? Или всё ещё на YAML? 👇
#Инструменты
❤4👍1🤓1
🔞 Work‑life balance: почему советы «выключай телефон» не работают
Бегу 4,2 км. Дыхание сбилось, ноги гудят, а в голове одна мысль: «Зачем я вообще на это подписалась?».
Параллельно вспоминаю вчерашние дедлайны, недописанные требования, несогласованные вопросы. И тут меня осеняет: баланс между работой и жизнью — это как бег. Если рвануть с места — сорвёшь дыхание. Если остановиться — не добежишь.
Вот о чём я думала на финише и какие модели из организационной психологии реально помогают не выгорать (даже когда начальник в другом часовом поясе, а дети болеют).
🧠 Модель №1. Границы не по времени, а по энергии
На забеге нельзя всё время бежать в одном темпе. Ты ускоряешься на спусках, сбавляешь на подъёмах.
Так же и с работой. Классическая ошибка — пытаться отделить работу хронологически (с 9 до 18). Но если вы вымотаны — вы не отдохнёте, даже если часы показывают 18:00.
Что делать:
Определите свои пики продуктивности и провалы. У меня утро и поздний вечер — пики (да, я сова). 14–16 часов — провал: там только механическая работа или вышивка.
Баланс — это не «сколько часов», а «восстановился ли я к следующему рабочему отрезку».
После забега я была разбита физически, но ментально отдохнула. И на следующий день работала эффективнее, чем после 8 часов сна.
🧩 Модель №2. Не «работа vs жизнь», а ролевой баланс
У вас не две сферы (работа и не‑работа), а с десяток: родитель, партнёр, друг, сотрудник, хобби-энтузиаст, бегун, человек, который спит и ест.
Проблема не в перекосе между работой и жизнью, а в том, что какая‑то роль долго недополучает внимания.
Что делать:
Раз в месяц выписывайте 5–6 ключевых ролей. Напротив каждой — оценку от 1 до 10.
Баланс — это не равенство часов, а отсутствие ролей с оценкой ниже 4 две недели подряд.
У меня роль «бегунья» иногда падает до 3 — тогда я записываюсь на забег. Роли «системный аналитик» и «работник ИТМО» почти всегда высокие — но это перекос, и тогда страдает роль «человек с книжкой».
🎯 Модель №3. Приоритеты по принципу «не больше трёх»
Модель Грега МакКеона из «Эссенциализма»: в любой момент времени у вас может быть только 3 настоящих приоритета. Остальное — делегировать, отложить или отменить.
На уровне дня: выберите 3 задачи, после которых день можно считать успешным. У меня в списке 5–7 задач, но три из них — жирным шрифтом.
На уровне жизни: выберите 3 сферы, которые развиваете прямо сейчас. Остальные — поддерживаете в фоновом режиме. Сейчас у меня: 1) канал, 2) работа, 3) здоровье.
🚫 Почему модели работают лучше популярных советов
Совет «не работайте после 20» не работает, если у вас дедлайн и пик энергии вечером. Вы будете чувствовать себя виноватым.
✅ Работают энергетические границы: поработал вечером — честно возьми выходной днём.
Совет «отдыхайте с семьёй по выходным» не работает, если выходные — единственное время на хобби.
✅ Работает ролевой баланс: «Сегодня суббота — роль "бегунья" в приоритете, семья подождёт час».
Совет «делайте список из 5–7 задач» не работает, потому что качественно вы делаете 2–3.
✅ Работает принцип трёх: 3 задачи = успех. Остальное — бонус.
📚 Моё резюме
Work‑life balance — это не расписание и не самодисциплина. Это система управления энергией, ролями и приоритетами.
Если выстроить эти три опоры, можно работать и по ночам, и по выходным — и при этом не выгорать. А без них не помогут ни тайм-блоки, ни цифровой детокс.
У меня эта система неидеальна. Я всё ещё иногда работаю до полуночи и забываю про чтение книг. Но благодаря этим моделям я знаю, что именно сломалось, и могу это починить.
А на следующем забеге я точно не буду думать о работе. Или буду, но хотя бы осознанно.
#Карьера #Инструменты
Бегу 4,2 км. Дыхание сбилось, ноги гудят, а в голове одна мысль: «Зачем я вообще на это подписалась?».
Параллельно вспоминаю вчерашние дедлайны, недописанные требования, несогласованные вопросы. И тут меня осеняет: баланс между работой и жизнью — это как бег. Если рвануть с места — сорвёшь дыхание. Если остановиться — не добежишь.
Вот о чём я думала на финише и какие модели из организационной психологии реально помогают не выгорать (даже когда начальник в другом часовом поясе, а дети болеют).
🧠 Модель №1. Границы не по времени, а по энергии
На забеге нельзя всё время бежать в одном темпе. Ты ускоряешься на спусках, сбавляешь на подъёмах.
Так же и с работой. Классическая ошибка — пытаться отделить работу хронологически (с 9 до 18). Но если вы вымотаны — вы не отдохнёте, даже если часы показывают 18:00.
Что делать:
Определите свои пики продуктивности и провалы. У меня утро и поздний вечер — пики (да, я сова). 14–16 часов — провал: там только механическая работа или вышивка.
Баланс — это не «сколько часов», а «восстановился ли я к следующему рабочему отрезку».
После забега я была разбита физически, но ментально отдохнула. И на следующий день работала эффективнее, чем после 8 часов сна.
🧩 Модель №2. Не «работа vs жизнь», а ролевой баланс
У вас не две сферы (работа и не‑работа), а с десяток: родитель, партнёр, друг, сотрудник, хобби-энтузиаст, бегун, человек, который спит и ест.
Проблема не в перекосе между работой и жизнью, а в том, что какая‑то роль долго недополучает внимания.
Что делать:
Раз в месяц выписывайте 5–6 ключевых ролей. Напротив каждой — оценку от 1 до 10.
Баланс — это не равенство часов, а отсутствие ролей с оценкой ниже 4 две недели подряд.
У меня роль «бегунья» иногда падает до 3 — тогда я записываюсь на забег. Роли «системный аналитик» и «работник ИТМО» почти всегда высокие — но это перекос, и тогда страдает роль «человек с книжкой».
🎯 Модель №3. Приоритеты по принципу «не больше трёх»
Модель Грега МакКеона из «Эссенциализма»: в любой момент времени у вас может быть только 3 настоящих приоритета. Остальное — делегировать, отложить или отменить.
На уровне дня: выберите 3 задачи, после которых день можно считать успешным. У меня в списке 5–7 задач, но три из них — жирным шрифтом.
На уровне жизни: выберите 3 сферы, которые развиваете прямо сейчас. Остальные — поддерживаете в фоновом режиме. Сейчас у меня: 1) канал, 2) работа, 3) здоровье.
🚫 Почему модели работают лучше популярных советов
Совет «не работайте после 20» не работает, если у вас дедлайн и пик энергии вечером. Вы будете чувствовать себя виноватым.
✅ Работают энергетические границы: поработал вечером — честно возьми выходной днём.
Совет «отдыхайте с семьёй по выходным» не работает, если выходные — единственное время на хобби.
✅ Работает ролевой баланс: «Сегодня суббота — роль "бегунья" в приоритете, семья подождёт час».
Совет «делайте список из 5–7 задач» не работает, потому что качественно вы делаете 2–3.
✅ Работает принцип трёх: 3 задачи = успех. Остальное — бонус.
📚 Моё резюме
Work‑life balance — это не расписание и не самодисциплина. Это система управления энергией, ролями и приоритетами.
Если выстроить эти три опоры, можно работать и по ночам, и по выходным — и при этом не выгорать. А без них не помогут ни тайм-блоки, ни цифровой детокс.
У меня эта система неидеальна. Я всё ещё иногда работаю до полуночи и забываю про чтение книг. Но благодаря этим моделям я знаю, что именно сломалось, и могу это починить.
А на следующем забеге я точно не буду думать о работе. Или буду, но хотя бы осознанно.
#Карьера #Инструменты
🔥10🤓6❤2👏1
🫣 Безопасность ИИ для системного аналитика: как не слить данные в ChatGPT
На митапе «Цифровой диалог на Неве» я выступала с темой «Безопасность ИИ для системного аналитика».
Вокруг LLM сейчас столько хайпа, что про безопасность вспоминают не все.
Другие доклады только подтвердили: мы все нащупываем новые роли.
👉 Как ощущает себя системный аналитик в эру ИИ
👉 Agent Coding для аналитика
❓ Ваша LLM-безопасность: 5 вопросов себе
Вместо скучной лекции показала чек-лист вопросов, которые необходимо задавать перед оптравкой промпта.
Когда вы в следующий раз откроете ChatGPT или корпоративный LLM, остановитесь на 10 секунд и спросите себя:
1️⃣ Удалил ли я из промпта всё, что нельзя показывать посторонним?
ФИО, паспорт, IP, банковские реквизиты, внутренние кодовые названия проектов. LLM запоминает и может «случайно» вернуть это другому пользователю.
2️⃣ Запросил ли у модели источники или пошаговую логику?
Если ИИ выдал готовый ответ без объяснений — вы не можете проверить, откуда он взялся. Просите ссылки, обоснования, шаги рассуждений.
3️⃣ Добавил ли запрет на генерацию опасного кода?
LLM может радостно сгенерировать
4️⃣ Проверил ли ответ на противоречия с утверждёнными артефактами?
ИИ может звучать убедительно, но противоречить вашему ТЗ, архитектурному решению или стандарту безопасности. Сверяйте.
5️⃣ Использую ли LLM для NDA-материалов?
Только локальную или корпоративную. Публичный ChatGPT — не место для коммерческой тайны.
⚠️ OWASP Top 10 для LLM
Да, у OWASP теперь есть отдельный топ‑10 рисков для генеративного ИИ. Там, например:
Prompt Injection — Инъекция промптов — пользователь заставляет бота игнорировать системные правила.
Insecure Output Handling — Небезопасная обработка выходных данных — модель возвращает HTML с тегом script, и фронтенд его выполняет. Классический XSS, но источник — LLM.
Excessive Agency — Избыточный уровень прав — это когда у модели слишком много прав. Она сама решает вызвать API удаления данных. Очень опасная штука.
Data Poisoning — Отравление данных — в базу знаний (RAG) или в датасет для дообучения кто-то загрузил вредоносный документ.
🎓 Моё резюме
LLM — мощный инструмент, но не магия. И тем более не замена головы.
Промпт тоже требования. Только требования к нейросети. Чем точнее вы опишете, что можно и что нельзя, тем меньше рисков.
А вы как проверяете свои промпты? Есть свои «запретные темы»? 👇
#Термины #Инструменты
На митапе «Цифровой диалог на Неве» я выступала с темой «Безопасность ИИ для системного аналитика».
Вокруг LLM сейчас столько хайпа, что про безопасность вспоминают не все.
Другие доклады только подтвердили: мы все нащупываем новые роли.
👉 Как ощущает себя системный аналитик в эру ИИ
👉 Agent Coding для аналитика
❓ Ваша LLM-безопасность: 5 вопросов себе
Вместо скучной лекции показала чек-лист вопросов, которые необходимо задавать перед оптравкой промпта.
Когда вы в следующий раз откроете ChatGPT или корпоративный LLM, остановитесь на 10 секунд и спросите себя:
1️⃣ Удалил ли я из промпта всё, что нельзя показывать посторонним?
ФИО, паспорт, IP, банковские реквизиты, внутренние кодовые названия проектов. LLM запоминает и может «случайно» вернуть это другому пользователю.
2️⃣ Запросил ли у модели источники или пошаговую логику?
Если ИИ выдал готовый ответ без объяснений — вы не можете проверить, откуда он взялся. Просите ссылки, обоснования, шаги рассуждений.
3️⃣ Добавил ли запрет на генерацию опасного кода?
LLM может радостно сгенерировать
DELETE FROM users; без WHERE или eval(input()), если вы об этом не попросите. Прописывайте ограничения прямо в промпте.4️⃣ Проверил ли ответ на противоречия с утверждёнными артефактами?
ИИ может звучать убедительно, но противоречить вашему ТЗ, архитектурному решению или стандарту безопасности. Сверяйте.
5️⃣ Использую ли LLM для NDA-материалов?
Только локальную или корпоративную. Публичный ChatGPT — не место для коммерческой тайны.
⚠️ OWASP Top 10 для LLM
Да, у OWASP теперь есть отдельный топ‑10 рисков для генеративного ИИ. Там, например:
Prompt Injection — Инъекция промптов — пользователь заставляет бота игнорировать системные правила.
Insecure Output Handling — Небезопасная обработка выходных данных — модель возвращает HTML с тегом script, и фронтенд его выполняет. Классический XSS, но источник — LLM.
Excessive Agency — Избыточный уровень прав — это когда у модели слишком много прав. Она сама решает вызвать API удаления данных. Очень опасная штука.
Data Poisoning — Отравление данных — в базу знаний (RAG) или в датасет для дообучения кто-то загрузил вредоносный документ.
🎓 Моё резюме
LLM — мощный инструмент, но не магия. И тем более не замена головы.
Промпт тоже требования. Только требования к нейросети. Чем точнее вы опишете, что можно и что нельзя, тем меньше рисков.
А вы как проверяете свои промпты? Есть свои «запретные темы»? 👇
#Термины #Инструменты
🤓5🔥2
🖋Конструктивная критика: что это такое (и что — нет)
📖 Определение
Конструктивная критика — форма обратной связи, которая направлена на выявление недостатков и предложений по их устранению, осуществляемая с фокусом на позитивных аспектах работы. Это не просто указание на ошибки, а детальный и обоснованный анализ, который позволяет человеку увидеть свои слабые места и понять, каким образом он может улучшить свою практику.
В более широком философском смысле конструктивная критика — «созидательная критика, предлагающая конкретные пути решения проблем, реальные методы разрешения противоречий, эффективные способы преодоления заблуждений». В отличие от негативной, разрушительной критики («голого» отрицания всего и вся), конструктивная критика не просто отбрасывает критикуемые концепции, но сохраняет их позитивное, рациональное содержание.
Неконструктивная критика — оценка личности, обобщения, эмоции без фактов.
🧠 Ключевое различие: факты vs оценки
Факты можно проверить. Оценки — это чужое мнение, часто эмоциональное.
❌ «Ты вечно опаздываешь» — это оценка, обобщение.
✅ «Ты пришёл на встречу в 10:15 вместо 10:00» — это факт.
❌ «Ты пишешь ужасный код» — оценка личности.
✅ «Этот метод не обрабатывает null» — факт.
❌ «Ты не умеешь писать ТЗ» — оценка.
✅ «В разделе 2 нет ошибочного сценария» — факт.
⚖️ Почему люди боятся критики
Исследования показывают: мозг реагирует на критику так же, как на физическую боль. Поэтому даже нейтральные замечания воспринимаются как угроза.
Конструктивная критика снижает эту реакцию, потому что:
➖даёт понятные рамки («сделай вот это» вместо «ты плохой»)
➖оставляет лицо («я совершил ошибку», а не «я — ошибка»)
📌 Примеры из практики
Ситуация: Коллега перебивает вас на совещаниях.
❌ Неконструктивно: «Ты грубиян, вечно меня перебиваешь».
✅ Конструктивно: «На последних трёх совещаниях, когда я начинал говорить про API, ты вступался в диалог. Мне сложно донести мысль. Давай договоримся: я поднимаю руку или говорю «дай закончить», и ты ждёшь паузы».
Ситуация: Студент сдал отчёт с ошибками в формулах.
❌ Неконструктивно: «Ты безграмотный, не учил матан».
✅ Конструктивно: «В разделе 3 во второй формуле неправильно посчитана дисперсия. Ошибка в знаменателе. Сверься с методичкой на стр. 15 и приди на консультацию завтра».
Ситуация: Разработчик прислал код с проблемами.
❌ Неконструктивно: «Ты халтурщик, переделывай всё».
✅ Конструктивно: «В этом классе нет обработки ошибок при пустом вводе. Пользователь увидит непонятное сообщение. Добавь проверку и верни на ревью».
🎓 Моё резюме
Конструктивная критика — это не про «быть вежливым». Это про точность и полезность. Она — важнейшее условие для профессионального развития. Если вы не можете сформулировать, что конкретно не так или что делать, — не критикуйте. Сначала поймите сами.
#Карьера
📖 Определение
Конструктивная критика — форма обратной связи, которая направлена на выявление недостатков и предложений по их устранению, осуществляемая с фокусом на позитивных аспектах работы. Это не просто указание на ошибки, а детальный и обоснованный анализ, который позволяет человеку увидеть свои слабые места и понять, каким образом он может улучшить свою практику.
В более широком философском смысле конструктивная критика — «созидательная критика, предлагающая конкретные пути решения проблем, реальные методы разрешения противоречий, эффективные способы преодоления заблуждений». В отличие от негативной, разрушительной критики («голого» отрицания всего и вся), конструктивная критика не просто отбрасывает критикуемые концепции, но сохраняет их позитивное, рациональное содержание.
Неконструктивная критика — оценка личности, обобщения, эмоции без фактов.
🧠 Ключевое различие: факты vs оценки
Факты можно проверить. Оценки — это чужое мнение, часто эмоциональное.
❌ «Ты вечно опаздываешь» — это оценка, обобщение.
✅ «Ты пришёл на встречу в 10:15 вместо 10:00» — это факт.
❌ «Ты пишешь ужасный код» — оценка личности.
✅ «Этот метод не обрабатывает null» — факт.
❌ «Ты не умеешь писать ТЗ» — оценка.
✅ «В разделе 2 нет ошибочного сценария» — факт.
⚖️ Почему люди боятся критики
Исследования показывают: мозг реагирует на критику так же, как на физическую боль. Поэтому даже нейтральные замечания воспринимаются как угроза.
Конструктивная критика снижает эту реакцию, потому что:
➖даёт понятные рамки («сделай вот это» вместо «ты плохой»)
➖оставляет лицо («я совершил ошибку», а не «я — ошибка»)
📌 Примеры из практики
Ситуация: Коллега перебивает вас на совещаниях.
❌ Неконструктивно: «Ты грубиян, вечно меня перебиваешь».
✅ Конструктивно: «На последних трёх совещаниях, когда я начинал говорить про API, ты вступался в диалог. Мне сложно донести мысль. Давай договоримся: я поднимаю руку или говорю «дай закончить», и ты ждёшь паузы».
Ситуация: Студент сдал отчёт с ошибками в формулах.
❌ Неконструктивно: «Ты безграмотный, не учил матан».
✅ Конструктивно: «В разделе 3 во второй формуле неправильно посчитана дисперсия. Ошибка в знаменателе. Сверься с методичкой на стр. 15 и приди на консультацию завтра».
Ситуация: Разработчик прислал код с проблемами.
❌ Неконструктивно: «Ты халтурщик, переделывай всё».
✅ Конструктивно: «В этом классе нет обработки ошибок при пустом вводе. Пользователь увидит непонятное сообщение. Добавь проверку и верни на ревью».
🎓 Моё резюме
Конструктивная критика — это не про «быть вежливым». Это про точность и полезность. Она — важнейшее условие для профессионального развития. Если вы не можете сформулировать, что конкретно не так или что делать, — не критикуйте. Сначала поймите сами.
#Карьера
👍8🔥2🤯1
🎭 Зачем ходить в театр и читать книги, если вы уже не в школе
Два дня подряд я ходила на спектакли, испытала восторг и задалась вопросом: зачем я это делаю. Делюсь своими размышлениями.
🧠 Учиться на чужих ошибках
В книгах и спектаклях герои постоянно принимают неверные решения. Лгут, не договаривают, недооценивают риски, переоценивают себя.
Мы смотрим и думаем: «Ну как так можно? Надо было сказать правду». Или: «Надо было проверить контрагента».
Это бесплатный тренажёр ошибок. Свои ошибки мы не любим и не замечаем. Чужие — видим отчётливо.
И в работе это окупается: вы начинаете замечать, где коллеги или вы сами повторяете судьбу героя. И вовремя тормозите.
🎭 Понимать людей
Карьера — это не только про технологии. Карьера также про отношения. С заказчиком, с начальником, с командой, с подчинёнными.
В спектаклях и хороших романах мы видим, почему люди поступают так, а не иначе. Страх, любовь, гордость, обида, желание казаться, а не быть.
Когда вы понимаете, что движет человеком, вы:
➖ задаёте правильные вопросы
➖ слышите, что не сказано
➖ не лезете на рожон, когда можно договориться
➖ переводите эмоции в конструктив
Это навык. И его прокачивают не только курсы по коммуникациям, но и Чехов, и Островский.
🔎 Критическое мышление
В хорошей книге или пьесе нет однозначных героев. У каждого своя правда. Каждый злодей считает себя спасителем.
Вы учитесь:
➖ видеть разные точки зрения
➖ не верить первому впечатлению
➖ искать скрытые мотивы
➖ задавать вопрос «а что если наоборот?»
Без этого в карьере — никак. Начальник говорит «срочно». А что на самом деле? Страх опоздать? Конкурент дышит в спину? Просто не умеет говорить о приоритетах?
🎓 Моё резюме
Профессиональная литература даёт ответы. Художественная — учит задавать вопросы.
Спектакль «Гроза» или роман «Преступление и наказание» — это не развлечение. Это тренировка эмпатии и критического мышления.
Для карьеры в ИТ тоже полезно, как и десятый курс по управлению проектами.
А вы замечали, как книги или фильмы помогают вам в работе?а 👇
#Карьера
Два дня подряд я ходила на спектакли, испытала восторг и задалась вопросом: зачем я это делаю. Делюсь своими размышлениями.
🧠 Учиться на чужих ошибках
В книгах и спектаклях герои постоянно принимают неверные решения. Лгут, не договаривают, недооценивают риски, переоценивают себя.
Мы смотрим и думаем: «Ну как так можно? Надо было сказать правду». Или: «Надо было проверить контрагента».
Это бесплатный тренажёр ошибок. Свои ошибки мы не любим и не замечаем. Чужие — видим отчётливо.
И в работе это окупается: вы начинаете замечать, где коллеги или вы сами повторяете судьбу героя. И вовремя тормозите.
🎭 Понимать людей
Карьера — это не только про технологии. Карьера также про отношения. С заказчиком, с начальником, с командой, с подчинёнными.
В спектаклях и хороших романах мы видим, почему люди поступают так, а не иначе. Страх, любовь, гордость, обида, желание казаться, а не быть.
Когда вы понимаете, что движет человеком, вы:
➖ задаёте правильные вопросы
➖ слышите, что не сказано
➖ не лезете на рожон, когда можно договориться
➖ переводите эмоции в конструктив
Это навык. И его прокачивают не только курсы по коммуникациям, но и Чехов, и Островский.
🔎 Критическое мышление
В хорошей книге или пьесе нет однозначных героев. У каждого своя правда. Каждый злодей считает себя спасителем.
Вы учитесь:
➖ видеть разные точки зрения
➖ не верить первому впечатлению
➖ искать скрытые мотивы
➖ задавать вопрос «а что если наоборот?»
Без этого в карьере — никак. Начальник говорит «срочно». А что на самом деле? Страх опоздать? Конкурент дышит в спину? Просто не умеет говорить о приоритетах?
🎓 Моё резюме
Профессиональная литература даёт ответы. Художественная — учит задавать вопросы.
Спектакль «Гроза» или роман «Преступление и наказание» — это не развлечение. Это тренировка эмпатии и критического мышления.
Для карьеры в ИТ тоже полезно, как и десятый курс по управлению проектами.
А вы замечали, как книги или фильмы помогают вам в работе?а 👇
#Карьера
❤8🤓2👍1
🏃♀ Сойти с дистанции — это не проигрыш
Я бежала трейл 25 км. Сошла на 8,5 км, у меня примерно на 7-м километре заболело колено, старая проблема обострилась. Я дошла до контрольной точки и поняла: продолжать не могу, нога не сгибается. И снялась.
И знаете что? Это был не проигрыш. Это был правильный выбор с дальнейшей рефлексией что и как надо делать, чтобы повторно зайти на этот путь и уже пройти его полностью.
🧠 Сойти с пути — значит вовремя остановиться
В беге, в карьере, в проектах, в жизни.
Мы привыкли думать, что сойти — это провал. Что надо терпеть, дожимать, идти до конца. Что слабые сходят, а сильные — доходят.
Но есть другая правда...
Сойти из-за сложностей — не слабость. Это реальная оценка своих сил и состояния в тот момент. Это умение сказать: «Сейчас я не могу. Дальше будет хуже. Я выбираю остановиться, чтобы сохранить себя для другого».
Бежать через боль — не героизм. Бежать через боль, которая разрушает тело — глупость. В профессии то же самое: работать на износ до выгорания — не доблесть, а путь в никуда.
⚖️ Переоценить и недооценить
Можно переоценить себя. Я думала, что 25 км — это просто. Но колено решило иначе. И это нормально — не угадать заранее.
Можно и недооценить. Моя сестра сомневалась, стоит ли вообще ехать. Хотела продать слот. Я её поддержала: «Давай попробуем. Ты сможешь. А если нет — ничего страшного».
Она поехала. И прошла всю дистанцию. Без травм, без сомнений.
🤝 Поддержка на выбранном пути
Иногда человек рядом сомневается. Боится. Думает, что не справится.
И твоя задача — не тянуть его/её за руку, а сказать: «Я рядом. Делай свой выбор. Что бы ты ни решил/решила — я с тобой».
Сестра хотела сойти вместе со мной. Я сказала: «Беги дальше. Ты сможешь.».
Она решила идти дальше. И дошла.
Получается, если бы не поддержка — она вообще не поехала бы на старт. Иногда поддержка нужна не на дистанции, а в момент сомнения: «А стоит ли вообще начинать?».
🎓 Моё резюме
Сойти из-за сложностей — не проигрыш. Проигрыш — не начать, не попробовать, отказаться из-за страха. Важно проанализировать что пошло не так и если это того стоит — вернуться на тот путь.
Важно быть тем, кто поддержит. Не толкает, не тянет, не кричит «ты должна/должен». А просто говорит: «Я с тобой. Что бы ты ни решила/решила — я рядом».
И тогда человек идёт дальше. Или вовремя останавливается. И то, и другое — правильно.
Был ли у вас момент, когда вы вовремя остановились или, наоборот, решили идти дальше благодаря поддержке? 👇
#Байки #Карьера
Я бежала трейл 25 км. Сошла на 8,5 км, у меня примерно на 7-м километре заболело колено, старая проблема обострилась. Я дошла до контрольной точки и поняла: продолжать не могу, нога не сгибается. И снялась.
И знаете что? Это был не проигрыш. Это был правильный выбор с дальнейшей рефлексией что и как надо делать, чтобы повторно зайти на этот путь и уже пройти его полностью.
🧠 Сойти с пути — значит вовремя остановиться
В беге, в карьере, в проектах, в жизни.
Мы привыкли думать, что сойти — это провал. Что надо терпеть, дожимать, идти до конца. Что слабые сходят, а сильные — доходят.
Но есть другая правда...
Сойти из-за сложностей — не слабость. Это реальная оценка своих сил и состояния в тот момент. Это умение сказать: «Сейчас я не могу. Дальше будет хуже. Я выбираю остановиться, чтобы сохранить себя для другого».
Бежать через боль — не героизм. Бежать через боль, которая разрушает тело — глупость. В профессии то же самое: работать на износ до выгорания — не доблесть, а путь в никуда.
⚖️ Переоценить и недооценить
Можно переоценить себя. Я думала, что 25 км — это просто. Но колено решило иначе. И это нормально — не угадать заранее.
Можно и недооценить. Моя сестра сомневалась, стоит ли вообще ехать. Хотела продать слот. Я её поддержала: «Давай попробуем. Ты сможешь. А если нет — ничего страшного».
Она поехала. И прошла всю дистанцию. Без травм, без сомнений.
🤝 Поддержка на выбранном пути
Иногда человек рядом сомневается. Боится. Думает, что не справится.
И твоя задача — не тянуть его/её за руку, а сказать: «Я рядом. Делай свой выбор. Что бы ты ни решил/решила — я с тобой».
Сестра хотела сойти вместе со мной. Я сказала: «Беги дальше. Ты сможешь.».
Она решила идти дальше. И дошла.
Получается, если бы не поддержка — она вообще не поехала бы на старт. Иногда поддержка нужна не на дистанции, а в момент сомнения: «А стоит ли вообще начинать?».
🎓 Моё резюме
Сойти из-за сложностей — не проигрыш. Проигрыш — не начать, не попробовать, отказаться из-за страха. Важно проанализировать что пошло не так и если это того стоит — вернуться на тот путь.
Важно быть тем, кто поддержит. Не толкает, не тянет, не кричит «ты должна/должен». А просто говорит: «Я с тобой. Что бы ты ни решила/решила — я рядом».
И тогда человек идёт дальше. Или вовремя останавливается. И то, и другое — правильно.
Был ли у вас момент, когда вы вовремя остановились или, наоборот, решили идти дальше благодаря поддержке? 👇
#Байки #Карьера
❤6👏3👍1😁1
🔆 Как давать обратную связь: модели, которые работают
В продолжении поста про конструктивную критику.
🧠 Модель SBI (Situation — Behaviour — Impact)
Разработана в Центре творческого лидерства (CCL). Используется в крупных корпорациях по всему миру.
Situation (ситуация) — когда и где это случилось.
Пример: «На совещании во вторник...»
Behaviour (поведение) — конкретное действие (только факты, без оценок).
Пример: «...ты сказал, что моя идея не сработает, и не объяснил почему»
Impact (влияние) — последствие для дела, команды, процесса.
Пример: «Я растерялся и не стал предлагать ещё одну идею, которая могла быть полезной»
Почему SBI работает:
✅ Конкретика. Человек знает, о каком именно моменте речь.
✅ Нет оценок. Вы говорите про действия, а не про личность.
✅ Понятны последствия. Объясняется, почему проблема важна, а не «потому что я так сказал».
🍞 Про «сэндвич» (похвала — критика — похвала)
Метод всё ещё популярен, но исследования (включая работу профессора Карен Макмиллан) показывают: он чаще вредит.
Почему:
❌ Люди запоминают только середину
❌ Похвала в начале и конце кажется неискренней
❌ Создаётся ощущение манипуляции
Когда сэндвич может работать:
Если у вас доверительные отношения и вы регулярно даёте обратную связь, а не раз в полгода.
🎯 Другие модели
1️⃣ COIN (Context — Observation — Impact — Next steps)
Расширенная версия SBI. В классической версии буква C означает Context (Контекст), а не «Care», как иногда пишут в адаптациях. Контекст помогает ещё точнее обозначить обстоятельства, а уже затем вы переходите к наблюдению и последствиям.
Context (Контекст): «На встрече с заказчиком вчера...»
Observation (Наблюдение): «...ты сказал "это невозможно" без объяснений».
Impact (Влияние): «Заказчик замолчал и теперь не говорит о рисках».
Next steps (Следующие шаги): «Давай в следующий раз фиксировать проблемы словами "я вижу риск", а потом обсуждать решения».
2️⃣ Модель «Я — Мы — Ты» (формула быстрой связи)
Популяризирована консалтинговой компанией Bain & Company как структура для командной динамики. В рабочей практике её часто адаптируют для быстрой постановки задач или срочных правок в переписке.
«Я»: «Я заметил, что отчёт по практике задержался на три дня».
«Мы»: «Нам нужно сдать его к пятнице».
«Ты»: «Можешь прислать черновик завтра к обеду, чтобы я успел проверить?»
⚠️ Эту модель часто путают с Radical Candor («Честность»), но это разные подходы. Radical Candor строится на сочетании личной заботы и прямой конфронтации, а «Я — Мы — Ты» — это просто чёткая структура просьбы.
🎓 Моё резюме
Выберите модель, которая удобна вам. SBI — самая универсальная для рабочих ситуаций. COIN — для эмоционально сложных разговоров. «Я — Мы — Ты» — для быстрого решения задач.
Главное в любой модели: конкретика, факты, отсутствие оценок личности и чёткий переход к действиям. Сэндвич оставьте в прошлом.
Что думаете? Какая модель ближе вам в работе? 👇
#Карьера #Инструменты
В продолжении поста про конструктивную критику.
🧠 Модель SBI (Situation — Behaviour — Impact)
Разработана в Центре творческого лидерства (CCL). Используется в крупных корпорациях по всему миру.
Situation (ситуация) — когда и где это случилось.
Пример: «На совещании во вторник...»
Behaviour (поведение) — конкретное действие (только факты, без оценок).
Пример: «...ты сказал, что моя идея не сработает, и не объяснил почему»
Impact (влияние) — последствие для дела, команды, процесса.
Пример: «Я растерялся и не стал предлагать ещё одну идею, которая могла быть полезной»
Почему SBI работает:
✅ Конкретика. Человек знает, о каком именно моменте речь.
✅ Нет оценок. Вы говорите про действия, а не про личность.
✅ Понятны последствия. Объясняется, почему проблема важна, а не «потому что я так сказал».
🍞 Про «сэндвич» (похвала — критика — похвала)
Метод всё ещё популярен, но исследования (включая работу профессора Карен Макмиллан) показывают: он чаще вредит.
Почему:
❌ Люди запоминают только середину
❌ Похвала в начале и конце кажется неискренней
❌ Создаётся ощущение манипуляции
Когда сэндвич может работать:
Если у вас доверительные отношения и вы регулярно даёте обратную связь, а не раз в полгода.
🎯 Другие модели
1️⃣ COIN (Context — Observation — Impact — Next steps)
Расширенная версия SBI. В классической версии буква C означает Context (Контекст), а не «Care», как иногда пишут в адаптациях. Контекст помогает ещё точнее обозначить обстоятельства, а уже затем вы переходите к наблюдению и последствиям.
Context (Контекст): «На встрече с заказчиком вчера...»
Observation (Наблюдение): «...ты сказал "это невозможно" без объяснений».
Impact (Влияние): «Заказчик замолчал и теперь не говорит о рисках».
Next steps (Следующие шаги): «Давай в следующий раз фиксировать проблемы словами "я вижу риск", а потом обсуждать решения».
2️⃣ Модель «Я — Мы — Ты» (формула быстрой связи)
Популяризирована консалтинговой компанией Bain & Company как структура для командной динамики. В рабочей практике её часто адаптируют для быстрой постановки задач или срочных правок в переписке.
«Я»: «Я заметил, что отчёт по практике задержался на три дня».
«Мы»: «Нам нужно сдать его к пятнице».
«Ты»: «Можешь прислать черновик завтра к обеду, чтобы я успел проверить?»
⚠️ Эту модель часто путают с Radical Candor («Честность»), но это разные подходы. Radical Candor строится на сочетании личной заботы и прямой конфронтации, а «Я — Мы — Ты» — это просто чёткая структура просьбы.
🎓 Моё резюме
Выберите модель, которая удобна вам. SBI — самая универсальная для рабочих ситуаций. COIN — для эмоционально сложных разговоров. «Я — Мы — Ты» — для быстрого решения задач.
Главное в любой модели: конкретика, факты, отсутствие оценок личности и чёткий переход к действиям. Сэндвич оставьте в прошлом.
Что думаете? Какая модель ближе вам в работе? 👇
#Карьера #Инструменты
🔥4🤓2
📩 Как принимать критику и не взрываться
В прошлом посте мы говорили о том, как давать конструктивную обратную связь. Но критика — это диалог, и вторая сторона в нём не менее важна. Умение принимать замечания без потери самооценки и отношений — это навык, который открывает двери в карьере и жизни.
🧠 Почему сложно принимать критику
Это не слабость, это биология. Нейровизуализационные исследования (МРТ) показывают, что критика активирует те же зоны мозга, что и физическая боль — особенно переднюю поясную кору и островковую долю. Мозг включает защиту: отрицание, оправдания, контратака.
Это нормальная эволюционная реакция. Но если не научиться её тормозить, вы:
➖ перестанете слышать полезную информацию
➖ испортите отношения с людьми, чьё мнение важно
➖ застрянете в карьере (никто не хочет работать с тем, кто не воспринимает обратную связь)
Важный нюанс: критика особенно ранит перфекционистов и людей с заниженной самооценкой — они склонны воспринимать замечание не как «ошибку в задаче», а как «я неудачник». Этот внутренний перевод «факт → приговор» и есть главный источник боли. Осознание этого механизма уже помогает снизить накал.
🛠 Алгоритм приёма критики (5 шагов)
1️⃣ Остановитесь
Не отвечайте сразу. Сделайте вдох. Скажите: «Спасибо, я услышал. Дай подумать минуту». Эта пауза прерывает автоматическую защитную реакцию.
2️⃣ Отделите факты от интерпретации
Здесь важно различать три уровня:
📌 Факт — объективное событие. Пример: «В двух последних спринтах я сдал задачи на день позже».
📌 Обобщение — преувеличение. Пример: «Ты вечно срываешь сроки».
📌 Интерпретация — оценочный вывод. Пример: «Ты безответственный» или «Твой код — каша».
Ваша задача — отсечь обобщения и интерпретации и остаться в поле фактов. Вместо «мой код — каша» спросите себя: «Какая конкретная часть кода вызвала замечание?» Обычно там оказывается один спорный момент, а не вся ваша профессиональная жизнь.
3️⃣ Уточните, если что-то непонятно
Не достраивайте догадки — задавайте вопросы:
✅ Можешь привести конкретный пример?
✅ Что именно в моей работе тебя не устроило?
✅ Что ты предлагаешь сделать иначе?
4️⃣ Поблагодарите за обратную связь
Даже если критика кажется несправедливой. Фраза «Спасибо, что сказал» не означает «я согласен». Это означает «я услышал и подумаю». Это сохраняет отношения и оставляет вам пространство для манёвра.
5️⃣ Решите, что делать
После паузы возможны варианты:
🔸 согласиться и изменить поведение
🔸 не согласиться и аргументированно объяснить почему (по фактам, а не эмоциям)
🔸 попросить время подумать
🎯 Кого критикует — так же важно, как и что
Не всякая обратная связь имеет одинаковый вес. Вот простая система оценки, которая поможет не тратить нервы зря:
🔥 Компетентный и доброжелательный — это золотой источник. Слушайте внимательно и благодарите.
🙉 Некомпетентный, но доброжелательный — вежливо выслушайте, но не спешите внедрять. Проверьте факты сами.
⚠️ Компетентный, но недоброжелательный — фильтруйте. Может быть полезно, но перепроверяйте каждое замечание.
🚫 Некомпетентный и недоброжелательный — это не критика, а шум. Пропускайте мимо ушей без чувства вины.
Уважающий вас человек не будет использовать оскорбительные формулировки. Если критикующий не разбирается в вашей работе и не желает вам добра — его мнение можно игнорировать.
❓ Как реагировать на несправедливую критику
Формула: Признание + Вопрос + Переход в конструктив
❌ Ты не прав, у меня всё нормально
✅ Я слышу твою оценку. Можешь привести пример, где я поступил не так?
Если критика — это оскорбление или переход на личности:
«Я готов обсуждать факты и конкретные действия. Если ты переходишь на личности, я вынужден остановить разговор и вернуться к нему, когда мы оба будем готовы к диалогу».
Отдельный случай — троллинг или пассивная агрессия. Если человек не приводит аргументов, использует обобщения («все так говорят») или насмехается — это не критика. Не тратьте время на анализ такого «фидбека». Лучшая реакция — коротко и нейтрально закончить диалог.
🎓 Моё резюме
Принимать критику — навык. Он тренируется. Главные принципы:
➡️ не защищаться сразу — дайте себе паузу
➡️ отделять факты от обобщений и оценок
➡️ уточнять, а не додумывать
➡️ благодарить за обратную связь, даже если она неприятна
➡️ фильтровать источник — не всё сказанное заслуживает вашего внимания
И помните: если вы никогда не получаете критику — вы, скорее всего, стоите на месте. Рост начинается там, где заканчивается зона комфорта.
#Карьера #SoftSkills
В прошлом посте мы говорили о том, как давать конструктивную обратную связь. Но критика — это диалог, и вторая сторона в нём не менее важна. Умение принимать замечания без потери самооценки и отношений — это навык, который открывает двери в карьере и жизни.
🧠 Почему сложно принимать критику
Это не слабость, это биология. Нейровизуализационные исследования (МРТ) показывают, что критика активирует те же зоны мозга, что и физическая боль — особенно переднюю поясную кору и островковую долю. Мозг включает защиту: отрицание, оправдания, контратака.
Это нормальная эволюционная реакция. Но если не научиться её тормозить, вы:
➖ перестанете слышать полезную информацию
➖ испортите отношения с людьми, чьё мнение важно
➖ застрянете в карьере (никто не хочет работать с тем, кто не воспринимает обратную связь)
Важный нюанс: критика особенно ранит перфекционистов и людей с заниженной самооценкой — они склонны воспринимать замечание не как «ошибку в задаче», а как «я неудачник». Этот внутренний перевод «факт → приговор» и есть главный источник боли. Осознание этого механизма уже помогает снизить накал.
🛠 Алгоритм приёма критики (5 шагов)
1️⃣ Остановитесь
Не отвечайте сразу. Сделайте вдох. Скажите: «Спасибо, я услышал. Дай подумать минуту». Эта пауза прерывает автоматическую защитную реакцию.
2️⃣ Отделите факты от интерпретации
Здесь важно различать три уровня:
📌 Факт — объективное событие. Пример: «В двух последних спринтах я сдал задачи на день позже».
📌 Обобщение — преувеличение. Пример: «Ты вечно срываешь сроки».
📌 Интерпретация — оценочный вывод. Пример: «Ты безответственный» или «Твой код — каша».
Ваша задача — отсечь обобщения и интерпретации и остаться в поле фактов. Вместо «мой код — каша» спросите себя: «Какая конкретная часть кода вызвала замечание?» Обычно там оказывается один спорный момент, а не вся ваша профессиональная жизнь.
3️⃣ Уточните, если что-то непонятно
Не достраивайте догадки — задавайте вопросы:
✅ Можешь привести конкретный пример?
✅ Что именно в моей работе тебя не устроило?
✅ Что ты предлагаешь сделать иначе?
4️⃣ Поблагодарите за обратную связь
Даже если критика кажется несправедливой. Фраза «Спасибо, что сказал» не означает «я согласен». Это означает «я услышал и подумаю». Это сохраняет отношения и оставляет вам пространство для манёвра.
5️⃣ Решите, что делать
После паузы возможны варианты:
🔸 согласиться и изменить поведение
🔸 не согласиться и аргументированно объяснить почему (по фактам, а не эмоциям)
🔸 попросить время подумать
🎯 Кого критикует — так же важно, как и что
Не всякая обратная связь имеет одинаковый вес. Вот простая система оценки, которая поможет не тратить нервы зря:
🔥 Компетентный и доброжелательный — это золотой источник. Слушайте внимательно и благодарите.
🙉 Некомпетентный, но доброжелательный — вежливо выслушайте, но не спешите внедрять. Проверьте факты сами.
⚠️ Компетентный, но недоброжелательный — фильтруйте. Может быть полезно, но перепроверяйте каждое замечание.
🚫 Некомпетентный и недоброжелательный — это не критика, а шум. Пропускайте мимо ушей без чувства вины.
Уважающий вас человек не будет использовать оскорбительные формулировки. Если критикующий не разбирается в вашей работе и не желает вам добра — его мнение можно игнорировать.
❓ Как реагировать на несправедливую критику
Формула: Признание + Вопрос + Переход в конструктив
❌ Ты не прав, у меня всё нормально
✅ Я слышу твою оценку. Можешь привести пример, где я поступил не так?
Если критика — это оскорбление или переход на личности:
«Я готов обсуждать факты и конкретные действия. Если ты переходишь на личности, я вынужден остановить разговор и вернуться к нему, когда мы оба будем готовы к диалогу».
Отдельный случай — троллинг или пассивная агрессия. Если человек не приводит аргументов, использует обобщения («все так говорят») или насмехается — это не критика. Не тратьте время на анализ такого «фидбека». Лучшая реакция — коротко и нейтрально закончить диалог.
🎓 Моё резюме
Принимать критику — навык. Он тренируется. Главные принципы:
➡️ не защищаться сразу — дайте себе паузу
➡️ отделять факты от обобщений и оценок
➡️ уточнять, а не додумывать
➡️ благодарить за обратную связь, даже если она неприятна
➡️ фильтровать источник — не всё сказанное заслуживает вашего внимания
И помните: если вы никогда не получаете критику — вы, скорее всего, стоите на месте. Рост начинается там, где заканчивается зона комфорта.
#Карьера #SoftSkills
❤3👍2🔥1🙏1🤓1
🫁 Микрофронтенды vs SPA: когда монолит перестаёт дышать
SPA (Single Page Application) — это классика. Один фронтенд-репозиторий, одна сборка, одна точка входа. Загрузился раз — и дальше роутинг живёт внутри браузера без перезагрузок. Всё просто и предсказуемо.
Microfrontends (Микрофронтенды) — это «микросервисы на клиенте». Большое приложение собирается из независимых модулей (виджетов/микро-приложений), каждый из которых может разрабатываться отдельной командой, на своей технологии и выкатываться по своему графику.
⚔️ SPA: плюсы и минусы
✅ Плюсы:
После загрузки — молниеносный роутинг
Один стек на всю команду — проще онбординг
Легко шарить утилиты, UI-кит, логику через общий код
Сборка и деплой — тривиальные (одна команда
❌ Минусы:
Первая загрузка может раздуваться до огромных размеров (бандл толстеет со временем)
Код превращается в монолит: страшно менять что-то в «старой» зоне, потому что непонятно, кто ещё это использует
Любое изменение — пересборка и перекат всего приложения целиком
Разные команды в одном репозитории начинают мешать друг другу (конфликты в
🧩 Микрофронтенды: плюсы и минусы
✅ Плюсы:
Команды полностью независимы: каждый сам решает, когда выкатывать фичу
Можно обновить один модуль без пересборки всего остального — деплой точечный
Технологическая свобода: команда А пишет на React, команда Б — на Vue, команда В — на Angular (и это реально работает через Module Federation или Single-SPA)
Масштабирование разработки: 10+ команд работают параллельно, не наступая друг другу на пятки
❌ Минусы:
Инфраструктура резко усложняется: нужна сборщица (оркестратор), которая склеивает части в рантайме
Дублирование кода — общая боль. Каждый модуль тащит свою копию React, свои стили, свои утилиты, если не настроить разделение зависимостей
Роутинг и общее состояние (например, корзина в маркетплейсе) требуют отдельной архитектуры, которую надо продумывать с нуля
Высокий порог входа: новому разработчику надо понять, как работают 5 модулей, а не один монолит
🎯 Когда что выбирать
SPA подходит, если:
➖ Команда до 10–15 человек
➖ Приложение не разбито на жёсткие доменные зоны
➖ Вы не переживаете, что не сможете обновить часть без переката всего
➖ Хотите быстро стартовать и минимизировать инфраструктурные затраты
Микрофронтенды оправданы, если:
➖ Команда более 20 разработчиков (или активно растёт)
➖ У приложения есть чёткие домены: каталог, корзина, личный кабинет, админка
➖ Разные команды хотят быть независимыми в выборе технологий и графиков релизов
➖ Это Enterprise, где части продукта могут развиваться разными темпами
Классический пример:
Веб-версия маркетплейса. Команда «Каталог» пишет на React, команда «Корзина» — на Vue, команда «Личный кабинет» — на Angular. Все три собираются в одну страницу через Webpack Module Federation или Single-SPA. Пользователь видит единый сайт, а внутри — модули от разных команд.
🎓 Моё резюме
Микрофронтенды — это не про «круто», а про «больно, но надо, когда выросли». Это те же микросервисы, только на фронте: та же независимость и та же головная боль с инфраструктурой.
Мой совет: не начинайте с микрофронтов. Начните с хорошего SPA-монолита. Используйте правильную архитектуру внутри (FSD, модули, чёткие слои). Когда монолит начнёт душить вас организационно — тогда и задумайтесь о разделении.
А у вас что за проект? SPA или уже микрофронтенды? Если делите — как именно? В рантайме или на сборке? 👇
#Термины #Архитектура
SPA (Single Page Application) — это классика. Один фронтенд-репозиторий, одна сборка, одна точка входа. Загрузился раз — и дальше роутинг живёт внутри браузера без перезагрузок. Всё просто и предсказуемо.
Microfrontends (Микрофронтенды) — это «микросервисы на клиенте». Большое приложение собирается из независимых модулей (виджетов/микро-приложений), каждый из которых может разрабатываться отдельной командой, на своей технологии и выкатываться по своему графику.
⚔️ SPA: плюсы и минусы
✅ Плюсы:
После загрузки — молниеносный роутинг
Один стек на всю команду — проще онбординг
Легко шарить утилиты, UI-кит, логику через общий код
Сборка и деплой — тривиальные (одна команда
build)❌ Минусы:
Первая загрузка может раздуваться до огромных размеров (бандл толстеет со временем)
Код превращается в монолит: страшно менять что-то в «старой» зоне, потому что непонятно, кто ещё это использует
Любое изменение — пересборка и перекат всего приложения целиком
Разные команды в одном репозитории начинают мешать друг другу (конфликты в
package.json, разный стиль кода, очереди на деплой)🧩 Микрофронтенды: плюсы и минусы
✅ Плюсы:
Команды полностью независимы: каждый сам решает, когда выкатывать фичу
Можно обновить один модуль без пересборки всего остального — деплой точечный
Технологическая свобода: команда А пишет на React, команда Б — на Vue, команда В — на Angular (и это реально работает через Module Federation или Single-SPA)
Масштабирование разработки: 10+ команд работают параллельно, не наступая друг другу на пятки
❌ Минусы:
Инфраструктура резко усложняется: нужна сборщица (оркестратор), которая склеивает части в рантайме
Дублирование кода — общая боль. Каждый модуль тащит свою копию React, свои стили, свои утилиты, если не настроить разделение зависимостей
Роутинг и общее состояние (например, корзина в маркетплейсе) требуют отдельной архитектуры, которую надо продумывать с нуля
Высокий порог входа: новому разработчику надо понять, как работают 5 модулей, а не один монолит
🎯 Когда что выбирать
SPA подходит, если:
➖ Команда до 10–15 человек
➖ Приложение не разбито на жёсткие доменные зоны
➖ Вы не переживаете, что не сможете обновить часть без переката всего
➖ Хотите быстро стартовать и минимизировать инфраструктурные затраты
Микрофронтенды оправданы, если:
➖ Команда более 20 разработчиков (или активно растёт)
➖ У приложения есть чёткие домены: каталог, корзина, личный кабинет, админка
➖ Разные команды хотят быть независимыми в выборе технологий и графиков релизов
➖ Это Enterprise, где части продукта могут развиваться разными темпами
Классический пример:
Веб-версия маркетплейса. Команда «Каталог» пишет на React, команда «Корзина» — на Vue, команда «Личный кабинет» — на Angular. Все три собираются в одну страницу через Webpack Module Federation или Single-SPA. Пользователь видит единый сайт, а внутри — модули от разных команд.
🎓 Моё резюме
Микрофронтенды — это не про «круто», а про «больно, но надо, когда выросли». Это те же микросервисы, только на фронте: та же независимость и та же головная боль с инфраструктурой.
Мой совет: не начинайте с микрофронтов. Начните с хорошего SPA-монолита. Используйте правильную архитектуру внутри (FSD, модули, чёткие слои). Когда монолит начнёт душить вас организационно — тогда и задумайтесь о разделении.
А у вас что за проект? SPA или уже микрофронтенды? Если делите — как именно? В рантайме или на сборке? 👇
#Термины #Архитектура
👍3❤2🤓1
🤓 Что такое RFC и почему их должен знать каждый ИТ-специалист
Вы когда-нибудь задумывались, почему интернет работает так, как работает? Почему ваш браузер понимает сервер, а сервер — ваш запрос?
За этим стоят RFC — Request for Comments («Запрос комментариев»). За этим скромным названием скрывается основа основ: от того, как устроен TCP/IP, до того, как работают email и веб-протоколы.
📜 Что такое RFC простыми словами
RFC — это документы, в которых описаны технические спецификации интернета. Они публикуются IETF (Internet Engineering Task Force) — открытым международным сообществом разработчиков и исследователей, которые и создают интернет-стандарты.
Первый RFC появился в 1969 году. С тех пор их выпущено уже больше 9000. И да, среди них есть даже первоапрельские шутки — например, RFC 1149 про передачу IP-пакетов по голубиной почте. Кстати, формально этот документ имеет статус «Experimental», но это не мешает ему быть классикой юмористических RFC.
🧠 Главное, что надо знать об RFC
1️⃣ Не все RFC — это стандарты
Это распространённое заблуждение. Некоторые RFC носят информационный характер. Другие — экспериментальные. Только часть из них попадает на «стандартный трек».
Современный путь к статусу «Интернет-стандарт» выглядит так (с 2011 года):
Internet‑Draft (черновик, живёт 6 месяцев) → Proposed Standard (предлагаемый стандарт) → Internet Standard (получает номер STD).
Промежуточного статуса «Draft Standard» больше не существует — его упразднили, чтобы ускорить процесс стандартизации.
И даже статус стандарта не вечен — он может устареть и быть помечен как «Historic».
2️⃣ Философия RFC: «Грубый консенсус и работающий код»
Главный принцип IETF, который в 1992 году сформулировал Дэвид Кларк: «We reject kings, presidents, and voting. We believe in rough consensus and running code» («Мы отвергаем королей, президентов и голосования. Мы верим в грубый консенсус и работающий код»).
Стандарт должен быть не просто красиво написан. Он должен быть реализован и протестирован на практике. Поэтому для перехода на уровень «Internet Standard» требуется как минимум две успешные, независимые реализации.
🎓 Моё резюме
RFC — это язык, на котором говорит интернет. Понимать их — значит понимать, как устроена основа вашей профессии.
Вы знали об их существовании? Какой последний прочли? 👇
#Термины
Вы когда-нибудь задумывались, почему интернет работает так, как работает? Почему ваш браузер понимает сервер, а сервер — ваш запрос?
За этим стоят RFC — Request for Comments («Запрос комментариев»). За этим скромным названием скрывается основа основ: от того, как устроен TCP/IP, до того, как работают email и веб-протоколы.
📜 Что такое RFC простыми словами
RFC — это документы, в которых описаны технические спецификации интернета. Они публикуются IETF (Internet Engineering Task Force) — открытым международным сообществом разработчиков и исследователей, которые и создают интернет-стандарты.
Первый RFC появился в 1969 году. С тех пор их выпущено уже больше 9000. И да, среди них есть даже первоапрельские шутки — например, RFC 1149 про передачу IP-пакетов по голубиной почте. Кстати, формально этот документ имеет статус «Experimental», но это не мешает ему быть классикой юмористических RFC.
🧠 Главное, что надо знать об RFC
1️⃣ Не все RFC — это стандарты
Это распространённое заблуждение. Некоторые RFC носят информационный характер. Другие — экспериментальные. Только часть из них попадает на «стандартный трек».
Современный путь к статусу «Интернет-стандарт» выглядит так (с 2011 года):
Internet‑Draft (черновик, живёт 6 месяцев) → Proposed Standard (предлагаемый стандарт) → Internet Standard (получает номер STD).
Промежуточного статуса «Draft Standard» больше не существует — его упразднили, чтобы ускорить процесс стандартизации.
И даже статус стандарта не вечен — он может устареть и быть помечен как «Historic».
2️⃣ Философия RFC: «Грубый консенсус и работающий код»
Главный принцип IETF, который в 1992 году сформулировал Дэвид Кларк: «We reject kings, presidents, and voting. We believe in rough consensus and running code» («Мы отвергаем королей, президентов и голосования. Мы верим в грубый консенсус и работающий код»).
Стандарт должен быть не просто красиво написан. Он должен быть реализован и протестирован на практике. Поэтому для перехода на уровень «Internet Standard» требуется как минимум две успешные, независимые реализации.
🎓 Моё резюме
RFC — это язык, на котором говорит интернет. Понимать их — значит понимать, как устроена основа вашей профессии.
Вы знали об их существовании? Какой последний прочли? 👇
#Термины
🔥7🤓1