39 лет (Рубрика #Retrospective)

Сегодня мне исполнилось 39 лет:) Кажется, что это достаточно много, но мне до сих пор кажется, что я только начинаю знакомиться с окружающим миром:) И в этом мне помогает моя семья:
- Жена в прошедшем году изучала психоаналитическое бизнес-консультирование и местами мне казалось, что и я тоже. Она успешно закончила первый курс магистратуры и начала делать дипломную работу про профессиональную идентификацию продакт менеджеров:)
- Старший сын стал первокурсником, поступив на геймдизайн. Я начал читать больше книг по геймдизайну, чтобы быть способным поддерживать непринужденную беседу
- Средний сын заинтересовался футболом, хокеем и баскетболом. Теперь я хожу с ним на стадион и смотрю матчи футбольного и хоккейного ЦСКА, а на баскетбольный ЦСКА мы пойдем через 2 недели:)
- Младший сын научился считать и складывать в четыре года - он вообще быстро учится, поэтому я ему рассказываю научно-популярные истории о мире вокруг нас.
- Еще у нас в семье есть собака и кошка, причем кошка появилась относительно недавно. Теперь я понимаю фразу "живут как кошка с собакой" гораздо лучше:)

Если говорить про работу, то впечатления смешанные
- Моя команда радовала меня своими успехами - ребята действительно хорошо поработали и достигли крутых результатов, я писал об этом в посте про свой юбилей "0b1000 в Т-Банке"
- На уровне всей компании часть моих инициатив зашла не так хорошо, как хотелось бы мне. Мне кажется, что иногда мое особое мнение об идеальном результате мешает достигать just enough результатов:)

Если говорить про творческую часть, то за прошедший год я
- Прочитал порядка 100 книг
- Написал кучу постов на разные ITшные темы (здесь и на Medium)
- Снял порядка 60 часов видео с крутыми гостями
- Прошел курс МИФа для начинающих писателей
- Определился с четырьмя темами книг и нашел для каждой из них соавтора - осталось их только дописать:)

В общем, до 40 надо много успеть сделать, поэтому я не планирую снижать обороты.

#SelfDevelopment

Code of Leadership #28 - Interview with Vadim Goncharov about Design in Software Development (Рубрика #Management)

В этом выпуске подкаста ко мне пришел Вадим Гончаров поговорить про свой путь в ИТ и как на это повлияло увлечение дизайном. Вадим в веб-разработке больше 15 лет. В 2008 руководил собственной веб-студией. С 2013 работал в VK, а в 2017 присоединился к Т-Банку, где в качестве технического руководителя запускал "Тинькофф Журнал", самое крупное медиа про деньги в России. С 2020 Вадим начал руководить разработкой интерактивных спецпроектов и игр в мобильном приложении Т-Банка. Он проповедует lifelong learning: закончил МИЭМ, учился в Британке и Вышке, а сейчас учится в Сколково на программе МБА. Эпизод также доступен в Yandex Music и podster.fm

Мы обсудили следующие темы
- Ранние годы Вадима и учебу в школе и универе: Вадим всегда увлекался играми, учился в физмат лицее, а потом пошел в МИЭМ
- Влияние образования на карьеру: университет дал Вадиму базовые знания и умение учиться. Он подчеркивает важность понимания взаимосвязи различных идей и концепций.
- Создание агентства дизайна: после школы Вадим основал агентство дизайна в Подольске, которое занималось разработкой и дизайном сайтов
- Принципы работы и качество: В агентстве уделялось большое внимание качеству и эстетике. Вадим подчеркивает важность развития вкуса и поиска хороших специалистов.
- Влияние книг и обучения: Вадим рассказывает о влиянии различных книг, что повлияли на его подход к дизайну и разработке.
- Сертификация и фреймворки: обсуждается важность сертификации в программировании и изучения различных фреймворков.
- Визуализация данных: Вадим говорит о важности визуализации данных и упоминает работы Эдварда Тафта.
- Взаимодействие дизайнеров и разработчиков: Вадим подчеркивает важность синергии между дизайнерами и разработчиками для создания качественных продуктов.
- Опыт работы в Mail.ru: Вадим рассказывает о своем опыте работы в Mail.ru, где он развивался как фронтенд-разработчик и тесно сотрудничал с дизайнерами.
- Обучение в Британке: Вадим рассказывает о том, как обучение в Британской школе дизайна прокачало его скиллыы

