The Creative Programmer (Креативный программист) (Рубрика #SelfDevelopment)

Недавно я прочитал эту книгу Ваутера Гренефелда про креативнрость в программировании. Суть в том, что Ваутер рассматривает разработку как творческую деятельность, сравнимую с созданием музыки, а не просто технический процесс. Мало того, автор утверждает, что креативность можно развивать и даже дает практические советы о том, как это делать. Книга в оригинале вышла в издательстве Manning, а на русский переведена издательством "Питер". Читал я на русском и особых проблем не заметил.

Если возращаться к самой книге, то автор выделяет следующие столпы креативности
- Technical knowledge (технические знания): без hard skills в инженерии никуда - сложно быть креативным без знания технической базы. Я уже как-то рассказывал про путь в сторону staff engineer и как прокачивать харды для становления крутым IC (individual contributor)
- Collaboration (сотрудничество): это то, что обычно называют soft skills, а точнее тут про эффективное общение в команде и обмен идеями. Недавно у меня был доклад как раз на эту тему
- Constraints (ограничения): часто именно наличие ограничений стимулирует инновации для их преодолениея
- Critical thinking (критическое мышление): сомнение в предположениях и улучшение решений. У меня есть целая подборка ресурсов про критическое мышление
- Curiosity (любознательность): стремление к постоянному обучению и разнообразным интересам
- Creative state of mind (творческое состояние ума): развитие концентрации и внутренней мотивации
- Creative techniques (творческие техники): методы, такие как использование метафор и мозговой штурм

Если обобщать основные мысли, то
- Креативность возникает из соединения идей из разных дисциплин, что автор иллюстрирует историческими примерами
- Автор поощряет "хорошее воровство" идей (адаптация концепций) в противовес простому подражанию
- Ваутер говорит про баланс между внутренней мотивацией (например, любопытством) и внешними факторами (например, сроками) - это по его мнению повышает продуктивность

В последней главе есть много креативных практик из инструментария писателя, художника и инженра. Поэтому желающий повысить свою креативность может взять эти инструменты и начать их практиковать. А для отслеживания прогресса можно взять Creative Programming Problem Solving Test, позволяющий отслеживать и измерять прогресс в развитии креативности.

P.S.
Вопросы креативности в software engineering очень важны, например, ребята из Google исследовали их и недавно написали интересный whitepaper "Developer Productivity for Humans, Part 8: Creativity in Software Engineering", который я уже разбирал раньше.

#Thinking #Engineering #SelfDevelopment #Software #Brain

The Engineering Unlocks Behind DeepSeek | YC Decoded (Рубрика #AI)

Интересный 13 минутный разбор DeepSeek R1 от ребят из Y Combinator, который фокусируется не на хайпе, а на инженерных вещах. Основные моменты разбора такие

1) Deepseek анонсировала логическую модель R1, которая обеспечивает сопоставимую производительность с OpenAIo1 при меньших затратах.
2) Это вызвало панику в социальных сетях и снижение рыночной капитализации Nvidia на 600 миллиардов долларов.
3) Но DeepSeek - это не новый игрок на рынке. Они публикуют результаты своих исследований и модели весов, в отличие от других крупных лабораторий, таких как OpenAI и Google DeepMind. И многие результаты уже были опубликованы ранее, например, они оптимизировали обучение в fp8 и исправление накопления ошибки
4) Важно различать модели DeepSeek-R1 и DeepSeek-V3
- DeepSeek V3 обеспечивает производительность, сопоставимую с GPT-4 и другими базовыми моделями.
• R1 является reasoning моделью, построенной на основе V3, и достигает производительности, сравнимой с OpenAI o1 и Google Gemini Flash 20.
5) В V3 они использовали архитектуру, что активирует только 37 миллиардов параметров для каждого предсказания, что экономит массу вычислений, а также использовали технологии multi-head latent attention (mla) для уменьшения объема памяти и увеличения пропускной способности.
6 ) Для R1 они придумали интересную схему обучения с подкреплением (reinforcement learning)
7) Часть хайпа вокруг R1 была свзяана с доступностью модели через веб-сайт и приложение Deepseek. Сама модель предлагала сравнимую производительность за небольшую часть стоимости других моделей.
8 ) Большая часть шумихи связана с ошибочными представлениями о стоимости обучения, сумма была указана для финального обучения модели без
9) Методы DeepSeek можно воспроизвести для создания своих моделей, например, Лаборатория Калифорнийского университета в Беркли применила эти методы для создания небольших reasoning моделей всего за 30 долларов.
10) Так как это видео от Y Combinator, то они заканчивают идеей о том, что на переднем краю развития AI есть место для новых игроков, которые могут подвинуть старожилов за счет оптимизации рабочих нагрузок GPU, улучшения софта и так далее. А все это приводит к уменьшению стоимости внедрения AI в конечные продукты, что делает текущий момен подходящим временем для создания стартапа.

