Все слышали об этих сложных проблемах в информатике, и это моя любимая формулировка:


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

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

И это действительно сложно.

Техноболтовня

Как и во всех других отраслях, в программировании есть свой жаргон, облегчающий передачу своих мыслей другим.

Этот жаргон важен. Если мой коллега и я пытаемся выбрать между двумя разными алгоритмами для решения какой-то задачи, то мы можем сказать «вариант А имеет O(n^2) и минимальный оверхед, а вариант Б можно запилить за O(n log n), но с большими костами».

Одно предложение многое говорит о том, в каких случаях нужно использовать эти алгоритмы и как они реализованы:

• Вариант A подходит для случаев, когда количество входных данных мало.
  
• Вариант Б подходит для случаев, когда нужно работать с большим количеством входных данных, когда большие затраты на подготовку будут компенсированы более эффективным выполнением.
  
• Если нужно прогонять алгоритм циклически, то лучше выбрать вариант А, чтобы избежать дорогой подготовки.
  
• С помощью кэширования можно уменьшить затраты на подготовку в варианте Б.
  
• Вариант A, вероятно, сравнивает каждое входное значение с каждым выходным (например, для входного Х { для входного Y { если некое_условие(x, y) {… }}}).
  
• Вариант Б, вероятно, создаёт в начале дерево, а затем выполняет по нему линейный поиск.
  

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

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

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

Это я называю техноболтовнёй.

Скажу прямо: чаще всего эти подробности просто непонятны людям из других отраслей, они им не интересны.

Например, вы описываете новую классную фичу поиска кратчайшего пути из А в Б с помощью генерирования навигационной сетки и применения алгоритма А*. Не описывайте её так, как в предыдущем предложении. Скажите что-нибудь вроде «мы вычисляем возможные пути, а затем с помощью умных алгоритмов из игровой индустрии находим самый лучший маршрут».

Не имеет значения, что мы используем для этого А* (в отличие от Dijkstra или поиска сначала вширь), или что A* используется не только для того, чтобы NPC могли ходить по игровым мирам. Вашему собеседнику интересно лишь, что вы нашли хороший маршрут из А в Б и что мы используем надёжный инструмент, проверенный в других отраслях.



Не помешает также проиллюстрировать, что вы имеете в виду.

Я встречал много senior-программистов, которые с помощью технолоболтовни демонстрируют свой невероятный интеллект и превосходство над другими, и меня это очень раздражает.

Не поймите меня неправильно: иногда бывают ситуации, в которых люди, которые знают достаточно, чтобы быть опасными, говорят: «это слишком сложно, почему нельзя сделать Х?», и вам нужно показать им, что вы в этом специалист, а они не понимают, о чём говорят… Но сделать это можно правильно и неправильно.

Не удовлетворяйте своё эго с помощью техноболтовни, это отталкивает людей и создаёт нам плохую репутацию.

Проявляйте уважение

Плавно переходим к следующему пункту: не забывайте об уважении.

Большинство людей, с которыми я работаю, действительно умны и являются специалистам в своём деле. Но они не всегда обладают такими же знаниями и опытом в создании информационных систем.

Часто приходится выражаться проще (например, объясняя сложную задачу, над которой вы работаете), но не ведите себя снисходительно.

Когда «нормальный» человек спрашивает упомянутого выше разработчика, как работает какая-нибудь фича, тот часто отвечает: «это… сложно», и больше ничего не объясняет. Словно код настолько сложен, что тот, у кого нет 20 лет опыта в программировании, не способен ничего понять.

Не будьте этим разработчиком.

Лучше ответьте: «Я немного упрощу, но идея в том, что сначала мы делаем Х, затем Y, а потом Z. Есть ряд пограничных случаев, о которых нужно помнить (возможно, объясните один-два), но в целом так». Вы работаете с умными людьми, и если не впадаете в техноболтовню, они более чем способны вас понять.

