🏃♀ Сойти с дистанции — это не проигрыш
Я бежала трейл 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
🔞 PROVOKE: история, которая началась на улице
Сегодня на Хабре вышла моя статья — первая из серии про наш с Тарасом доклад «PROVOKE: системный анализ между соблазнением, манипуляцией и властью», который занял 3 место на Analyst Days 22.
Она не про слайды, не про структуру и не про то, как мы репетировали. Она про то, как мы придумали тему. Про прогулку по Москве после первой конференции, про разговор на улице, про ужин, про кафе на следующий день. Про то, как идея родилась не тогда, когда мы её искали, а когда просто шли и говорили.
Это история о том, как решение делать доклад вдвоём принимается за один вечер. И о том, почему лучшие решения приходят быстро — без долгих обсуждений, без взвешивания «за» и «против». Просто смотришь на человека и знаешь: да, это он. Это мы.
❓ Зачем пишу этот пост
Во‑первых, чтобы вы знали: Хабр читают. И на нём стоит публиковаться. Если у вас есть что сказать — говорите. Если у вас есть идея — записывайте. Если вы сомневаетесь — попробуйте. Это не первая моя статья на Хабре, но после долгой паузы и я планирую продолжать.
Во‑вторых, анонсирую продолжение. В следующих частях я напишу:
— как мы готовили доклад за 1500 км друг от друга
— с какими сложностями столкнулись, выступая вдвоём
— как мы спорили о каждом слайде и что из этого вышло
Подписывайтесь на мой блог на Хабре, чтобы не пропустить.
В‑третьих, вопрос к вам: читаете ли вы Хабр? Пишете ли сами? Или считаете, что эта площадка уже не та, что была раньше? 👇Мне правда интересно.
Ссылка на статью
Ссылка на доклад
Ссылка на первую статью на Хабре
#Байки
Сегодня на Хабре вышла моя статья — первая из серии про наш с Тарасом доклад «PROVOKE: системный анализ между соблазнением, манипуляцией и властью», который занял 3 место на Analyst Days 22.
Она не про слайды, не про структуру и не про то, как мы репетировали. Она про то, как мы придумали тему. Про прогулку по Москве после первой конференции, про разговор на улице, про ужин, про кафе на следующий день. Про то, как идея родилась не тогда, когда мы её искали, а когда просто шли и говорили.
Это история о том, как решение делать доклад вдвоём принимается за один вечер. И о том, почему лучшие решения приходят быстро — без долгих обсуждений, без взвешивания «за» и «против». Просто смотришь на человека и знаешь: да, это он. Это мы.
❓ Зачем пишу этот пост
Во‑первых, чтобы вы знали: Хабр читают. И на нём стоит публиковаться. Если у вас есть что сказать — говорите. Если у вас есть идея — записывайте. Если вы сомневаетесь — попробуйте. Это не первая моя статья на Хабре, но после долгой паузы и я планирую продолжать.
Во‑вторых, анонсирую продолжение. В следующих частях я напишу:
— как мы готовили доклад за 1500 км друг от друга
— с какими сложностями столкнулись, выступая вдвоём
— как мы спорили о каждом слайде и что из этого вышло
Подписывайтесь на мой блог на Хабре, чтобы не пропустить.
В‑третьих, вопрос к вам: читаете ли вы Хабр? Пишете ли сами? Или считаете, что эта площадка уже не та, что была раньше? 👇
Ссылка на статью
Ссылка на доклад
Ссылка на первую статью на Хабре
#Байки
🔥10❤4🤓1
🇷🇺 Вход на сайты — только по-российски. Штрафы ввели, а закон действовал уже два года
Важное уточнение: Сам закон, обязывающий владельцев российских сайтов использовать для авторизации только отечественные системы, был подписан президентом ещё 31 июля 2023 года и вступил в силу в декабре того же года .
Однако до сих пор за его нарушение не было административной ответственности. Теперь — есть. 26 июня 2026 года президент подписал поправки в КоАП, которые вводят конкретные штрафы .
📜 Что изменилось и для кого
Закон 2023 года обязал владельцев российских интернет-ресурсов предоставлять пользователям вход только через:
➖ российский номер телефона
➖ портал «Госуслуг» (ЕСИА)
➖ единую биометрическую систему
➖ иную систему, владельцем которой является гражданин РФ или российское юрлицо
Теперь за использование только зарубежных сервисов для входа (например, Google или Apple ID) владельцам ресурсов грозят штрафы :
➖ для граждан (например, владельцев блогов): от 10 000 до 20 000 ₽
➖ для должностных лиц: от 30 000 до 50 000 ₽
➖ для юридических лиц: от 500 000 до 700 000 ₽
При повторном нарушении суммы увеличиваются в два раза.
🧠 Важные нюансы
Закон не имеет обратной силы. Уже зарегистрированных пользователей не обязывают менять иностранную почту на российскую .
Штрафы накладываются на владельца ресурса, а НЕ на рядового пользователя.
Сама по себе возможность входа по логину и паролю с адресом зарубежной почты не является нарушением, если ресурс проводит авторизацию самостоятельно, а не через иностранный сервис .
🎓 Моё резюме для ИТ-команд
Если ваш продукт работает с российскими пользователями, самое время проверить:
✅ Какие системы авторизации вы используете для новых пользователей.
✅ Если у вас есть единственный способ входа через Google, Apple ID или другой зарубежный SSO — это прямой путь к штрафу.
Технически задача решаема: подключите вход через «Госуслуги», СМС-код или российский OAuth. Но на это нужно время.
Уже перешли на российские системы авторизации или пока на паузе? 👇
#Карьера
Важное уточнение: Сам закон, обязывающий владельцев российских сайтов использовать для авторизации только отечественные системы, был подписан президентом ещё 31 июля 2023 года и вступил в силу в декабре того же года .
Однако до сих пор за его нарушение не было административной ответственности. Теперь — есть. 26 июня 2026 года президент подписал поправки в КоАП, которые вводят конкретные штрафы .
📜 Что изменилось и для кого
Закон 2023 года обязал владельцев российских интернет-ресурсов предоставлять пользователям вход только через:
➖ российский номер телефона
➖ портал «Госуслуг» (ЕСИА)
➖ единую биометрическую систему
➖ иную систему, владельцем которой является гражданин РФ или российское юрлицо
Теперь за использование только зарубежных сервисов для входа (например, Google или Apple ID) владельцам ресурсов грозят штрафы :
➖ для граждан (например, владельцев блогов): от 10 000 до 20 000 ₽
➖ для должностных лиц: от 30 000 до 50 000 ₽
➖ для юридических лиц: от 500 000 до 700 000 ₽
При повторном нарушении суммы увеличиваются в два раза.
🧠 Важные нюансы
Закон не имеет обратной силы. Уже зарегистрированных пользователей не обязывают менять иностранную почту на российскую .
Штрафы накладываются на владельца ресурса, а НЕ на рядового пользователя.
Сама по себе возможность входа по логину и паролю с адресом зарубежной почты не является нарушением, если ресурс проводит авторизацию самостоятельно, а не через иностранный сервис .
🎓 Моё резюме для ИТ-команд
Если ваш продукт работает с российскими пользователями, самое время проверить:
✅ Какие системы авторизации вы используете для новых пользователей.
✅ Если у вас есть единственный способ входа через Google, Apple ID или другой зарубежный SSO — это прямой путь к штрафу.
Технически задача решаема: подключите вход через «Госуслуги», СМС-код или российский OAuth. Но на это нужно время.
Уже перешли на российские системы авторизации или пока на паузе? 👇
#Карьера
❤🔥2🔥2❤1👻1
Ⓜ️ Мандраж: слово, которое живёт в речи, но прячется от словарей
Есть слова, которые звучат так, будто их придумали вчера. А есть те, что живут десятилетиями, переходят из уст в уста и остаются с нами. Мандраж — как раз из таких.
Я люблю это слово. Оно точное, хлёсткое и сразу передаёт состояние: когда коленки трясутся, в груди холодок, а в голове одна мысль: «А вдруг?». Но откуда оно взялось?
Честно говоря, я не знала. И решила разобраться.
🕵️♂️ Что говорят источники
Точного ответа нет. Языковеды признают: происхождение многих жаргонных слов остаётся туманным. И «мандраж» — один из таких случаев .
1️⃣ Из бильярда и цирка
В романе Льва Славина «Наследник» (1930 год) слово уже используют бильярдисты. Там описывается «та крайняя растерянность сил, которая называется у бильярдистов мандражем».
Актёр Юрий Никулин вспоминал, что слово жило и в цирковой среде: «Как говорят в цирке, нас бил мандраж. Откуда пошло это слово — мандраж, не знаю. Означает оно страх, волнение».
2️⃣ Из воровского жаргона
В словарях арго слово фиксируется в двух значениях: «испуг» и «страх разоблачения, задержания» . То есть это был сленг людей, которые постоянно жили в опасности. Оттуда слово могло уйти в широкую речь.
3️⃣ Связь с диалектами
Автор «Словаря московского арго» В. С. Елистратов приводит несколько диалектных слов, предположительно связанных с «мандражем»: «мандара» — «земля, берег», «мандровать» — «странствовать», «мандрыка» — «лепёшка» . Но прямое родство не доказано.
4️⃣ Пикантная и сомнительная
Некоторые источники допускают, что «мандраж» — это замаскированное нецензурное слово, которое потеряло грубость . Авторы указывают, что «внешний псевдофранцузский вид слова „мандраж“ — дань стремлению к эвфемизации неприличного слова» . Но эта гипотеза не подтверждена.
🎭 Моя любимая догадка (до того, как я залезла в словари)
Честно говоря, я всегда была уверена, что «мандраж» — заимствование из французского.
Ну правда, звучит же: «мандраж» — как будто от французского mandrage или mandragore. Тем более во французском есть слово mandragore — так называется растение мандрагора . А в средневековой английской лексике встречается слово mandrage — как раз в значении «мандрагора» .
И я думала: ну вот, скорее всего, пришло из французского через какую-то диалектную цепочку.
Но нет. Как пишут лингвисты, «происхождение многих жаргонных слов является затемнённым» . Никаких следов французского заимствования в этимологических словарях нет. «Псевдофранцузский вид» — это лишь внешняя оболочка, а не реальное происхождение.
Так что моя догадка не подтвердилась. Но она была красивой.
📖 Есть ли оно в словарях?
Да, но с оговоркой.
Ефремова включает «мандраж» с пометкой «разговорное»: «состояние страха, неуверенности в себе, нервозности».
Викисловарь даёт ту же трактовку и приводит пример из литературы.
Словарь арго фиксирует слово с вариантами: «испуг, ужас; волнение, озабоченность» .
Но вот что важно: «мандраж» отсутствует в академических словарях русского языка. Его нет в словаре Ушакова. Его нет в Большом академическом словаре. Это слово живёт в разговорной речи, жаргонах и спортивной среде, но не получило статуса «литературного».
🎭 Пример классического жаргонизма
«Мандраж» — идеальный пример того, как жаргонное слово приживается, но остаётся на периферии.
Оно есть в разговорной речи. Его используют в спорте, в цирке, в бильярдных, в ИТ-командах перед релизом. Оно точное и понятное. Но в официальную литературную норму не входит.
И это нормально. Жаргонизмы — не «плохие» слова. Они обогащают язык, делают его живым.
🎓 Моё резюме
История «мандража» — как любой уважающий себя жаргонизм: недоказуемая, запутанная и полная догадок. Моя гипотеза о французском происхождении не подтвердилась, но я даже рада — так история интереснее.
Слово живёт, потому что оно точное и человечное. Оно называет то, что мы все чувствовали перед важным событием.
Вы используете слово «мандраж»? Или у вас есть свой любимый синоним для предрелизного состояния? 👇
#Термины
Есть слова, которые звучат так, будто их придумали вчера. А есть те, что живут десятилетиями, переходят из уст в уста и остаются с нами. Мандраж — как раз из таких.
Я люблю это слово. Оно точное, хлёсткое и сразу передаёт состояние: когда коленки трясутся, в груди холодок, а в голове одна мысль: «А вдруг?». Но откуда оно взялось?
Честно говоря, я не знала. И решила разобраться.
🕵️♂️ Что говорят источники
Точного ответа нет. Языковеды признают: происхождение многих жаргонных слов остаётся туманным. И «мандраж» — один из таких случаев .
1️⃣ Из бильярда и цирка
В романе Льва Славина «Наследник» (1930 год) слово уже используют бильярдисты. Там описывается «та крайняя растерянность сил, которая называется у бильярдистов мандражем».
Актёр Юрий Никулин вспоминал, что слово жило и в цирковой среде: «Как говорят в цирке, нас бил мандраж. Откуда пошло это слово — мандраж, не знаю. Означает оно страх, волнение».
2️⃣ Из воровского жаргона
В словарях арго слово фиксируется в двух значениях: «испуг» и «страх разоблачения, задержания» . То есть это был сленг людей, которые постоянно жили в опасности. Оттуда слово могло уйти в широкую речь.
3️⃣ Связь с диалектами
Автор «Словаря московского арго» В. С. Елистратов приводит несколько диалектных слов, предположительно связанных с «мандражем»: «мандара» — «земля, берег», «мандровать» — «странствовать», «мандрыка» — «лепёшка» . Но прямое родство не доказано.
4️⃣ Пикантная и сомнительная
Некоторые источники допускают, что «мандраж» — это замаскированное нецензурное слово, которое потеряло грубость . Авторы указывают, что «внешний псевдофранцузский вид слова „мандраж“ — дань стремлению к эвфемизации неприличного слова» . Но эта гипотеза не подтверждена.
🎭 Моя любимая догадка (до того, как я залезла в словари)
Честно говоря, я всегда была уверена, что «мандраж» — заимствование из французского.
Ну правда, звучит же: «мандраж» — как будто от французского mandrage или mandragore. Тем более во французском есть слово mandragore — так называется растение мандрагора . А в средневековой английской лексике встречается слово mandrage — как раз в значении «мандрагора» .
И я думала: ну вот, скорее всего, пришло из французского через какую-то диалектную цепочку.
Но нет. Как пишут лингвисты, «происхождение многих жаргонных слов является затемнённым» . Никаких следов французского заимствования в этимологических словарях нет. «Псевдофранцузский вид» — это лишь внешняя оболочка, а не реальное происхождение.
Так что моя догадка не подтвердилась. Но она была красивой.
📖 Есть ли оно в словарях?
Да, но с оговоркой.
Ефремова включает «мандраж» с пометкой «разговорное»: «состояние страха, неуверенности в себе, нервозности».
Викисловарь даёт ту же трактовку и приводит пример из литературы.
Словарь арго фиксирует слово с вариантами: «испуг, ужас; волнение, озабоченность» .
Но вот что важно: «мандраж» отсутствует в академических словарях русского языка. Его нет в словаре Ушакова. Его нет в Большом академическом словаре. Это слово живёт в разговорной речи, жаргонах и спортивной среде, но не получило статуса «литературного».
🎭 Пример классического жаргонизма
«Мандраж» — идеальный пример того, как жаргонное слово приживается, но остаётся на периферии.
Оно есть в разговорной речи. Его используют в спорте, в цирке, в бильярдных, в ИТ-командах перед релизом. Оно точное и понятное. Но в официальную литературную норму не входит.
И это нормально. Жаргонизмы — не «плохие» слова. Они обогащают язык, делают его живым.
🎓 Моё резюме
История «мандража» — как любой уважающий себя жаргонизм: недоказуемая, запутанная и полная догадок. Моя гипотеза о французском происхождении не подтвердилась, но я даже рада — так история интереснее.
Слово живёт, потому что оно точное и человечное. Оно называет то, что мы все чувствовали перед важным событием.
Вы используете слово «мандраж»? Или у вас есть свой любимый синоним для предрелизного состояния? 👇
#Термины
😁4👍1
🔲 Законы Мерфи в ИТ: когда всё идёт не так (и это нормально)
«Если что-то может пойти не так, оно обязательно пойдёт не так» (Точный перевод: «Если есть какой-либо способ сделать это неправильно, он найдёт его»). Эту фразу знают все. Она стала символом человеческой ошибки, случайности и неидеальности любых систем.
В ИТ она работает особенно ярко, потому что здесь ошибка — не просто досадная мелочь, а потеря денег, времени, репутации.
🧐 Откуда взялся закон Мерфи
В 1949 году инженер Эдвард Мерфи участвовал в эксперименте по определению перегрузок. Датчики показали нулевые значения — техник установил все 16 датчиков неправильно, хотя, казалось бы, ошибиться можно было лишь в одном из двух вариантов крепления. Раздосадованный Мерфи произнес фразу, которую его коллеги сократили до «Если есть какой-либо способ сделать это неправильно, он найдёт его». Позже коллеги сократили её до известного нам «Если неприятность может произойти, она произойдёт».
В 1977 году писатель Артур Блох собрал и систематизировал эти законы в книгу, добавив множество следствий из жизни инженеров и программистов. С тех пор «законы Мерфи» стали культурным феноменом.
💻 Законы Мерфи для программистов и аналитиков
У программистов есть свой «свод правил». Вот самые узнаваемые:
✅ Любая работающая программа уже устарела.
✅ Любая программа обходится дороже и требует больше времени, чем казалось в начале.
✅ Если программа полезна, её обязательно переделают. Если бесполезна — тщательно документируют.
✅ В программе всегда есть ещё одна ошибка.
✅ Сложность программы растёт до тех пор, пока не превысит способности программиста, призванного её поддерживать.
Закон Брука (Фредерик Брукс, «Мифический человеко-месяц»): добавление людей в опаздывающий проект только сильнее его задерживает.
Правило 90–90 (Том Каргилл, Bell Labs, 1985): первые 90% кода отнимают 90% времени, оставшиеся 10% кода — ещё 90% времени.
Закон Хофштадтера (Дуглас Хофштадтер, книга «Гёдель, Эшер, Бах», 1979): любое дело всегда длится дольше, чем ожидается, даже если учесть сам этот закон.
🧩 Законы для системных аналитиков и архитекторов
У систем есть свои закономерности. В «Полном собрании законов Мерфи» есть несколько:
🔹 Любая рабочая сложная система когда-то была рабочей простой системой.
🔹 Система, созданная с нуля, скорее всего, не заработает. Начинать нужно с простой версии и наращивать сложность.
🔹 Все системы бесконечно сложны. Иллюзия простоты возникает, когда мы сосредотачиваемся на одном аспекте .
И фундаментальные постулаты:
✅ Все, что угодно, — система.
✅ Все, что угодно, — часть более крупной системы.
✅ Все системы бесконечно сложны. Иллюзия простоты возникает от того, что внимание сосредотачивается на одном или нескольких вариантах.
🎓 Моё резюме
Законы Мерфи — это не оправдание для фатализма. Это инструмент планирования.
Когда вы знаете, что программа устареет, а задача займёт больше времени — вы закладываете буфер. Когда вы знаете, что сложная система, созданная с нуля, не заработает — вы начинаете с простой версии и наращиваете сложность.
Как пишут эксперты по управлению проектами, закон Мерфи не настраивает на пессимистический лад, а напоминает о неизбежности сбоев и необходимости быть к ним готовым .
И если что-то пошло не так — вы хотя бы не удивляетесь.
А какие «законы подлости» чаще всего сбываются в вашей работе? 👇
#Байки #Термины
«Если что-то может пойти не так, оно обязательно пойдёт не так» (Точный перевод: «Если есть какой-либо способ сделать это неправильно, он найдёт его»). Эту фразу знают все. Она стала символом человеческой ошибки, случайности и неидеальности любых систем.
В ИТ она работает особенно ярко, потому что здесь ошибка — не просто досадная мелочь, а потеря денег, времени, репутации.
🧐 Откуда взялся закон Мерфи
В 1949 году инженер Эдвард Мерфи участвовал в эксперименте по определению перегрузок. Датчики показали нулевые значения — техник установил все 16 датчиков неправильно, хотя, казалось бы, ошибиться можно было лишь в одном из двух вариантов крепления. Раздосадованный Мерфи произнес фразу, которую его коллеги сократили до «Если есть какой-либо способ сделать это неправильно, он найдёт его». Позже коллеги сократили её до известного нам «Если неприятность может произойти, она произойдёт».
В 1977 году писатель Артур Блох собрал и систематизировал эти законы в книгу, добавив множество следствий из жизни инженеров и программистов. С тех пор «законы Мерфи» стали культурным феноменом.
💻 Законы Мерфи для программистов и аналитиков
У программистов есть свой «свод правил». Вот самые узнаваемые:
✅ Любая работающая программа уже устарела.
✅ Любая программа обходится дороже и требует больше времени, чем казалось в начале.
✅ Если программа полезна, её обязательно переделают. Если бесполезна — тщательно документируют.
✅ В программе всегда есть ещё одна ошибка.
✅ Сложность программы растёт до тех пор, пока не превысит способности программиста, призванного её поддерживать.
Закон Брука (Фредерик Брукс, «Мифический человеко-месяц»): добавление людей в опаздывающий проект только сильнее его задерживает.
Правило 90–90 (Том Каргилл, Bell Labs, 1985): первые 90% кода отнимают 90% времени, оставшиеся 10% кода — ещё 90% времени.
Закон Хофштадтера (Дуглас Хофштадтер, книга «Гёдель, Эшер, Бах», 1979): любое дело всегда длится дольше, чем ожидается, даже если учесть сам этот закон.
🧩 Законы для системных аналитиков и архитекторов
У систем есть свои закономерности. В «Полном собрании законов Мерфи» есть несколько:
🔹 Любая рабочая сложная система когда-то была рабочей простой системой.
🔹 Система, созданная с нуля, скорее всего, не заработает. Начинать нужно с простой версии и наращивать сложность.
🔹 Все системы бесконечно сложны. Иллюзия простоты возникает, когда мы сосредотачиваемся на одном аспекте .
И фундаментальные постулаты:
✅ Все, что угодно, — система.
✅ Все, что угодно, — часть более крупной системы.
✅ Все системы бесконечно сложны. Иллюзия простоты возникает от того, что внимание сосредотачивается на одном или нескольких вариантах.
🎓 Моё резюме
Законы Мерфи — это не оправдание для фатализма. Это инструмент планирования.
Когда вы знаете, что программа устареет, а задача займёт больше времени — вы закладываете буфер. Когда вы знаете, что сложная система, созданная с нуля, не заработает — вы начинаете с простой версии и наращиваете сложность.
Как пишут эксперты по управлению проектами, закон Мерфи не настраивает на пессимистический лад, а напоминает о неизбежности сбоев и необходимости быть к ним готовым .
И если что-то пошло не так — вы хотя бы не удивляетесь.
А какие «законы подлости» чаще всего сбываются в вашей работе? 👇
#Байки #Термины
🔥6🤓1
📉 M‑Shape: ваш страховой полис против AI или просто модный термин?
Все слышали про T‑shape — глубокую вертикаль в одной области и широкий кругозор по смежным. Этот формат долго был идеалом.
Но сегодня ИТ-рынок говорит: одного «Т» больше недостаточно. Почему? AI всё лучше справляется с узкими типовыми задачами. Он не заменит архитектора, но легко заменит «исполнителя», который умеет только крутить гайки в своей вертикали.
На сцену выходит M‑Shape (или Comb‑shape) — профиль с несколькими глубинами в разных карьерных треках, соединённых широкой базой. Звучит красиво. Давайте разберём, что это на самом деле.
🧠 Чем M отличается от жирного Т?
Важное уточнение: если бэкенд-разработчик знает ещё и DevOps — это не M, это просто очень прокачанный сеньор с широкой экосистемной экспертизой.
M‑Shape — это когда ваши вершины лежат в разных дисциплинах, которые редко пересекаются:
➖ Инженерия + Продажи (Pre-sale)
➖ Аналитика + Управление продуктом
➖ Разработка + Бизнес-стратегия
➖ Инфраструктура + Клиентский опыт
Вы не просто «добавили скилл». Вы научились думать на двух разных языках и переводить между ними.
🔍 Примеры M‑профилей из ИТ (и почему это работает)
🟡 Системный аналитик, который глубоко знает архитектуру, управление требованиями и продуктовую стратегию с метриками.
Он не ждёт, пока продакт напишет ТЗ. Он сам переводит бизнес-запрос в архитектурные ограничения и видит, что из этого выйдет по срокам.
🔴 Инженер данных, который разбирается в ETL-процессах, бизнес-аналитике и безопасности данных.
Он проектирует хранилище так, чтобы не закладывать костыли под будущие отчёты, и знает, какие данные нельзя светить в дашбордах.
🟢 Разработчик, который сочетает бэкенд и продуктовый дизайн (UX).
Он не пишет «технически правильный» код, он пишет код, который не бесит пользователя.
В чём здесь ценность? Такой человек не закрывает всё сам (это было бы безумием). Он ставит корректные задачи профильным спецам, спорит с ними на их языке и не даёт команде свернуть не туда.
📊 Кому это выгодно и как качать
По данным исследований, сотрудники с несколькими экспертизами быстрее растут и получают выше рынка. Но дело не только в деньгах.
Главная выгода для компании: на старте проекта или при кризисе M‑специалист заменяет двух-трёх узких игроков и видит риски на стыках, которые другие не замечают.
Главная выгода для вас: если одна экспертиза просядет (а такое бывает), вторая страхует вашу карьеру. Это ваш профессиональный страховой полис.
Как качать M‑профиль без выгорания:
1️⃣ Прокачайте первую глубину до уровня «кормит». Нельзя строить вторую вершину на слабом фундаменте.
2️⃣ Выберите вторую дисциплину из другой вселенной. Аналитик → в продуктовый менеджмент. Разработчик → в продажи или архитектуру. Маркетолог → в аналитику данных.
3️⃣ Находите пересечения в ежедневной работе. Не просто «изучайте теорию», а берите задачи, где эти две области сталкиваются. Только там рождается реальная глубина.
⚠️ Честный минус M‑Shape
Вы всегда будете чувствовать себя немного самозванцем. В каждой из вершин вы уступаете «чистому» профильному специалисту. И вам придётся это принять. M‑Shape — это не про «быть лучшим во всём». Это про быть самым полезным в нестандартной ситуации.
🎓 Моё резюме
M‑Shape — это не модный ярлык для сеньоров. Это новый способ думать о своей карьере. Мир становится сложнее, AI берёт рутину, и выигрывают те, кто умеет соединять несоединимое и говорить на нескольких профессиональных языках.
А вы уже чувствуете, что одной глубокой экспертизы становится мало? Какие вторые «вершины» видите для себя? Или считаете, что M‑Shape — это перебор и глубокий Т всё ещё рулит?
👇 Давайте поспорим в комментариях.
#Карьера
Все слышали про T‑shape — глубокую вертикаль в одной области и широкий кругозор по смежным. Этот формат долго был идеалом.
Но сегодня ИТ-рынок говорит: одного «Т» больше недостаточно. Почему? AI всё лучше справляется с узкими типовыми задачами. Он не заменит архитектора, но легко заменит «исполнителя», который умеет только крутить гайки в своей вертикали.
На сцену выходит M‑Shape (или Comb‑shape) — профиль с несколькими глубинами в разных карьерных треках, соединённых широкой базой. Звучит красиво. Давайте разберём, что это на самом деле.
🧠 Чем M отличается от жирного Т?
Важное уточнение: если бэкенд-разработчик знает ещё и DevOps — это не M, это просто очень прокачанный сеньор с широкой экосистемной экспертизой.
M‑Shape — это когда ваши вершины лежат в разных дисциплинах, которые редко пересекаются:
➖ Инженерия + Продажи (Pre-sale)
➖ Аналитика + Управление продуктом
➖ Разработка + Бизнес-стратегия
➖ Инфраструктура + Клиентский опыт
Вы не просто «добавили скилл». Вы научились думать на двух разных языках и переводить между ними.
🔍 Примеры M‑профилей из ИТ (и почему это работает)
🟡 Системный аналитик, который глубоко знает архитектуру, управление требованиями и продуктовую стратегию с метриками.
Он не ждёт, пока продакт напишет ТЗ. Он сам переводит бизнес-запрос в архитектурные ограничения и видит, что из этого выйдет по срокам.
🔴 Инженер данных, который разбирается в ETL-процессах, бизнес-аналитике и безопасности данных.
Он проектирует хранилище так, чтобы не закладывать костыли под будущие отчёты, и знает, какие данные нельзя светить в дашбордах.
🟢 Разработчик, который сочетает бэкенд и продуктовый дизайн (UX).
Он не пишет «технически правильный» код, он пишет код, который не бесит пользователя.
В чём здесь ценность? Такой человек не закрывает всё сам (это было бы безумием). Он ставит корректные задачи профильным спецам, спорит с ними на их языке и не даёт команде свернуть не туда.
📊 Кому это выгодно и как качать
По данным исследований, сотрудники с несколькими экспертизами быстрее растут и получают выше рынка. Но дело не только в деньгах.
Главная выгода для компании: на старте проекта или при кризисе M‑специалист заменяет двух-трёх узких игроков и видит риски на стыках, которые другие не замечают.
Главная выгода для вас: если одна экспертиза просядет (а такое бывает), вторая страхует вашу карьеру. Это ваш профессиональный страховой полис.
Как качать M‑профиль без выгорания:
1️⃣ Прокачайте первую глубину до уровня «кормит». Нельзя строить вторую вершину на слабом фундаменте.
2️⃣ Выберите вторую дисциплину из другой вселенной. Аналитик → в продуктовый менеджмент. Разработчик → в продажи или архитектуру. Маркетолог → в аналитику данных.
3️⃣ Находите пересечения в ежедневной работе. Не просто «изучайте теорию», а берите задачи, где эти две области сталкиваются. Только там рождается реальная глубина.
⚠️ Честный минус M‑Shape
Вы всегда будете чувствовать себя немного самозванцем. В каждой из вершин вы уступаете «чистому» профильному специалисту. И вам придётся это принять. M‑Shape — это не про «быть лучшим во всём». Это про быть самым полезным в нестандартной ситуации.
🎓 Моё резюме
M‑Shape — это не модный ярлык для сеньоров. Это новый способ думать о своей карьере. Мир становится сложнее, AI берёт рутину, и выигрывают те, кто умеет соединять несоединимое и говорить на нескольких профессиональных языках.
А вы уже чувствуете, что одной глубокой экспертизы становится мало? Какие вторые «вершины» видите для себя? Или считаете, что M‑Shape — это перебор и глубокий Т всё ещё рулит?
👇 Давайте поспорим в комментариях.
#Карьера
✍3🔥3😁1🥴1
Forwarded from Analyst Days Channel
Два аналитика выходят на сцену: один — прагматик, открыто признающий, что использует триггеры, полуправду и «иллюзию выбора», чтобы протащить архитектуру через сопротивление; второй — оппонент, который каждый день противостоит таким приёмам и знает их механику изнутри. На Analyst Days 22 Татьяна Маркина и Тарас Шевченко разобрали те травмы, о которых в профессии принято молчать.
В докладе:
✅ Техника влияния, которую вы уже используете (и почему не стоит делать вид, что это не так).
✅ Тело и голос как API влияния: почему одинаковая фраза в другом исполнении читается как «статус» или как «попытка имитировать статус».
✅ Коммуникационный патч vs выживание: когда «маленькая манипуляция» превращается в условие работы команды.
Это не лекция с «готовыми ответами». Это приглашение взглянуть в лицо профессиональным дилеммам и осознанно сделать свой выбор. Тот самый, который вы уже делаете на каждом митинге.
Смотреть видео: https://vkvideo.ru/video-137540756_456240178
В докладе:
✅ Техника влияния, которую вы уже используете (и почему не стоит делать вид, что это не так).
✅ Тело и голос как API влияния: почему одинаковая фраза в другом исполнении читается как «статус» или как «попытка имитировать статус».
✅ Коммуникационный патч vs выживание: когда «маленькая манипуляция» превращается в условие работы команды.
Это не лекция с «готовыми ответами». Это приглашение взглянуть в лицо профессиональным дилеммам и осознанно сделать свой выбор. Тот самый, который вы уже делаете на каждом митинге.
Смотреть видео: https://vkvideo.ru/video-137540756_456240178
VK Видео
Analyst Days 22 — PROvoke: Системный анализ между соблазнением, манипуляцией и властью (Парный перформанс-диалог)
Татьяна Маркина, Тарас Шевченко Это не доклад. Это публичный допрос профессии. Два аналитика выходят на сцену. Один — прагматик, который честно признаётся: он использует триггеры, полуправду и «иллюзию выбора», чтобы протащить архитектуру через сопротивление.…
🔥6❤🔥4🤓1
🔞 Когда анализ встречается с безопасностью: мой день на ProIT Fest VIII
На Летнем ProIT Fest VIII, который прошёл 11 июля, я побывала в секциях, где мои два любимых предмета в ИТМО сошлись в одном. Организаторы подготовили целый поток Hard Tech, который раскрывает доменные области IT: FinTech, Ecom, TravelTech и другие. Необычный был не только формат с маленькими залами в пространстве СЕНО, но и мерч: презерватив и смазка...
🎤 Что я послушала
Егор Марюшка @egormaryushko, создатель платформы знаний умений и навыков СА, рассказал о том как начать вайбкодить и какие ошибки можно избежать. Уже не раз начинала это и всё бросала, но после рассказа — приступила повторно уже без ошибок.
Наталья Козлова, начальник отдела системного анализа в Код безопасности и спикер множества конференций, презентовала моделирование угроз в формате игры Elevation of Privileges, где на примере S.T.R.I.D.E. (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) мы искали уязвимости в реальной системdoctorponos
Александр Князев, руководитель развития ИИ агентов "AMA" провёл мастер-класс по взлому ИИ агентов, было увлекательно на практике поломать сайт через чат-бот.
📝 Что можно было найти ещё
Интерактив и живые дискуссии. Организаторы сделали ставку на диалог, а не на обычный доклад-монолог. Секция Fight Club — место споров и оппозиционных мнений. Конечно же спорили "до хрипоты", перебивали спикеров, задавали неудобные вопросы.
Честные истории о фейлах. Особенно зашёл формат Oops, секция, посвящённая эпическим фейлам различных масштабов. Специалисты из sec, devops, ops, sre, mlops рассказывали о том, как всё у них ломалось. Я считаю, что учиться на ошибках ценнее любых учебников.
Нетворкинг. Поговорила с коллегами из других компаний. Оказалось, у всех одни и те же боли: как объяснить заказчику, что безопасность — это не "лишняя работа", а часть продукта.
🎓 Моё резюме
Быть слушателем без дополнительных обязанностей — отличный отдых. Ходить на спикеров, а не на конференции.
А вы были на ProIT Fest? Какая секция зашла больше всего? 👇
На Летнем ProIT Fest VIII, который прошёл 11 июля, я побывала в секциях, где мои два любимых предмета в ИТМО сошлись в одном. Организаторы подготовили целый поток Hard Tech, который раскрывает доменные области IT: FinTech, Ecom, TravelTech и другие. Необычный был не только формат с маленькими залами в пространстве СЕНО, но и мерч: презерватив и смазка...
🎤 Что я послушала
Егор Марюшка @egormaryushko, создатель платформы знаний умений и навыков СА, рассказал о том как начать вайбкодить и какие ошибки можно избежать. Уже не раз начинала это и всё бросала, но после рассказа — приступила повторно уже без ошибок.
Наталья Козлова, начальник отдела системного анализа в Код безопасности и спикер множества конференций, презентовала моделирование угроз в формате игры Elevation of Privileges, где на примере S.T.R.I.D.E. (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) мы искали уязвимости в реальной системdoctorponos
Александр Князев, руководитель развития ИИ агентов "AMA" провёл мастер-класс по взлому ИИ агентов, было увлекательно на практике поломать сайт через чат-бот.
📝 Что можно было найти ещё
Интерактив и живые дискуссии. Организаторы сделали ставку на диалог, а не на обычный доклад-монолог. Секция Fight Club — место споров и оппозиционных мнений. Конечно же спорили "до хрипоты", перебивали спикеров, задавали неудобные вопросы.
Честные истории о фейлах. Особенно зашёл формат Oops, секция, посвящённая эпическим фейлам различных масштабов. Специалисты из sec, devops, ops, sre, mlops рассказывали о том, как всё у них ломалось. Я считаю, что учиться на ошибках ценнее любых учебников.
Нетворкинг. Поговорила с коллегами из других компаний. Оказалось, у всех одни и те же боли: как объяснить заказчику, что безопасность — это не "лишняя работа", а часть продукта.
🎓 Моё резюме
Быть слушателем без дополнительных обязанностей — отличный отдых. Ходить на спикеров, а не на конференции.
А вы были на ProIT Fest? Какая секция зашла больше всего? 👇
❤3🔥2👍1😁1
🤓 Про ИИ, Линуса и страх, который мы все чувствуем
Когда я читаю про ИИ в разработке, я задумываюсь о роли человека в разработке и сам собой всплывает вопрос: «А не заменит ли ИИ все роли в разработке через пару лет?»
И тут появляется Линус Торвальдс, как будто отвечая на мои вопросы. Тот самый, который создал ядро Linux, на котором работает почти весь мир. Он, тот кто в 2024 говорил, что это всё хайп, теперь уже признаёт эту реальность, под которую надо адаптироваться.
🧑💻 Что произошло
Недавно разработчики Linux начали использовать ИИ-инструмент для ревью кода Sashiko. Конечно было много споров. И тогда Торвальдс сказал то, что обычно говорит — жёстко и прямо: «Если вам не нравится, что мы используем ИИ, сделайте форк и катитесь. Linux — не анти-ИИ-проект. Год назад это ещё было не очевидно, а сегодня — очевидно».
📈 Про цифры, которые меня поразили
Линус привёл статистику: за последние полгода количество изменений в ядре выросло на 20%. Сначала он думал, что это из-за нового релиза. А потом понял: причина в ИИ.
Люди входят в проект быстрее, пишут код быстрее, находят ошибки быстрее.
При этом Sashiko нашёл 53,6% ошибок, которые разработчики потом исправили.
📩 Что я об этом думаю
Мы же используем компьютеры, а не печатную машинку, а кто-то уже даже только голосовой набор без клавиатуры. Студенты приходят с ChatGPT. Коллеги из PT пробуют LLM. Я сама также использую "умные" чатики.
Как я вижу ситуацию — это не заменяет мышление, только ускоряет процессы, повышает количество задач, которые можно успеть.
Компилятор в своё время не заменил программиста. И ИИ не заменит. Тот, кто умеет пользоваться компилятором — пишет быстрее, а кто умеет пользоваться ИИ — ещё быстрее.
Как обычно есть нюансы. Вайб-кодинг, по словам того же Линуса, может быть опасен для серьёзных проектов. Если ты пишешь приложение на коленке — ок. Если ты строишь систему, которая будет жить 10 лет — ИИ не заменит понимания архитектуры.
Но для новичков это отличный способ войти. Для рутины — спасение. Для сложных размышлений — всё равно нужна голова.
🎓 Моё резюме
Согласна с человеком, который строил ядро Linux 35 лет, надо адаптироваться.
Страх устареть — нормален, но я считаю, что ИИ не заменит нас. Он точно заменит тех, кто отказывается его использовать.
А вы уже используешь ИИ в работе? Или он тебя пока пугает? Признавайся 👇
Когда я читаю про ИИ в разработке, я задумываюсь о роли человека в разработке и сам собой всплывает вопрос: «А не заменит ли ИИ все роли в разработке через пару лет?»
И тут появляется Линус Торвальдс, как будто отвечая на мои вопросы. Тот самый, который создал ядро Linux, на котором работает почти весь мир. Он, тот кто в 2024 говорил, что это всё хайп, теперь уже признаёт эту реальность, под которую надо адаптироваться.
🧑💻 Что произошло
Недавно разработчики Linux начали использовать ИИ-инструмент для ревью кода Sashiko. Конечно было много споров. И тогда Торвальдс сказал то, что обычно говорит — жёстко и прямо: «Если вам не нравится, что мы используем ИИ, сделайте форк и катитесь. Linux — не анти-ИИ-проект. Год назад это ещё было не очевидно, а сегодня — очевидно».
📈 Про цифры, которые меня поразили
Линус привёл статистику: за последние полгода количество изменений в ядре выросло на 20%. Сначала он думал, что это из-за нового релиза. А потом понял: причина в ИИ.
Люди входят в проект быстрее, пишут код быстрее, находят ошибки быстрее.
При этом Sashiko нашёл 53,6% ошибок, которые разработчики потом исправили.
📩 Что я об этом думаю
Мы же используем компьютеры, а не печатную машинку, а кто-то уже даже только голосовой набор без клавиатуры. Студенты приходят с ChatGPT. Коллеги из PT пробуют LLM. Я сама также использую "умные" чатики.
Как я вижу ситуацию — это не заменяет мышление, только ускоряет процессы, повышает количество задач, которые можно успеть.
Компилятор в своё время не заменил программиста. И ИИ не заменит. Тот, кто умеет пользоваться компилятором — пишет быстрее, а кто умеет пользоваться ИИ — ещё быстрее.
Как обычно есть нюансы. Вайб-кодинг, по словам того же Линуса, может быть опасен для серьёзных проектов. Если ты пишешь приложение на коленке — ок. Если ты строишь систему, которая будет жить 10 лет — ИИ не заменит понимания архитектуры.
Но для новичков это отличный способ войти. Для рутины — спасение. Для сложных размышлений — всё равно нужна голова.
🎓 Моё резюме
Согласна с человеком, который строил ядро Linux 35 лет, надо адаптироваться.
Страх устареть — нормален, но я считаю, что ИИ не заменит нас. Он точно заменит тех, кто отказывается его использовать.
А вы уже используешь ИИ в работе? Или он тебя пока пугает? Признавайся 👇
👍6🤓3