Для начала немного обо мне: я и практикующий дантист, и разработчик ПО. Со вторника по четверг я пишу код, а с пятницы по воскресенье принимаю пациентов. До того, как стать дантистом, я работал в таких компаниях, как Allstate Insurance, Lockheed Martin и ICS. Освоив обе эти профессии, я заметил, что разработчики ПО могут многому научиться у дантистов и наоборот. Я решил записать эти уроки в надежде, что они кому-то могут помочь. Это просто общие рекомендации — не стоит рассчитывать, что они идеально подходят для любой ситуации.

▍ Dx-навыки важнее, чем Tx-навыки

Хирург может иметь самые ловкие руки в мире, но это ничего не стоит, если он не знает, что делает и почему это делает. В медицине/лечении зубов мы ценим способность врачей диагностировать (diagnose, Dx) гораздо больше, чем их способность просто лечить (treat, Tx).

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

Поэтому когда я собеседую кандидата на должность разработчика, то обычно не прошу его писать новый код. Он удалённо подключается к VM, в которой запущен полный SDK, анализирует код с несколькими багами и объясняет, почему возникают баги.

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

▍ Клиенты должны явным образом давать согласие на принятие очень плохих решений

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

Я считаю, что такой принцип следует применять и в разработке ПО. Очень часто у клиентов возникают очень плохие идеи, и все инженеры понимают это. Можно проводить совещания, на которых эта тема будет подниматься множество раз, но клиент просто игнорирует все доводы, чтобы сэкономить. На такой случай я рекомендую составить очень простую форму согласия. Это необязательно должен быть юридический документ или контракт, и форма не должна быть особо длинной. В ней просто должно быть написано: «Я, имярек, после обсуждения с инженерами понимаю, что запись экрана всех пользователей приложения — очень плохая идея», плюс, возможно, несколько примеров последствий такого решения.

Смысл вот в чём: большинство людей, особенно клиенты, ненавидят, когда им говорят «Ну я же говорил». После подписания этой формы такой потребности не возникнет. Клиент будет знать, что вы были вынуждены попросить его подписать форму; и он запомнит это, даже если не захочет этого признавать. Больше не будет никаких игр в «обвини другого», потому что клиент уже будет знать, что наделал, и вам не придётся напоминать ему об этом, даже если он не признает этого вслух.

▍ Замена (некоторых) совещаний тестами

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

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

То же самое можно сделать и с доброй частью совещаний. Допустим, вы управляете двадцатью с лишним разработчиками и вам нужно создать новое правило, например, «у всех баг-репортов, имеющих статус resolved, в комментариях должен быть id коммита с патчем». Если вы разошлёте письма, то большинство людей не прочитают их и продолжат менять статус багов без id коммитов. Если вы проведёте совещание, то оно отнимет у каждого сотрудника не только по 30-60 минут, но и то время, которое необходимо ему для возвращения «в колею». Если же устроить обязательный для прохождения, но короткий тест, то разработчики не только смогут проходить его между задачами, но и с большей вероятностью прочитают презентацию/документ вместо того, чтобы витать в облаках на протяжении всего совещания. Тест должен оцениваться, а не быть простым опросом. Почему? Потому что если вам нужны отзывы о новой политике, то я гарантирую, что люди поделятся своим мнением, если будут недовольны полученной в тесте оценкой.

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

Не так давно я анализировал рентгеновские снимки зубов одной своей пациентки и заметил, что пломбы выглядят очень плохо. Было похоже на то, как будто врач не знал, как пользоваться матрицей для нанесения композита. Однако изучив рот пациентки, я понял, в чём дело: её зубы имели такие смещения, что было очень трудно наносить композит и, учитывая условия, ставивший пломбы врач проделал потрясающую работу. Большинство врачей не оценивают работу своих коллег, не получив полную картину. Как бы нам ни хотелось сказать: «Ха! Ужасный врач! Я бы справился лучше!», нас не было рядом при выполнении процедуры и мы не можем судить другого врача, пока не узнаем историю целиком. Поэтому когда мы видим результаты лечения, которые выглядят странно, то первым делом думаем: «Наверно, что-то заставило врача сделать именно так».

Думаю, тот же принцип должен применяться и при анализе кода. Легко посмотреть на код и сказать: «Ого! Этот код ужасен! Разработчик должен был сделать X вместо Y», не изучив предварительно остальные обстоятельства. Например, когда-то давно я анализировал код на Java, который выглядел ужасно. В нём была куча целочисленных констант, хотя разумнее было бы использовать enum. Первым делом я подумал: «Он что, не знает о enum?», а потом спросил у коллеги, в чём может быть причина. Он ответил: «А, да, этот код писали до Java 5, поэтому он не мог использовать enum». И тогда я осознал, что не должен судить разработчика, ведь он сделал максимум, что было возможно в его условиях.

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

▍ Лучше говорить с людьми, которые пользуются продуктом, а не с теми, кто его создавал

Очень часто врачам нужна помощь в использовании стоматологического материала. Мы можем получить базовую информацию о применении этого материала от производителя, но проблема в том, что производители не используют покупаемые нами материалы в повседневной работе. Да, они проводят тестирование, но не обладают знаниями, как использовать материалы в клинических условиях. Поэтому мы обычно обращаемся за советами и подсказками по технике к другим врачам. У вас возникают проблемы с извлечением матрицы Garrison? Воспользуйтесь зажимом, ухватитесь за кольцо и проверните его. Трудно сделать слепок нёбного свода? Разместите шарик альгинатной массы непосредственно на своде, а затем прижмите пластину. Действительно полезные советы можно получить только от других врачей и техников.

Тот же принцип актуален и в разработке ПО. Только то, что компания разрабатывает SDK/API/тулкит, не означает, что она будет наилучшим источником информации о решении проблемы, с которой вы столкнётесь. Лучше всего обсуждать их с коллегами-разработчиками, использующими это ПО. Иногда их «best practices» лучше, чем у компании, создавшей продукт. У некоторых компаний есть строгие политики, запрещающие разработчикам говорить о проблемах с внешними разработчиками. Я считаю, что в долговременной перспективе это оказывается ошибкой, потому что общение с разработчиками, использующими SDK, может быть бесценным ресурсом, а такие строгие политики могут нивелировать преимущества скрытности. Я не рекомендую разработчикам нарушать их NDA; я просто считаю, что им следует просить руководство быть более снисходительным к тому, что они могут и не могут публиковать онлайн.

Telegram-канал со скидками, розыгрышами призов и новостями IT ?