Список рекомендаций для изучения
- Программист Прагматик. Эндрю Хант
- Совершенный код. Стив Макконнелл
- Чистый Код. Роберт Мартин
- Release It! Second Edition. Design and Deploy Production-Ready Software. Michael Nygard
- Дизайн привычных вещей. Дональд Норман
- Дизайн для реального мира. Виктор Папанек
- Дизайн-мышление в бизнесе. Тим Браун
- Beautiful Evidence. Edward Tufte
- Visual Explanations: Images and Quantities, Evidence and Narrative. Edward Tufte
- Envisioning Information. Edward Tufte
- The Visual Display of Quantitative Information. Edward Tufte
- Look Inside: Cutaway Illustrations and Visual Storytelling. Juan Velasco and Samuel Velasco

#Management #Leadership #Software #Processes #Retrospective #Design #Processes #SelfDevelopment

Как я начал публично выступать (Рубрика #LifeStory)

Вчера я был на ИТ-квартирнике от наших devrel, который они проводили для людей, кто много делает для технического бренда компании. Мероприятие было теплым и ламповым - я пообщался со старыми знакомыми и похлопал коллегам, что победили в разных номинациях и поехал домой. Но пока ехал, я решил свпомнить о том, как я поборол страх выступлений и впервые вышел на сцену большой конференции, которой оказалась Teamlead Conf.

К этому привели события весны 2018 года, когда я решил в марте с друзьями съездить в Сорочаны покататься на сноуборде. Вроде это должна была быть рядовая поездка, ведь катать я начал лет за девять до этого, пару раз ездил в Альпы, достаточно много катал в Подмосковье. Но тут все пошло не по плану - за мной утром, как мы и договаривались заехали друзья и мы поехали на каталку. В ту ночь я поспал пару часов, но считал, что этого достаточно. Незадолго до этого я купил жесткую и быструю доску и очень хотел ее обкатать ...

Дальше я помню, как я очнулся на пассажирском сидении автомобиля, у меня болела голова, грудь, нога ...
Я повернулся к своему другу, что вел машину и задал вопрос "А где мы и что происходит?". Он посмотрел на меня и, как бы нехотя, начал рассказывать, что мы поехали на склон, приехали и начали кататься, прошел где-то часик, а потом один из них увидел как кого-то похожего на меня увозят на снегокате в сторону медпункта. Дальше они пришли туда и увидели, как мне оказывают помощь. В какой-то момент я очнулся и дальше начал задавать вопросы в стиле "А где мы и что происходит?", мне на них отвечали, но через 30 секунд происходил reboot и дальше я задавал их по новой. Мои друзья решают отвезти меня в Москву, чтобы вызвать для меня скорую и положить в московскую больницу. Медперсонал дает совет по дороге общаться со мной и отвечать на повторяющиеся вопросы, ожидая, что через N итераций ребуты перестанут происходить и память схватится.

Собственно, в какой-то момент так и произошло, где-то на полпути по дороге в Москву. Дальше мы доехали до нашего офиса на Водном, к которому мы вызвали скорую. Дальше меня увезли и лечили около недели от ушиба головного мозга.

Из этого происшествия я вынес несколько важных уроков
1) Не стоит в плохой форме заниматься экстремальными видами спорта
2) Даже если ты профи в чем-то, то техника безопасности наше все (теперь шлем всегда со мной)
3) Очень тяжело чувствовать себя как главный герой из романа "Цветы для Элджернона" ("Flowers for Algernon")
4) Через месяц, когда из основных пост-эффектов остались только очки, я решил, что надо начать больше делится своим опытом с окружающими - чтобы были материальные подтверждения для потенциальных внуков, что их дедушка до того, как впал в маразм, был достаточно прошаренным :)

