Три свойства хорошего примера в технологическом выступлении

daaf294687e645dc842690510d33b6f4.jpg

Ричард Фейнман в знаменитой книге «Вы, конечно, шутите, мистер Фейнман» поделился своим способом быстро понимать и оценивать новые вещи:

Я придумал схему, которой пользуюсь и по сей день, когда кто-то объясняет мне что-то, а я пытаюсь это понять: я придумываю примеры. Скажем, в комнату входят математики в чрезвычайно возбужденном состоянии с потрясающей теоремой. Пока они рассказывают мне условия этой теоремы, я в уме строю нечто, что подходит ко всем ее условиям. Это легко: у вас есть множество (один мяч), два непересекающихся множества (два мяча). Затем, по мере роста количества условий, мои мячики приобретают цвет, у них отрастают волосы или что-нибудь еще. Наконец, математики выдают какую-то дурацкую теорему о мяче, которая совсем не подходит к моему волосатому зеленому мячику. Тогда я говорю: «Ложь!»


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

Пояснение и развлечение


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

  • Те, кому всё, о чем вы говорите, просто и понятно. Они быстро уходят в телефон, чтобы никогда оттуда не вернуться.
  • Те, кто, наоборот, с большим трудом следят за ходом вашей мысли. Возможно, тема для них слишком нова или превосходит их интеллектуальные возможности. Эти тоже быстро уходят в телефон.
  • Наконец, люди, которым в принципе не очень интересна тема, а на доклад они забрели по ошибке или от безысходности. Вы ведь, посещая конференции, наверняка замечали, что неинтересные доклады часто идут в параллель? Это тот самый случай.


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

Доказательная сила


Индукция (переход от частного к общему) вообще свойственна людям гораздо больше, чем дедукция (переход от общего к частному), на чём в своё время и построил успешный бизнес Шерлок Холмс. Даже те, кто считает себя думающими и объективными, всё равно склонны делать обобщения на основе недостаточных данных. Чем интереснее история, тем легче слушатели обобщат её выводы на все жизненные ситуации.
Было бы ошибкой думать ©, что IT чем-то отличается от других областей и приводить убедительные примеры здесь труднее или не нужно. Ниже я попробую (на примерах, как же иначе) показать, как это делается в технической презентации, и заодно сформулировать признаки хорошего примера. Надеюсь, они вам пригодятся.

Хороший пример парадоксален


Хороший пример бросает аудитории интеллектуальный вызов. Когда что-то очевидное оказывается вдруг неверным, это всегда запоминается и часто служит пищей для последующего анализа и самостоятельного поиска. Пример возьмём из выступления Алексея Шипилёва о хэшкоде java.lang.String:


Интересующий нас фрагмент длится две минуты и начинается с 19:53, вот ссылка на youtube с точным моментом начала.

Две одинаковые по длине и составу символов строчки, будучи помещены в один и тот же бенчмарк, многократно вычисляющий их хэшкод, производят радикально разные по скорости результаты. WTF? — только успевает подумать зритель, и тут всё проясняется: оказывается хэшкод кэшируется, но, если он равен нулю, система считает, что его ещё не вычисляли. Таким образом, с вероятностью 2–32 строчке не повезёт, и её хэшкод, равный нулю, будет пересчитываться каждый раз при вызове. Именно такой невезучей строчкой и оказалась «сверхинструментом пренебрегшая».

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

Часто обычный пример можно превратить в парадоксальный, изменив порядок изложения: сначала расскажите симптомы, а потом уже объясните, откуда они взялись. Так всегда интереснее!

Хороший пример масштабен


История из жизни крупной компании, стоившая (или, наоборот, принесшая) много денег, или хотя бы послужившая причиной карьерного поворота известного человека, хоть как-то резонансная — лучше, чем рассказ о неизвестном Васе Пупкине. Совсем хорошо, если вам удастся показать эти события под новым углом.

Посмотрите версию известных событий про 41 оттенок синего в изложении Джейсона Коэна:

Интересующий нас фрагмент длится 4 минуты и начинается с 18:42, вот точная ссылка на начало.

