Сегодня я хотел бы уделить несколько минут, чтобы сосредоточиться на чем-то, что затрагивает нас всех, но не имеет отношения к коду. Я имею в виду людей, которые заказывают традиционные книги и журнальные статьи, которые вы читаете и изучаете каждый день.
Что вы можете не осознавать, так это то, что издатели имеют тенденцию навязывать удивительно строгие правила в отношении авторов.
Для тех из вас, кто еще не внес свой вклад в техническую книгу или журнал — или даже в некоторые коммерческие блоги, — вы, возможно, не поймете, что издатели имеют тенденцию навязывать удивительно строгие правила в отношении авторов.
- Ваша статья должна быть таким количеством слов.
- Вы должны предоставить в общей сложности X изображений с вашей статьей — независимо от того, заслуживает ли контент изображения.
- Ваше введение должно быть триста слов.
- Каждый раздел вашей статьи должен содержать до ста слов и содержать два примера кода.
- При написании книги полный план главы должен быть предоставлен в начале процесса, прежде чем у вас будет время жить с книгой, и определить, когда и как обсуждать каждую тему.
- Хуже всего то, что вы должны использовать наш нелепый, не интуитивно понятный документ и шаблон Word при подготовке своей статьи или книги.
Пункты, отмеченные выше, представляют собой лишь небольшую часть ограничений, которые лежат на плечах технического писателя. Это означает следующее: в дополнение к расшифровке того, как лучше всего объяснить значительно сложные технологии, технический писатель также должен каким-то образом уметь приспосабливать свой контент к границам запутанных предопределенных руководящих принципов издателя.
Для обледенения дела — и для оказания еще большего давления на автора — будут установлены различные (довольно интенсивные) сроки, чтобы обеспечить своевременное завершение книги. Хотя это, конечно, понятно, во многих случаях издатели, как правило, слишком амбициозны в сроки, которые они выбирают, которые не учитывают работу автора на полный рабочий день и другие обязанности.
Эта модель устарела и быстро приближается к исчезновению, если она не рассматривается и не модернизируется.
Почему они это делают?
Учебный код во многом является искусством.
Прежде чем мы продолжим выбирать традиционных издателей, важно сначала понять, почему они это делают. Рассмотрим журнал с конечным числом страниц, доступных для определенного фрагмента контента — скажем, пять страниц. Если бы это было единственным ограничением, это все равно оказалось бы трудным для автора. Учебный код во многом является искусством. Это требует как понимания технологии, так и умения объяснить ее таким образом, чтобы каждый мог ее понять. Как вы полагаете, что художественное и объяснительное слово стоит в подсчетах? Ну, ответ в том, что вы не можете — по крайней мере, без значительных жертв и редактирования.
Давайте продолжим; теперь, когда мы установили, что в журнале X может быть место только для пяти страниц, следующее ограничение заключается в том, чтобы найти способ втиснуть вашу статью в предварительно определенный шаблон макета, что, разумеется, не способствует любой способ, форма или форма в процессе написания. Здесь вступают в игру требования к количеству слов и количеству разделов.
Представьте, что вам говорят, что вам нужно описать, как этот кусок кода работает, в 25-35 словах. Выполнено? А теперь представьте, какие жертвы вам придется принести, чтобы изменить ваше объяснение настолько, чтобы соответствовать этому требованию! Кому это выгодно?
Речь идет об автоматизации — не писатель
Проблема заключается в том, что эти шаблоны и макросы не учитывают процесс написания.
С точки зрения не писателя, вполне понятно, почему может быть необходимо установить эти ограничения. Рассмотрим издателей, которые организуют и редактируют сотни книг в год. В этих случаях быстро становится необходимым — для их собственного здравого смысла — готовить шаблоны и значительно усложнять документы и макросы Word для максимально возможной автоматизации.
Проблема заключается в том, что эти шаблоны и макросы даже не начинают принимать во внимание процесс написания. Теперь вместо того, чтобы сосредоточиться на том, что является самым важным (объяснение сложного кода), автор вместо этого вынужден прилагать значительные усилия и время для расшифровки того, как использовать конкретный макрос Word или форматировать свой документ, в соответствии с рекомендациями издателя.
Один из трех результатов может быть вызван тем, что издатель навязывает авторам страницы с требованиями, которые хотят лишь научить других технологии и, возможно, выплатить закладную в процессе. (Если вы думаете, что авторы ваших любимых технических книг делают это за деньги, подумайте еще раз.)
- Принятие: Автор соглашается с ограничениями и делает все возможное, чтобы пробиться сквозь процесс, как лабиринт.
- Отказ от участия: после значительных инвестиций автор в конечном итоге выходит из проекта из-за неестественного процесса написания и сроков.
- Отказ: после получения различных форм и руководящих принципов, автор быстро становится перегруженным и отказывается от контракта.
Я уверен, что вы можете догадаться, какой вариант выше, как правило, самый популярный.
Что идеально?
В какой-то момент у меня были аналогичные требования для участников Nettuts +.
Должен признать, что в какой-то момент у меня были похожие требования к авторам и сотрудникам Nettuts +. К счастью, формат блога, естественно, предусматривает менее строгие требования. Требование подсчета слов в разделе глупо и бессмысленно для блога. Тем не менее, я все еще подчеркивал количество слов, предоставление изображений и использование нашего специального HTML-шаблона для Nettuts при подготовке новых руководств.
Почему? Ну, по той же причине, что и традиционные издатели: моя работа проще всего, когда статья соответствует моему заранее заданному макету для статьи Nettuts +.
То, что я не принял во внимание, было числом потенциальных авторов, которых я непреднамеренно оттолкнул, устанавливая эти требования. У кого честно есть время поработать в рамках чужого шаблона? Когда время является ценным товаром (особенно для тех, у кого есть постоянные рабочие места и семьи), эти ограничения служат не более чем сдерживающим фактором.
В настоящее время моя единственная цель при вводе в эксплуатацию нового контента — сделать процесс написания для автора максимально легким и естественным.
- Не беспокойтесь об использовании Microsoft Word или наших пользовательских шаблонов. Используйте любой инструмент для письма, который вам удобнее всего.
- Не узнайте, как сделать ваш код подходящим для нашей специальной подсветки синтаксиса. Мы позаботимся об этом.
- Даже не думайте о количестве слов или требованиях к изображению. Конечно, я не могу принять статьи, которые содержат всего 400 слов, но, по моему опыту, писатели наиболее эффективны, когда их гораздо меньше интересует соблюдение произвольных требований по количеству слов, а больше — обучение как контенту, так и самим ». Ре способен. Если это означает, что в статье 1500 слов или в три раза больше этого числа, мне все равно. Просто научи это правильно!
Теперь, когда я стал зрелым редактором Nettuts +, при работе с новыми авторами я запрашиваю только файл Markdown , который для тех, кто незнаком, является псевдо-языком, который, как правило, предпочитают разработчики. Markdown полностью исключает визуальные эффекты и форматирование из процесса записи, как и должно быть, особенно в нашей отрасли. Кроме того, если они не чувствуют себя комфортно с Markdown, они могут использовать что-либо еще, чтобы выполнить работу.
Теперь, когда я стал редактором Nettuts +, при работе с новыми авторами я запрашиваю только файл Markdown .
Возможно, этот метод может сделать немного больше работы с моей стороны, но он абсолютно и положительно стоит компромисса. Я хочу, чтобы наши авторы сосредоточились только на объяснении сложных технологий настолько эффективно, насколько это возможно. Мы позаботимся обо всем остальном. Если бы только все издатели приняли аналогичную модель.