Осенью 2018 года я уже выступил на питерском Teamlead Conf, где рассказывал про то, как мы выстраивали процессы разработки в наших фронтовых командах. Если найти запись этого выступления, то видно, что я сильно волнуюсь и мне сложно дается выступление на публике. Но с тех пор много воды утекло, поэтому сейчас публичные выступления на русском для меня это просто. В конце 2019 года я планировал в 2020 году податься на западные конференции и съездить выступить ... но не сложилось. Но из этих публичных выступлений вырос мой бложик TellMeAbout.Tech, а также этот tg канал.

P.S.
Как мне сказал однажды мой лучший друг: "В любых ситуациях надо попробовать увидеть лучшее, а не фокусироваться на проблемах". Кажется, что я внял совету и теперь вспоминаю про то падение, не как о причине серьезной травмы, а как триггер серии событий, что привели меня к знакомству с моей будущей женой. Мы с ней познакомились и начали общаться на первой конференции ArchDays, которую я открывал в главном зале, а она была ведущей второго зала:)

#Storytelling #PublicSpeaking #Leadership #SelfDevelopment

Teaching Software Architecture Design - Building Intuition - Part I (Рубрика #Architecture)

Прочитал недавно интересный whitepaper про обучение архитектуре от Gaurav Agerwala, Len Bass. Заинтересовался я этой статьей из-за ее автора - Len Bass, который является соавтором классической книги "Software Architecture in Practice" и преподает в Carnegie Mellon University. И могу отметить, что я не был разочарован - подход авторов к обучению чем-то напоминает тот процесс system design interview, что мы практикуем у себя в компании:) Кстати, описание подхода есть на Github

Ну а теперь давайте перейдем к самой статье.

Исследователи в статье рассказывают о своем методе и структуре курса, который ставит себе целью демистифицировать процесс проектирования софта и помочь студентам думать аналитически, одновременно развивая интуицию, о компромиссных решениях, принимаемых на этапе проектирования. Но начинается все с введения, где авторы вспоминают про разные процессы проектирования
- ACDM (Architecure Centric Design Method) - итеративный подход из середины двухтысячных к проектированию софта, который ставит проектирование в центр процессов разработки. Подробнее можно почитать здесь
- ADD (Attribute Driven Design) - системная методология из начала двухтысячных для проектирования софта, которая фокусируется на внедрении и приоритизации атрибутов качества (quality attributes) одновременно с функциональными требованиями. Цель в том, чтобы создать эффективную архитектуру, которая будет удовлетворять как функциональные, так и нефункциональные требования.

К обоим подходам имел отношение Len Bass, но для студентов он решил сделать процесс SADM (Software Architecture Design Method), который доступен на GitHub и который фокусируется на ключевых активностях по идентификации и анализу верхнеуровнего дизайна на основе требований. В этом он похож на ADD, но он менее формален и фокусируется на том, чтобы помочь студентам наработать интуицию. Здесь фокус скорее не на отдельных шагах сложного процесса, а на практике в дизайне сложных систем, где много неизвестных. Сама суть метода SADM в том, чтобы дать дизайнером инструмент для работы с этими неизвестными. SADM - это метод для декомпозиции системы или компонета, который выглядит так
- У нас на входе есть требования
- Мы строим контекстную диаграмму
- Дальше выбираем scope для декомпозиции
- Предлагаем гипотезу того, как можно сделать декомпозицию
- Проверяем, что при этом мы удовлетворяем функциональные требования (сценарии)
- Проверяем, что при этом удовлетворяем атрибуты качества (кстати, в Github репозитории есть презентации про такие атрибуты как availability, performance, observability, security, modifiability, integrability)
- Если у нас есть неизвестные моменты, то мы заносим их в таблицу с process steps, чтобы разобраться с ними позже
Такая декомпозиция идет пока мы не декомпозировали систему на части так, чтобы закрыть все требования.