Другая полезная методика: использовать непрограммиста в качестве референтной группы, эдакого воплощения «резиновой уточки». Если вы хотите предложить какое-то решение, вкратце опишите людям проблему и как вы предлагаете её решить, а затем спросите, могут ли они предложить вариант получше.

Наша компания занимается разработкой ЧПУ-станков, и когда речь заходит о задачах реального мира (например, вы пытаетесь реализовать компенсацию ширины реза), инженеры могут прекрасно анализировать проблемы, связанные с физикой и геометрией.

Персонифицируйте, преувеличивайте и используйте аналогии

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

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

Представим, что покупатель по имени Пётр хочет купить десяток спиннеров. Он идёт на www.example.com, добавляет спиннеры в корзину и нажимает «оформить» (большинство людей уже имеют опыт онлайн-покупок, так что можно опустить описание, как работают корзина и оформление заказа).

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

Есть ещё один парень (назовём его Олег), который постоянно спрашивает у Тани, появились ли новые заказы. Если появились, то Олег сообщает живым людям, что можно взять товары со стеллажей и передать Маше в почтовый отдел (Маша — живой человек), чтобы она отправила их Петру улиточной почтой.

Коля и Зина (рекомендательные системы) находятся в сговоре, так что когда заказ был размещён, Коля сообщит об этом Зине, чтобы она с помощью искусственного интеллекта и чёрной магии порекомендовала Петру другие товары.

Всё это звучит комично, и пример совершенно надуманный, но уверяю вас, что так будет лучше, чем рисовать большую сетевую диаграмму и говорить такие слова, как «веб-сервер», «архитектура с управлением по событиям» или Apache Kafka.

Другой пример. Когда вы пытаетесь описать неспециалисту, как работает алгоритм поиска пути, вы же не говорите «маршруты, которые мы уже посетили, получают большие веса», вы говорите «алгоритм не хочет снова идти по маршрутам, по которым он уже ходил».

Это неочевидно, но когда вы персонифицируете алгоритм поиска пути выражениями «хочет сделать Х» и «попытается избежать Y», это зачастую помогает людям понять.

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

Рисуйте симпатичные картинки

Звучит банально, но иногда одна картинка действительно заменяет тысячу слов.

Пару месяцев назад я проводил занятия по работе с радиостанцией, и женщине рядом со мной трудно было запомнить, какие кнопки нужно нажимать, чтобы ходить по меню на маленьком экране 16x2.

Я спросил, не нарисовать ли ей карту.

Она решила, что я просто насмехаюсь над ней.

Я не насмехался.

Я нашёл лист бумаги и вместе мы изобразили вот что:



Программист сразу поймёт, что эта «карта» является диаграммой конечного автомата. А тем, кто с этим не знаком, я только что объяснил фундаментальную методику из информатики и логику интерфейса радиостанции.

Однако женщине (и остальной группе) на это было наплевать. Для них это была карта, с помощью которой они могли ходить по меню.

Испытываешь какое-то странное удовлетворение, когда находишь способ объяснить кому-то сложную идею. Особенно когда человек способен понять, что в карте есть ошибка и нужно нажать и держать кнопку отмены, чтобы вернуться в состояние ожидания, потому что просто нажатие отмены возвращает в главное меню.

У меня на столе лежит нелинованный блокнот. Обычно я использую его для составления планов на день или для черновиков, но часто и для поясняющих иллюстраций. Если вы можете что-то нарисовать в ходе объяснения, это помогает убедиться, что все находятся на одной странице (намеренный каламбур), и что вы все говорите об одном, используя какие-то термины.

Я ускорил $НАЗВАНИЕ_ФИЧИ в 10 раз

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

С одной стороны, если кто-то спросит, чем вы занимались последнюю неделю, вы сможете сказать правду: «я добавил к lookup_something() кэширование, чтобы ускорить поиск, и перевёл алгоритм в detect_collisions() с O(n^2) на O(n log n)». Но велика вероятность, что вас вообще не поймут (см. главу про техноболтовню).