#AI #Engineering #Software #ML #Architecture

Драйв (Drive: The Surprising Truth About What Motivates Us) (Рубрика #Management)

Недавно я прочитал эту классическую книгу Даниэля Пинка (обложки в отдельном посте), которая была написана в конце 2000-х годов. В то время она звучала свежо и бросала вызов традиционным представлениям о мотивации, особенно подходу «кнут и пряник», основанному на вознаграждениях и наказаниях. Дэниель смешал фокус на внутренней мотивации, а не внешних стимулах. Автор хорошо вплетал в свое повествование результаты исследований ученых, таких как Дэниеля Канемана и его книгу "Thniking, Fast and Slow" (подробности в моем посте) или Дэна Ариели и его книгу "Predictably Irrational" (подробности в моем посте).

По-факту, Дэниэль Пинк предлагает модель мотивации 3.0, которая основывается на трех столпах
1) Автономия: Желание контролировать свою работу и принимать собственные решения. Пинк подчеркивает, что автономия способствует вовлеченности и креативности, позволяя людям самостоятельно направлять свои усилия.
2) Мастерство: Стремление улучшать свои навыки и достигать совершенства в значимых задачах. Это требует постоянного обучения и упорства.
3) Цель: Необходимость вносить вклад во что-то большее, чем собственные интересы. Связь работы с более высокой миссией усиливает мотивацию и удовлетворение.

Пинк противопоставляет эти внутренние мотиваторы внешним, таким как денежные вознаграждения, которые эффективны только для простых механических задач. Для сложной, творческой или когнитивной работы внешние стимулы могут даже снижать производительность, подавляя креативность и внутренний интерес.

В итоге, по Пинку есть 3 модели мотивации
1) Мотивация 1.0 — выживание
2) Мотивация 2.0 — вознаграждения/наказания
3) Мотивация 3.0 - внутренняя мотивация на основе автономии, мастерства и цели
Собственно, надо стремиться с мотивации 3.0, но для этого компании должны «платить достаточно, чтобы убрать деньги с повестки дня», чтобы сотрудники могли сосредоточиться на более значимых стимулах. Чем-то эти уровни мотивации напоминают пирамиду Маслоу

Пинк выделяет два типа поведения у людей
1) Тип X - внешне мотивированные
2) Тип I - внутренне мотивированные.
Поведение типа I более устойчиво, так как опирается на возобновляемые внутренние ресурсы, такие как страсть и любопытство.

Книга Пинка написана очень просто и достаточно популярна, но к ней и ряд замечаний
1) Автор по кругу повторяет мысли про автономию, мастерство и цели без особых изменений и развития темы
2) Автор упоминает исследования, что поддерживают его мысли, но почти не упоминает исследования, которые могли бы опровергнуть его выводы, создавая впечатление предвзятости.
3) Некоторые рецензенты считают описание мотивации на рабочем месте слишком упрощенным. Например, Пинк предполагает, что развитие внутренней мотивации автоматически улучшит производительность, игнорируя такие факторы как обучение сотрудников или различия в индивидуальных целях.
4) Центральный аргумент о переходе к внутренней мотивации кажется некоторым критикам преувеличенным. Они отмечают важность внешних стимулов во многих рутинных или некреативных профессиях, которые Пинк практически не рассматривает.
5) Многие рецензенты указывают на то, что *Drive* лишь популяризирует уже существующие психологические теории (особенно теорию самодетерминации), не добавляя существенных новых идей.
6) Книга критикуется за недостаток конкретных шагов по внедрению идей в реальной практике.
7) Акцент на автономии как ключевом факторе мотивации может быть неактуален для всех культур. Критики отмечают ограниченную применимость модели Пинка в странах с более строгими рабочими структурами или другими культурными нормами. Рекомендую почитать на тему разнообразия культур книгу "The culture map" (подробнее в моем посте)

