Is Writing as Important as Coding?

eugeneyan

Начните отсюда Статьи Выступления Прототипирование О себе

Так ли важно письмо, как код?

[ writing leadership ] · 13 мин чтения

Становится ли письмо важнее (относительно кода) по мере перехода на сениорные роли? Чем письмо полезно на технических должностях? Как помочь команде писать лучше?

Как data scientist я постоянно балансирую между построением и развёртыванием ML-систем (код) и доведением предложений и объяснением результатов (письмо). Каков оптимальный баланс между написанием кода и написанием документов?

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

David Said, Principal Engineer @ Amazon Alexey Grigorev, Lead Data Scientist @ OLX Group Pratik Bhavsar, NLP Engineer @ Jina AI Grace Tang, Senior Data Scientist @ Netflix

По мере роста меняется то, как мы можем приносить наибольшую пользу

В начале карьеры всё сводится к доставке результата. Мы приносим пользу, реализуя и поставляя системы (через написание кода). David метко это описывает:

«[В начале] нужно сосредоточиться на том, чтобы отрастить клыки [нечто вроде того, чтобы заслужить свои нашивки] на реальных задачах. А затем, когда клыки отросли и карьера пошла в рост, всё важнее становится делиться тем, что знаешь». — David Said

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

Один из способов (направлять команду) — давать контекст и объяснять «зачем». Поднимаясь по сениорности, мы получаем контекст — цели бизнеса, дорожную карту организации, бюджет, — которого может не хватать junior-сотрудникам. Простой способ повысить эффективность команды — делиться этим контекстом и помогать команде его понять. С контекстом они решат задачу лучше.

Как lead data scientist, роль Alexey — связывать разные части организации и иметь общую картину всей системы. Хотя теперь он пишет меньше кода, он приносит пользу, донося до команды общую картину и «зачем». Делает он это через написание документов: продуктовых дорожных карт, требований, спецификаций API и т. д. Он советует: умение видеть контекст и доносить его становится всё важнее по мере развития карьеры:

«Когда ты растёшь от среднего уровня к сениорному, важен контекст. Важно общение с другими командами. Важно понимать, действительно ли клиент хочет пользоваться тем, что ты строишь. Именно тогда письмо становится особенно важным — через определение контекста и донесение мысли». — Alexey Grigorev

Допустим, мы — часть e-commerce-платформы. Популярные товары получают трафик и продолжают оставаться популярными; новые товары из «длинного хвоста» не получают трафика и остаются в безвестности (хотя могут быть хорошими). Вместо того чтобы доносить что (повысить видимость новых товаров) и как (случайно выбирать новейший товар и ставить его высоко), нам стоит доносить зачем:

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

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

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

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

«Становясь техническим лидером, нужно думать о будущем. Опытные — это те, кто знает, где находятся углы и как заглядывать за них. Им приходится разбирать бизнес-задачи, проводить ревью (дизайна и кода) и минимизировать ошибки, которые совершает команда». — David Said

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

Кроме того, нам нужно научиться масштабировать своё влияние. Число систем, которые мы можем построить сами, ограничено. Чтобы усилить своё влияние, нам нужно получить рычаг, работая с другими людьми, через несколько команд и проектов.

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

«Как только ты попадаешь на сениорную роль (может, не по титулу, но с возросшим объёмом ответственности), тебе придётся работать с другими. Отличный механизм для этого — документация. Если ты всегда был кодером, тебе это может показаться скучным. Но написание документации — например, как разворачивать CloudFormation — невероятно полезно и для тебя, и для команды». — Pratik Bhavsar

В целом это говорит о том, что (по мере роста в карьере) мы будем писать больше, а кодить меньше. Grace заметила, что в общем индивидуальные контрибьюторы (ICs) обычно пишут больше кода, тогда как технические лидеры и менеджеры — больше документов. Тем не менее писать документы важно, даже если ты IC:

«Важно и писать документы, и писать код: напиши хороший код и проведи качественный анализ, а затем напиши хорошие документы, чтобы максимизировать его эффект. Тебе нужно помочь стейкхолдерам узнать о твоей работе и понять её, чтобы она принесла пользу. Не делиться своей работой — значит, что о ней никто не знает и никто не может ею воспользоваться». — Grace Tang

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

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

У письма есть несколько преимуществ, особенно на технических ролях

«Письмо — это способ природы дать тебе знать, насколько неряшливо твоё мышление». — Dick Guindon, через Leslie Lamport

Без письма мы можем считать наши дизайны продуманными, методологию ясной, а понимание полным. Что ж, попытка написать об этом всё расставит по местам. Письмо — это хак для обретения ясности. Вот Jeff Bezos о том, почему он запретил PowerPoint (как формат на совещаниях) и ввёл вместо него шестистраничные нарративы:

Тот судьбоносный email, который изменил Amazon.

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

И даже если документ потеряется, исследование и осмысление уже проделаны. Процесс и итоги мышления зачастую важнее самого документа.

«Отчёты — это в большей степени средство самодисциплины, чем способ передачи информации. Важно написать отчёт; читать его часто — нет». — Andy Grove

Я полностью с этим согласен и выступаю за практику написания one-pager'ов. (В моих прежних командах это было обязательно перед началом проекта.) Этот процесс помогает прояснить замысел, желаемый результат, поставляемый артефакт и ограничения. Подобные практики распространены и в Amazon — например, процесс working backwards и документ press release.

