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

Тем не менее, я должен отметить, что это еще не все: вы можете усвоить стиль , просто много читая; это залезет тебе в голову. Но содержание , которое вы не можете получить подсознательно, во всяком случае, не так легко. Вам нужно активно думать о том, что вы читаете. Почему компоненты отчета были размещены именно в том порядке, в котором они были? Что автор подробно рассмотрел, а что замазал? С чего они начались и чем закончились?

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

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

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

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

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

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

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

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

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

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

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

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

Пишите и ищите отзывы!

Полезные способы получить обратную связь:

1. Доброволец для написания проектов, которые будут рассмотрены критически. Рецензенты часто более внимательны и критичны при рассмотрении рекламного контента, чем технического. Однако для многих продуктов рекламный контент должен быть техническим. Как технический писатель, вы должны хорошо знать продукты своей компании. Волонтерствуя в проектах, которые традиционно считаются «рекламными», вы можете помочь обеспечить точность и ясность рекламного контента, открывая себя для большего количества и более качественных отзывов.
2. Развивайте отношения с рецензентами, которые ценят четкую коммуникацию. Будьте благодарны рецензентам, которые дают хорошую конструктивную критику. Убедитесь, что рецензенты понимают, что их критика делает вас лучшим писателем, что приводит к лучшему контенту и лучшему имиджу бренда.
3. Участвуйте в stackexchange. Хотя я только начал пользоваться этим сайтом, я уже заметил, что члены сообщества отлично справляются с редактированием вопросов/ответов.