Тема — профессиональная репутация и усиление влияния внутри компании и во внешних комьюнити через развитие профессиональной репутации.
Не в смысле «как начать вести канал» или «как стать заметнее в соцсетях». На уровне senior и C-level репутация — это рабочий управленческий инструмент. От неё зависит, чью позицию слышат, кому доверяют сложные задачи, кого зовут в важные проекты, партнёрства и профессиональные дискуссии.
В «Диапазоне» репутацию рассматривали как систему: карьерная стратегия, экспертность, стейкхолдер-менеджмент, публичность, профессиональное сообщество и умение говорить о своей работе так, чтобы это создавало влияние.
В программе выступили HR-директор Яндекса Дарья Золотухина, предприниматель Денис Кутергин, инвестор и сооснователь Okko Екатерина Лапшина, Нина Зверева и другие практики.
Сам факт такого проекта — интересный сигнал от Яндекса: компания инвестирует не только в развитие навыков сотрудников, но и в формирование сильного экспертного комьюнити — внутри компании и на рынке.
Часть материалов мастерской открывают для внешней аудитории.
«Я как продукт и я как герой: как системно строить репутацию эксперта».
Обсудят продуктовый подход к собственной карьере, профессиональное позиционирование и сторителлинг, который помогает доносить экспертизу без «самопиара ради самопиара».
После регистрации можно получить промпт для самостоятельного аудита себя как профессионального продукта.
Please open Telegram to view this post
VIEW IN TELEGRAM
👎8❤6🔥5👍4
This media is not supported in your browser
VIEW IN TELEGRAM
Тревожит FOMO — страх что-то упустить?
Чувствуете, что упускаете ИИ-волну и не знаете, что с этим делать? Вокруг ИИ-агенты, вайбкодинг... А у вас бизнес, рутина и ... По-честному... Даже некогда сесть и разобраться...
В Битрикс24 есть все для того, чтобы начать использовать новые фишки ИИ в числе первых. Это ИИ-сервис для бизнеса, где нейросети встроены прямо в рабочие процессы.
Пока все платят в долларах за подписки и жонглируют десятками приложений — уже тысячи компаний в России автоматизируют бизнес с Битрикс24.
Что внутри?
• База для любого бизнеса: CRM, задачи, мессенджер
• Нейросети и агенты: помогают с задачами, ищут информацию, пишут тексты и т.д.
• Вайбкодинг для всех: с подсказками и в привычном интерфейсе
Подключите ИИ к своему бизнесу уже сегодня.
Чувствуете, что упускаете ИИ-волну и не знаете, что с этим делать? Вокруг ИИ-агенты, вайбкодинг... А у вас бизнес, рутина и ... По-честному... Даже некогда сесть и разобраться...
В Битрикс24 есть все для того, чтобы начать использовать новые фишки ИИ в числе первых. Это ИИ-сервис для бизнеса, где нейросети встроены прямо в рабочие процессы.
Пока все платят в долларах за подписки и жонглируют десятками приложений — уже тысячи компаний в России автоматизируют бизнес с Битрикс24.
Что внутри?
• База для любого бизнеса: CRM, задачи, мессенджер
• Нейросети и агенты: помогают с задачами, ищут информацию, пишут тексты и т.д.
• Вайбкодинг для всех: с подсказками и в привычном интерфейсе
Подключите ИИ к своему бизнесу уже сегодня.
👎9❤4👍3🔥1
Как строятся современные базы знаний
Команда Cerebras рассказала, как они построили свою автоматически обновляемую внутреннюю базу знаний, которую одновременно используют и люди, и агенты. Вот интересное:
👉База знаний строится поверх всех источников, в которых уже накапливается ценная информация – Slack, кодовая база, документы, Jira, Confluence и куча чего еще.
👉Самые полезные сведения лежат в Slack, так как в глубине тредов принимается куча важных решений. Вытаскивать ее оттуда тоже очень сложно, потому что мусорных обсуждений тоже много. В итоге сработала комбинация из полнотекстового поиска, эмбеддингов, механизма устаревания фактов, реранкинга более редких токенов.
👉Для поиска по коду используется опенсорсный фреймворк CocoIndex, который умеет пересчитывать индекс для каждого коммита инкрементально.
👉В базе знаний есть механизм плагинов, чтобы каждая команда могла добавить свой кастомный источник.
👉Помимо непосредсвенно поиска информации, сделали отдельный тул
👉Информация агрегируется по проектам, чтобы сделать результаты поиска более релевантными.
Команда Cerebras рассказала, как они построили свою автоматически обновляемую внутреннюю базу знаний, которую одновременно используют и люди, и агенты. Вот интересное:
👉База знаний строится поверх всех источников, в которых уже накапливается ценная информация – Slack, кодовая база, документы, Jira, Confluence и куча чего еще.
👉Самые полезные сведения лежат в Slack, так как в глубине тредов принимается куча важных решений. Вытаскивать ее оттуда тоже очень сложно, потому что мусорных обсуждений тоже много. В итоге сработала комбинация из полнотекстового поиска, эмбеддингов, механизма устаревания фактов, реранкинга более редких токенов.
👉Для поиска по коду используется опенсорсный фреймворк CocoIndex, который умеет пересчитывать индекс для каждого коммита инкрементально.
👉В базе знаний есть механизм плагинов, чтобы каждая команда могла добавить свой кастомный источник.
👉Помимо непосредсвенно поиска информации, сделали отдельный тул
who_knows, который сразу выдает имена людей, релевантных поисковому запросу.👉Информация агрегируется по проектам, чтобы сделать результаты поиска более релевантными.
👍26🔥7❤4
AI внушает ложную уверенность
Можете добавлять себе еще одно исследование в копилку когнитивных искажений, которые появляются при взаимодействии людей из AI.
В этот раз сделали следующее – выдали группам испытуемых доступ к довольно слабенькой гугловой модели, и задавали им вопросы из категорий, в которых модели часто ошибаются – например, про визуальные детали из фильмов.
Наблюдения вот такие:
👉Доступ к AI снижает вероятность ответа на вопрос "я не знаю" с 44% до 3%.
👉Точность ответов при этом упала с 27% до 9%, а вот уверенность в ответе, наоборот, выросла в 2.5 раза, с 30% до 76%. При этом часть участников были готовы ответить правильно до консультации с AI, а потом поменяли свой ответ.
👉Добавление денежной мотивации почти не помогло, готовность признать незнание поднялась только до 8%, а точность до 16%.
Можете добавлять себе еще одно исследование в копилку когнитивных искажений, которые появляются при взаимодействии людей из AI.
В этот раз сделали следующее – выдали группам испытуемых доступ к довольно слабенькой гугловой модели, и задавали им вопросы из категорий, в которых модели часто ошибаются – например, про визуальные детали из фильмов.
Наблюдения вот такие:
👉Доступ к AI снижает вероятность ответа на вопрос "я не знаю" с 44% до 3%.
👉Точность ответов при этом упала с 27% до 9%, а вот уверенность в ответе, наоборот, выросла в 2.5 раза, с 30% до 76%. При этом часть участников были готовы ответить правильно до консультации с AI, а потом поменяли свой ответ.
👉Добавление денежной мотивации почти не помогло, готовность признать незнание поднялась только до 8%, а точность до 16%.
TNW
AI advice made people three times less accurate but twice as confident, researchers found
TL;DRResearchers found AI advice suppressed judgment suspension from 44% to 3%, accuracy from 27% to 9%, while confidence rose from 30% to 76%. People trusted wrong AI answers. Researchers from three French and Italian universities found th
👍21❤3
Про comprehension debt
На прошлой неделе в посте про оргдизайн я вспоминал замечательную книгу Team Topologies. Одна из мыслей, которые мне очень запали в душу – это то, что зону ответственности команды надо проектировать с учетом ее ограниченной когнитивной емкости, а не просто закидывать в нее ответственность за все рядом лежащие компоненты.
Когнитивная емкость – это способность команды переварить когнитивную нагрузку. К такой нагрузке относится все, что команда должна понимать, чтобы самостоятельно безопасно обслуживать и менять свой продукт: бизнесовые правила, доменный язык, архитектура, устройство инфраструктуры и пайплайнов, интеграции с другими сервисами, особенности пользователей.
Когнитивная нагрузка появляется от двух видов сложности:
👉Intrinsic, неотъемлимая сложность предметной области. Как код ни упрощай, биллинг всегда будет сложным.
👉Extraneous, случайная сложность. Плохо организованный ручной пайплайн деплоя, много разных форматов конфигурации, лишние слои абстракции.
Так вот, агентская разработка, при всем ее великолепии, очень сильно влияет на когнитивную нагрузку. Во-первых, очень просто резко вырастить случайную сложность. Агенты любят оверинжинирить, писать обработчики для тридцати эдж кейсов, и городить те самые слои абстракций. Если не выстраивать правильную инженерную дисциплину, то уже этого хватит, чтобы когнитивная емкость переполнилась.
Во-вторых, разработка фичей ускоряется, и у эффективных менеджеров появляется соблазн закинуть в зону ответственности каждой команды побольше всего, или, наоборот, оставить зону ответственности такой же, а количество голов, думающих над ней, сократить. И тогда даже без учета выросшей случайной сложности, даже неотъемлимая сложность перестает помещаться в головах.
Так мы и получаем comprehension debt – головы разработчиков уже перегружены, их емкости не хватает, чтобы вместить туда что-то новое, и знание о том, как работает продукт, постепенно ускользает. Спустя короткое время, команда уже не может безопасно менять свою систему – количество инцидентов растет, а способность их предсказать падает.
С таким долгом можно бороться инструментальными способами, упрощая для человека понимание того, как работает система – ну условно показывать простые диаграммы вместо полотен кода. Но важно помнить, что, как информацию не сжимай, количество концепций, которые мы в голове можем держать – ограничено. И лучшее, что вы, как менеджер, можете в такой ситуации сделать – это удерживать количество компонентов, за которые отвечает команда, в пределах ее когнитивной емкости.
Еще про comprehension debt хорошо пишет у себя в канале Владимир Балун. Он руководил разработкой системы трейсинга с трафиком 11GB/s в Яндексе, поэтому набил руку на сложных системах, и знает, о чем говорит. Поэтому можете почитать его пост, а заодно подписаться на его канал, где он рассказывает о своем опыте программирования, разработке сложных высоконагруженных систем и просто делится своими мыслями о разработке.
На прошлой неделе в посте про оргдизайн я вспоминал замечательную книгу Team Topologies. Одна из мыслей, которые мне очень запали в душу – это то, что зону ответственности команды надо проектировать с учетом ее ограниченной когнитивной емкости, а не просто закидывать в нее ответственность за все рядом лежащие компоненты.
Когнитивная емкость – это способность команды переварить когнитивную нагрузку. К такой нагрузке относится все, что команда должна понимать, чтобы самостоятельно безопасно обслуживать и менять свой продукт: бизнесовые правила, доменный язык, архитектура, устройство инфраструктуры и пайплайнов, интеграции с другими сервисами, особенности пользователей.
Когнитивная нагрузка появляется от двух видов сложности:
👉Intrinsic, неотъемлимая сложность предметной области. Как код ни упрощай, биллинг всегда будет сложным.
👉Extraneous, случайная сложность. Плохо организованный ручной пайплайн деплоя, много разных форматов конфигурации, лишние слои абстракции.
Так вот, агентская разработка, при всем ее великолепии, очень сильно влияет на когнитивную нагрузку. Во-первых, очень просто резко вырастить случайную сложность. Агенты любят оверинжинирить, писать обработчики для тридцати эдж кейсов, и городить те самые слои абстракций. Если не выстраивать правильную инженерную дисциплину, то уже этого хватит, чтобы когнитивная емкость переполнилась.
Во-вторых, разработка фичей ускоряется, и у эффективных менеджеров появляется соблазн закинуть в зону ответственности каждой команды побольше всего, или, наоборот, оставить зону ответственности такой же, а количество голов, думающих над ней, сократить. И тогда даже без учета выросшей случайной сложности, даже неотъемлимая сложность перестает помещаться в головах.
Так мы и получаем comprehension debt – головы разработчиков уже перегружены, их емкости не хватает, чтобы вместить туда что-то новое, и знание о том, как работает продукт, постепенно ускользает. Спустя короткое время, команда уже не может безопасно менять свою систему – количество инцидентов растет, а способность их предсказать падает.
С таким долгом можно бороться инструментальными способами, упрощая для человека понимание того, как работает система – ну условно показывать простые диаграммы вместо полотен кода. Но важно помнить, что, как информацию не сжимай, количество концепций, которые мы в голове можем держать – ограничено. И лучшее, что вы, как менеджер, можете в такой ситуации сделать – это удерживать количество компонентов, за которые отвечает команда, в пределах ее когнитивной емкости.
Еще про comprehension debt хорошо пишет у себя в канале Владимир Балун. Он руководил разработкой системы трейсинга с трафиком 11GB/s в Яндексе, поэтому набил руку на сложных системах, и знает, о чем говорит. Поэтому можете почитать его пост, а заодно подписаться на его канал, где он рассказывает о своем опыте программирования, разработке сложных высоконагруженных систем и просто делится своими мыслями о разработке.
Telegram
Владимир Балун
💭 Пожалуй, самый интересный побочный эффект AI в разработке, о котором пока говорят не так много, - это Comprehension Debt, или долг понимания.
Вы наверняка замечали, что писать код стало значительно быстрее. Раньше, чтобы реализовать новую функциональность…
Вы наверняка замечали, что писать код стало значительно быстрее. Раньше, чтобы реализовать новую функциональность…
👍21❤13👎1
Почему автономные фабрики софта не работают
Последние полгода из каждого угла говорят про то, что вот-вот агентская разработка эволюционирует до того момента, когда людей можно будет полностью убрать из этого процесса, заменив все полностью автономными фабриками. А если у вас это не получается, то skill issue. На самом деле все немного не так.
👉Модели становятся лучше только в вопросах выполнения одной конкретной задачи, но не в том, чтобы поддерживать кодовую базу в долгую. Поэтому спустя достаточно быстрое время такого развития, проект станет неподдерживаемым ни вами, ни моделью.
👉Так происходит из-за текущих механизмов reinforcement learning – определить правильное поведение и награду на горизонте атомарных задач легко, а вот на уровень выше уже очень сложно. За плохие архитектурные решения модели никак не наказываются.
Последние полгода из каждого угла говорят про то, что вот-вот агентская разработка эволюционирует до того момента, когда людей можно будет полностью убрать из этого процесса, заменив все полностью автономными фабриками. А если у вас это не получается, то skill issue. На самом деле все немного не так.
👉Модели становятся лучше только в вопросах выполнения одной конкретной задачи, но не в том, чтобы поддерживать кодовую базу в долгую. Поэтому спустя достаточно быстрое время такого развития, проект станет неподдерживаемым ни вами, ни моделью.
👉Так происходит из-за текущих механизмов reinforcement learning – определить правильное поведение и награду на горизонте атомарных задач легко, а вот на уровень выше уже очень сложно. За плохие архитектурные решения модели никак не наказываются.
GitHub
advanced-context-engineering-for-coding-agents/wsff.md at main · humanlayer/advanced-context-engineering-for-coding-agents
Contribute to humanlayer/advanced-context-engineering-for-coding-agents development by creating an account on GitHub.
👍21❤5👎2
Управленческие антипаттерны, характерные для России
👉Гиперцентрализация, когда все решает один человек. Иногда вырастает до культа личности основателя, который плох с двух сторон – если такой человек уходит, компания разваливается, а если остается – то компания начинает копировать все его недостатки.
👉Отсутствие стратегии и в целом короткий горизонт планирования.
👉Кумовство – при найме предпочтение может отдаваться личным отношениям, а не реальным компетенциям.
👉Недостаточная работа с людьми, из-за чего текучка получается довольно большой, а навыки и эффективность не особо растут.
👉Непрозрачная бухгалтерия. С одной стороны, это ведет к тому, что бизнес не получится продать, как не получится и найти желающих в него инвестировать. С другой – бюрократии в таких компанияз будет поменьше.
👉Рыночная конкуренция подменяется лоббированием, из-за чего игрвоое поле становится неравным. Побеждает в итоге не тот, кто работает эффективнее, а тот, у кого лучше доступ к госзаказу или политические связи.
👉Гиперцентрализация, когда все решает один человек. Иногда вырастает до культа личности основателя, который плох с двух сторон – если такой человек уходит, компания разваливается, а если остается – то компания начинает копировать все его недостатки.
👉Отсутствие стратегии и в целом короткий горизонт планирования.
👉Кумовство – при найме предпочтение может отдаваться личным отношениям, а не реальным компетенциям.
👉Недостаточная работа с людьми, из-за чего текучка получается довольно большой, а навыки и эффективность не особо растут.
👉Непрозрачная бухгалтерия. С одной стороны, это ведет к тому, что бизнес не получится продать, как не получится и найти желающих в него инвестировать. С другой – бюрократии в таких компанияз будет поменьше.
👉Рыночная конкуренция подменяется лоббированием, из-за чего игрвоое поле становится неравным. Побеждает в итоге не тот, кто работает эффективнее, а тот, у кого лучше доступ к госзаказу или политические связи.
Хабр
Управленческие антипаттерны, которые убивают компании в России
У каждой страны есть свои особенности управления. Например, в Японии или Германии всё вокруг уютных жёстких правил, в Корее надо тимбилдиться в сопли с руководителем в баре, а у нас надо что-то...
👍22👎13❤7
Что общего у рынка труда журналистов и программистов
Традиционная журналистика уже достаточно давно умерла. В 2008 году в результате финансового кризиса из прессы ушли рекламодатели, и кучу штатных журналистов уволили. Они пошли во фриланс – и обнаружили, что на пару десятков заказов в месяц отзывается десятки кандидатов в день. При этом университеты продолжали выпускать новых журналистов, профессия годы до этого была на хайпе.
Рынок работодателя сразу же создал несколько довольно знакомых нам явлений. Для начала, вокруг отбора кандидатов появилось много ритуальных бессмысленных действий. Это привело к тому, что получение заказа стало отдельным искусством, и работу стали получать не лучшие авторы, а те, кто лучше всего умел под эти требования адаптироваться. Ну и, конечно же, появились волчьи сообщества, которые учили журналистов получше продавать свои питчи и проходить гейткипинг.
Что происходило с журналистами дальше:
👉Мидлы вымерли. На рынке остались начинающие фрилансеры, работающие за копейки, и завездные опытные журналисты.
👉Выжившие ушли от гейткиперов. Самые сильные авторы перестали пытаться пробиться к редакторам в издания, и стали независимыми – открыли рассылки, сделали подкасты, сколотили собственный бренд. Гейткипер при этом, конечно, остался – но теперь это не редактор-человек, а алгоритм ленты в соцсетях.
👉Сместился дефицит. Раньше им было место в журнале, теперь – доверие читателя к конкретному имени.
Что из этого можно перенести на рынок программистов – вопрос хороший, и упирается он в то, конечен ли спрос на программистов, или нет (парадокс Джевонса и вот это все). Пока все показывает на то, что на самом деле спрос конечен – люди не начинают ставить себе больше приложений на телефон, а компании не то, чтобы успешно диверсифицировали свою продуктовую линейку и запускали кучу новых успешных продуктов.
Традиционная журналистика уже достаточно давно умерла. В 2008 году в результате финансового кризиса из прессы ушли рекламодатели, и кучу штатных журналистов уволили. Они пошли во фриланс – и обнаружили, что на пару десятков заказов в месяц отзывается десятки кандидатов в день. При этом университеты продолжали выпускать новых журналистов, профессия годы до этого была на хайпе.
Рынок работодателя сразу же создал несколько довольно знакомых нам явлений. Для начала, вокруг отбора кандидатов появилось много ритуальных бессмысленных действий. Это привело к тому, что получение заказа стало отдельным искусством, и работу стали получать не лучшие авторы, а те, кто лучше всего умел под эти требования адаптироваться. Ну и, конечно же, появились волчьи сообщества, которые учили журналистов получше продавать свои питчи и проходить гейткипинг.
Что происходило с журналистами дальше:
👉Мидлы вымерли. На рынке остались начинающие фрилансеры, работающие за копейки, и завездные опытные журналисты.
👉Выжившие ушли от гейткиперов. Самые сильные авторы перестали пытаться пробиться к редакторам в издания, и стали независимыми – открыли рассылки, сделали подкасты, сколотили собственный бренд. Гейткипер при этом, конечно, остался – но теперь это не редактор-человек, а алгоритм ленты в соцсетях.
👉Сместился дефицит. Раньше им было место в журнале, теперь – доверие читателя к конкретному имени.
Что из этого можно перенести на рынок программистов – вопрос хороший, и упирается он в то, конечен ли спрос на программистов, или нет (парадокс Джевонса и вот это все). Пока все показывает на то, что на самом деле спрос конечен – люди не начинают ставить себе больше приложений на телефон, а компании не то, чтобы успешно диверсифицировали свою продуктовую линейку и запускали кучу новых успешных продуктов.
Хабр
Кризис найма (как в IT) журналисты прошли ещё в 2013. Как у них получилось выйти?
К 2013 году американская журналистика пять лет как падала в яму. Кризис 2008-го обрушил рекламную модель прессы; газетные ньюсрумы США за следующее десятилетие потеряли больше половины сотрудников —...
1❤15👍6🔥1
Почему CTO сейчас стало особенно тяжело
Всю прошлую неделю в Твиттере обсуждали интересный тренд – многие CTO / VP of Engineering / Head of Development в стартапах и компаниях среднего размера сейчас жестко выгорают и увольняются, проработав буквально пару месяцев. Причины называют вот такие:
👉Роль, на которую их взяли, довольно расстрельная, с нереалистичными ожиданиями из-за AI
👉У компании нет никакой стратегии и видимого будущего с учетом изменений рынка, вызванных AI
👉В этой компании не получить так называемый AI-native опыт, который им точно в будущем для карьеры понадобится
👉Человек, на замену которого их наняли, уволился из-за тех же причин
👉Начать свой стартап сейчас в целом не очень сложно, деньгами в хороших инженерных лидов готовы кидать
👉СЕО словил AI психоз, перешел в founder mode, и работать стало невозможно
Ну а вообще вакансии для инженерных руководителей сейчас как будто бы разделились на два типа:
1️⃣Наша компания умирает из-за AI, пожалуйста, спасите нас и сделайте AI трансформацию разработки. Все сильные люди уволились. Никого нового сильного нанять вы не сможете. Платить мы вам сможем примерно как стафф-инженеру в бигтехе. Но вот если все поправите, получите премию!
2️⃣У нас переоцененный AI стартап, пожалуйста, помогите нам начать делать настоящие AI штуки. У нас никогда не было технического лида, только 25 летний кофаундер, который разобрался с консолью AWS. Платить мы вам сможем примерно как стафф-инженеру в бигтехе. Но вот если все поправите, получите премию!
Короче, цитаты твита и реплаи там прямо золото, рекомендую почитать!
Всю прошлую неделю в Твиттере обсуждали интересный тренд – многие CTO / VP of Engineering / Head of Development в стартапах и компаниях среднего размера сейчас жестко выгорают и увольняются, проработав буквально пару месяцев. Причины называют вот такие:
👉Роль, на которую их взяли, довольно расстрельная, с нереалистичными ожиданиями из-за AI
👉У компании нет никакой стратегии и видимого будущего с учетом изменений рынка, вызванных AI
👉В этой компании не получить так называемый AI-native опыт, который им точно в будущем для карьеры понадобится
👉Человек, на замену которого их наняли, уволился из-за тех же причин
👉Начать свой стартап сейчас в целом не очень сложно, деньгами в хороших инженерных лидов готовы кидать
👉СЕО словил AI психоз, перешел в founder mode, и работать стало невозможно
Ну а вообще вакансии для инженерных руководителей сейчас как будто бы разделились на два типа:
1️⃣Наша компания умирает из-за AI, пожалуйста, спасите нас и сделайте AI трансформацию разработки. Все сильные люди уволились. Никого нового сильного нанять вы не сможете. Платить мы вам сможем примерно как стафф-инженеру в бигтехе. Но вот если все поправите, получите премию!
2️⃣У нас переоцененный AI стартап, пожалуйста, помогите нам начать делать настоящие AI штуки. У нас никогда не было технического лида, только 25 летний кофаундер, который разобрался с консолью AWS. Платить мы вам сможем примерно как стафф-инженеру в бигтехе. Но вот если все поправите, получите премию!
Короче, цитаты твита и реплаи там прямо золото, рекомендую почитать!
X (formerly Twitter)
Gergely Orosz (@GergelyOrosz) on X
Interesting trend:
CTO/ Head of Eng / VPE folks at startups and mid-sized companies are... leaving / burning out. Hiring for these roles is HARD, but even after filling the role, they will often leave a few months later and take a career break
And they…
CTO/ Head of Eng / VPE folks at startups and mid-sized companies are... leaving / burning out. Hiring for these roles is HARD, but even after filling the role, they will often leave a few months later and take a career break
And they…
👍29🔥11❤7👎1
Огромная библиотека постмортемов
Кто-то собрал на одном сайте гигантскую подборку из 650 постмортемов от разных компаний. Использовать можно и для того, чтобы посмотреть, как деградируют ваши любимые сервисы, и для того, чтобы вдохновиться форматом и процессами.
Кто-то собрал на одном сайте гигантскую подборку из 650 постмортемов от разных компаний. Использовать можно и для того, чтобы посмотреть, как деградируют ваши любимые сервисы, и для того, чтобы вдохновиться форматом и процессами.
postmortem.io
postmortem.io · the library of real postmortems
A carefully organized library of public engineering incident reports, postmortems, and shutdown writeups — every entry linked back to its original source.
👍22❤3🔥3
😔 79% уволившихся называют причиной ухода недостаток признания.
Руководители переоценивают частоту похвалы: им кажется, что они говорят «спасибо» каждую неделю, на самом деле сотрудники получают признание в лучшем случае несколько раз в год. Результат — выгорание, демотивация и уход лучших.
Команда Яндекс Практикума собрала гайд из 30 способов похвалы, которые реально работают с любым бюджетом. Внутри:
✅ Идеи от простого «спасибо» до опционов и жилищных программ
✅ Реальные кейсы из Т-Банка, 2ГИС, Ozon и ВТБ
✅ Пошаговый план по созданию культуры признания
✅ Советы по автоматизации похвалы с помощью ИИ
✅ Готовые фразы, чтобы не ломать голову, что сказать
Скачивайте бесплатно и начните внедрять лучшие практики уже завтра
Реклама, ООО Яндекс, ИНН 7736207543, erid: 2Vtzquo2GYz
Руководители переоценивают частоту похвалы: им кажется, что они говорят «спасибо» каждую неделю, на самом деле сотрудники получают признание в лучшем случае несколько раз в год. Результат — выгорание, демотивация и уход лучших.
Команда Яндекс Практикума собрала гайд из 30 способов похвалы, которые реально работают с любым бюджетом. Внутри:
✅ Идеи от простого «спасибо» до опционов и жилищных программ
✅ Реальные кейсы из Т-Банка, 2ГИС, Ozon и ВТБ
✅ Пошаговый план по созданию культуры признания
✅ Советы по автоматизации похвалы с помощью ИИ
✅ Готовые фразы, чтобы не ломать голову, что сказать
Скачивайте бесплатно и начните внедрять лучшие практики уже завтра
Реклама, ООО Яндекс, ИНН 7736207543, erid: 2Vtzquo2GYz
4👎32❤1👍1🔥1
Не понимать кодовую базу – нормально
Один из стандартных набросов на LLM – это то, что разработчики, слишком сильно полагающиеся на агентов, довольно быстро теряют понимание кодовой базы проекта. Но если задуматься – а насколько это понимание было и раньше, когда код писали руками? А если подумать не про сравнительно компактные кодовые базы, а огромные энтерпрайзные проекты?
Планируя изменение программы, мы всегда оперируем своей собственной теорией о том, как она работает. В больших кодобазах эта теория всегда будет неверной или неполной – просто невозможно все детали удержать в голове. Поэтому в любом случае нужно уметь работать в таких условиях – сжимать зубы, выдвигать гипотезы о том, как программа работает, проверять их, и обновлять свою теорию.
AI, конечно, усложняет поддержку теории об устройстве программы в собственной голове. Но, с другой стороны, он помогает гораздо быстрее поднимать контекст про незнакомые или забытые части системы, и очень быстро тестировать свои гипотезы – поэтому прямо однозначно сказать, что AI в этой части сделал все хуже, нельзя.
Один из стандартных набросов на LLM – это то, что разработчики, слишком сильно полагающиеся на агентов, довольно быстро теряют понимание кодовой базы проекта. Но если задуматься – а насколько это понимание было и раньше, когда код писали руками? А если подумать не про сравнительно компактные кодовые базы, а огромные энтерпрайзные проекты?
Планируя изменение программы, мы всегда оперируем своей собственной теорией о том, как она работает. В больших кодобазах эта теория всегда будет неверной или неполной – просто невозможно все детали удержать в голове. Поэтому в любом случае нужно уметь работать в таких условиях – сжимать зубы, выдвигать гипотезы о том, как программа работает, проверять их, и обновлять свою теорию.
AI, конечно, усложняет поддержку теории об устройстве программы в собственной голове. Но, с другой стороны, он помогает гораздо быстрее поднимать контекст про незнакомые или забытые части системы, и очень быстро тестировать свои гипотезы – поэтому прямо однозначно сказать, что AI в этой части сделал все хуже, нельзя.
👎59👍39
AI в разработке уже прошел стадию «нужен или нет» и стал вопросом процессов: как считать эффект, как перестроить ревью, кто отвечает за код агента и что делать с выгоранием, которое приходит вместе с AI-слопом.
Об этом будет говорить TeamLead Сибирь — конференция для тимлидов и руководителей. AI-трансформация заняла самый большой трек, 15 докладов о реальных внедрениях:
🔸 как считать экономику внедрения ИИ и вести его как управляемый эксперимент
🔸 почему AI-трансформация буксует и откуда берется сопротивление
🔸 как команда из двух-трех человек с ИИ-агентами тащит целый продукт
🔸 молиться на модель или строить harness: что агент делает за вас и как ему помочь
Кроме AI разбирают найм и удержание, процессы и управление изменениями. Плюс мастер-классы про выгорание, которого с приходом AI меньше не стало.
Выступают практики из Точка Банк, Альфа-Банк, X5 Tech, iSource и других. 10–11 сентября, Новосибирск и онлайн. 10 августа цена поднимется, успейте купить на выгодных условиях.
👉 Программа и билеты
Рекламодатель: ООО "Конференции Олега Бунина ИНН: 7733863233 erid: 2SDnjcsadbZ
Об этом будет говорить TeamLead Сибирь — конференция для тимлидов и руководителей. AI-трансформация заняла самый большой трек, 15 докладов о реальных внедрениях:
🔸 как считать экономику внедрения ИИ и вести его как управляемый эксперимент
🔸 почему AI-трансформация буксует и откуда берется сопротивление
🔸 как команда из двух-трех человек с ИИ-агентами тащит целый продукт
🔸 молиться на модель или строить harness: что агент делает за вас и как ему помочь
Кроме AI разбирают найм и удержание, процессы и управление изменениями. Плюс мастер-классы про выгорание, которого с приходом AI меньше не стало.
Выступают практики из Точка Банк, Альфа-Банк, X5 Tech, iSource и других. 10–11 сентября, Новосибирск и онлайн. 10 августа цена поднимется, успейте купить на выгодных условиях.
👉 Программа и билеты
Рекламодатель: ООО "Конференции Олега Бунина ИНН: 7733863233 erid: 2SDnjcsadbZ
👎17❤1
Про скорость ради скорости
Задумайтесь – а насколько часто, когда вы пытались ускориться сами, или просили об этом команду, это действительно было важно? В нашей индустрии уже довольно давно стало моветоном не пытаться всеми силами оптимизировать time to market. А итоги у этого не всегда положительные:
👉Предложения замедлиться и подумать по умолчанию воспринимаются как контрпродуктивные.
👉Многие ненужные фичи делаются только потому, что их можно сделать быстро. Они дают ощущение прогресса, хотя на самом деле могут быть просто броуновским движением.
Реальная скорость происходит не от бездумной спешки, а скорее от противоположного – траты лишнего времени на то, чтобы принять нужные решения, убедиться, что задача всем понятна, и нужный контекст собран. И, что еще важнее, когда потрачено время на то, чтобы ответить на сложные неудобные вопросы вроде "а нужную ли вещь мы вообще делаем?".
Золотая статья!
Задумайтесь – а насколько часто, когда вы пытались ускориться сами, или просили об этом команду, это действительно было важно? В нашей индустрии уже довольно давно стало моветоном не пытаться всеми силами оптимизировать time to market. А итоги у этого не всегда положительные:
👉Предложения замедлиться и подумать по умолчанию воспринимаются как контрпродуктивные.
👉Многие ненужные фичи делаются только потому, что их можно сделать быстро. Они дают ощущение прогресса, хотя на самом деле могут быть просто броуновским движением.
Реальная скорость происходит не от бездумной спешки, а скорее от противоположного – траты лишнего времени на то, чтобы принять нужные решения, убедиться, что задача всем понятна, и нужный контекст собран. И, что еще важнее, когда потрачено время на то, чтобы ответить на сложные неудобные вопросы вроде "а нужную ли вещь мы вообще делаем?".
Золотая статья!
The Gospel According to Graybeard
The Religion of Speed
At some point, “moving fast” stopped being a practical concern and became a moral position. You see it damn near everywhere now.
How fast can we ship this...
How fast can we ship this...
👍44❤11🔥2
Лето, ИТ-Пикник и музыка известных артистов уже через несколько дней!
8 августа в Коломенском пройдет ИТ-Пикник.
В программе — выступления проекта LAB Антона Беляева, IOWA, Cream Soda, Pompeya, мартина и Совы.
А днем — научпоп-лекции, дискуссии об ИИ и больших языковых моделях, мастер-классы и интерактивы. Полезные знакомства и развлечения тоже будут.
Зарегистрироваться и узнать подробности можно на сайте мероприятия.
В билет входит +1 — можно позвать близких и друзей.
До встречи в месте притяжения ИТ.
8 августа в Коломенском пройдет ИТ-Пикник.
В программе — выступления проекта LAB Антона Беляева, IOWA, Cream Soda, Pompeya, мартина и Совы.
А днем — научпоп-лекции, дискуссии об ИИ и больших языковых моделях, мастер-классы и интерактивы. Полезные знакомства и развлечения тоже будут.
Зарегистрироваться и узнать подробности можно на сайте мероприятия.
В билет входит +1 — можно позвать близких и друзей.
До встречи в месте притяжения ИТ.
❤4👍2👎2🔥2
Как стафф инженеру найти достойные проблемы
Большинство компаний сходятся на том, что главная черта, отличающая стаффа от сеньора – это умение самостоятельно находить самые ценные точки приложения своих усилий. Вот простой алгоритм, как можно это делать:
👉Накапливайте знания о проблемах в вашей области компетенции, на которые жалуются люди.
👉Не бросайтесь на первую проблему, которая показалась важной. Дайте им накопиться, и беритесь за то, что проявляется хотя бы несколько раз для разных команд.
👉После того, как вы выбрали кластер связанных проблем, с решением тоже не спешите. Потратьте побольше времени на то, чтобы найти наилучшую форму решения, которая сможет закрыть сразу все эти проблемы.
👉До того, как начать полноценную реализацию, потратьте еще сколько-то времени на то, чтобы сделать дешевый прототип, показать его заинтересованным людям, и перепроверить, а туда ли вообще вы копаете.
Обратите внимания на классные пересечения со вчерашней статьей – ни один из этих пунктов не сработает, если главная ценность вашей компании – скорость.
Большинство компаний сходятся на том, что главная черта, отличающая стаффа от сеньора – это умение самостоятельно находить самые ценные точки приложения своих усилий. Вот простой алгоритм, как можно это делать:
👉Накапливайте знания о проблемах в вашей области компетенции, на которые жалуются люди.
👉Не бросайтесь на первую проблему, которая показалась важной. Дайте им накопиться, и беритесь за то, что проявляется хотя бы несколько раз для разных команд.
👉После того, как вы выбрали кластер связанных проблем, с решением тоже не спешите. Потратьте побольше времени на то, чтобы найти наилучшую форму решения, которая сможет закрыть сразу все эти проблемы.
👉До того, как начать полноценную реализацию, потратьте еще сколько-то времени на то, чтобы сделать дешевый прототип, показать его заинтересованным людям, и перепроверить, а туда ли вообще вы копаете.
Обратите внимания на классные пересечения со вчерашней статьей – ни один из этих пунктов не сработает, если главная ценность вашей компании – скорость.
Lalit Maganti
How I Find Problems to Solve as a Staff Engineer
How listening broadly turns everyday problems into useful project ideas.
❤15👍13