Для тех, кому смотреть неудобно, вот краткое изложение.
Дизайнер Даг Боумэн работал в Гугле и делал gmail. Там, в частности, есть рекламные ссылки. Бывшая тогда его начальницей Марисса Майер потребовала провести эксперимент на пользователях (A/B тест), чтобы найти самый кликабельный цвет рекламных ссылок из 41 возможного варианта. Ок, сказал Даг и уволился, потому что не хотел заниматься такой ерундой. А эксперимент провели без него, и цвет был выбран именно так.

Далее Коэн объясняет, что и математически Даг прав, а Марисса — нет. Если проводить эксперименты со значимостью 0.95, то вероятность того, что хоть в одном из них случится false positive, то есть случайная победа, равна 1 — 0.9541 ~= 0.88. То есть почти наверняка там будет не реальный победитель, а рандом.

Это история про Гугл, величественная и прекрасная Марисса Майер в ней предстаёт дурочкой, а миллиарды пользователей Гугла — подопытными кроликами. Это одновременно масштабно и парадоксально. И когда докладчик призывает слушателей не повторять ошибку Гугла и не пытаться перебором A/B тестов найти выигрывающую комбинацию параметров, другие доказательства людям вроде как и не нужны. Если можете проиллюстрировать свою мысль масштабным примером, лучше сделать именно так.

Хороший пример пересекается с реальностью


Детали из реальной жизни придают рассказу правдоподобия, они служат якорями, помогающими фокусировать внимание.

В последнее время я смотрел и помогал готовить несколько презентаций на тему примитивов синхронизации и управления параллельными потоками. Естественная задача, которая при этом всплывает, — задача о читателях и писателях.

Кто подзабыл, вот её смысл.
Есть область памяти, позволяющая чтение и запись. Несколько потоков имеют к ней доступ, при этом одновременно могут читать сколько угодно потоков, но писать — только один. Как обеспечить такой режим доступа? Более подробно — в википедии.

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

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

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

В этом же контексте часто упоминается инверсия приоритетов, и вот про неё хороший пример есть. В 1997 году компьютер марсохода Pathfinder внезапно стал уходить в ребут, при этом ему не удавалось завершить цикл сбора и отправки очередной порции данных с исследовательских датчиков.

Расследование показало, что

Метеорологический датчик, работающий с низшим из возможных приоритетов, берёт лок на общую память, а затем его вытесняет с процессора самодиагностика, имеющая средний приоритет. Самодиагностика работает дольше, чем ожидалось, и высокоприоритетный процесс, собирающий все данные со всех датчиков (через общую память, которая залочена), не успевает закончиться до временной отсечки «конец цикла». После чего система считает, что всё как-то непоправимо сломалось и перезагружается. Команда разработки смогла починить проблему дистанционно, молодцы.


Инверсия приоритетов — понятие довольно простое, но всё равно разумно сопроводить его примером. А к этому конкретному примеру можно приложить красивые фотографии. Те, кто всё это время ломал голову, что за пейзаж изображён на стартовой картинке и какое отношение он имеет к теме презентаций, сейчас узнают, что это один из снимков, сделанных Pathfinder’ом. Возможный недостаток: не слишком ли эта история заезжена? Все её проходили на втором-третьем курсе, или всё-таки для кого-то она оказалась новостью?

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


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

Бонус для внимательных читателей, которые добрались до конца


Вы заметили ошибку в рассуждениях Джейсона Коэна?

А она есть.

Он говорит о значимости в 0.95, но у Гугла достаточно пользователей и вычислительных мощностей, чтобы довести эксперимент до 0.999, даже когда приходится делить всех пользователей на 41 эксперимент. И в этом случае вероятность false positive’а уже гораздо меньше: 1 — 0.99941 ~= 0.05, с этим вполне можно жить. В Бинге, кстати, рапортовали, что цвет рекламных ссылок тоже крутили, и сколько-то миллионов долларов в год оттуда выжали. Так что пример не обязан быть корректным, чтобы хорошо работать. Тем более, по существу-то Коэн советует правильное и хорошее.

Ссылки на упомянутые в тексте темы


Что случилось на Марсе: записки участников запуска Pathfinder’а. Раз, два (мне одному кажется, что они противоречат друг другу?…)
Кто такой Джейсон Коэн.
Статья Рона Кохави со товарищи, в которой упоминаются успешные эксперименты с цветом ссылок.

© Megamozg