А теперь немного про process steps, куда мы переместили моменты, по которым требовалась дополнительная работа. Собственно, там могут быть 3 активности
- Отложенные решения - это решения, что мы отложили до появления новой информации. Например, использовать DBaaS решение или разворачивать самому кастомную технологию. Это решение может принимать после некоторого количества итерацаций SADM процесса
- Исследовательские активности - возможно требуется дополнительный сбор информации и поиск по внешним источникам, например, варианты подключаемых устройств к умному дому при дизайне IoT системы
- Активности по тестированию - некоторые решения стоит принимать после построения прототипа и проверки гипотез на нем.

Продолжение разбора статьи в следующем посте.

#Architecture #Software #Engineering #SelfDevelopment

Teaching Software Architecture Design - Building Intuition - Part II (Рубрика #Architecture)

Продолжая первый пост с разбором whtepaper про обучение архитектуре, здесь я расскажу про оставшуюся часть статьи

Анализ гипотез по отношению к требованиям в итоге должен вести к
- Развитию инженерного подхода к принятию дизайн решений
- Повышению уверенности инжнеров, что предложенный ими диазайн удовлетворяет требованиям
- Способствует дискуссии о компромиссах, которые принимаются при выборе того или иного варианта дизайна

Для этого авторы предлагают использовать подход с опровержимой аргументацией (defeasible argumentation), в которой аргументы принимаются на текущий момент, если они звучат разумно и приняты на основе доказательств, что есть на текущий момент. Но эти аргументы могут быть пересмотрены при появлении новых данных. Этот подход очень напоминает то, как работают люди, что проектируют софт
- Они опираются на текущие данные и принимают решения в этом контексте
- При появлении новой информации они могут увидеть, что это противоречит предпосылкам, на которых был основан дизайн раньше
- А это потребует принятия нового решения, что изменит старое
Обычно такой процесс реализуется с использованием подходов RFC и ADR, где
- RFC - это request for comments или подход коммитетов к принятию решения
- ADR - это architecture decision record, что добавляется в список принятых архитектурных решений.

В рамках SADM студенты учатся задавать критические вопросы по отношению к дизайн гипотезам, практикуясь в формулировании аргументации, а также в ее опровержении. Причем здесь есть 2 формата аргументов

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

2) Аргументы для анализа атрибутов качества
Эта часть посложнее, так как требует много лет опыта, чтобы приводить неотразимые аргументы. А у начинающих часто аргументы звучат в формате "так работает google/aws/netflix", а значит это масштабируется, что является очень слабым аргументом. Здесь авторы предлагают студентам делать отсылки к референсной архитектуре, а также общепринятым архитектурным паттернам. Например, во второй части книги "Software Architecture in Practice" есть примеры паттернов, что приведены в свзяи с теми атрибутами качества, которые они поддерживают. Для использования паттернов можно использовать следующий подход
- Показать, как предлагаемая архитектура является примером задокументированного шаблона или эталонной архитектуры.
- Показать, что шаблон или эталонная архитектура, как известно, удовлетворяют указанному атрибуту качества.
Критические вопросы, которые студенты могут задавать по этим аргументам звучат примерно так
- Включает ли предлагаемая архитектура другие паттерны, которые отрицательно влияют на атрибут качества?
- Мешает ли предлагаемый шаблон/эталонная архитектура другому требованию к системе?

Авторы давали студентам дизайнить решения из разных индустрий, что приводило к тому, что баланс между атрибутами качества каждый раз был разный. Это позволило студентам научиться анализировать требования, выдвигать дизайн-гипотезы, а также составлять аргументацию в поддержку своих гипотез. В общем, цель развития интуиции при принятии дизайн-решений была достигнута.

P.S.
Мне кажется, что здесь описан логичный и легкий процесс того, как можно подтянуть свои умения в дизайне сложных систем:)

#Architecture #Software #Engineering #SelfDevelopment

