Не всё ли равно, что думают другие? (What Do You Care What Other People Think?) (Рубрика #Science)
Я люблю читать книги за авторством Фейнмана, а этот сборник автобиографических историй понравился мне особо. Возможно, это обусловлено названием, в которое вынесен риторический вопрос:) Кстати, я ее прикупил в прошлое посещение Физтеха:)
Если говорить про саму книгу, то она состоит из двух больших частей
1. «Пытливый характер» - тёплые и местами очень личные истории о человеке и учёном: отец и его уроки любознательности, первая любовь и жена Арлин (именно её фраза дала книге название), радость открытия и пр. В русскоязычных изданиях эта часть так и обозначена; в конце помещена речь Фейнмана «Ценность науки».
2. «Мистер Фейнман едет в Вашингтон» - хроника работы в комиссии Роджерса по расследованию катастрофы «Челленджера» (1986): от уличного эксперимента с резиновым O‑ring в стакане со льдом до анализа культуры безопасности и честности в отчётности. В книгу включён и его знаменитый Аппендикс F к отчёту комиссии.
Если говорить про основные идеи книги, то они такие
1. Независимость мышления. Тут мысль про то, что не стоит не позволять чужим ожиданиям подменять собственное мышление и ценности (история Арлин).
2. Реальность важнее статуса и PR. В деле «Челленджера» Фейнман болезненно показывает разрыв между тем, как вещи устроены на самом деле, и тем, как об этом говорят. Его финальная фраза из Аппендикса F стала девизом инженерной честности:
3. Честная оценка риска. Фейнман сопоставляет инженерные оценки вероятности отказа (порядка 1 к 100) с "верой‑в‑совершенство" у менеджмента (1 к 100 000) и объясняет, почему такая пропасть опасна. В общем, тут про правильный риск менеджмент
4. Думать руками. Простые наглядные эксперименты (как с охлаждённым O‑ring) порой важнее многословных совещаний: правильно поставленный эксперимент делает проблему очевидной для всех. Тут видно, что нужна связь между инженинирингом и менеджментом - когда она теряется, то презентации и отчеты скрывают от людей в высоких кабинетах реальность:)
5. «Ценность науки». Наука - это не каталог истин, а культура сомнения, проверяемости и интеллектуальной честности. Эта речь замыкает книгу и резюмирует этический стержень Фейнмана.
Кажется, что эта книга как никогда актуальна во времена AI-хайпа и снижения критичности мышления у тех, кто слишком доверяет AI-инструментам, а также верит в надежность и безопасность, но не проверяет это на практике:)
P.S.
Книга отправилась в букшеринговый уголок, что у нас есть в нашем офисе - надеюсь, что она найдет новых читателей и поможет им оценить научный подход.
#Science #Engineering #Brain #Thinking #PopularScience #Physics
Я люблю читать книги за авторством Фейнмана, а этот сборник автобиографических историй понравился мне особо. Возможно, это обусловлено названием, в которое вынесен риторический вопрос:) Кстати, я ее прикупил в прошлое посещение Физтеха:)
Если говорить про саму книгу, то она состоит из двух больших частей
1. «Пытливый характер» - тёплые и местами очень личные истории о человеке и учёном: отец и его уроки любознательности, первая любовь и жена Арлин (именно её фраза дала книге название), радость открытия и пр. В русскоязычных изданиях эта часть так и обозначена; в конце помещена речь Фейнмана «Ценность науки».
2. «Мистер Фейнман едет в Вашингтон» - хроника работы в комиссии Роджерса по расследованию катастрофы «Челленджера» (1986): от уличного эксперимента с резиновым O‑ring в стакане со льдом до анализа культуры безопасности и честности в отчётности. В книгу включён и его знаменитый Аппендикс F к отчёту комиссии.
Если говорить про основные идеи книги, то они такие
1. Независимость мышления. Тут мысль про то, что не стоит не позволять чужим ожиданиям подменять собственное мышление и ценности (история Арлин).
2. Реальность важнее статуса и PR. В деле «Челленджера» Фейнман болезненно показывает разрыв между тем, как вещи устроены на самом деле, и тем, как об этом говорят. Его финальная фраза из Аппендикса F стала девизом инженерной честности:
Для успеха технологии реальность должна преобладать над пиаром, потому что природу не обманешь
3. Честная оценка риска. Фейнман сопоставляет инженерные оценки вероятности отказа (порядка 1 к 100) с "верой‑в‑совершенство" у менеджмента (1 к 100 000) и объясняет, почему такая пропасть опасна. В общем, тут про правильный риск менеджмент
4. Думать руками. Простые наглядные эксперименты (как с охлаждённым O‑ring) порой важнее многословных совещаний: правильно поставленный эксперимент делает проблему очевидной для всех. Тут видно, что нужна связь между инженинирингом и менеджментом - когда она теряется, то презентации и отчеты скрывают от людей в высоких кабинетах реальность:)
5. «Ценность науки». Наука - это не каталог истин, а культура сомнения, проверяемости и интеллектуальной честности. Эта речь замыкает книгу и резюмирует этический стержень Фейнмана.
Кажется, что эта книга как никогда актуальна во времена AI-хайпа и снижения критичности мышления у тех, кто слишком доверяет AI-инструментам, а также верит в надежность и безопасность, но не проверяет это на практике:)
P.S.
Книга отправилась в букшеринговый уголок, что у нас есть в нашем офисе - надеюсь, что она найдет новых читателей и поможет им оценить научный подход.
#Science #Engineering #Brain #Thinking #PopularScience #Physics
Telegram
Книжный куб
По традиции при посещении МФТИ зашел в книжный магазин и не смог выйти без покупок - купил пачку книг Фейнмана
- Фейнмановские лекции по физике. Современная наука о природе (The Feynman Lectures on Physics. The New Millenium Edition (1-7))
- Радость познания…
- Фейнмановские лекции по физике. Современная наука о природе (The Feynman Lectures on Physics. The New Millenium Edition (1-7))
- Радость познания…
🔥11❤7👍3
Code of Leadership #54 - Interview with Maxim Korobov about management and mobile development (Рубрика #Management)
Интервью с Максимом Коробовым, моим коллегой и техническим директором управления клиентских интерфейсов, который в Т отвечает за платформенные части мобильного банка, веба и API. Мы обсудили с Максимом его карьеру и как движение по ней было переплетено с развитием мобильных технологий и работой в Т-Банке. А вообще мы обсудили следующие темы
- Введение и знакомство с Максимом Коробовым
- Образование и первые шаги в IT
- Первая работа и опыт с мобильными приложениями
- Переход в новую компанию и роль тим-лида
- Выбор технологий и вызовы стартапа
- Переход в Тинькофф и старт мобильной разработки
- Организация процессов и первые изменения в компании
- Развитие мобильного кошелька и стратегия 2015 года
- Инвестиции и рост мобильных технологий
- Безрелизная разработка и генераторы форм
- Качество, удобство и кросс-платформенные решения
- Экстенсивный рост и трансформация 2020 года
- Управление трансформацией и новые роли
- Санкции, ренессанс веба и эволюция интерфейсов
- Гибридный формат, личное стратегирование, будущее технологий
- Советы для слушателей
Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music.
#Software #Engineering #Management #Career #Leadership #Architecture
Интервью с Максимом Коробовым, моим коллегой и техническим директором управления клиентских интерфейсов, который в Т отвечает за платформенные части мобильного банка, веба и API. Мы обсудили с Максимом его карьеру и как движение по ней было переплетено с развитием мобильных технологий и работой в Т-Банке. А вообще мы обсудили следующие темы
- Введение и знакомство с Максимом Коробовым
- Образование и первые шаги в IT
- Первая работа и опыт с мобильными приложениями
- Переход в новую компанию и роль тим-лида
- Выбор технологий и вызовы стартапа
- Переход в Тинькофф и старт мобильной разработки
- Организация процессов и первые изменения в компании
- Развитие мобильного кошелька и стратегия 2015 года
- Инвестиции и рост мобильных технологий
- Безрелизная разработка и генераторы форм
- Качество, удобство и кросс-платформенные решения
- Экстенсивный рост и трансформация 2020 года
- Управление трансформацией и новые роли
- Санкции, ренессанс веба и эволюция интерфейсов
- Гибридный формат, личное стратегирование, будущее технологий
- Советы для слушателей
Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music.
#Software #Engineering #Management #Career #Leadership #Architecture
YouTube
Code of Leadership #54 - Interview with Maxim Korobov about management and mobile development
Интервью с Максимом Коробовым, моим коллегой и техническим директором управления клиентских интерфейсов, который в Т отвечает за платформенные части мобильного банка, веба и API. Мы обсудили с Максимом его карьеру и как движение по ней было переплетено с…
❤6👍2🔥2
Flexible work update (Рубрика #Management)
Недавно Microsoft объявила об обновлении политики гибридной работы: ожидается присутствие сотрудников в офисе не менее трёх дней в неделю. Это решение изложено в письме за авторством Эми Коулман, исполнительного вице-президента и директора по персоналу Microsoft. Аргументами стало то, что в эпоху AI личное общение повышает энергию, инновации и эффективность команд, поэтому компании важно чаще собирать людей вместе офлайн. Новый стандарт будет раскатываться постепенно, начиная со штаб-квартиры в Сиэтле, дальше по США, а потом и по всему миру. Отдельно подчеркивается, что это не про сокращение штата, а про улучшение совместной работы.
После этой новости мне стало интересно чекнуть, а как дела с политикой RTO (return to office) у других бигтех компаний и выяснилось примерно следующее
- Google с весны 2022 года ввёл гибридный режим, который был относительно мягким. Но в июне 2023 Google разослал сотрудникам внутренние меморандумы, сообщив, что отныне офисная посещаемость (3/5 дней в офисе) будет отслеживаться (через пропускные бейджи) и учитываться при оценке эффективности работы. В апреле 2025 г. сообщалось, что Google требует от ряда полностью дистанционных работников вернуться в офис, иначе их роли могут попасть под сокращение в рамках оптимизации затрат. Сейчас в Google 3/5 дней надо проводить в офисе.
- Запрещенная в России компания Meta в первые пандемийные годы поощрала удаленку. А в сентябре 2023 Meta официально обновила политику: всем офисным сотрудникам предписано работать из офиса минимум три дня в неделю - ставка была на личное взаимодействие для повышения культуры и «эффективности» в их «год эффективности».
- Amazon традиционно до пандемии культивировала офисную культуру, но в 2020–2021 гг. также была вынуждена перейти на удалёнку для офисных сотрудников. В начале 2023 года генеральный директор Энди Джасси разослал меморандум, где объявил, что офисное присутствие необходимо для укрепления культуры и эффективного сотрудничества. В феврале 2023 г. Amazon официально потребовала от сотрудников присутствовать в офисе не менее 3 дней в неделю, начиная с 1 мая 2023. В сентябре 2024 г. Энди Джасси выпустил новое обращение к персоналу, где заявил, что компания «возвращается к офисному режиму работы, как до COVID», то есть к 5/5 дней в офисе:)
Если смотреть на другие компании, то аналогичные шаги сделали Apple (с 2022 - 3 дня в офисе, несмотря на протесты сотрудников), IBM (для менеджеров - либо 3 дня в офисе, либо увольнение), Salesforce (с 2024 отдельные категории сотрудников должны быть на месте 4-5 дней), Dell (в 2025 вовсе отменила гибридность, вернув всех, кто живёт рядом, на 5/5 график) и многие другие. То есть, Big Tech и крупный бизнес в целом двигаются к схеме, где удалёнка уступает место гибридному или полностью офисному формату. Можно ожидать, что в течение ближайших пары лет все крупнейшие корпорации унифицируют свои политики примерно до одного стандарта, а пандемийный эксперимент с тотальной удалёнкой фактически уже завершён - компании считают, что он себя исчерпал и несёт больше рисков (для культуры, обучения молодых сотрудников, творчества), чем плюсов.
Причин для этого решения видится две:
1. Руководители действительно рассчитывают поднять продуктивность оставшихся работников: мол, теперь нужно делать больше меньшим составом, а для этого людей надо собрать вместе и мотивировать, исключив расслабленность удалёнки.
2. Негласно RTO подталкивает к естественному оттоку тех, кого компания, возможно, и так считала лишними. Как указывалось выше, жёсткие требования могут привести к тому, что часть сотрудников сами уволятся (по семейным обстоятельствам, из-за релокации, нежелания менять образ жизни).
В общем, мне кажется, что эта тендеция не ограничивается рынком США и имеет место быть для крупных компаний в других локациях. Так что удаленка - это конечно хорошо, но гибрид лучше, а оптимум - это работа из офиса:)
#Software #Engineering
Недавно Microsoft объявила об обновлении политики гибридной работы: ожидается присутствие сотрудников в офисе не менее трёх дней в неделю. Это решение изложено в письме за авторством Эми Коулман, исполнительного вице-президента и директора по персоналу Microsoft. Аргументами стало то, что в эпоху AI личное общение повышает энергию, инновации и эффективность команд, поэтому компании важно чаще собирать людей вместе офлайн. Новый стандарт будет раскатываться постепенно, начиная со штаб-квартиры в Сиэтле, дальше по США, а потом и по всему миру. Отдельно подчеркивается, что это не про сокращение штата, а про улучшение совместной работы.
После этой новости мне стало интересно чекнуть, а как дела с политикой RTO (return to office) у других бигтех компаний и выяснилось примерно следующее
- Google с весны 2022 года ввёл гибридный режим, который был относительно мягким. Но в июне 2023 Google разослал сотрудникам внутренние меморандумы, сообщив, что отныне офисная посещаемость (3/5 дней в офисе) будет отслеживаться (через пропускные бейджи) и учитываться при оценке эффективности работы. В апреле 2025 г. сообщалось, что Google требует от ряда полностью дистанционных работников вернуться в офис, иначе их роли могут попасть под сокращение в рамках оптимизации затрат. Сейчас в Google 3/5 дней надо проводить в офисе.
- Запрещенная в России компания Meta в первые пандемийные годы поощрала удаленку. А в сентябре 2023 Meta официально обновила политику: всем офисным сотрудникам предписано работать из офиса минимум три дня в неделю - ставка была на личное взаимодействие для повышения культуры и «эффективности» в их «год эффективности».
- Amazon традиционно до пандемии культивировала офисную культуру, но в 2020–2021 гг. также была вынуждена перейти на удалёнку для офисных сотрудников. В начале 2023 года генеральный директор Энди Джасси разослал меморандум, где объявил, что офисное присутствие необходимо для укрепления культуры и эффективного сотрудничества. В феврале 2023 г. Amazon официально потребовала от сотрудников присутствовать в офисе не менее 3 дней в неделю, начиная с 1 мая 2023. В сентябре 2024 г. Энди Джасси выпустил новое обращение к персоналу, где заявил, что компания «возвращается к офисному режиму работы, как до COVID», то есть к 5/5 дней в офисе:)
Если смотреть на другие компании, то аналогичные шаги сделали Apple (с 2022 - 3 дня в офисе, несмотря на протесты сотрудников), IBM (для менеджеров - либо 3 дня в офисе, либо увольнение), Salesforce (с 2024 отдельные категории сотрудников должны быть на месте 4-5 дней), Dell (в 2025 вовсе отменила гибридность, вернув всех, кто живёт рядом, на 5/5 график) и многие другие. То есть, Big Tech и крупный бизнес в целом двигаются к схеме, где удалёнка уступает место гибридному или полностью офисному формату. Можно ожидать, что в течение ближайших пары лет все крупнейшие корпорации унифицируют свои политики примерно до одного стандарта, а пандемийный эксперимент с тотальной удалёнкой фактически уже завершён - компании считают, что он себя исчерпал и несёт больше рисков (для культуры, обучения молодых сотрудников, творчества), чем плюсов.
Причин для этого решения видится две:
1. Руководители действительно рассчитывают поднять продуктивность оставшихся работников: мол, теперь нужно делать больше меньшим составом, а для этого людей надо собрать вместе и мотивировать, исключив расслабленность удалёнки.
2. Негласно RTO подталкивает к естественному оттоку тех, кого компания, возможно, и так считала лишними. Как указывалось выше, жёсткие требования могут привести к тому, что часть сотрудников сами уволятся (по семейным обстоятельствам, из-за релокации, нежелания менять образ жизни).
В общем, мне кажется, что эта тендеция не ограничивается рынком США и имеет место быть для крупных компаний в других локациях. Так что удаленка - это конечно хорошо, но гибрид лучше, а оптимум - это работа из офиса:)
#Software #Engineering
The Official Microsoft Blog
Flexible work update
Amy Coleman, Executive Vice President and Chief People Officer, shared the below communication with Microsoft employees this morning. How we work has forever changed. I remember starting at Microsoft in the late ‘90s, always in the office, no laptops, and…
👎17👍8❤5🗿2👻1
Большое исследование AI в инженерной культуре России (Рубрика #AI)
Мы в Т-Банке активно работаем над созданием AI экосистемы инструментов для наших разработчиков, которые помогают нам эффективнее создавать продукты для клиентов. Мы много рассказываем про это конференциях для разработчиков, а в пятничной мега-конференции BigTechNight весь трек Т-Банка был посвящен этой теме. И именно в пятницу мой коллега Станислав Моисеев рассказывал доклад про измерение продуктивности на уровне человека / команды / компании / целой индустрии. И если первый три уровня мы измерять умеем, то последний требует отдельного подхода. И Стас анонсировал старт большого исследования AI в инженерной культуре российских компаний.
Мы решили провести такой опрос для того, чтобы
- Получить актуальные данные о том, как AI‑решения применяют в России. Пока есть информация только о международных практиках, но к российскому рынку это почти неприменимо
- Отделить хайп от реального эффекта. Многие компании экспериментируют с AI, но не всегда ясно, помогает ли это повысить продуктивность и качество. Исследование поможет измерить реальные результаты;
- Понять, как AI влияет на бизнес‑результаты. Например, на пользовательский опыт и удержание сотрудников;
- Помочь компаниям и инженерам. Компаниям - понять, где они находятся в контексте рынка и какие AI‑решения правда работают, а инженерам - оценить, насколько их опыт совпадает с опытом коллег.
Мы ожидаем, что в опросе поучаствуют
- Инженеры и технические специалисты: разработчики, DevOps/SRE, инженеры данных, QA‑инженеры, специалисты по ML и AI;
- Технические лиды и менеджеры: тимлиды, Engineering Managers, руководители групп разработки;
- Руководители и топ‑менеджеры: CTO, Heads of Engineering, директоры по продукту.
Если вы хотите поучаствовать в опросе, то вот ссылка на его прохождение (ориентировочно, опрос занимает полчаса), сам опрос закончится в конце ноября, а результатами мы поделися в конце января или начале февраля следующего года. На выходе будет большой отчет + описание методологии, которое базируется на подходе DORA (про этот подход я рассказывал в деталях и не раз: 1, 2, 3, 4, 5).
P.S.
Я отвечаю за методологию этого исследования и подведение итогов, поэтому я очень заинтересован в большом охвате исследования. И если вы не только пройдете сам опрос, но и скинете ссылку на него своим друзьям и коллегам, то я буду вам очень благодарен.
#AI #Software #Engineering #Management #RnD #Leadership #Data
Мы в Т-Банке активно работаем над созданием AI экосистемы инструментов для наших разработчиков, которые помогают нам эффективнее создавать продукты для клиентов. Мы много рассказываем про это конференциях для разработчиков, а в пятничной мега-конференции BigTechNight весь трек Т-Банка был посвящен этой теме. И именно в пятницу мой коллега Станислав Моисеев рассказывал доклад про измерение продуктивности на уровне человека / команды / компании / целой индустрии. И если первый три уровня мы измерять умеем, то последний требует отдельного подхода. И Стас анонсировал старт большого исследования AI в инженерной культуре российских компаний.
Мы решили провести такой опрос для того, чтобы
- Получить актуальные данные о том, как AI‑решения применяют в России. Пока есть информация только о международных практиках, но к российскому рынку это почти неприменимо
- Отделить хайп от реального эффекта. Многие компании экспериментируют с AI, но не всегда ясно, помогает ли это повысить продуктивность и качество. Исследование поможет измерить реальные результаты;
- Понять, как AI влияет на бизнес‑результаты. Например, на пользовательский опыт и удержание сотрудников;
- Помочь компаниям и инженерам. Компаниям - понять, где они находятся в контексте рынка и какие AI‑решения правда работают, а инженерам - оценить, насколько их опыт совпадает с опытом коллег.
Мы ожидаем, что в опросе поучаствуют
- Инженеры и технические специалисты: разработчики, DevOps/SRE, инженеры данных, QA‑инженеры, специалисты по ML и AI;
- Технические лиды и менеджеры: тимлиды, Engineering Managers, руководители групп разработки;
- Руководители и топ‑менеджеры: CTO, Heads of Engineering, директоры по продукту.
Если вы хотите поучаствовать в опросе, то вот ссылка на его прохождение (ориентировочно, опрос занимает полчаса), сам опрос закончится в конце ноября, а результатами мы поделися в конце января или начале февраля следующего года. На выходе будет большой отчет + описание методологии, которое базируется на подходе DORA (про этот подход я рассказывал в деталях и не раз: 1, 2, 3, 4, 5).
P.S.
Я отвечаю за методологию этого исследования и подведение итогов, поэтому я очень заинтересован в большом охвате исследования. И если вы не только пройдете сам опрос, но и скинете ссылку на него своим друзьям и коллегам, то я буду вам очень благодарен.
#AI #Software #Engineering #Management #RnD #Leadership #Data
🔥19❤5😁3🍌2⚡1🏆1
Релиз мобильного Т-Банка на iOS с оплатой по bluetooth:)
Forwarded from Т-Банк
This media is not supported in your browser
VIEW IN TELEGRAM
Запустили T-Pay на iPhone и вернули бесконтактную оплату на смартфоны Apple ⚡
Сервис работает на технологии Bluetooth Low Energy и совместим с технологией оплаты iPhone от Сбера. Для покупки достаточно поднести смартфон к терминалу. Кэшбэк и мили начислим так же, как при оплате картой.
Рассказываем, как подготовить iPhone к оплате с T-Pay:
1️⃣ Скачайте и установите актуальную версию нашего приложения. Его могут удалить из App Store в любой момент, поэтому лучше обновиться прямо сейчас. У приложения могут быть разные названия, так и задумано. Главное — скачивать по официальной ссылке.
2️⃣ Убедитесь, что ваш смартфон подключен к интернету и работает на iOS 16 или новее, а версия приложения Т-Банка — 7.19 и выше.
3️⃣ Проверьте, что у вас подключен Bluetooth, затем настройте его. Для этого зайдите в настройки iPhone: «Конфиденциальность и безопасность» → Bluetooth → разрешите доступ приложению Т-Банка.
4️⃣ Если при оплате автоматически открывается Apple Pay, рекомендуем увеличить расстояние между смартфоном и терминалом либо удалить карты из Wallet, чтобы использовать именно T-Pay.
➡️ Скачать приложение: https://t.tb.ru/ble_smm
❤️ — если скучали по бесконтактным покупкам
Сервис работает на технологии Bluetooth Low Energy и совместим с технологией оплаты iPhone от Сбера. Для покупки достаточно поднести смартфон к терминалу. Кэшбэк и мили начислим так же, как при оплате картой.
Рассказываем, как подготовить iPhone к оплате с T-Pay:
❤️ — если скучали по бесконтактным покупкам
Please open Telegram to view this post
VIEW IN TELEGRAM
❤12🔥8🗿4👍3
Code of Leadership #55 Interview with Alexey Kashin about management, architecture & reliability (Рубрика #Leadership)
Интервью с Алексеем Кашиным, моим коллегой, который в Т-Банке руководит направлением разработки сервисов неклиентских профилей в нашей платформе профилей. Интересно, что параллельно этому Леша выполняет роль chief reliability officer, главного за надежность в той же profiles platform. За полтора часа мы обсудили множество тем
- Вступление и текущая роль (платформа профайлов)
- Ранние годы и первые шаги в программировании
- Вуз: поступление, SQL/БД, диплом
- Старт карьеры: финуправление и администрирование
- Внедрение документооборота: процессы, обучение, модель работы
- Переход к руководству и запуск BPM-направления (стоимость, импортозамещение, Java)
- Первый продукт на новой платформе; смена стека и переход в другую компанию
- Формат работы и инфраструктура; проблемы многопоточности и зависаний
- Рост команды и обучение; «единая кредитная заявка» и финмаркетплейс
- Платформа и технические улучшения; переход в Тинькофф и реинжиниринг CRM
- Архитектура домена компаний и бесшовная миграция (репликация, Kafka, сверка данных)
- Инструменты и надёжность: инциденты, метрики, шардирование/кастом БД, миграции
- Инженер vs менеджер, распределёнка и роль офисов
- Work/liffe баланс и советы слушателям
Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music.
#Software #Engineering #Management #Career #Leadership #Architecture #Reliability
Интервью с Алексеем Кашиным, моим коллегой, который в Т-Банке руководит направлением разработки сервисов неклиентских профилей в нашей платформе профилей. Интересно, что параллельно этому Леша выполняет роль chief reliability officer, главного за надежность в той же profiles platform. За полтора часа мы обсудили множество тем
- Вступление и текущая роль (платформа профайлов)
- Ранние годы и первые шаги в программировании
- Вуз: поступление, SQL/БД, диплом
- Старт карьеры: финуправление и администрирование
- Внедрение документооборота: процессы, обучение, модель работы
- Переход к руководству и запуск BPM-направления (стоимость, импортозамещение, Java)
- Первый продукт на новой платформе; смена стека и переход в другую компанию
- Формат работы и инфраструктура; проблемы многопоточности и зависаний
- Рост команды и обучение; «единая кредитная заявка» и финмаркетплейс
- Платформа и технические улучшения; переход в Тинькофф и реинжиниринг CRM
- Архитектура домена компаний и бесшовная миграция (репликация, Kafka, сверка данных)
- Инструменты и надёжность: инциденты, метрики, шардирование/кастом БД, миграции
- Инженер vs менеджер, распределёнка и роль офисов
- Work/liffe баланс и советы слушателям
Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music.
#Software #Engineering #Management #Career #Leadership #Architecture #Reliability
YouTube
Code of Leadership #55 Interview with Alexey Kashin about management, architecture & reliability
Интервью с Алексеем Кашиным, моим коллегой, который в Т-Банке руководит направлением разработки сервисов неклиентских профилей в нашей платформе профилей. Интересно, что параллельно этому Леша выполняет роль chief reliability officer, главного за надежность…
❤3👍3🔥2
Как измерять продуктивность инженеров на разных уровнях (Рубрика #DevEx)
Появилась запись выступления Станислава Моисеева, директора R&D‑центра Т‑Банка с Big Tech Night. В этом докладе Стас делает обзор лучших практик последних лет и связывает их с волной GenAI‑инструментов. За 5 лет ландшафт сильно изменился: ковид → удалёнка → внедрение AI. Компании инвестируют в ИИ‑инструменты для разработки, но без измерений сложно доказать ROI. Доклад показывает, какие метрики и на каком уровне отвечают на вопрос «что реально ускоряет поставку ценности», и упоминает методологию индустриального опроса 2025 для оценки влияния GenAI на разработку.
Если говорить про уровни, то они такие IC (индивидуальные контрибьюторы) -> команды -> компании -> индустрия целиком. И работает это так
- IC (индивидуальный инженер): следить стоит не за «строками кода», а за временем потока (сколько часов без переключений), cycle time своего PR, долей переделок/rollback’ов, качеством ревью. Это помогает видеть, как инструменты (IDE‑плагины, ассистенты, автотесты) влияют на вашу личную скорость и аккуратность. Осмысленный набор метрик хорошо описывается рамкой SPACE (удовлетворённость, performance, activity, communication, efficiency).
- Команда: классический набор DORA (частота деплоев, lead time for changes, доля неудачных изменений, MTTR) + операционные метрики потока: WIP, размер PR, доля «ожидания» vs «работы», стабильность спринтов. Эти показатели коррелируют с предсказуемостью поставки и качеством.
- Компания: здесь важны сквозные метрики: cost‑per‑change, time‑to‑value, скорость онбординга, покрытие автотестами критичных путей, утилизация платных AI‑мощностей на разработку vs «игрушки», экономия инженерных часов от ассистентов. Цель - связать инженерные метрики с P&L: сколько стоил прирост скорости и как он отразился на бизнесе.
- Индустрия: бенчмарки и сравнительные опросы. В докладе заявлен подход к индустриальному исследованию 2025 года по влиянию GenAI — чтобы компании могли соотнести свои практики с «средней температурой по цеху» и отделить хайп от эффекта (я уже рассказывал про это исследование раньше)
Если говорить про то, на что обратить внимание при использовании метрик, то
- Не стоит использовать анти‑метрики: «строки кода», «количество задач», «скорость закрытия багов» без контекста. Они легко геймитсятся и толкают к плохим решениям.
- Не используйте метрики без обратной связи: любой график должен вести к конкретному решению процесса или инструмента.
- Не мерьте температуру «среднюю по больнице»: сравнивайте себя со своей историей (тренды), а не с соседним отделом с другим контекстом или на другой архитектуре.
#Software #Engineering #Productivity #DevEx #AI #Management #RnD #Leadership
Появилась запись выступления Станислава Моисеева, директора R&D‑центра Т‑Банка с Big Tech Night. В этом докладе Стас делает обзор лучших практик последних лет и связывает их с волной GenAI‑инструментов. За 5 лет ландшафт сильно изменился: ковид → удалёнка → внедрение AI. Компании инвестируют в ИИ‑инструменты для разработки, но без измерений сложно доказать ROI. Доклад показывает, какие метрики и на каком уровне отвечают на вопрос «что реально ускоряет поставку ценности», и упоминает методологию индустриального опроса 2025 для оценки влияния GenAI на разработку.
Если говорить про уровни, то они такие IC (индивидуальные контрибьюторы) -> команды -> компании -> индустрия целиком. И работает это так
- IC (индивидуальный инженер): следить стоит не за «строками кода», а за временем потока (сколько часов без переключений), cycle time своего PR, долей переделок/rollback’ов, качеством ревью. Это помогает видеть, как инструменты (IDE‑плагины, ассистенты, автотесты) влияют на вашу личную скорость и аккуратность. Осмысленный набор метрик хорошо описывается рамкой SPACE (удовлетворённость, performance, activity, communication, efficiency).
- Команда: классический набор DORA (частота деплоев, lead time for changes, доля неудачных изменений, MTTR) + операционные метрики потока: WIP, размер PR, доля «ожидания» vs «работы», стабильность спринтов. Эти показатели коррелируют с предсказуемостью поставки и качеством.
- Компания: здесь важны сквозные метрики: cost‑per‑change, time‑to‑value, скорость онбординга, покрытие автотестами критичных путей, утилизация платных AI‑мощностей на разработку vs «игрушки», экономия инженерных часов от ассистентов. Цель - связать инженерные метрики с P&L: сколько стоил прирост скорости и как он отразился на бизнесе.
- Индустрия: бенчмарки и сравнительные опросы. В докладе заявлен подход к индустриальному исследованию 2025 года по влиянию GenAI — чтобы компании могли соотнести свои практики с «средней температурой по цеху» и отделить хайп от эффекта (я уже рассказывал про это исследование раньше)
Если говорить про то, на что обратить внимание при использовании метрик, то
- Не стоит использовать анти‑метрики: «строки кода», «количество задач», «скорость закрытия багов» без контекста. Они легко геймитсятся и толкают к плохим решениям.
- Не используйте метрики без обратной связи: любой график должен вести к конкретному решению процесса или инструмента.
- Не мерьте температуру «среднюю по больнице»: сравнивайте себя со своей историей (тренды), а не с соседним отделом с другим контекстом или на другой архитектуре.
#Software #Engineering #Productivity #DevEx #AI #Management #RnD #Leadership
YouTube
Станислав Моисеев — «Как измерять продуктивность инженеров на разных уровнях»
Тема эффективности в последние 5 лет всегда была на слуху в технологических компаниях — сначала из-за COVID, потом из-за удаленки, потом из-за взлета AI и интеграции его в разработку. В докладе расскажу про разные подходы к эффективности на уровне IC (Individual…
❤17🔥12👍7
Библиотеки
Прикольно, что в парке на Ходынке сделали библиотеку. Забавно, что в нее я хожу со своими книгами:) Но сама идея - топ. Правда, я все равно предпочитаю читать книги, гуляя по парку, а не сидя в библиотеке. Вот дочитываю книгу Гергели Ороша, про котрую писал уже раньше
Прикольно, что в парке на Ходынке сделали библиотеку. Забавно, что в нее я хожу со своими книгами:) Но сама идея - топ. Правда, я все равно предпочитаю читать книги, гуляя по парку, а не сидя в библиотеке. Вот дочитываю книгу Гергели Ороша, про котрую писал уже раньше
❤12👍11🔥8
AI в SDLC: от ассистентов к агентам
3 октября на конференции AI Boost я буду выступать с таким докладом. Саму конференцию про реальное ускорение разработки с помощью AI организовали ребята из Surf и где-то месяц назад они предложили мне выступить с продолжением моего доклада "Интегрируем AI в процессы разработки в большой компании", который я рассказывал летом на CTO Conf.
В новом докладе я планирую поговорить про переход от режима AI-«ассистентов» (GitHub Copilot, Cursor и др.) к агентному подходу - когда автономные ИИ-агенты становятся полноценными участниками SDLC и взаимодействуют между собой. Будут затронуты следующе темы
1. Почему про это так много говорят - экономические предпосылки и эффект на workforce
2. Почему для эффективности AI-агентов критически важны чёткая постановка задач и знание контекста проекта
3. Как роль инженера смещается в сторону тимлида команды AI-агентов и какие для этого требуются навыки и образ мышления
4. Как мы дошли до жизни такой и какие агентские инструменты появились или засияли в 2025 году (Claude Code, OpenAI Codex, ...)
5. Как мы создали свой агентский режим для разработки и как он себя показывает на наших сценариях
6. Как это связано с модным "вайб-кодингом", где новым многообещающим языком программирования видят ... английский
Если вам нравится эта тема, то покупайте билеты на конференцию и приходите слушать и задавать вопросы. А если вам интересно общее состояние дел о том, как AI влияет на инженерную культуру, то предлагаю пройти опрос от Т-Банка на эту тему. О чем этот опрос и почему его результаты будут интересными я уже рассказывал раньше.
#AI #Engineering #Software #Management #ML #DevEx
3 октября на конференции AI Boost я буду выступать с таким докладом. Саму конференцию про реальное ускорение разработки с помощью AI организовали ребята из Surf и где-то месяц назад они предложили мне выступить с продолжением моего доклада "Интегрируем AI в процессы разработки в большой компании", который я рассказывал летом на CTO Conf.
В новом докладе я планирую поговорить про переход от режима AI-«ассистентов» (GitHub Copilot, Cursor и др.) к агентному подходу - когда автономные ИИ-агенты становятся полноценными участниками SDLC и взаимодействуют между собой. Будут затронуты следующе темы
1. Почему про это так много говорят - экономические предпосылки и эффект на workforce
2. Почему для эффективности AI-агентов критически важны чёткая постановка задач и знание контекста проекта
3. Как роль инженера смещается в сторону тимлида команды AI-агентов и какие для этого требуются навыки и образ мышления
4. Как мы дошли до жизни такой и какие агентские инструменты появились или засияли в 2025 году (Claude Code, OpenAI Codex, ...)
5. Как мы создали свой агентский режим для разработки и как он себя показывает на наших сценариях
6. Как это связано с модным "вайб-кодингом", где новым многообещающим языком программирования видят ... английский
Если вам нравится эта тема, то покупайте билеты на конференцию и приходите слушать и задавать вопросы. А если вам интересно общее состояние дел о том, как AI влияет на инженерную культуру, то предлагаю пройти опрос от Т-Банка на эту тему. О чем этот опрос и почему его результаты будут интересными я уже рассказывал раньше.
#AI #Engineering #Software #Management #ML #DevEx
aiboost2025.ru
AI Boost | SURF
Конференция про реальное ускорение разработки с помощью ИИ
🔥12❤9👍2
Мы рассказали чуть подробнее о том, как работает наш агентский режим для разработчиков
Forwarded from Код Желтый
Мы в Т запустили агентский режим для разработки. Теперь агент не просто подсказывает части кода, а выполняет последовательность действий по заданию инженеров и помогает им сфокусироваться на сложных и креативных задачах.
#AI4SDLC
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤12👍8⚡5🥴1
Angular: The Documentary | An origin story (Рубрика #Engineering)
Посмотрел интересный документальный фильм про создание и развитие фронтового фреймворка Angular. Этот фильм интересно посмотреть даже если вам не интересна история фронтовых фреймворков(кстати, про react тоже есть документалка и я уже про нее рассказывал ) . Фильм рассказывает как Angular родился как внутренний эксперимент в Google, который поначалу отмахнули большие команды (Gmail и Maps), а затем стал массовым фреймворком и прошёл через болезненную «вторую жизнь» (Angular 2+). А теперь чуть
1. Как Angular появился внутри Google (локальная инициатива)
Старт проекту дала команда, работавшая над Google Feedback. Она утонула в 17 000 строк фронтенда и низкой тестопригодности. Тогда Ми́шко Хевери предложил дерзкий ход: переписать всё за две недели своим хобби‑проектом (GetAngular/AngularJS). Вышло за три, но код сжался до ~1 500 строк, и это стало моментом истины — менеджмент увидел в подходе ценность и дал зелёный свет на развитие. В общем, видно, что Angular родился не как глобальная инциатива "сверху-вниз", а скорее как локальная инженерная идея, доказавшаяся прототипом лечение реальной боли команды.
2. Борьба за ресурсы и «нет» по дороге
На старте AngularJS не получал аппрув от флагманов внутри Google - многие говорили что-то в стиле "хорошая игрушка, удачи". Поддержка пришла после демонстрации драматической экономии сложности/кода и скорости разработки. Сначала - маленькая команда, много скепсиса, мало ресурсов; дальше - органический рост вокруг первых успешных внедрений. Итого, в большой компании лучше один раз радикально показать ценность на рабочем кейсе, чем долго убеждать словами.
3. Как в Angular появился Dart и почему далее произошёл «раскол» AngularJS и Angular
Следующей развилкой стала производительность, статанализ и tree‑shaking. Внутри Google к этому моменту крепки были позиции Dart (с его dart2js и агрессивным tree‑shaking), а команда Angular экспериментировала между JS, AtScript и Dart. В итоге Google и Microsoft сошлись на TypeScript: ключевые идеи AtScript попали в TS 1.5, а Angular 2 строили уже на TypeScript, параллельно поддерживая AngularDart для крупных внутренних продуктов (Ads/AdSense). Это и закрепило исторический «раскол»: AngularJS (1.x) и Angular (2+) — два разных мира. В итоге, видно, что Dart повлиял на выделение дополнительных ресурсов, архитектуру фреймворка и компиляцию (статичность, AOT, tree‑shaking), но "языковая ставка" в открытой экосистеме ушла в сторону TypeScript.
4. Большие миграции
У Angular было две ключевые миграции:
- Архитектурный разрыв AngularJS → Angular (2+) - без обратной совместимости. Перепроектирование ради мобильности, модульности, типизации и будущей компиляции. Это самая болезненная точка истории.
- Смена движка рендера на Ivy (Angular 9) - уже внутренняя замена View Engine на новый компилятор/рендерер, специально спроектированный под мелкогранулярный tree‑shaking и меньшие бандлы. Переход стал дефолтом в v9 и принёс ощутимую экономию размера без переписывания приложений с нуля.
Обе миграции были болезненны, но кажется, что необходимы.
5. Как Angular чувствует себя сейчас и планы
Angular снова на подъёме: зрелая реактивность (Signals), сильный SSR/гидрация, фокус на DX и производительности, аккуратные мажоры без «лома мира». А Google планирует переносить фичи Wiz (внутреннего фреймворка внутри Google) в публичный Angular. Акутальная дорожная карта есть на angular.dev/roadmap.
В общем, документалка показалась мне интересной как техническому руководителю и инженеру - из этой истории можно извлечь много полезных уроков о том, как создавать и развивать крупные проекты.
#Software #SoftwareDevelopment #Architecture #Engineering #Management #OpenSource
Посмотрел интересный документальный фильм про создание и развитие фронтового фреймворка Angular. Этот фильм интересно посмотреть даже если вам не интересна история фронтовых фреймворков
1. Как Angular появился внутри Google (локальная инициатива)
Старт проекту дала команда, работавшая над Google Feedback. Она утонула в 17 000 строк фронтенда и низкой тестопригодности. Тогда Ми́шко Хевери предложил дерзкий ход: переписать всё за две недели своим хобби‑проектом (GetAngular/AngularJS). Вышло за три, но код сжался до ~1 500 строк, и это стало моментом истины — менеджмент увидел в подходе ценность и дал зелёный свет на развитие. В общем, видно, что Angular родился не как глобальная инциатива "сверху-вниз", а скорее как локальная инженерная идея, доказавшаяся прототипом лечение реальной боли команды.
2. Борьба за ресурсы и «нет» по дороге
На старте AngularJS не получал аппрув от флагманов внутри Google - многие говорили что-то в стиле "хорошая игрушка, удачи". Поддержка пришла после демонстрации драматической экономии сложности/кода и скорости разработки. Сначала - маленькая команда, много скепсиса, мало ресурсов; дальше - органический рост вокруг первых успешных внедрений. Итого, в большой компании лучше один раз радикально показать ценность на рабочем кейсе, чем долго убеждать словами.
3. Как в Angular появился Dart и почему далее произошёл «раскол» AngularJS и Angular
Следующей развилкой стала производительность, статанализ и tree‑shaking. Внутри Google к этому моменту крепки были позиции Dart (с его dart2js и агрессивным tree‑shaking), а команда Angular экспериментировала между JS, AtScript и Dart. В итоге Google и Microsoft сошлись на TypeScript: ключевые идеи AtScript попали в TS 1.5, а Angular 2 строили уже на TypeScript, параллельно поддерживая AngularDart для крупных внутренних продуктов (Ads/AdSense). Это и закрепило исторический «раскол»: AngularJS (1.x) и Angular (2+) — два разных мира. В итоге, видно, что Dart повлиял на выделение дополнительных ресурсов, архитектуру фреймворка и компиляцию (статичность, AOT, tree‑shaking), но "языковая ставка" в открытой экосистеме ушла в сторону TypeScript.
4. Большие миграции
У Angular было две ключевые миграции:
- Архитектурный разрыв AngularJS → Angular (2+) - без обратной совместимости. Перепроектирование ради мобильности, модульности, типизации и будущей компиляции. Это самая болезненная точка истории.
- Смена движка рендера на Ivy (Angular 9) - уже внутренняя замена View Engine на новый компилятор/рендерер, специально спроектированный под мелкогранулярный tree‑shaking и меньшие бандлы. Переход стал дефолтом в v9 и принёс ощутимую экономию размера без переписывания приложений с нуля.
Обе миграции были болезненны, но кажется, что необходимы.
5. Как Angular чувствует себя сейчас и планы
Angular снова на подъёме: зрелая реактивность (Signals), сильный SSR/гидрация, фокус на DX и производительности, аккуратные мажоры без «лома мира». А Google планирует переносить фичи Wiz (внутреннего фреймворка внутри Google) в публичный Angular. Акутальная дорожная карта есть на angular.dev/roadmap.
В общем, документалка показалась мне интересной как техническому руководителю и инженеру - из этой истории можно извлечь много полезных уроков о том, как создавать и развивать крупные проекты.
#Software #SoftwareDevelopment #Architecture #Engineering #Management #OpenSource
YouTube
Angular: The Documentary | An origin story
Born as an internal Google experiment - and initially brushed off by Gmail and Google Maps - AngularJS soon became a JavaScript sensation. But when internal pressures pushed the team towards a radical overhaul of the framework, the community felt left behind.…
❤8👍5🔥3🥰1