По 3-4, очень большие, но вчера, либо по 2–3 релиза, маленькие, но сегодня!
Свежатинка из мира корпоративного опенсорса, Павел Сушин написал статью на хабр.
YTsaurus — два года в опенсорсе: чего мы достигли и куда движемся
Из вкусного, реальный расказ про роадмап и цикл релизов. Очень открыто и честно.
Каждый раз кайфую от такого рода материалов.
Свежатинка из мира корпоративного опенсорса, Павел Сушин написал статью на хабр.
YTsaurus — два года в опенсорсе: чего мы достигли и куда движемся
Из вкусного, реальный расказ про роадмап и цикл релизов. Очень открыто и честно.
Мы стремимся делать релиз YTsaurus server 3–4 раза в год, но на практике получается чуть реже: 2–3 релиза. Каждый релиз сначала тестируется в несколько этапов внутри Яндекса и только после этого появляется в открытом доступе. Поэтому от коммита до стабильного релиза может пройти до 5–6 месяцев.
Каждый раз кайфую от такого рода материалов.
👍3👀3🔥1
Гордыня.
Вместе с Алексеем в две каски развлекались в 292-м эпизоде подкаста «Разбор полетов». Позлословили на тему DDoS-атаки на букмекера. И слегка похвалили Huawei за выход новых железок.
Слушать подкаст на Яндекс.Музыке.
Читать полезняшки от «Разбора Полетов».
#подкаст #debriefing
Вместе с Алексеем в две каски развлекались в 292-м эпизоде подкаста «Разбор полетов». Позлословили на тему DDoS-атаки на букмекера. И слегка похвалили Huawei за выход новых железок.
Слушать подкаст на Яндекс.Музыке.
Читать полезняшки от «Разбора Полетов».
#подкаст #debriefing
👍1
Второй пилот Ai.
Вместе с Игорем Лученковым из Clarify обсудили Vibe coding. Вспомнили Андрея Карпати, Тоби (Тобиас) Лютке, Чип Хьюен, затронули тему PRD. Хвалили и ругали разные Ai. Короче развлекались как могли.
Горим в подкасте на тему вторых пилотов, Ai и всего что нас окружает уже сейчас. Слушайте 331-й подкаст The Art of Programming — «Второй пилот Ai».
Подписаться в iTunes.
Смотреть на VK.
Слушать на Яндекс Музыке.
#подкаст #taop
Вместе с Игорем Лученковым из Clarify обсудили Vibe coding. Вспомнили Андрея Карпати, Тоби (Тобиас) Лютке, Чип Хьюен, затронули тему PRD. Хвалили и ругали разные Ai. Короче развлекались как могли.
Горим в подкасте на тему вторых пилотов, Ai и всего что нас окружает уже сейчас. Слушайте 331-й подкаст The Art of Programming — «Второй пилот Ai».
Подписаться в iTunes.
Смотреть на VK.
Слушать на Яндекс Музыке.
#подкаст #taop
🔥5👍1
Настало время перемен.
Как компании должны поддерживать амбиции своих сотрудников? Вот как в Яндексе:
— Хотите что-то изобрести?
— Долго искали тех, кто поддержит вас и ваши инициативы?
— Время пришло!
P. S. Пора перешутить все шутки про роботов +) Иначе их пошутят вместо нас.
А если серьезно, то по теме можно почитать тут.
Как компании должны поддерживать амбиции своих сотрудников? Вот как в Яндексе:
— Хотите что-то изобрести?
— Долго искали тех, кто поддержит вас и ваши инициативы?
— Время пришло!
Яндекс открыл фонд технологических инициатив — Yet Another Tech Fund. Фонд будет поддерживать новаторские проекты сотрудников Яндекса — такие, которые способны продвинуть вперёд науку или технологии. В 2025 году на это выделят 330 млн руб.
В этом году YATF поддержит проекты по оцифровке офлайн-магазинов, разработке программного обеспечения для роботов-гуманоидов, упрощению поиска по базам данных под управлением YDB и развитию ИИ в медицине.
P. S. Пора перешутить все шутки про роботов +) Иначе их пошутят вместо нас.
А если серьезно, то по теме можно почитать тут.
🔥7👍5🤩5
The Split Keyboard.
Пока идут праздничные дни, решил посмотреть на новые железки. Давно присматриваюсь к формату разделенных клавиатур, одна тут попалась в обзоре.
А вам какие-то железки интересные за последние время попадались? Что-то такое, от чего глаза загорелись и руки зачесались?
Пока идут праздничные дни, решил посмотреть на новые железки. Давно присматриваюсь к формату разделенных клавиатур, одна тут попалась в обзоре.
А вам какие-то железки интересные за последние время попадались? Что-то такое, от чего глаза загорелись и руки зачесались?
👍1
Деньги, общее горе, общий враг и взаимная выгода.
Шел пятый час обсуждения всякого важного и делового небольшой компанией уже битых жизнью друзей-коллег по опасному бизнесу. И вот все это безумие закончилось. Все бумаги подписаны, все руки пожаты. Все выдохнули и нервно посмеялись и расслабились.
Это важно. Расслабись. Так как нервы были очень накалены. Адовые переговоры закончились, и вот все слегка выпили, перекурили, даже нервно всплакнули. Кривая осуждалок вынесла на тему «Разваливающихся команд». Вспоминали разные случаи из своей практики, какие-то кейсы и бурно писали на салфетке «клей», удерживающий команду в одной обойме.
Цинично вычеркивали и возвращали обратно пункты. Приводили аргументы и контр аргументы. И через пару часов в коротком списке остались: деньги, общее горе, общий враг и взаимная выгода.
При этом члены команды не будут любить друг друга, вероятно, будут испытывать стресс и раздражение, но они будут склеены и, возможно, надолго.
Шел пятый час обсуждения всякого важного и делового небольшой компанией уже битых жизнью друзей-коллег по опасному бизнесу. И вот все это безумие закончилось. Все бумаги подписаны, все руки пожаты. Все выдохнули и нервно посмеялись и расслабились.
Это важно. Расслабись. Так как нервы были очень накалены. Адовые переговоры закончились, и вот все слегка выпили, перекурили, даже нервно всплакнули. Кривая осуждалок вынесла на тему «Разваливающихся команд». Вспоминали разные случаи из своей практики, какие-то кейсы и бурно писали на салфетке «клей», удерживающий команду в одной обойме.
Цинично вычеркивали и возвращали обратно пункты. Приводили аргументы и контр аргументы. И через пару часов в коротком списке остались: деньги, общее горе, общий враг и взаимная выгода.
Деньги. Тут все просто. Когда люди завязаны на общую премию, бонус или грант, им вынужденно приходится работать вместе. Общий финансовый интерес мотивирует держаться друг за друга и за результат.
Общее горе. Команда быстро сближается (правда, отбраковывая не своих), когда вместе всё плохо: дедлайн горит, начальство прессует, клиентов невозможно удовлетворить. Совместные страдания и стресс лучше любых тимбилдингов связывают людей друг с другом.
Общий враг. Внешний раздражитель или угроза (нервный заказчик, бесполезное руководство, конкуренты) объединяет людей против кого-то или чего-то. Вместо того чтобы ссориться между собой, команда фокусируется на борьбе с этим общим врагом.
Взаимная выгода. Если у членов команды есть чёткое понимание, что каждый отдельно ничего не получит или не справится, но вместе можно достичь выгоды (закрыть проект, получить аванс, продвинуться по службе), их интересы пересекаются, они начинают работать слаженно.
При этом члены команды не будут любить друг друга, вероятно, будут испытывать стресс и раздражение, но они будут склеены и, возможно, надолго.
1👍5💯2🔥1
Победители и проигравшие.
Победителям аплодируют, проигравших критикуют, и редко кто задумывается: а было ли принятое решение разумным на момент выбора? Всё дело в действии когнитивного искажения — Outcome Bias, или «отклонение в сторону результата». Оно может приводить к несправедливой оценке людей, событий и даже наших собственных поступков.
Непонятно, кто первый выделил Outcome Bias как отдельный вид, но многие склоняются к работе Baruch Fischhoff 1975 года:
Baruch Fischhoff — Hindsight ≠ Foresight: The Effect of Outcome Knowledge on Judgment Under Uncertainty — 1975
В работе Барух экспериментально показал, что когда люди узнают исход ситуации, они начинают переоценивать, насколько этот исход был предсказуем — и тем более — насколько целесообразным было изначальное решение. После уже совершившегося события кажется, что «другого быть не могло».
Что это значит? Ну вот представьте: врач выбирает сложное лечение для пациента. Если пациент выздоравливает, все считают, что решение врача было правильным. Если пациент умирает — решение кажется ошибочным. Однако в обоих случаях врач мог действовать наилучшим образом, исходя из имеющейся информации и медицинских протоколов.
Спустя десятилетия психологи Джонатан Барон и Джон Херши описали outcome bias как отдельное когнитивное искажение.
Jonathan Baron, John Hershey — Outcome Bias in Decision Evaluation — 1988
В ряде своих экспериментов они предложили участникам оценить решения, которые приводили либо к положительным, либо к отрицательным последствиям, при том что условия выбора были одинаковы. Оказалось, что люди и вправду считают решение «хорошим», если оно принесло удачу, и «плохим» — если всё обернулось неудачей. Такой подход к оценке полностью игнорирует риски, логику и качество рассуждений на момент принятия решения.
Авторы также показали важное отличие от «иллюзии предсказуемости задним числом» (hindsight bias, надо будет тоже про него написать): outcome bias — это именно склонность судить о правильности решений через призму их исхода, а не память о том, что «все знали, чем всё закончится».
Мы в работе, связанной с Developer Relations, часто стараемся переосмыслить достигнутые результаты, и Outcome bias заставляет нас быть несправедливыми по отношению к себе и окружающим. Оценивать решения только по результату — значит отказываться от объективности и учёбы на ошибках.
Пусть ваш анализ будет честным: смотрите не только на исход, но и на мотивы, контекст и разумность действий на момент выбора. Так вы научитесь принимать и оценивать решения по-настоящему зрелым образом.
Как избавиться от outcome bias?
🔵 Анализируйте процесс принятия решений: старайтесь оценивать не только конечный результат, но и обоснованность, логику и доступную информацию при выборе.
🔵 Держите в уме фактор случайности: помните, что даже идеальные решения иногда приводят к неудаче.
🔵 Разделяйте решение и исход: это разные категории; первое зависит от вас, второе — нет всегда.
В следующий раз, когда будете проводить post-mortem анализ проекта, сначала запишите все факты, которые были известны НА МОМЕНТ принятия решения. Только потом смотрите на результат.
#DevRel
Победителям аплодируют, проигравших критикуют, и редко кто задумывается: а было ли принятое решение разумным на момент выбора? Всё дело в действии когнитивного искажения — Outcome Bias, или «отклонение в сторону результата». Оно может приводить к несправедливой оценке людей, событий и даже наших собственных поступков.
Непонятно, кто первый выделил Outcome Bias как отдельный вид, но многие склоняются к работе Baruch Fischhoff 1975 года:
Baruch Fischhoff — Hindsight ≠ Foresight: The Effect of Outcome Knowledge on Judgment Under Uncertainty — 1975
В работе Барух экспериментально показал, что когда люди узнают исход ситуации, они начинают переоценивать, насколько этот исход был предсказуем — и тем более — насколько целесообразным было изначальное решение. После уже совершившегося события кажется, что «другого быть не могло».
Что это значит? Ну вот представьте: врач выбирает сложное лечение для пациента. Если пациент выздоравливает, все считают, что решение врача было правильным. Если пациент умирает — решение кажется ошибочным. Однако в обоих случаях врач мог действовать наилучшим образом, исходя из имеющейся информации и медицинских протоколов.
Спустя десятилетия психологи Джонатан Барон и Джон Херши описали outcome bias как отдельное когнитивное искажение.
Jonathan Baron, John Hershey — Outcome Bias in Decision Evaluation — 1988
Outcome bias is the tendency to evaluate a decision according to its outcome rather than on the quality of the decision at the time it was made.
Outcome bias — склонность оценивать решение по его исходу, а не по качеству принятого решения в момент его принятия.
В ряде своих экспериментов они предложили участникам оценить решения, которые приводили либо к положительным, либо к отрицательным последствиям, при том что условия выбора были одинаковы. Оказалось, что люди и вправду считают решение «хорошим», если оно принесло удачу, и «плохим» — если всё обернулось неудачей. Такой подход к оценке полностью игнорирует риски, логику и качество рассуждений на момент принятия решения.
Авторы также показали важное отличие от «иллюзии предсказуемости задним числом» (hindsight bias, надо будет тоже про него написать): outcome bias — это именно склонность судить о правильности решений через призму их исхода, а не память о том, что «все знали, чем всё закончится».
Мы в работе, связанной с Developer Relations, часто стараемся переосмыслить достигнутые результаты, и Outcome bias заставляет нас быть несправедливыми по отношению к себе и окружающим. Оценивать решения только по результату — значит отказываться от объективности и учёбы на ошибках.
Пусть ваш анализ будет честным: смотрите не только на исход, но и на мотивы, контекст и разумность действий на момент выбора. Так вы научитесь принимать и оценивать решения по-настоящему зрелым образом.
Как избавиться от outcome bias?
В следующий раз, когда будете проводить post-mortem анализ проекта, сначала запишите все факты, которые были известны НА МОМЕНТ принятия решения. Только потом смотрите на результат.
#DevRel
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6💯3❤1🔥1
За парты!
Забавная штука произошла в понедельник — топы крупнейших компаний решили тряхнуть стариной и вспомнить школьные годы. В The New York Times вышло открытое письмо с призывом сделать информатику базовым предметом в школах, начиная с самого начала.
Конечно, всё это не просто так — бизнес думает на перспективу. Современный мир требует от специалистов совсем других навыков, чем 20 лет назад. И начинать готовить кадры нужно со школьной скамьи. К тому же, это хорошая возможность вырастить потребителей сервисов, которые прямо сейчас находятся в разработке.
Интересно, что инициатива идёт именно от бизнеса, а не от системы образования (хотя кто знает). Видимо, нехватка квалифицированных кадров или желание наэкономить стало настолько острым, что CEO решили взять дело в свои руки.
Microsoft, IBM, Meta, Adobe и другие 250 CEO поставили подписи, интересно исследовать, кто же подписался и какие были у них мотивы.
Как думаете, сработает? Или это очередная попытка бизнеса повлиять на образование?
Забавная штука произошла в понедельник — топы крупнейших компаний решили тряхнуть стариной и вспомнить школьные годы. В The New York Times вышло открытое письмо с призывом сделать информатику базовым предметом в школах, начиная с самого начала.
Конечно, всё это не просто так — бизнес думает на перспективу. Современный мир требует от специалистов совсем других навыков, чем 20 лет назад. И начинать готовить кадры нужно со школьной скамьи. К тому же, это хорошая возможность вырастить потребителей сервисов, которые прямо сейчас находятся в разработке.
Интересно, что инициатива идёт именно от бизнеса, а не от системы образования (хотя кто знает). Видимо, нехватка квалифицированных кадров или желание наэкономить стало настолько острым, что CEO решили взять дело в свои руки.
Microsoft, IBM, Meta, Adobe и другие 250 CEO поставили подписи, интересно исследовать, кто же подписался и какие были у них мотивы.
Как думаете, сработает? Или это очередная попытка бизнеса повлиять на образование?
😁1👀1
Повайбим?
Тема всплыла в разговоре с коллегами. Пацаны за гаражами вайбкодили, а я так, рядом стоял. Говорят, новое поколение разработчиков якобы требует платных ассистентов для работы, иначе «не могут». Как человек, который застал времена без подсказок в IDE, отказываюсь в это верить. Ну конечно, могу представить вэротических фантазиях.
Да, инструменты важны. Но когда ты понимаешь базу, можешь писать код хоть в блокноте, хоть на салфетке в кафешке. А вот слепая зависимость от помощников — кажется, какой-то путь в никуда.
К тому же, многие компании запрещают использование сторонних ассистентов из соображений безопасности. Ваш код буквально утекает на чужие сервера. Хотите рискнуть проектом ради удобства? Текущие страхи и боли индустрии, прям прослеживаются аналогии с облаками.
Моё мнение — инструменты должны помогать, а не становиться костылями. Уже как-то говорил, я верю в AI-ассистента как второго пилота, коллегу по парному программированию. Но чтобы начать программировать в паре, надо изначально обладать компетенциями. Учитесь думать самостоятельно, прежде чем полагаться на чужой разум.
Тема всплыла в разговоре с коллегами. Пацаны за гаражами вайбкодили, а я так, рядом стоял. Говорят, новое поколение разработчиков якобы требует платных ассистентов для работы, иначе «не могут». Как человек, который застал времена без подсказок в IDE, отказываюсь в это верить. Ну конечно, могу представить в
Да, инструменты важны. Но когда ты понимаешь базу, можешь писать код хоть в блокноте, хоть на салфетке в кафешке. А вот слепая зависимость от помощников — кажется, какой-то путь в никуда.
К тому же, многие компании запрещают использование сторонних ассистентов из соображений безопасности. Ваш код буквально утекает на чужие сервера. Хотите рискнуть проектом ради удобства? Текущие страхи и боли индустрии, прям прослеживаются аналогии с облаками.
Моё мнение — инструменты должны помогать, а не становиться костылями. Уже как-то говорил, я верю в AI-ассистента как второго пилота, коллегу по парному программированию. Но чтобы начать программировать в паре, надо изначально обладать компетенциями. Учитесь думать самостоятельно, прежде чем полагаться на чужой разум.
❤6👍3🔥3😁2
Две разные философии разработки.
Последние продукты Google и Anysphere показывают, как по-разному можно подходить к созданию инструментов для разработчиков. Наш любимый Developer Experience на передовой.
Firebase Studio — это попытка Google сделать единую браузерную среду для быстрого прототипирования. Всё под рукой: редактор, Gemini для подсказок, сервисы Google Cloud и Firebase для деплоя. Минимум настроек, максимум автоматизации - идеально для быстрого старта проектов. Так кажется на первый взгляд, перекрестимся в этом месте.
С другой стороны — Cursor от Anysphere . Это расширение для VS Code, которое интегрируется в привычный рабочий процесс. Основной фокус на максимальной производительности: гибкие настройки, прямая работа с локальным кодом (хочется верить, что с локальным, и второй раз перекрестимся), умные подсказки.
Заявляются два разных подхода для разных сценариев:
🔵 Firebase Studio = быстрый старт и прототипирование
🔵 Cursor = «локальная» эффективность в продакшене
Чей подход вам кажется более правильным?
Firebase Studio — 🔥
Cursor— 🤩
Надо потестить оба — 👀
P.S. Забавно наблюдать, как крупные компании и стартапы по-разному видят будущее инструментов разработки. А вы что думаете о таких разных подходах?
Последние продукты Google и Anysphere показывают, как по-разному можно подходить к созданию инструментов для разработчиков. Наш любимый Developer Experience на передовой.
Firebase Studio — это попытка Google сделать единую браузерную среду для быстрого прототипирования. Всё под рукой: редактор, Gemini для подсказок, сервисы Google Cloud и Firebase для деплоя. Минимум настроек, максимум автоматизации - идеально для быстрого старта проектов. Так кажется на первый взгляд, перекрестимся в этом месте.
С другой стороны — Cursor от Anysphere . Это расширение для VS Code, которое интегрируется в привычный рабочий процесс. Основной фокус на максимальной производительности: гибкие настройки, прямая работа с локальным кодом (хочется верить, что с локальным, и второй раз перекрестимся), умные подсказки.
Заявляются два разных подхода для разных сценариев:
Чей подход вам кажется более правильным?
Firebase Studio — 🔥
Cursor— 🤩
Надо потестить оба — 👀
P.S. Забавно наблюдать, как крупные компании и стартапы по-разному видят будущее инструментов разработки. А вы что думаете о таких разных подходах?
Please open Telegram to view this post
VIEW IN TELEGRAM
🤩11👀9🔥4
В Иркутске, отгремел салют. С праздником.
П.С. Не отгремел +) это были местные учения… фальстарт, а то местные уже пишут, что как так. В далее слышу как еще бахает +) люди празднуют.
П.С. Не отгремел +) это были местные учения… фальстарт, а то местные уже пишут, что как так. В далее слышу как еще бахает +) люди празднуют.
🎉10🔥5
Все еще меряете? Тогда мы идём к вам!
В банковской и академической среде есть известный принцип, который давно вышел за пределы экономики и стал актуален для всех, кто работает с метриками и показателями. Речь идет о Законе Гудхарта.
В 1975 году Чарльз Гудхарт, сотрудник Банка Англии и профессор Лондонской школы экономики, сформулировал этот закон так: «Любая наблюдаемая статистическая закономерность разрушается, как только на нее начинают влиять в целях управления.»
Позже антрополог Мэрилин Стратерн переформулировала его короче и точнее:
«Когда мера становится целью, она перестает быть хорошей мерой.»
В этот момент многие вспоминают не менее известную фразу Питера Друкера: «Нельзя управлять тем, что нельзя измерить.» И начинают спорить: что же тогда делать с метриками и KPI?
Однако суть закона Гудхарта — в очень простой вещи. Как только метрика становится целью, ее начинают сознательно или бессознательно искажать. Это может быть прямое манипулирование результатами (фальсификация), либо выполнение формальных требований без реального улучшения. Чаще всего сотрудники и целые компании перестраивают работу не ради реального результата, а ради «красивых» показателей — ведь от них теперь зависит премия, рейтинг команды или даже выживание бизнеса.
Лучше всего это иллюстрирует одна старая производственная история, которую мне рассказывал мой опытный коллега.
Представьте завод по производству гвоздей. Руководство ставит задачу: «Сделайте как можно больше гвоздей». От выполнения плана зависит премия. Работники мгновенно находят самый простой путь — начинают штамповать огромное количество маленьких, но никому не нужных гвоздиков. План по количеству перевыполнен, премия получена, но клиентам эти гвозди не нужны.
В следующем периоде метрику «оптимизируют» — премия теперь привязана не к количеству, а к общему весу выпущенной продукции. Завод тут же переходит на производство исключительно больших и тяжелых гвоздей — теперь ненужных для основной массы клиентов. Суммарный вес максимален, KPI выполнен, но снова — пользы от продукта мало.
Этот пример отлично показывает: когда человек или система работают только для выполнения показателя, зачастую реальная ценность работы исчезает. А уж в ИТ, где мы завалены всевозможными метриками, scorecard’ами и отчетами, помнить об этом принципе особенно важно.
Метрики и показатели нужны, чтобы подсветить, где мы и куда идем. Но они не должны становиться самоцелью — иначе теряется смысл самой работы. Не превращайте измерение в «самостоятельную жизнь», и ваши проекты будут приносить больше настоящей пользы.
В банковской и академической среде есть известный принцип, который давно вышел за пределы экономики и стал актуален для всех, кто работает с метриками и показателями. Речь идет о Законе Гудхарта.
В 1975 году Чарльз Гудхарт, сотрудник Банка Англии и профессор Лондонской школы экономики, сформулировал этот закон так: «Любая наблюдаемая статистическая закономерность разрушается, как только на нее начинают влиять в целях управления.»
Any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes.
Позже антрополог Мэрилин Стратерн переформулировала его короче и точнее:
«Когда мера становится целью, она перестает быть хорошей мерой.»
When a measure becomes a target, it ceases to be a good measure.
В этот момент многие вспоминают не менее известную фразу Питера Друкера: «Нельзя управлять тем, что нельзя измерить.» И начинают спорить: что же тогда делать с метриками и KPI?
Однако суть закона Гудхарта — в очень простой вещи. Как только метрика становится целью, ее начинают сознательно или бессознательно искажать. Это может быть прямое манипулирование результатами (фальсификация), либо выполнение формальных требований без реального улучшения. Чаще всего сотрудники и целые компании перестраивают работу не ради реального результата, а ради «красивых» показателей — ведь от них теперь зависит премия, рейтинг команды или даже выживание бизнеса.
Лучше всего это иллюстрирует одна старая производственная история, которую мне рассказывал мой опытный коллега.
Представьте завод по производству гвоздей. Руководство ставит задачу: «Сделайте как можно больше гвоздей». От выполнения плана зависит премия. Работники мгновенно находят самый простой путь — начинают штамповать огромное количество маленьких, но никому не нужных гвоздиков. План по количеству перевыполнен, премия получена, но клиентам эти гвозди не нужны.
В следующем периоде метрику «оптимизируют» — премия теперь привязана не к количеству, а к общему весу выпущенной продукции. Завод тут же переходит на производство исключительно больших и тяжелых гвоздей — теперь ненужных для основной массы клиентов. Суммарный вес максимален, KPI выполнен, но снова — пользы от продукта мало.
Этот пример отлично показывает: когда человек или система работают только для выполнения показателя, зачастую реальная ценность работы исчезает. А уж в ИТ, где мы завалены всевозможными метриками, scorecard’ами и отчетами, помнить об этом принципе особенно важно.
Метрики и показатели нужны, чтобы подсветить, где мы и куда идем. Но они не должны становиться самоцелью — иначе теряется смысл самой работы. Не превращайте измерение в «самостоятельную жизнь», и ваши проекты будут приносить больше настоящей пользы.
🔥6👍3
Делай раз, делай два.
Недавно мы с братом обсуждали, как изменения, связанные с карантином, повлияли на работу команд. Один вопрос, который всплыл в разговоре, — насколько важно правильно ставить задачи и управлять их плотностью. Вспомнился интересный случай из докарантинной практики.
Ко мне обратился бывший студент — на тот момент начинающий тимлид. Ему досталась команда после масштабных перестановок в компании, и с первых дней ему пришлось разбираться с постоянными «пожарами». Задачи всё время возвращались на доработку, бэклог пух, количество запросов от других команд росло, а дедлайны сгорали один за другим. Словом: классическая антикризисная ситуация, когда всё на грани хаоса.
Он спросил: «Что делать, если система не работает, а на приведение всё в порядок нет ни времени, ни ресурсов, ни кредитов доверия?»
Вводить сложные процессы «по учебнику» в такой обстановке невозможно. Я предложил начать с двух простых шагов, которые не требовали серьёзных изменений и особого одобрения сверху.
Шаг 1. Перестать обещать сроки вслепую.
Я посоветовал: не называть конкретные сроки задачи на этапе планирования или формирования бэклога. Какой смысл заранее обещать сроки, которые команда почти всегда не выдерживает? Реалистичные даты стоит назначать, только когда задача уже в работе, у неё есть конкретный исполнитель, и вместе с ним обсуждены риски и нюансы. В ситуации, когда доверие к срокам было на нуле, коллеги не возражали против такого подхода. Результат не заставил себя ждать: уже через пару месяцев команда начала укладываться в 8 из 10 задач, хотя раньше точные оценки совпадали только в 2 из 10 случаев.
По сути, мы просто разделили предварительную оценку сложности задачи (когда она только попадает в бэклог) и реальные сроки выполнения, за которые команда могла взять ответственность.
Шаг 2. Встроить «рефакторинг» в каждую задачу.
Второй приём — к каждой основной задаче добавлять небольшую подзадачу, объёмом не больше 10% от общей работы. Эта микро-задача обязательно должна быть направлена на улучшение инфраструктуры, документации или инструментов, связанных с основной задачей. С виду — мелочь, и её добавление редко вызывало вопросы: никто не ждал, что пропащая команда будет попадать в сроки, так что чуть больший объём работ никто не замечал.
За счёт таких «микро-рефакторингов» удалось постепенно чинить старые баги, наращивать качество рабочего окружения и сократить время на поиск ошибок примерно вдвое. За пять месяцев команда существенно сократила десятки долговременных «зависших» задач и уменьшила количество экстренных инцидентов.
Признаюсь, над качеством постановки задач всё равно ещё пришлось поработать, но это уже совсем другая история — расскажу о ней в следующий раз.
Недавно мы с братом обсуждали, как изменения, связанные с карантином, повлияли на работу команд. Один вопрос, который всплыл в разговоре, — насколько важно правильно ставить задачи и управлять их плотностью. Вспомнился интересный случай из докарантинной практики.
Ко мне обратился бывший студент — на тот момент начинающий тимлид. Ему досталась команда после масштабных перестановок в компании, и с первых дней ему пришлось разбираться с постоянными «пожарами». Задачи всё время возвращались на доработку, бэклог пух, количество запросов от других команд росло, а дедлайны сгорали один за другим. Словом: классическая антикризисная ситуация, когда всё на грани хаоса.
Он спросил: «Что делать, если система не работает, а на приведение всё в порядок нет ни времени, ни ресурсов, ни кредитов доверия?»
Вводить сложные процессы «по учебнику» в такой обстановке невозможно. Я предложил начать с двух простых шагов, которые не требовали серьёзных изменений и особого одобрения сверху.
Шаг 1. Перестать обещать сроки вслепую.
Я посоветовал: не называть конкретные сроки задачи на этапе планирования или формирования бэклога. Какой смысл заранее обещать сроки, которые команда почти всегда не выдерживает? Реалистичные даты стоит назначать, только когда задача уже в работе, у неё есть конкретный исполнитель, и вместе с ним обсуждены риски и нюансы. В ситуации, когда доверие к срокам было на нуле, коллеги не возражали против такого подхода. Результат не заставил себя ждать: уже через пару месяцев команда начала укладываться в 8 из 10 задач, хотя раньше точные оценки совпадали только в 2 из 10 случаев.
По сути, мы просто разделили предварительную оценку сложности задачи (когда она только попадает в бэклог) и реальные сроки выполнения, за которые команда могла взять ответственность.
Шаг 2. Встроить «рефакторинг» в каждую задачу.
Второй приём — к каждой основной задаче добавлять небольшую подзадачу, объёмом не больше 10% от общей работы. Эта микро-задача обязательно должна быть направлена на улучшение инфраструктуры, документации или инструментов, связанных с основной задачей. С виду — мелочь, и её добавление редко вызывало вопросы: никто не ждал, что пропащая команда будет попадать в сроки, так что чуть больший объём работ никто не замечал.
За счёт таких «микро-рефакторингов» удалось постепенно чинить старые баги, наращивать качество рабочего окружения и сократить время на поиск ошибок примерно вдвое. За пять месяцев команда существенно сократила десятки долговременных «зависших» задач и уменьшила количество экстренных инцидентов.
Признаюсь, над качеством постановки задач всё равно ещё пришлось поработать, но это уже совсем другая история — расскажу о ней в следующий раз.
👍13🔥3
How Cursor Works?
Погружаясь в Model Context Protocol (MCP), наткнулся на интересную публикацию от Shrivu Shankar про устройство Cursor.
Shrivu Shankar — How Cursor (AI IDE) Works
После прочтения заметки мне стало чуть больше понятно, как думают разработчики IDE нового типа (таких как Cursor). По сути, такие редакторы как Cursor — это сложные обёртки вокруг языковых моделей. Но самое интересное, конечно, кроется в деталях реализации, и мы об этом узнаем не скоро.
Погружаясь в Model Context Protocol (MCP), наткнулся на интересную публикацию от Shrivu Shankar про устройство Cursor.
Shrivu Shankar — How Cursor (AI IDE) Works
После прочтения заметки мне стало чуть больше понятно, как думают разработчики IDE нового типа (таких как Cursor). По сути, такие редакторы как Cursor — это сложные обёртки вокруг языковых моделей. Но самое интересное, конечно, кроется в деталях реализации, и мы об этом узнаем не скоро.
👍2👎1
Vibe coding.
Андрей Карпати (Andrej Karpathy) 2 февраля 2025 ввел новый термин, породил тред более чем на тысячу твитов, и буквально через месяц термин уже попал в словарь Merriam-Webster:
Андрей Карпати (Andrej Karpathy) 2 февраля 2025 ввел новый термин, породил тред более чем на тысячу твитов, и буквально через месяц термин уже попал в словарь Merriam-Webster:
Vibe coding (также пишется как vibecoding) — недавно введенный термин для обозначения практики написания кода, создания веб-страниц или приложений, когда вы просто сообщаете программе искусственного интеллекта, чего вы хотите, и позволяете ей создавать продукт за вас. В vibe coding программисту не нужно понимать, как и почему работает код, и часто ему придется смириться с тем, что будет присутствовать определенное количество ошибок и глюков.
😁7🔥4❤1
Утечки системных промптов.
Если вы давно работаете в ИТ, то наверняка привыкли к разного рода утечкам: то база данных «уплывёт», то исходники окажутся в интернете. Потом весь рынок обсуждает: а что же там такого утекло у конкурентов на этот раз?
Но сегодня я наткнулся на нечто действительно особенное — репозиторий с системными промптами (инструкциями) для крупных языковых моделей:
Если объяснить просто — это своего рода конфигурационные инструкции, которые управляют поведением нейросервисов. Причём это не просто формальные правила, а полноценные «команды», определяющие базовое поведение ИИ, его ограничения и даже стиль ответов.
Смотреть такие «внутренности» особенно интересно: пусть что-то из этого быстро устаревает, но подобные утечки позволяют заглянуть под капот современных языковых моделей, понять, как инженеры настраивают их «двигатель», чтобы получать нужный результат.
Попадаются довольно любопытные примеры:
🔵 инструкции по цитированию: как правильно оформлять ссылки, когда давать короткие или развернутые цитаты, какой объём текста можно цитировать;
🔵 рекомендации по работе с конкретными вопросами — буквально захардкоженные ответы на определённые типы запросов;
🔵 этические ограничения и корпоративные нормы, которые задают границы допустимого поведения модели.
P. S. Когда поймаете себя на классическом «сопротивлении» мозговой работе — иногда полезно покопаться вот в таких штуках. Отлично помогает переключиться и вернуться к задачам с новыми мыслями!
Если вы давно работаете в ИТ, то наверняка привыкли к разного рода утечкам: то база данных «уплывёт», то исходники окажутся в интернете. Потом весь рынок обсуждает: а что же там такого утекло у конкурентов на этот раз?
Но сегодня я наткнулся на нечто действительно особенное — репозиторий с системными промптами (инструкциями) для крупных языковых моделей:
Если объяснить просто — это своего рода конфигурационные инструкции, которые управляют поведением нейросервисов. Причём это не просто формальные правила, а полноценные «команды», определяющие базовое поведение ИИ, его ограничения и даже стиль ответов.
Смотреть такие «внутренности» особенно интересно: пусть что-то из этого быстро устаревает, но подобные утечки позволяют заглянуть под капот современных языковых моделей, понять, как инженеры настраивают их «двигатель», чтобы получать нужный результат.
Попадаются довольно любопытные примеры:
P. S. Когда поймаете себя на классическом «сопротивлении» мозговой работе — иногда полезно покопаться вот в таких штуках. Отлично помогает переключиться и вернуться к задачам с новыми мыслями!
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2😁1🎉1
Хвост ценой в один цент.
Сегодня хочу поделиться с вами поучительной историей, которая косвенно связана с законом Гудхарта. Ранее мы обсуждали , что «Когда мера становится целью, она перестает быть хорошей мерой.»
Как только метрика становится целью, ее начинают сознательно или бессознательно искажать. Это может быть прямое манипулирование результатами (фальсификация), либо выполнение формальных требований без реального улучшения.
Думаю, многие знают, что крысы — те еще разносчики заразы. И контроль за популяцией значительно снижает риски больших эпидемий. Об этом знали очень давно. На рисунке французская индокитайская монета номиналом 1 цент 1902 года, которая предлагалась в качестве вознаграждения за крысиный хвост.
В 1902 году французское колониальное правительство в Ханое учредило программу вознаграждения за каждую убитую крысу. Чтобы получить вознаграждение, нужно было предоставить отрезанный крысиный хвост.
Однако колониальные чиновники начали замечать в Ханое крыс без хвостов. Вьетнамские крысоловы ловили крыс, отрезали им хвосты, а затем выпускали обратно в канализацию, чтобы они могли размножаться и производить на свет ещё больше крыс, тем самым увеличивая доход крысоловов.
Так с легкой руки чиновников полчища крыс наводнили Ханой, а кто-то на этом еще и заработал.
Сегодня хочу поделиться с вами поучительной историей, которая косвенно связана с законом Гудхарта. Ранее мы обсуждали , что «Когда мера становится целью, она перестает быть хорошей мерой.»
Как только метрика становится целью, ее начинают сознательно или бессознательно искажать. Это может быть прямое манипулирование результатами (фальсификация), либо выполнение формальных требований без реального улучшения.
Думаю, многие знают, что крысы — те еще разносчики заразы. И контроль за популяцией значительно снижает риски больших эпидемий. Об этом знали очень давно. На рисунке французская индокитайская монета номиналом 1 цент 1902 года, которая предлагалась в качестве вознаграждения за крысиный хвост.
В 1902 году французское колониальное правительство в Ханое учредило программу вознаграждения за каждую убитую крысу. Чтобы получить вознаграждение, нужно было предоставить отрезанный крысиный хвост.
Однако колониальные чиновники начали замечать в Ханое крыс без хвостов. Вьетнамские крысоловы ловили крыс, отрезали им хвосты, а затем выпускали обратно в канализацию, чтобы они могли размножаться и производить на свет ещё больше крыс, тем самым увеличивая доход крысоловов.
Так с легкой руки чиновников полчища крыс наводнили Ханой, а кто-то на этом еще и заработал.
👍9🔥3
Полезные привычки или как не сгореть на работе.
Пили кофе с коллегой из конкурирующей компании. Разговорились о том, как выгорание стало чуть ли не нормой в нашей индустрии. И тут он поделился интересным наблюдением — у него в команде те, кто придерживается определённых рабочих привычек, гораздо реже жалуются на истощение.
Набросали на салфетке три самых простых для внедрения в свою жизнь практик:
1. Правило двух минут.
Если задача занимает меньше двух минут — делаем сразу. Никаких «отложу на потом» или «запишу в список дел». Это снижает когнитивную нагрузку и не даёт накапливаться мелким делам.
2. Временные блоки.
День разбивается на чёткие интервалы по 25–30 минут с небольшими перерывами. В каждом блоке — только одна задача. Прям горжусь теми, кто реально этому следует, а не просто ставит помидорку для галочки.
3. Ритуал завершения рабочего дня.
Последние 15–30 минут рабочего дня — на подведение итогов и планирование следующего. Помогает «закрыть» рабочий день в голове и не тащить задачи домой.
Эти привычки работают прекрасно и в стабильных условиях, и во время постоянных «пожаров». Недостатки или проблемы в этих практиках, конечно, можно найти — возможно, в вашем контексте они не подойдут. Но суть не в слепом следовании, а в выработке своей системы. Регулярность и осознанность. Хотя по первости от внедрения этих практик чувствуешь, что работа тебя аж выжимает.
А какие рабочие привычки помогают вам оставаться в ресурсе?
Пили кофе с коллегой из конкурирующей компании. Разговорились о том, как выгорание стало чуть ли не нормой в нашей индустрии. И тут он поделился интересным наблюдением — у него в команде те, кто придерживается определённых рабочих привычек, гораздо реже жалуются на истощение.
Набросали на салфетке три самых простых для внедрения в свою жизнь практик:
1. Правило двух минут.
Если задача занимает меньше двух минут — делаем сразу. Никаких «отложу на потом» или «запишу в список дел». Это снижает когнитивную нагрузку и не даёт накапливаться мелким делам.
2. Временные блоки.
День разбивается на чёткие интервалы по 25–30 минут с небольшими перерывами. В каждом блоке — только одна задача. Прям горжусь теми, кто реально этому следует, а не просто ставит помидорку для галочки.
3. Ритуал завершения рабочего дня.
Последние 15–30 минут рабочего дня — на подведение итогов и планирование следующего. Помогает «закрыть» рабочий день в голове и не тащить задачи домой.
Эти привычки работают прекрасно и в стабильных условиях, и во время постоянных «пожаров». Недостатки или проблемы в этих практиках, конечно, можно найти — возможно, в вашем контексте они не подойдут. Но суть не в слепом следовании, а в выработке своей системы. Регулярность и осознанность. Хотя по первости от внедрения этих практик чувствуешь, что работа тебя аж выжимает.
А какие рабочие привычки помогают вам оставаться в ресурсе?
👍19🔥1
This media is not supported in your browser
VIEW IN TELEGRAM
❤4💯2👍1
An Intro to DeepSeek's Distributed File System.
Новинку из мира open source подкинул Алексей — 3FS (Fire-Flyer File System), распределённая файловая система, выпущенная DeepSeek.
Меня зацепило описание CRAQ — протокола для обеспечения строгой согласованности и отказоустойчивости данных. Для тех, кто хочет покопаться в деталях, есть отличная статья с описанием архитектуры и результатами тестирования производительности.
Читать полезняшки от «Разбора Полетов».
Новинку из мира open source подкинул Алексей — 3FS (Fire-Flyer File System), распределённая файловая система, выпущенная DeepSeek.
Меня зацепило описание CRAQ — протокола для обеспечения строгой согласованности и отказоустойчивости данных. Для тех, кто хочет покопаться в деталях, есть отличная статья с описанием архитектуры и результатами тестирования производительности.
Читать полезняшки от «Разбора Полетов».
👍3