Недавно выступал на конфе имени Андрея Смирнова из X5, где рассказывал про soft skills и важности баланса между ними и hard skills. На записи есть проблемы с качеством звука, поэтому краткое саммари того, что я рассказывал такое
1) Эволюция разработки и роль софтов
- Разработка за последние 20 лет стала сложнее.
- В современных компаниях разработчики должны проектировать системы, писать код и тесты.
- Важность коммуникации и взаимодействия между различными ролями в разработке.
2) Pipeline Driven Organization и абстракции
- Pipeline Organization: интеграция различных ролей в начале процесса.
- Нам нужно использовать абстракции для упрощения работы, но все равно остается необходимость взаимодействия с деталями.
- Важность понимания под капотом систем и взаимодействия с разработчиками.
3) Сложность современного мира и коммуникация
- Мир меняется быстро, что требует постоянной адаптации.
- Коммуникация становится ключевым фактором в сложных и хаотичных условиях.
- Конечно можно работать на одном уровне, но часто люди хотят активного роста.
4) Рост в инженерии и лидерство
- Возможность роста в инженерии через индивидуальные проекты и менеджмент.
- Важность лидерских качеств и умения вести за собой команду.
- Инициатива о повышении исходит от самих сотрудников.
5) Личный опыт и планирование роста
- Личный опыт становления руководителем и важность планирования времени.
- Умение брать ответственность и доводить дела до конца.
- Важность коммуникационных навыков и навыков переговоров.
6) Мотивация и планирование
- Важно понимать, зачем ты делаешь то, что делаешь.
- Поддерживай мотивацию окружающих, особенно если ты лидер.
- Планирование помогает структурировать задачи и достигать целей.
7) Матрица Эйзенхауэра
- Важные и срочные задачи решаются сразу.
- Важные, но не срочные задачи откладываются на потом.
- Срочные, но не важные задачи можно делегировать.
- Цели должны быть амбициозными и достижимыми.
😍 Подход от желаемого результата (working backwards)
- Начинайте с желаемого результата, а не с текущего состояния.
- Стройте шаги от цели к текущему состоянию, а не наоборот.
• Это помогает избежать ментальных блокировок и достигать амбициозных целей.
9) Проектный менеджмент
- Проектный менеджмент полезен для больших задач с большими затратами на координацию
- Важно уметь использовать проектный менеджмент для достижения целей.
10) Принятие ответственности
- Признайте и примите ответственность за свои действия.
- Четко определите свои обязанности и цели.
- Фокусируйтесь на том, что можете контролировать
11) Решение проблем и рефлексия
- Решайте проблемы, а не откладывайте их.
- Учитесь на своих и чужих ошибках.
- Будьте устойчивы к проблемам и показывайте пример.
12) Развитие навыков коммуникации
- Активное слушание помогает лучше понимать собеседника.
- Адаптируйте стиль коммуникации под аудиторию.
- Важно понимать, что хочет услышать аудитория, и адаптировать свои выступления.
13) Проблемы с ясностью и публичными выступлениями
- Обсуждение важности ясности в речи и публичных выступлениях.
- Личный опыт выступлений на конференциях и трудности с эмоциями.
- Важность фидбека и рефлексии для развития коммуникационных навыков.
14) Планирование и чекпоинты
- Идея планирования с чекпоинтами для достижения больших целей.
- Личный опыт написания постов и создания книг.
- Важность фиксации результатов и планирования для достижения успеха.
15) Теоретический и практический подходы
- Различие между теоретическим и практическим подходом к решению проблем.
- Личный опыт работы с теоретическими и практическими методами.
- Важность фиксации и повторения результатов для роста и развития.
16) Лидерство и софт скилы
- Софт скилы важны как для инженеров, так и для лидеров.
- От высокогрейдового инженера сейчас ожидается лидерская проактивная позиция
- Для достижения амбициозных результатов необходимы лидерские качества и эффективные коммуникации.
- Без этих навыков сложно достичь масштабных результатов.

#Management #Leadership #Software #Processes #SelfDevelopment