Итого, книга отлично популяризировала тему внутренней мотивации, но она достаточно поверхностна - с нее можно начать но для серьезного погружения в тему стоит почитать более фундаментальную литературу.

#Psychology #Economics #Brain #SelfDevelopment

[4/4] Software Engineering at Google (Делай как в Google. Разработка программного обеспечения) (Рубрика #Engineering)

Продолжая рассказ про эту крутую книгу, поднятый в постах 1 и 2 и 3, здесь я расскажу про четвертую и пятую часть книги под названием "Инструменты" и "Заключение".

IV. Tools (инструменты)
16. Version control and branch management (Управление версиями и управление ветками)
В этой главе авторы описывают, как Google использует управление версиями, а точнее свой монорепозиторий, для управления огромными объемами кода. Авторы объясняют стратегию управления ветками, которые обеспечивают непрерывную интеграцию и совместную разработку. По-факту, это версия TBD (trunk based development)
17. Code search (поиск кода)
Глава сосредоточена на инструментарии, который делает навигацию по огромному кодовому базису эффективной. Она объясняет, как мощные возможности поиска имеют решающее значение для понимания и поддержки крупных систем
18. Build systems and build philosophy (Системы сборки и философия сборки)
Авторы рассказывают про инфраструктуру сборки и практики, включая инкрементальные сборки и автоматизацию. Этот раздел детализирует, как системы сборки Google спроектированы для скорости и масштаба
19. Critique: Google’s code review tool (критика: инструмент обзора кода Google)
Интересная глава про внутренний инструмент, используемый для облегчения обзора кода. Обсуждение охватывает его сильные и слабые стороны, а также влияние на рабочий процесс и эффективность разработчиков.
20. Static analysis (статический анализ)
В этой глава объясняется, как автоматизированные инструменты анализируют исходный код для обнаружения ошибок или отклонений от стандартов до запуска кода. Этот активный подход является ключевым для поддержания качества кода в масштабе.
21. Dependency management (управление зависимостями)
Эта глава рассказывает про методы обработки зависимостей в огромной кодовой базе. Предоставляет стратегии для минимизации конфликтов и поддержания целостности системы по мере эволюции кода. Подробнее про концепт можно почитать на сайте build системы Bazel
22. Large-scale changes (крупномасштабные изменения)
В этой главе авторы обсуждают методы и инструменты для безопасного применения широкомасштабных изменений по тысячам файлов. Глава сосредоточена на планировании, автоматизации и минимизации рисков при обработке крупномасштабных изменений кода. Ясно, что такие возможности во многом основаны на использовании монорепы.
23. Continuous integration (непрерывная интеграция)
Эта глава детализирует практики и инфраструктуру, которые позволяют интегрировать изменения в коде часто и надежно. Непрерывная интеграция показана как необходимая для раннего обнаружения проблем в процессе разработки. Если хочется описания попроще, то рекомендую книгу "Grokking Continuous Delivery" ("Грокаем continuous delivery") тоже от ребят из Google, про которую я уже рассказывал
24. Continuous delivery (непрерывная доставка)
Здесь речь идет про конвейеры и автоматизацию, которые обеспечивают быструю и надежную развертывание изменений. Эта глава подчеркивает, как оптимизированные процессы доставки поддерживают постоянные инновации, сохраняя при этом стабильность. Книга "Grokking Continuous Delivery" тут тоже отлично подходит
25. Compute as a service (вычисления как сервис)
Описывает, как Google использует масштабируемые вычислительные ресурсы для поддержки разработки, тестирования и развертывания. Объясняет, как эта «инфраструктура как сервис» лежит в основе многих инженерных практик Google.

V. Заключение
Здесь авторы подводят итоги и отмечают, что инженерия программного обеспечения — это непрерывный процесс, который сочетает культуру, хорошо определенные процессы и передовые инструменты. Также авторы размышляют о выученных уроках, подчеркивая, что хотя не все практики будут применимы к каждой организации, принципы адаптивности и устойчивого развития являются универсальными.

#Engineering #Management #Software #Development #Processes #Leadership #SRE #DevOps

[1/2] Squad Health Check и сравнение его с DORA Metrics, SPACE, DevEx (Рубрика #Management)

Буквально на днях наткнулся на древний инструмент опросов от Spotify. Этот концепт был опубликован в далеком 2014 году, через пару лет после публикации знаменитой модели Spotify со всякими гильдиями, сквадами и другими забавными названиями. Эту модель придумал Henrik Kniberg и популяризировал красивыми мультиками и комиксами, что стали виральными. Несмотря на попытки прикрутить модель в лоб, это мало у кого получалось, а потом и создатели сказали, что сами отошли от нее и адаптировали свои процессы под новую реальность. Собствено, Squad Health Check появился больше 10 лет назад, но он до сих пор используется в Spotify. Если упрощать, то squad health check - это инструмент самооценки, разработанный для agile команд,. Он используется для оценки и улучшения динамики команды, производительности и общей эффективности путем отслеживания различных измерений здоровья команды с течением времени. Основными фичами этой системы являются

1) Traffic light system (светофорная система): члены команды оценивают различные измерения с помощью простых цветных индикаторов, что позволяет легко визуализировать общее состояние команды.
2) Dimensions evaluated (jцениваемые измерения): общие измерения включают доставку ценности, простоту выпуска, веселье, здоровье кодовой базы, моральный дух команды и сотрудничество. Их можно настраивать в соответствии с конкретными потребностями команды.
3) Open discussions (открытые обсуждения): результаты используются для содействия обсуждениям проблем и успехов, помогая командам определять области для улучшения и создавать выполнимые планы.
4) Historical tracking (историческое отслеживание): со временем команды могут отслеживать свой прогресс и определять тенденции или повторяющиеся проблемы.