Кроме того, письмо — это короткий путь к обкатке идей и получению обратной связи. Перед тем как браться за (дорогостоящую) реализацию, мы можем (дёшево) поделиться письменными предложениями, чтобы собрать обратную связь. С обратной связью наши первоначальные дизайны можно переработать с нулевой стоимостью разработки. Деление нашими дизайнами — в письменной форме — также гарантирует, что итоговая реализация соответствует замыслу:

«Когда ты пишешь своё предложение, у тебя появляется способ понять, интересно и полезно ли это другим. Напротив, можно писать код очень долго и так и не узнать, полезен ли он. Поэтому написание предложения важно для того, чтобы помочь и себе, и другим понять, действительно ли то, что ты строишь, решает проблему». — Alexey Grigorev

Те же документы, что мы пишем ради ясности, можно использовать и для обкатки идей. В Amazon, когда спрашивают о проекте, принято делиться документом press release (и шестистраничником, если он есть). В других организациях это может быть в форме документа требований, страницы в Confluence или спецификации API.

Кроме того, письмо помогает с сохранением и передачей знаний. Наша память дырявая — мы забываем до 90% прочитанного в течение 7 дней. Письмо — это как сохранение знаний в базу данных. И теперь, вместо того чтобы спрашивать нас, люди могут получить доступ к нашим знаниям через эту базу (т. е. через написанное) — это экономит нам время:

«Когда есть документация по проекту, легко ввести нового человека в курс дела. Вместо того чтобы садиться с ним и всё объяснять, можно просто отправить его к документам. К тому же, когда организация растёт, передавать знания становится трудно; это может приводить к недопониманию. Эффективный способ это предотвратить — хорошая документация». — Pratik Bhavsar

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

«У меня есть единый документ обо всём, что касается проекта. Как он начался, какова цель, каждое принятое решение. Это позволяет вернуться назад во времени, пройтись по проблемам и понять, какие решения мы принимали (особенно если что-то пошло не так). Со временем он становится очень ценным и содержит массу знаний, хотя и становится длинным. … Если кто-то спрашивает меня о проекте — что ж, держи < делится журналом проекта >». — Alexey Grigorev

Я также советую документировать результаты экспериментов, которые, возможно, поглотили сотни, если не тысячи, часов вычислений. Вот простой автоматизированный подход через Jupyter, Papermill и MLflow.

Как мы можем помочь команде писать лучше?

Один из способов повысить качество письма — поднять планку. Например, David написал документ о том, как писать дизайн-документы (очень мета), на который ссылаются разработчики в Amazon. Pratik советует: отличный способ научиться хорошо писать — подражать хорошему письму. Поэтому мы можем указывать команде на примеры хороших документов, которым можно подражать. Или давать команде шаблоны, например схему press release от Amazon.

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

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

Stripe балансирует стандартизацию и автономию, имея шаблоны для документов высокого уровня, у которых более широкая аудитория (т. е. в масштабах организации, нескольких команд) или значимые последствия (например, квартальные отчёты). Amazon делает то же самое — рекомендуемый формат для working backwards и press release, но нет шаблона для шестистраничников. Это гарантирует, что широко распространяемые документы стандартизированы и легко считываемы, при этом давая командам автономию над их внутренними документами.

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

«Великие мемо пишутся и переписываются, передаются коллегам, которых просят улучшить работу, откладываются на пару дней, а затем редактируются снова со свежей головой». — Jeff Bezos

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

Как нам писать хорошие технические документы? Вот несколько отличных ресурсов для начала:

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

Научиться писать гораздо важнее, чем научиться кодить.— Sahil (@shl) 3 мая 2020

Выбор между письмом и кодом — полезный вопрос

По мере продвижения в карьере кажется неизбежным, что мы будем писать больше документов, чем кода. Но, как мы видели, написание документов — тоже работа с высоким эффектом. Учитывая ограниченные время и энергию, как выбрать между ними?

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

Писать документы — всё равно что писать код. Код — для машин; документы — для людей.

Писать документы трудно. Для кого-то — труднее, чем писать код. И относительно написания кода эффект от написания документов не так сразу измерим. Но если это помогает дать ясность или сэкономить команде время, то оно того стоит. (Если вы знаете способы измерить эффект письма, мне было бы очень интересно услышать вас!)

Какой совет вы дали бы техническим специалистам, которые начинают писать больше? Поделитесь в комментариях ниже.

Почему письмо становится важнее (чем код) по мере роста сениорности? Как нам балансировать между ними? Как помочь команде писать лучше? Здесь я исследую ответы на эти вопросы с помощью нескольких друзей, включая @Al_Grigor и @nlpguy_.https://t.co/foqhU5A9Rx— Eugene Yan (@eugeneyan) 7 октября 2020

Спасибо Yang Xinyi и Drew Stegmaier за чтение черновиков. Спасибо David Said, Alexey Grigorev, Pratik Bhavsar и Grace Tang за то, что нашли время обсудить эту тему.

Если вы нашли это полезным, пожалуйста, ссылайтесь на эту заметку так:

Yan, Ziyou. (Oct 2020). Is Writing as Important as Coding?. eugeneyan.com. https://eugeneyan.com/writing/writing-and-coding/.

или

@article{yan2020coding, title = {Is Writing as Important as Coding?}, author = {Yan, Ziyou}, journal = {eugeneyan.com}, year = {2020}, month = {Oct}, url = {https://eugeneyan.com/writing/writing-and-coding/} }

Присоединяйтесь к 11 800+ читателям, получающим обновления о машинном обучении, RecSys, LLM и инженерии.