Is Writing as Important as Coding?

eugeneyan

eugeneyan

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

Is Writing as Important as Coding?

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

[ writing leadership ] · 13 min read

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

Does writing become more important (relative to coding) as we transition to senior roles? How is writing beneficial in technical positions? How can we help the team write better?

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

As a data scientist, I find myself straddling between building and deploying ML systems (coding), and communicating proposals and explaining results (writing). What’s the optimal balance between writing code and writing documents?

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

Here, we’ll discuss these questions and more. I’m also happy to have several friends who will chime in with their lessons and advice:

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

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

As we grow, how we can contribute most shifts

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

At the start of our careers, it’s all about delivery. We contribute by implementing and delivering systems (via writing code). David describes this aptly:

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

“[At the start,] you need to focus on getting your fangs [akin to earning your stripes] on real-world problems. Then, as you get your fangs and grow your career, it becomes more important to share what you know.” – David Said

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

So as we gain experience and grow our fangs, the way in which we create impact changes. Instead of implementing systems ourselves, it becomes more valuable to guide and serve the team. A great way to do this is via writing documents.

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

One way (to guide the team) is providing the context and the why. As we rise in seniority, we gain context—business goals, organization roadmap, budget—that junior members may lack. A straightforward way to increase team effectiveness is sharing this context and helping the team to understand it. With the context, they can solve the problem better.

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

As lead data scientist, Alexey’s role is to connect the different parts of the organization and have a big picture view of the entire system. While he codes less now, he contributes by conveying the big picture and why to the team. He does this through writing documents such as product roadmaps, requirements, API specs, etc. He advises that seeing the context and communicating it becomes more important as our careers progress:

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

“When you grow from middle to senior level, having context matters. Communicating with other teams matters. Understanding if the customer really wants to use what you’re building matters. This is when writing becomes especially important, through scoping the context and sharing the message.” – Alexey Grigorev

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

Assume that we’re part of an e-commerce platform. Popular products get traffic and continue to stay popular; newer long-tail products don’t get traffic and stay obscure (even though they might be good). Instead of communicating the what (increase visibility of new products) and the how (randomly pick the latest product to rank high), we should communicate the why:

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

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

By sharing the context and the why—and giving space to figure out the what and the how—we empower the team to creatively solve the customer’s problem. In my experience, this almost always leads to a far better outcome than expected.

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

(In this case, we fixed it with a combination of understanding customers unmet demands and providing the ability for sellers to place ads.)

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

Also, with the lessons we’ve learned (read: failures), we can contribute by helping to look around corners. We do this by foreseeing potential pitfalls the team should prioritize early. Or we can suggest (or decide) on problem statements, methodology, and technology. This could involve reviewing design docs and leaving feedback, or writing the design doc and setting boundaries. Thus, our contribution transitions from day-to-day execution to longer-term strategic thinking:

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

“As you become a tech leader, you need to think about the future. The experienced are those who know what the corners are and how to look around them. They have to parse the business problems, do the (design and code) reviews, and minimize the errors that the team commits.” – David Said

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

A well-timed insight can save weeks, if not months, of going down the rabbit hole. Unfortunately, the reverse can also happen if recommendations of tech leads are ignored.

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

In addition, we’ll need to learn how to scale our impact. The number of systems we can build ourselves is limited. To increase our impact, we’ll need to gain leverage by working with other people, by working across multiple teams and projects.

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

Here’s where writing helps. It scales well—once written, an API spec can be easily distributed without additional effort. It clarifies—the same spec can help achieve alignment and unblock multiple teams at once. Also, by writing about the lessons we’ve learned and the how-tos, we pave the way for those who follow our footsteps:

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

“As soon as you get into a senior role (maybe not title-wise, but having increased scope), you’ll have to work with others. A great mechanism for this is via documentation. If you’ve always been a coder, you might find this boring. But writing documentation, such as how to deploy CloudFormation, is tremendously helpful both for yourself and the team.” – Pratik Bhavsar

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

All in all, this suggests that (as we grow in our careers) we’ll find ourselves writing more and coding less. Grace observed that in general, individual contributors (ICs) tend to write more code, while tech leads and managers tend to write more docs. Nonetheless, writing documents is important even if you’re an IC:

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

“Both writing docs and writing code are important: Write good code and perform quality analysis, then write good docs to maximize its impact. You need to help stakeholders be aware of and understand your work so it can make an impact. Not sharing your work means no one knows about it and no one can use it.” – Grace Tang

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

If you're a senior member, the team counts on you to provide the strategic long-term vision and roadmap. To do this well, it’s essential to stay grounded on, and understand, the existing systems and codebase.

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

Consciously think about how to find time to code, perhaps by jumping into a sprint and picking up a task. Choose an area of the design and implementation that you can dig deep into. Focus on tasks with longer-term goals and a lengthier lead time. This way, your work will not become an immediate blocker for the team (when you get waylaid with higher-level tasks that demand your attention).

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

Writing has several benefits, especially in tech roles

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

“Writing is nature’s way of letting you know how sloppy your thinking is.” – Dick Guindon, via Leslie Lamport

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

Without writing, we might believe our designs are sound, our methodology clear, and our understanding complete. Well, trying to write about it will sort that out. Writing is a hack to gaining clarity. Here’s Jeff Bezos on why he banned powerpoint (as a medium at meetings) and enforced six-page narratives instead:

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

The fateful email that changed Amazon.

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

Yes, the audience benefits from reading well-structured narrative. But the main benefit goes to the writer. By writing long-form prose instead of bullet points, by adding data and connecting ideas, we’re forced to think deeply and resolve inconsistencies. We have to focus on the single thread that ties everything together. We need to remove redundant details (to fit the page limits). There is no way to write a six-page narrative and not come away with clear(er) thinking.

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

