Science Museum (Рубрика #Travel)
Были в будний день в Музее Науки в Лондоне и это было очень круто. Музей расположен рядом с Имперским колледжом Лондона, насчитывает пять этажей и каждый этаж посвящен своей теме. Сам вход в музей бесплатный, но можно пожертвовать сколько хочешь. Мы пришли за два часа до закрытия и практически бегом пробежали экспозиции инжиниринга, космоса, полетов, компьютеров, медицины и на выходе успели еще купить подарки детям. В следующее посещение Лондона мы сюда обязательно зайдем, но уже вместе с детьми.
#Science #Museum #ForKids #ForParents #Culture
Были в будний день в Музее Науки в Лондоне и это было очень круто. Музей расположен рядом с Имперским колледжом Лондона, насчитывает пять этажей и каждый этаж посвящен своей теме. Сам вход в музей бесплатный, но можно пожертвовать сколько хочешь. Мы пришли за два часа до закрытия и практически бегом пробежали экспозиции инжиниринга, космоса, полетов, компьютеров, медицины и на выходе успели еще купить подарки детям. В следующее посещение Лондона мы сюда обязательно зайдем, но уже вместе с детьми.
#Science #Museum #ForKids #ForParents #Culture
🔥16❤8👍4
Граф знаний сайта system-design.space (Рубрика #SystemDesign)
Материалов на сайте про system design стало слишком много и мне самому потребовалось средство для визуализации тем, глав и связей между ними. Так у меня получился граф знаний, который показывает 222 глав и 820 связей между ними. Каждый узел - это глава книги, а линия - смысловая связь между материалами. Связи строятся по перекрёстным ссылкам внутри контента глав: MarginNote на полях справа, ссылки из блоков "связанные главы" в конце глав и ссылки, что раскиданы по тексту статьи.
Я планирую в будущем добавить в этот граф возможность выбора траекторий изучения, но пока он работает попрощ
- Клик по кластеру в сайдбаре приводит к зуму и фокусу на главы из этой темы, а остальные главы затемняются
- Клик по ноде в графе открывает панель с деталями главы, списком связанных глав и появляется кнопка перехода к материалу
- Скролл / pinch позволяыт зумить. При приближении появляются названия глав
- Перетаскивание - можно передвигаться по графу или если потянуть за отдельный узело, то можно его перместить
- Цвета узлов соответствуют своим темам (кластерам)
- По разному отмечаются связи внутри кластера и между кластерами + сами связи направленные
- Для отрисовки графа используется force-directed layout (d3-force): узлы отталкиваются друг от друга, а связи притягивают. В итоге связанные главы оказываются рядом, а изолированные - на периферии.
Я использовал этот граф сам для того, чтобы проверить, что у меня я сам не забыл добавить кросс-ссылки между темами (на самом деле забыл и граф мне позволил это исправить).
#SystemDesign #Architecture #DistributedSystems #Career #Interview #Engineering
Материалов на сайте про system design стало слишком много и мне самому потребовалось средство для визуализации тем, глав и связей между ними. Так у меня получился граф знаний, который показывает 222 глав и 820 связей между ними. Каждый узел - это глава книги, а линия - смысловая связь между материалами. Связи строятся по перекрёстным ссылкам внутри контента глав: MarginNote на полях справа, ссылки из блоков "связанные главы" в конце глав и ссылки, что раскиданы по тексту статьи.
Я планирую в будущем добавить в этот граф возможность выбора траекторий изучения, но пока он работает попрощ
- Клик по кластеру в сайдбаре приводит к зуму и фокусу на главы из этой темы, а остальные главы затемняются
- Клик по ноде в графе открывает панель с деталями главы, списком связанных глав и появляется кнопка перехода к материалу
- Скролл / pinch позволяыт зумить. При приближении появляются названия глав
- Перетаскивание - можно передвигаться по графу или если потянуть за отдельный узело, то можно его перместить
- Цвета узлов соответствуют своим темам (кластерам)
- По разному отмечаются связи внутри кластера и между кластерами + сами связи направленные
- Для отрисовки графа используется force-directed layout (d3-force): узлы отталкиваются друг от друга, а связи притягивают. В итоге связанные главы оказываются рядом, а изолированные - на периферии.
Я использовал этот граф сам для того, чтобы проверить, что у меня я сам не забыл добавить кросс-ссылки между темами (на самом деле забыл и граф мне позволил это исправить).
#SystemDesign #Architecture #DistributedSystems #Career #Interview #Engineering
🔥44👍14❤10👏1
[1/2] Retired Netflix Engineering Director On Regrets, Video Engineering, Hiring Stories (Рубрика #Engineering)
Интересное интервью Дэвида Ронка, экс Engineering Director в Netflix (пришёл в 2007), позже Director/Principal в Meta (видеотехнологии), которое он дал Райану Питерману , Staff SWE в Instagram. В этом интервью Дэвид, который уже вышел на пенсию, делится ретроспективой своей карьеры и управленческих решений. Основные инсайты следующие
1️⃣ "No brilliant jerks" - это не HR-лозунг, а инженерная оптимизация throughput
Токсичная "звезда" может быть сильной индивидуально, но снижает скорость и качество всей команды (а значит и системы).
2️⃣ Героизм и 24/7 - симптом организационного бага, а не доблесть
Если команда не переживает нормальный отпуск ключевого инженера, проблема почти всегда в устройстве системы: ownership, знания, ротации, процессы, приоритеты.
3️⃣ Culture Memo "aspirational": культура без инфраструктуры ломается при росте
На небольшом масштабе "контекст вместо контроля" и сильные люди могут вытягивать многое. На большом масштабе без уровней/процессов/прозрачности вклада начинаются перекосы: вклад размывается, аттрибуция успехов уезжает вверх, компенсации сложнее объяснять.
4️⃣ Масштаб реально меняет физику инженерных решений
Переход в Meta показал ему, что некоторые задачи (например, видео на уровне платформы) нельзя "дожать CPU’шками и количеством серверов" - нужна другая парадигма.
5️⃣ Найм: конфликт "точность оценки <=> масштабируемость процесса"
У него жёсткая позиция про LeetCode (как не очень хороший сигнал качества инженера), но при этом он признаёт: в big tech стандартизация этапов часто неизбежна. Плюс важный тезис: over‑leveling - дорогая ошибка, потому что "мягко опустить ожидания" потом почти невозможно.
6️⃣ Performance/калибрации могут быть отличной школой управленческой объективности
Да, это тяжело и неприятно, но заставляет формулировать вклад инженеров так, чтобы он держался на фактах и impact’е, а не на харизме менеджера.
7️⃣ Риск формализованных систем: перекос в "индивидуальную аттрибуцию результатов"
Вклад становится видимым, но риск в том, что люди начинают оптимизировать "видимость" и личную победу, а не командный результат.
В продолжении расскажу как можно этот опыт переложить на практические рекомендации инженерам и техническим руководителям.
#Culture #Management #Leadership #Processes #Engineering #Software #Career #Interview
Интересное интервью Дэвида Ронка, экс Engineering Director в Netflix (пришёл в 2007), позже Director/Principal в Meta (видеотехнологии), которое он дал Райану Питерману , Staff SWE в Instagram. В этом интервью Дэвид, который уже вышел на пенсию, делится ретроспективой своей карьеры и управленческих решений. Основные инсайты следующие
1️⃣ "No brilliant jerks" - это не HR-лозунг, а инженерная оптимизация throughput
Токсичная "звезда" может быть сильной индивидуально, но снижает скорость и качество всей команды (а значит и системы).
2️⃣ Героизм и 24/7 - симптом организационного бага, а не доблесть
Если команда не переживает нормальный отпуск ключевого инженера, проблема почти всегда в устройстве системы: ownership, знания, ротации, процессы, приоритеты.
3️⃣ Culture Memo "aspirational": культура без инфраструктуры ломается при росте
На небольшом масштабе "контекст вместо контроля" и сильные люди могут вытягивать многое. На большом масштабе без уровней/процессов/прозрачности вклада начинаются перекосы: вклад размывается, аттрибуция успехов уезжает вверх, компенсации сложнее объяснять.
4️⃣ Масштаб реально меняет физику инженерных решений
Переход в Meta показал ему, что некоторые задачи (например, видео на уровне платформы) нельзя "дожать CPU’шками и количеством серверов" - нужна другая парадигма.
5️⃣ Найм: конфликт "точность оценки <=> масштабируемость процесса"
У него жёсткая позиция про LeetCode (как не очень хороший сигнал качества инженера), но при этом он признаёт: в big tech стандартизация этапов часто неизбежна. Плюс важный тезис: over‑leveling - дорогая ошибка, потому что "мягко опустить ожидания" потом почти невозможно.
6️⃣ Performance/калибрации могут быть отличной школой управленческой объективности
Да, это тяжело и неприятно, но заставляет формулировать вклад инженеров так, чтобы он держался на фактах и impact’е, а не на харизме менеджера.
7️⃣ Риск формализованных систем: перекос в "индивидуальную аттрибуцию результатов"
Вклад становится видимым, но риск в том, что люди начинают оптимизировать "видимость" и личную победу, а не командный результат.
В продолжении расскажу как можно этот опыт переложить на практические рекомендации инженерам и техническим руководителям.
#Culture #Management #Leadership #Processes #Engineering #Software #Career #Interview
YouTube
Retired Netflix Engineering Director On Regrets, Video Engineering, Hiring Stories
David Ronca joined Netflix in 2007 and grew to an engineering director there. Later he joined Meta as a Director and transitioned to a Principal engineer working on video technologies. Now he's retired and was graciously willing to share his career story…
❤12🔥6👍5
[2/2] Retired Netflix Engineering Director On Regrets, Video Engineering, Hiring Stories (Рубрика #Engineering)
В продолжении этого крутого интервью, я хотел бы поделиться выводами из него для инженеров и технических руководителей.
Что это значит для разработчиков (IC)
- Если ты single point of failure - это не "круто", это риск. Документация, runbook’и, ротации on-call, передача контекста, “absence drill” (плановая недоступность) — это то, что делает команду взрослой.
- Собирай "evidence of impact" до того, как тебя об этом попросят. Простая привычка: раз в месяц фиксировать “что сделал → какой эффект → какие риски снял → какие метрики/сигналы подтверждают”. Это помогает и в оценке, и в повышении, и в переговорах.
- Не путай "много работал" с "много решил". В разговоре красной нитью: часы - плохой KPI. Системы и команды должны работать так, чтобы не требовать постоянного героизма.
- Про собесы: будь готов к стандартизированным фильтрам, но выигрывает инженерная зрелость. Умение рассуждать про trade‑offs, неопределённость, дизайн систем и реальные решения - то, что отличает сильных на дистанции.
Что это значит для техлидов и технических руководителей
- Культура должна "исполняться", а не декларироваться. Например, "No brilliant jerks" работает только когда есть реальный enforcement: обратная связь, понятные ожидания и готовность расставаться даже с сильными, если они ломают команду.
- Сделайте отпуск диагностическим инструментом. "Vacation/bus‑factor тест": кто уходит на неделю → что ломается → какие знания/доступы/процессы надо распаковать из головы в систему.
- Видимость вклада - это инфраструктура роста. Не обязательно сразу “как в Meta”. Но вам нужна лёгкая версия: цели → зафиксированный impact → регулярная синхронизация ожиданий между командами, иначе на масштабе всё начнёт “тонуть в тумане”.
- Найм: определитесь, что вы реально измеряете, и структурируйте процесс. Если хотите системное мышление и зрелость - добавляйте этапы, которые это проявляют (work‑sample / разбор реального кейса / обсуждение решений при неполных данных), а не только "задачки".
- Компенсируйте перекос в индивидуальной аттрибуции резульататов. Если "светится" только личный вклад - получите локальную оптимизацию. Добавляйте командные сигналы, качество взаимодействия, ownership на длинной дистанции, культуру совместного результата.
#Culture #Management #Leadership #Processes #Engineering #Software #Career #Interview
В продолжении этого крутого интервью, я хотел бы поделиться выводами из него для инженеров и технических руководителей.
Что это значит для разработчиков (IC)
- Если ты single point of failure - это не "круто", это риск. Документация, runbook’и, ротации on-call, передача контекста, “absence drill” (плановая недоступность) — это то, что делает команду взрослой.
- Собирай "evidence of impact" до того, как тебя об этом попросят. Простая привычка: раз в месяц фиксировать “что сделал → какой эффект → какие риски снял → какие метрики/сигналы подтверждают”. Это помогает и в оценке, и в повышении, и в переговорах.
- Не путай "много работал" с "много решил". В разговоре красной нитью: часы - плохой KPI. Системы и команды должны работать так, чтобы не требовать постоянного героизма.
- Про собесы: будь готов к стандартизированным фильтрам, но выигрывает инженерная зрелость. Умение рассуждать про trade‑offs, неопределённость, дизайн систем и реальные решения - то, что отличает сильных на дистанции.
Что это значит для техлидов и технических руководителей
- Культура должна "исполняться", а не декларироваться. Например, "No brilliant jerks" работает только когда есть реальный enforcement: обратная связь, понятные ожидания и готовность расставаться даже с сильными, если они ломают команду.
- Сделайте отпуск диагностическим инструментом. "Vacation/bus‑factor тест": кто уходит на неделю → что ломается → какие знания/доступы/процессы надо распаковать из головы в систему.
- Видимость вклада - это инфраструктура роста. Не обязательно сразу “как в Meta”. Но вам нужна лёгкая версия: цели → зафиксированный impact → регулярная синхронизация ожиданий между командами, иначе на масштабе всё начнёт “тонуть в тумане”.
- Найм: определитесь, что вы реально измеряете, и структурируйте процесс. Если хотите системное мышление и зрелость - добавляйте этапы, которые это проявляют (work‑sample / разбор реального кейса / обсуждение решений при неполных данных), а не только "задачки".
- Компенсируйте перекос в индивидуальной аттрибуции резульататов. Если "светится" только личный вклад - получите локальную оптимизацию. Добавляйте командные сигналы, качество взаимодействия, ownership на длинной дистанции, культуру совместного результата.
#Culture #Management #Leadership #Processes #Engineering #Software #Career #Interview
Telegram
Книжный куб
[1/2] Retired Netflix Engineering Director On Regrets, Video Engineering, Hiring Stories (Рубрика #Engineering)
Интересное интервью Дэвида Ронка, экс Engineering Director в Netflix (пришёл в 2007), позже Director/Principal в Meta (видеотехнологии), которое…
Интересное интервью Дэвида Ронка, экс Engineering Director в Netflix (пришёл в 2007), позже Director/Principal в Meta (видеотехнологии), которое…
❤15🔥5👍3👎1
Кафедральный собор Святого Павла (Рубрика #Travel)
Мы сегодня с Настей посетили этот собор и остались в восторге. Величественное здание возвышается над округой и внутри выглядит замечательно. Кроме первого этажа можно спуститься в крипту, где покоятся исторические деятели, а также можео подняться под свод собора и даже выше, чтобы со смотровой площадки увидеть Лондон вокруг. В общем, это обязательное для посещение место ... как минимум для туристов.
#Culture
Мы сегодня с Настей посетили этот собор и остались в восторге. Величественное здание возвышается над округой и внутри выглядит замечательно. Кроме первого этажа можно спуститься в крипту, где покоятся исторические деятели, а также можео подняться под свод собора и даже выше, чтобы со смотровой площадки увидеть Лондон вокруг. В общем, это обязательное для посещение место ... как минимум для туристов.
#Culture
❤11🔥7👍6
Building AI-Powered Products (Рубрика #AI)
Прочитал интересную книгу Marily Nika, AI Product Lead (Google, ex‑Meta) и основателя AI Product Academy. Marily рассказывает в ней про то, как выглядит отдельная дисциплина AI product management и как определить, а что именно строим, как меряем качество продукта, сколько это будет стоить в продакшене и почему пользователи не уйдут через неделю. Эта книга вышла в феврале 2025 года и пыталась выдать плейбук, который связывает идею → продуктовую ценность → архитектуру → эксплуатацию → метрики → риски. В ней рассматривались вопросы вида
- Как выбирать AI сценарии, которые приносит value, а не "потому что модно"
- Как думать про измерение успеха: оффлайн‑метрики, human eval, мониторинг в проде
- Как оценивать trade‑offs: качество vs latency vs стоимость инференса vs риски
- Как выстроить работу продакт менеджеров, инжиниринга, data science и research, чтобы ожидания совпали
- Как быть с этикой и compliance: данные, приватность, "галлюцинации", ответственность за работу моделей
Если говорить про содержание книги, то она состоит из preface, 8 глав и appendix.
Chapter 1. The Role of AI Product Managers
Здесь автор рассказывает про роль AI продакт менеджеров и как развивалась эволюция AI: традиционный AI → GenAI → грядущий AGI. Какие особенно у AI продуктов, включая вероятностную природу, зависимость от данных, дрифт моделей, требования к интерпретируемости/объяснимости, автоматизированные решения, масштабируемость и влияние этого всего на UX. Тут же описывается какой набор скиллов требуется для AI продакт менеджеров
Chapter 2. The AI Product Development Lifecycle
Здесь автор рассказывает про каркас AI Product Development Lifecycle (AIPDL) и проводит по стадиям:
- Типы AI‑продуктов: 0‑to‑1 (новый продукт) vs 1‑to‑n (AI‑фичи в существующем) (напоминает историю "Zero to One" Питера Тиля)
- Этап Ideation (в т.ч. брейншторм и приоритизация через RICE
- Этап Opportunity: product‑market fit + бизнес‑viability (ROI/монетизация/риски/регуляторика), реализуемость и desirability,
- Concept & Prototype: прототип "хардкодом", проверка интеграции, доменная экспертиза, ценность "с первого дня",
- Testing & Analysis и Rollout
Chapter 3. Essential AI PM Knowledge
В этой главе автор рассказывает про базовые практики продакт менеджмента, классическую оценку build vs buy, лидерство и коммуникации, связь с инженерной командой, базовые технические концепции и так далее. В общем этакий product management 101.
Chapter 4. The AI PMs Day‑to‑Day
Здесь автор рассказывает про карьерную лестницу AI PM: execution → AI/ML PM → стратегическое лидерство. Дальше она приводит примеры людей, которые работали в этих ролях в разных компаниях. Здесь же идет рассказ про выстраивание кросс‑функциональных взаимодействий в командах.
Chapter 5. Strategic Thinking in AI
Здесь речь про стратегию и "правильные вопросы" до того, как писать код:
- Когда AI может быть не ответом,
- Disruptive vs sustaining и как не проиграть “innovator’s dilemma”,
- AI‑стратегия build vs buy (матрица решения + гибридные подходы),
- Data‑стратегия: synthetic vs real‑world data,
- Выбор подхода: fine‑tuning vs RAG vs grounding + фреймворк принятия решения,
- Product reviews как инструмент получения buy‑in от руководства.
Chapter 6. Setting Goals and Measuring Success
Здесь автор рассказывает про метрики и измеримость: product health, system health, ai proxy metrics. Как собирать OKR.
Chapter 7. AI Tools for Product Managers
Обзор классов инструментов для поддержки AIPDL и инструментов для совместной работы.
Chapter 8. Building AI Agents
Глава про агентные продукты, что это такое и как "сконструировать" агента под продукт: вертикальный vs general‑purpose, activation, autonomy, feedback/learning.
#ProductManagement #Software #SoftwareDevelopment #AI #Engineering #Management #Leadership
Прочитал интересную книгу Marily Nika, AI Product Lead (Google, ex‑Meta) и основателя AI Product Academy. Marily рассказывает в ней про то, как выглядит отдельная дисциплина AI product management и как определить, а что именно строим, как меряем качество продукта, сколько это будет стоить в продакшене и почему пользователи не уйдут через неделю. Эта книга вышла в феврале 2025 года и пыталась выдать плейбук, который связывает идею → продуктовую ценность → архитектуру → эксплуатацию → метрики → риски. В ней рассматривались вопросы вида
- Как выбирать AI сценарии, которые приносит value, а не "потому что модно"
- Как думать про измерение успеха: оффлайн‑метрики, human eval, мониторинг в проде
- Как оценивать trade‑offs: качество vs latency vs стоимость инференса vs риски
- Как выстроить работу продакт менеджеров, инжиниринга, data science и research, чтобы ожидания совпали
- Как быть с этикой и compliance: данные, приватность, "галлюцинации", ответственность за работу моделей
Если говорить про содержание книги, то она состоит из preface, 8 глав и appendix.
Chapter 1. The Role of AI Product Managers
Здесь автор рассказывает про роль AI продакт менеджеров и как развивалась эволюция AI: традиционный AI → GenAI → грядущий AGI. Какие особенно у AI продуктов, включая вероятностную природу, зависимость от данных, дрифт моделей, требования к интерпретируемости/объяснимости, автоматизированные решения, масштабируемость и влияние этого всего на UX. Тут же описывается какой набор скиллов требуется для AI продакт менеджеров
Chapter 2. The AI Product Development Lifecycle
Здесь автор рассказывает про каркас AI Product Development Lifecycle (AIPDL) и проводит по стадиям:
- Типы AI‑продуктов: 0‑to‑1 (новый продукт) vs 1‑to‑n (AI‑фичи в существующем) (напоминает историю "Zero to One" Питера Тиля)
- Этап Ideation (в т.ч. брейншторм и приоритизация через RICE
- Этап Opportunity: product‑market fit + бизнес‑viability (ROI/монетизация/риски/регуляторика), реализуемость и desirability,
- Concept & Prototype: прототип "хардкодом", проверка интеграции, доменная экспертиза, ценность "с первого дня",
- Testing & Analysis и Rollout
Chapter 3. Essential AI PM Knowledge
В этой главе автор рассказывает про базовые практики продакт менеджмента, классическую оценку build vs buy, лидерство и коммуникации, связь с инженерной командой, базовые технические концепции и так далее. В общем этакий product management 101.
Chapter 4. The AI PMs Day‑to‑Day
Здесь автор рассказывает про карьерную лестницу AI PM: execution → AI/ML PM → стратегическое лидерство. Дальше она приводит примеры людей, которые работали в этих ролях в разных компаниях. Здесь же идет рассказ про выстраивание кросс‑функциональных взаимодействий в командах.
Chapter 5. Strategic Thinking in AI
Здесь речь про стратегию и "правильные вопросы" до того, как писать код:
- Когда AI может быть не ответом,
- Disruptive vs sustaining и как не проиграть “innovator’s dilemma”,
- AI‑стратегия build vs buy (матрица решения + гибридные подходы),
- Data‑стратегия: synthetic vs real‑world data,
- Выбор подхода: fine‑tuning vs RAG vs grounding + фреймворк принятия решения,
- Product reviews как инструмент получения buy‑in от руководства.
Chapter 6. Setting Goals and Measuring Success
Здесь автор рассказывает про метрики и измеримость: product health, system health, ai proxy metrics. Как собирать OKR.
Chapter 7. AI Tools for Product Managers
Обзор классов инструментов для поддержки AIPDL и инструментов для совместной работы.
Chapter 8. Building AI Agents
Глава про агентные продукты, что это такое и как "сконструировать" агента под продукт: вертикальный vs general‑purpose, activation, autonomy, feedback/learning.
#ProductManagement #Software #SoftwareDevelopment #AI #Engineering #Management #Leadership
👍10❤5🔥1