Стипендия Т-Образования (Рубрика #Edu)

Уже в четвертый раз открылась ежегодная стипендиальная программа для талантливых студентов. Она доступна для студентов российских вузов очной формы обучения и любого курса, кроме выпускного. Для попадания в программу нужно будет пройти отбор (экзамен, портфоли и интервью), причем пройти экзамен и подготовить портфолио надо до 7 апреля включительно. В программе есть 2 трека: аналитика и разработка.
Для тех, кто получит стипендию будут доступны плюшки в виде
- 25к рублей в месяц в течение учебного года
- Ментор в виде сотрудника Т-Банка
- Доступ к образовательным материалам компании, куда входят курсы, лекции и т.д., а также приглашения на закрытые отраслевые мероприятия
- Упрощенный отбор в штат на работу в Т-Банке после окончания стипендии

В общем, если бы в мое бытие студентом была такая программа, то я бы точно попробовал в ней поучаствовать (но скорее всего не прошел по конкурсу).

P.S.
Если вспоминать про стипендиатов прошлых лет, то набор их достижений на школьном и университетском уровне действительно впечатляет. Мне нравится, что мы поддерживаем студентов в их стремлении к получению качественного образования, а также что многие из них после этого попадают к нам в штат и показывают хорошие результаты уже в работе.

#Edu #SelfDevelopment

"Дети Солнца" в театре-сцене "Мельников" (Рубрика #Culture)

На прошлой неделе я был на предпоказе этого спектакля в постаноке молодого режиссера Лизы Дороничевой на сцене Театра — Сцены "Мельников". Спектакль основан на пьессе Максима Горького, который написал ее 120 лет назад сразу после событий Кровавого воскресенья. Я не большой знаток театра, но могу сказать, что постановка мне понравилась, особенно первый акт, в котором мы знакомимся с бытом ученого Павла Протасова, представителя интеллегенции, который полностью погружен в свои исследования и обращает мало внимания на происходяшее вокруг. Мы видим идеализм и стремление к прогрессу Павла, но это имеет мало общего с реальной жизнью и проблемами окружающих, которых в пьессе достаточно много: безответная любовь, семейные конфликты и социальные противоречия, а также эпидемия холеры. Герои пьессы сталкиваются с одиночеством и невозможностью найти общий язык как между собой, так и с абстрактным народом. Второй акт разворачивает основные идеи пьесы, поэтому получается тяжелым и мы видим
- Разрыв между интеллигенцией и народом: мы видим пропасть между образованной элитой, мечтающей о светлом будущем, и простыми людьми, живущими в бедности и невежестве.
- Идеализм и реальность: герои стремятся к высоким идеалом, но оторванность от реальной жизни приводит к трагедии
- Социальное неравенство: мы видим разрыв между Павлом и его слугами, что усугубляет непонимание и приводит к социальным противоречиям
- Любовь и одиночество: Личные отношения героев отражают их внутренние конфликты и неспособность к взаимопониманию.
- Критика утопических идей: в конце пьессы мы видим как утопические идеалы разваливаются от контакта с реальным миром

Интересно, что название "Дети солнца" символизирует стремление героев к знаниям и прогрессу, но также указывает на их оторванность от реальности. Солнце становится метафорой иллюзорного света, который ослепляет героев, мешая им видеть окружающий мир. В самой постановке этот солнечный свет играет ключевую роль - он светит в красивое окно, иногда обжигающе ярко, иногда сквозь дождь, а в начале второго акта его просто нет с нами, что показывает, что настали тяжелые дни.

Отдельно отмечу, что постановка выполнена так, что мы оказываемся, фактически, вне времени и если не знать историю написания пьесы, то ни за что не поверишь, что ей 120 лет:)

P.S.
Кстати, художественным руководителем Театра на Бронной и Театра — Сцена «Мельников» является Константин Богомолов, который осенью прошлого года рассказывал о проектах нового сезона и где было упоминание о "Детях Солнца".

#Theater #Culture #SelfDevelopment

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