And even if the document is lost, the research and thinking has already been done. The process and outcomes of the thinking are often more important than the document.

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

“Reports are more a medium of self-discipline than a way to communicate information. Writing the report is important; reading it often is not.” – Andy Grove

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

I fully agree with this and advocate the practice of writing one-pagers. (In my previous teams, it was a must before starting on a project.) The process helps to clarify the intent, desired outcome, deliverable, and constraints. Such practices are also common in Amazon, such as the working backwards process and the press release document.

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

Also, writing is a short cut to socializing ideas and getting feedback. Before starting on (costly) implementation, we can (cheaply) share written proposals to gather feedback. With feedback, our initial designs can be refactored at zero development cost. Sharing our designs—in written form—also ensures our eventual implementation meets the intent:

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

“When you write your proposal, you have a way to understand if it’s interesting and useful for others. In contrast, you can write code for a very long time and still not know if it’s useful. Thus, writing the proposal is important to helping yourself and others understand if what you’re building is actually solving the problem.“ – Alexey Grigorev

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

The same documents we write to gain clarity can also be used to socialize our ideas. In Amazon, when asked about a project, it’s common to share the press release document (and the six-pager if it’s available). In other organizations, this could be in the form of a requirements doc, confluence page, or API specifications.

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

In addition, writing helps with knowledge retention and transfer. Our memory is leaky—we forget as much as 90% of what we read within 7 days. Writing is like saving knowledge to a database. And now, instead of asking us, people can access our knowledge via that database (i.e., writing)—this helps us save time:

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

“When you have project documentation, it’s easy to onboard someone onto the project. Instead of having to sit with them to explain it, you can just direct them to the docs. Also, as the organization grows larger, it becomes difficult to transfer knowledge; this can lead to miscommunication. An effective way to prevent this is via writing good documentation” – Pratik Bhavsar

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

Alexey strongly advocates this too. By investing time in documenting the process, decisions, and outcomes, it’s much easier to revisit the project when we need to (a year later). He does this through a project journal:

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

“I have a single document for everything about the project. How it started, what the goal is, every decision made. This allows you to go back in time and step through the problems and understand the decisions we made (especially if things didn’t go well). Eventually, it becomes very valuable and contains a lot of knowledge, though it also becomes lengthy. … If someone asks me about the project, well, here you go < shares project journal >” – Alexey Grigorev

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

I also suggest documenting outcomes of experiments that may have consumed hundreds, if not thousands, of compute hours. Here’s a simple automated approach via Jupyter, Papermill, and MLflow.

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

How can we help the team write better?

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

One way to improve writing quality by raising the bar. For example, David wrote a document on how to write design documents (very meta) that devs in Amazon refer. Pratik suggests that a great way to write well is to imitate good writing. Thus, we can point the team to examples of good documents that they can emulate. Or we can provide the team with templates, such as Amazon’s press release outline.

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

Templates are a great way to standardize how the team documents and shares knowledge. They streamline the writing process and ensure the resulting document is familiar to (internal) readers and thus easy to understand.

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

However, it can be difficult to balance between adhering to templates and allowing autonomy in structure and format. What works for one team may not necessarily work for another. For example, an engineering proposal will likely include sections for security, privacy, and infrastructure. On the other hand, a data science proposal will include sections for machine learning, experimentation plan, and model refresh procedure.

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

Stripe balances standardization and autonomy by having templates for high-level documents that would have a broader audience (i.e., organization-wide, multiple teams) or significant implications (e.g., quarterly reports). Amazon does the same with a suggested format for working backwards and press releases but no template for six-pagers. This ensures widely circulated documents and standardized as easily parsed while giving teams autonomy over their internal documents.

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

In addition, we need to provide sufficient time to write.

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

“The great memos are written and rewritten, shared with colleagues who are asked to improve the work, set aside for a couple of days, and then edited again with a fresh mind.” – Jeff Bezos

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

You just can’t churn out a great memo in a day. Jeff suggested that some memos might take a week to get right. Taking enough time can be more important than actual writing skills when it comes to such documents.

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

How do we write good technical documents? Here are some great resources to start with:

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

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

Learning to write is much more important than learning to code.

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

Deciding between writing & coding—a useful question

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

As we progress in our careers, it seems inevitable that we’ll write more documents than code. But as we’ve seen, writing documents is also high impact work. Given our limited time and energy, how do we choose between both?

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

Here’s a good question to ask ourselves: “Which would have greater impact right now?” If we need to understand and clarify the intent and context so we can start implementing, then writing a design doc will help most. If we’re struggling to meet an delivery deadline, then writing (and reviewing) code will help more.

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

Writing documents is like writing code. Code is for machines; documents are for people.

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

Writing documents is hard. For some, harder than writing code. And relative to writing code, the impact of writing documents is not as immediately measurable. But if it helps provide clarity, or save the team time, then it’s well worth the effort. (If you know of ways to measure the impact of writing, I would love to hear from you!)

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

What advice do you have for tech professionals starting to write more? Share in the comments below.

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

Why does writing become more important (than coding) as we gain seniority? How do we balance between both? How can we help the team write better?

Here, I explore answers to these question with the help of some friends, including @Al_Grigor & @nlpguy_.https://t.co/foqhU5A9Rx

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

Thanks to Yang Xinyi and Drew Stegmaier for reading drafts of this. Thanks to David Said, Alexey Grigorev, Pratik Bhavsar, and Grace Tang for making time to discuss on this topic.

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

If you found this useful, please cite this write-up as:

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

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

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

or

или

@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/} }

@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/} }

Join 11,800+ readers getting updates on machine learning, RecSys, LLMs, and engineering.

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