Или вы можете сказать: «делал разные улучшения производительности», но это звучит как отговорка и ваш начальник может задаться вопросом, зачем он вообще вас нанял.

Я часто слышу, как люди отвечают «я ускорил $НАЗВАНИЕ_ФИЧИ в 10 раз» (или ещё какое-то значение), и на этом останавливаются. Обычно это приводит к многочисленным поздравлениям от непрограммистов, но такой подход… немного вводит в заблуждение.

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

Также возникает вопрос: что именно вы сделали для повышения производительности в 10 раз? Это подозрительно специфическое число. Ваш код многократно выполнял одно и то же? Или он опрашивал (допустим, вы считывали информацию с оборудования или стороннего сайта) в 10 раз медленнее, чем должен был? Даже это уже ставит под сомнение ваши способности, потому что вы либо угадали (плохо) исходную частоту опроса, либо вы оставили производительность на прежнем уровне, при этом используете опрос вместо более эффективной системы под управлением событий.

Думаю, в такой ситуации лучше найти баланс между точностью и понятностью. Если вы внесли изменение, улучшающее алгоритмическую сложность части кода (например, detect_collisions() вместо O(n^2) получила сложность (O(n log n)), то можете сказать: «фича Х теперь должна масштабироваться на большее количество входных данных без такого повышения длительности выполнения, как прежде».

Нормально отвечать «Я не знаю»...

…но нужно затем добавить что-то вроде «но если дадите мне 5 минут, я смогу ответить».
Я часто с этим сталкиваюсь. Люди боятся показать свою неосведомлённость, и они предпочитают делать всё молча или что-то выдумывать.

Например, ваш начальник пришёл и сказал: «заказчик просит сделать фичу Х, это возможо? Если да, то сколько уйдёт времени?»

В 90 % случаев ему ответят «я не знаю», но это никак не поможет начальнику решить, стоит ли делать фичу. Он пришёл к вам, потому что вы специалист в соответствующей сфере и лучше можете ответить на вопрос.

Кто-то, напротив, сделает предположение или введёт в заблуждение (например, скажет: «да, можем сделать за 2-3 недели»), но в долгосрочной перспективе такой подход обычно не работает. В лучшем случае вы ошибётесь со сроком и задача выбьется из графика на пару недель, а в худшем случае вы потратите месяцы на разработку, а потом поймёте, что с текущей архитектурой эту фичу не реализовать.

Отличный способ потерять уважение людей.

А если бы вы ответили «я не уверен, но через 5-10 минут смогу точно ответить», то это скажет о том, что:

• Вы признаёте, что не знаете всего на свете (то есть не эгоист).
  
• Вы дорожите словом и не хотите давать ошибочные ответы.
  
• Вы уважаете собеседника и хотите потратить немного своего времени, чтобы ответить на его вопрос.
  
• Вы хороший человек :)
  

К тому же вы выигрываете себе достаточно времени, чтобы всё обдумать.

Это напоминает мне старую притчу:

(Обычно) другие не ждут от вас, что вы будете знать абсолютно всё о своей сфере деятельности, но они ожидают, что вы сможете исследовать вопрос и ответить в терминах, понятных другим.

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

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

На следующий день Начальник получает от Седобородого счёт на $5000. Начальник в ярости и отказывается платить. Седобородый утверждает, что это честная цена. Начальник отвечает, что будь цена честной, то пусть Седобородый детализирует счёт. Тот согласился, и принёс новый счёт…

Кувалда: $5

Знание, куда ударить по машине кувалдой: $4995

Любой может ввести запрос в Google. Но разработчик ПО знает, какие слова использовать и как интерпретировать результат.

Заключение

Эта статья не похожа на другие мои статьи, наполненные кодом, но иногда полезно вспомнить, что в этом мире есть многое другое помимо кода.

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

Кто-то скажет, что поднятая мной тема — это офисная политика и манипулирование чужим мнением о вас. Вот что я отвечу: ну… да. Но разве то же самое не скажешь про большинство случаев межличностного общения?

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