В общем, этот подход был хорош для 2014 года, но с тех пор успели появиться DORA (DevOps Research and Assesment) metrics (подробности в посте про книгу Accelerate), SPACE framework (подробности в посте) и DevEx (подробности в посте), которые шагнули сильно дальше. Если сравнить их между собой то получим примерно следующее (метод Squad health check я буду для краткости называть SHC)

1) Субъективность vs. Объективность.
- SHC сильно зависит от субъективных самооценок участников команды. Это может привести к предвзятым или непоследовательным результатам, так как разные люди могут по-разному интерпретировать вопросы или не быть полностью честными.
- DORA Metrics предоставляет объективные, количественные данные о параметрах разработки (например, deployment frequence или lead time).
- SPACE: Сочетает субъективные и объективные данные, но благодаря своей структуре минимизирует предвзятость, объединяя такие метрики, как удовлетворенность, с измеримыми показателями производительности, которые можно получить через логи/метрики из систем (activity часть SPACE)
- DevEx: Похожим на SPACE образом пытается сбалансировать субъективность и объективность.
2) Отсутствие фокуса на технических метриках
- SHC делает акцент на моральном духе команды, сотрудничестве и процессах, но не уделяет внимания техническим метрикам, таким как частота развертываний или качество кода.
- DORA Metrics сосредоточены на технических параметрах разработки, что делает его очень полезным для оптимизации DevOps/SRE практик
- SPACE охватывает технические аспекты (например, эффективность и поток) наряду с благополучием команды, предоставляя более целостное представление о продуктивности.
- DevEx прямо рассматривает технические препятствия (например, неэффективность инструментов), которые влияют на производительность и удовлетворенность разработчиков.

Продолжение сравнения этих разных подходов в следующем посте.

#Management #Devops #Management #Leadership #Processes #SRE #Software #Metrics #Productivity