❔Как вы обозначаете свою профессию?❔

Каждый раз, когда меня спрашивают, кем я работаю — я теряюсь.

Много лет назад я смело отвечала, что «копирайтером». Но это было во времена, когда я статью «Как варить гречку» начинала со слов «История гречки насчитывает тысячелетия...». Даже тогда это, кстати, не было копирайтингом, но ни в каком значении это слово мне теперь не подходит.

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

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

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

?«Пассивная агрессия» в статьях?

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

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

На первый взгляд ничего такого в этих фразах нет, и по отдельности они наверное даже ОК. Но когда их много появляется ощущение, что автор статьи смотрит на читателя снисходительно. С мыслью вроде «Ну это же всем известные вещи, а если вам не известны — жалко вас, конечно».

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

А то получается, что вы создаете у читателя ощущение, что он не просто чего-то не знает — это ок, он статью читает, чтобы узнать. А что он не знает чего-то простого, и будет из-за этого чувствовать себя дураком. А наша задача дать ему почувствовать себя умным, потому что так ему будет приятно.

А вы бы кстати как назвали такое «поведение» в статьях? И как часто с ним сталкивались? И какие оно у вас ощущения вызывает?

?Почему аналогии плохи для споров, но хороши для текстовАналогия — это когда вы поясняете что-то сложное или неоднозначное через что-то более простое и понятное, но из другой области. Сравнивая языки программирования и HTML с хлебом и котиком например (это как в посте выше). В отличие от примера, тут мы не показываем применение сложного на практике, а берем объяснение из другой области, просто чтобы что-то сложное стало понятнее.

?Аналогии иногда любят использовать в спорах, приводя их как аргумент. Но это прям так себе идея, потому что внешнее сходство не означает сходства внутреннего. Слышали когда-нибудь фразу: «Хорош тот ключ, что открывает много замков — и плох тот замок, что открывается многими ключами»? Ее иногда используют для оправдания женской моногамии и мужской полигамии, если что =) Это как раз аналогия, вот только люди не ключи и не замки, и никаким вообще логическим доказательством чего-либо это не является. Поэтому использовать аналогию, чтобы доказать правдивость чего-то через якобы «подобное» — это ошибка.

?Но в статьях, где мы что-то объясняем, нам не нужно что-то доказывать. Нам часто нужно пояснить какой-то очень сложный процесс, у которого нет отображения в реальной жизни. Поэтому мы можем сравнить озеро данных с реальным озером с рыбой, поток данных с водопроводом, набор библиотек с конструктором — просто для пояснения. В этом случае аналогия — прекрасный инструмент, который очень наглядно показывает, что и как на самом деле происходит в сложном процессе.

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

?А вы часто используете аналогии в своих статьях? И что думаете об аргументацию через аналогии? Поделитесь в комментариях!

#Объясняю_ITмемы

Есть языки программирования: Python, PHP, Java, C#, C++ и всякие еще другие вроде Go. На них программисты пишут программы, которые умеют что-то делать — например, считать или анализировать данные.

А есть HTML — язык гипертекстовой разметки. На дилетантский взгляд он тоже может показаться языком программирования: куча английских слов, всякие скобочки и двоеточия. Но от языков программирования его отличает то, что этот язык не умеет ничего делать и вычислять. Он нужен для того, чтобы описать браузеру, как визуально должна выглядеть страница. Браузер считывает язык и отрисовывает все так, чтобы было красиво. Это если очень упрощенно.

Поэтому говорить, что HTML язык программирования — нельзя. Но так иногда говорят, потому что HTML «маскируется» и «тоже IT» — прямо как этот котик, притворяющийся хлебом.

*?*Как я пишу примеры кода для статей*?***Иногда в статьях для начинающих нужны простенькие примеры кода — обычно чтобы продемонстрировать какие-то особенности языка. Дергать для таких примеров экспертов не хочется — так написание статьи займет в итоге слишком много времени.

Решить проблему с кодом мне помог ChatGPT. Он прекрасно справляется с примерами кода разного уровня: может сравнить одну и ту же операцию в разных языках, продемонстрировать наглядно какую-нибудь библиотеку и даже написать с нуля несложную программу, например, игру.

В прикрепленных картинках — примеры кода, которые он мне выдал по разным запросам. Я использую российский сервис Chad, который дает доступ к ChatGPT без всяких заморочек.

Главное здесь помнить, что ChatGPT пока не идеален, и эксперт все равно должен будет проверить, что он там понаписал. Но проверить проще, чем написать — особенно учитывая, что ChatGPT прекрасно комментирует все, что накодил.

?Почему вам в статьях нужны мемы

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

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

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

Я стараюсь использовать мемы везде, где это позволяет тема и тон оф войс издания. Но не те мемы, которые тупо заполняют пространство, а те, которые как-то закрепляют информацию.

Сразу приведу пример. В языке JavaScript есть прикол — когда мы задаем переменную, мы не говорим, строка это или число. И по умолчанию язык может посчитать, что переменные n=1 и m=2 — это строки, а не числа. В итоге если вы сделаете операцию m+n, вы получите не ожидаемую «3», а «12» — потому что JavaScript не сложил числа, а сложил строки, расположив их рядом.

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

А что вы думаете про мемы в статьях? И используете сами?

#Объясняю_ITмемы

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

Как правило в командах есть руководитель, который контролирует весь процесс разработки. Часто это тимлид, то есть team leader, лидер команды.

Может показаться, что тимлид сам не ходит, постоянно что-то контролирует и по сути только мешает программистам работать. Но на самом деле без него получится примерно так, как на этом меме.