07
Окт

Правила написания технических статей

Написал Максим Крентовский в Идеи

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

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

  • главный аспект восприятия, изложенный мне как студенту нашим преподавателем физики в период обучения в институте — среднесферический человек в вакууме не может воспринимать информацию, если в ней содержится более 10% новых данных (причем это сильно зависит от возраста и уже потребленного объема информации, так, например, для малыша цифра возрастает до 30%, а для академика — падает до 5%). Т.е. чтобы информация была воспринята целиком, в нее необходимо включить порядка 90% уже известных (например, по предыдущим статьям) человеку данных;
  • структура материала должна быть если и не обозначена, то четко видна. Обычно опытные в деле написания статей ученые (шикарный пример был в одном из журналов «Компьютерра», к сожалению, не смог отыскать ссылку) разбивают на несколько частей, причем по завершении каждой части делается краткий, в два предложения, вывод или сумма информации, изложенная в этом разделе. Такая организация позволяет подходить более подготовленным к чтению следующего фрагмента, а также делать временные перерывы в чтении статей — детали могут потеряться, но общая канва рассуждений сохранится;
  • компетентность и информированность специалиста, читающего статью, может варьироваться в весьма широком диапазоне. Поэтому вполне очевидные для автора или интуитивно понятные тезисы, негласно подразумеваемые при написании статьи, могут быть не поняты и не восприняты должным образом, а сама статья будет казаться скучной и излишне усложненной. Обратная крайность — максимально подробное описание всех элементов может так же вызвать раздражение. Поэтому «тестовая вычитка» — жизненно необходимое действие перед публикацией;
  • надо четко отдавать отчет, что восприятие и стиль мышления специалистов одной профессии могут кардинально различаться. Так, например, инженер-программист может быть как выпускником кафедры прикладной математики (и, соответственно, подходить к написанию программы как к решению некой математической абстракции), так и кафедры кибернетики (и тут подход уже меняется с учетом системотехнических знаний и представлении о вычислительной технике как объекте физического мира). Порой различия в мышлении настолько разительны, что взаимопонимание может быть достигнуто только при обоюдном приложении значительных усилий;
  • 96% информации мы получаем от зрения. Большая часть времени при чтении требуется на восприятие интервалов между символами. Поэтому если что-то можно представить графически — это лучше всего сделать именно так. Наглядность — важнейший процесс в деле познания, хотя он и не способствует нахождению статьи посредством традиционного поиска по тексту;
  • в любом скучном повествовании есть место шутке. В частности, разработчики ядра ОС Linux заняты серьезными делами, но даже в их материалах шутки — вполне обычная и порой очень расслабляющая вещь, позволяющая скрасить монотонность изложения;
  • не следует усугублять сносками и ссылками на источник информации — более 1-2 сносок на страницу и 4 на статью достаточно, чтобы читатели прокляли ее автора. Скобки для пояснений — самое то.

Приведенные выше постулаты могут быть использованы как для написания статей, так и для технических и специализированных презентаций и докладов. Удачи в техническом творчестве! :)

Комментирование недоступно.
Максим Крентовский
системный архитектор
E-mail / GTalk: mkrentovskiy@gmail.com
Skype: mkrentovskiy