Инструкцию, как завести блог на Highload и опубликовать в нем что-нибудь, можно посмотреть здесь. Но сначала советуем почитать на этой странице, для кого и как мы пишем.
Для кого мы пишем
Наша главная аудитория — разработчики, причем в основном опытные. По данным опроса, который мы провели у себя в Telegram-канале, 51% наших читателей — мидлы, сеньоры или менеджеры C-level (то есть, например, CTO). Разработчиков-джунов — еще 20%.
Но есть и другой сегмент — те, кто только учится разработке, пока присматривается к сфере IT, либо уже работает в ней, но на нетехнических специальностях (продакты, проджекты, HR). Таких у нас еще 29%.
Что их объединяет? Интерес к технической сфере и полезному контенту. В еще одном нашем опросе 67% читателей ответили, что им важны в первую очередь технические тексты — как писать код, как настроить все так, чтобы работало.
Важно, чтобы этот контент был хорошо упакован. Например, 50% читателей любят формат подборок — полезных идей, сервисов, приложений и т.п.
Другой вариант, как подать полезный контент, — через личную историю. 37% читателей Highload говорят, что любят читать на нашем сайте интервью с людьми из мира IT, 27% — интересные личные истории релокейта за границу, 19% хотят читать больше карьерных историй.
Как мы пишем
Мы стараемся разговаривать с нашей аудиторией на одном языке. Мы делаем ставку на разговорное и шутливое, дружелюбное и уважительное общение — то есть на «вы», но с «привет!» вместо «здравствуйте, глубокоуважаемые читатели».
В усредненном варианте это язык 30-летнего мужчины-разработчика из Киева. Если хотите его лучше понять — зайдите на любой IT-форум или неофициальный Telegram-канал. Это ироничный, иногда даже саркастичный тон, часто недоверчивое отношение к локальным и глобальным IT-гигантам, но в то же время — неподдельный интерес к реальным инновациям и полезным технологиям.
Про мужчин понятно. А что с феминитивами?
Мы не забываем и о том, что около трети нашей аудитории — женщины, доля которых в IT постоянно растет, в том числе и на технических специальностях. Их коллеги-мужчины пока еще пугаются слова «разработчица», но у нас насчет феминитивов есть простое правило: решает, использовать ли феминитив в названии своей должности, та, кто ее занимает. Мы уточняем это в разговоре или ориентируемся на то, как должность указана в соцсетях.
Сложные термины вашим читателям ведь и так понятны?
В текстах допустимы отраслевые термины и даже англицизмы вроде «задеплоить» — там, где они действительно отражают реальный язык разработчиков и помогают им лучше понять, о чем речь. Но если термины относятся лишь к одному конкретному сегменту разработки, лучше давать им пояснения в скобках — потенциальный читатель, даже опытный, точно не может разбираться сразу во всем.
А вот в более широком контексте англицизмов вроде «челлендж» или «фаундер» лучше вообще избегать — «испытание» и «основатель» вместо них ничуть не усложнят, а только облегчат восприятие текста.
У моей колонки был отличный заголовок. Зачем вы поменяли его на какой-то дурацкий?
Хороший заголовок — половина успеха текста. Когда мы их придумываем, то стараемся не только передать смысл статьи или колонки, но и зацепить читателя — дать ему понять, что этот текст принесет ему полезные знания или важные эмоции. Если зацепить читателя не удается, мы будем придумывать еще и еще раз — иначе текст так и останется недооцененным и сгинет в безвестности.
А гиперссылки в тексте ставить можно?
Да. Они будут в формате nofollow, и UTM-метки в них добавлять нельзя — это уже коммерческая услуга. Но вы можете поставить ссылку на свой профиль в соцсетях, на сайт своей компании или на мероприятие, которое планируете провести.
Какие колонки нам не нужны
Те, которые написаны не для программистов, а в расчете на какую-то другую аудиторию — потенциальных инвесторов, клиентов, владельцев бизнеса, вашего гендиректора. Задайте себе вопрос, который каждый день задаем себе мы: «Почему это должно быть интересно разработчикам?».
Те, которые не основаны на практическом опыте. Никому не интересно читать о том, почему важно следить за безопасностью веб-сайтов, — до того момента, пока вы не расскажете, как вы не уследили за своим и потеряли на этом кучу денег или лишились работы. Если своих историй нет, но рассказать что-то важное все равно хочется — подумайте о примерах из мирового опыта.
Те, в которых нет никакого полезного знания. Мы можем искренне порадоваться за вас, когда вы успешно выполнили очередной контракт на разработку корпоративного приложения для клиента или вышли на рынок Восточного Тимора, но к сожалению, знание об этом никак не поможет другим разработчикам, а значит, и читать об этом никто не захочет. Но может быть, в ходе разработки вы решительно поменяли свой подход к IT-архитектуре и готовы рассказать, почему, а ваши сотрудники хотят поделиться деталями сложной адаптации к жизни в Юго-Восточной Азии? Это совсем другое дело!
Те, в которых есть непроверенные утверждения. Если вы пишете, что 75% разработчиков ненавидят браузер Safari, а новый фреймворк повышает скорость разработки в 3,5 раза, — пожалуйста, приводите источник этих данных.
Что мы больше всего любим в колонках
Примеры кода — это самое полезное, чем вы можете поделиться с другими разработчиками. Все сразу захотят сказать вам спасибо (или объяснить, в чем вы не правы).
Иллюстрации — сплошной текст без картинок читать тяжело. Добавляйте туда схемы архитектуры, скриншоты работы сервиса, сайта или приложения, фотографии автора (если это рассказ о карьере), виды итальянских озер (если это история о релокейте), в конце концов — подходящие к случаю мемы: программисты тоже люди и любят посмеяться.
Легкий стиль — представьте, что рассказываете историю своему знакомому в баре, а не пишете дипломную работу в университете. Так вас точно поймут, захотят дочитать текст до конца, написать вам комментарий и устроиться к вам на работу.
Лаконичность — текст длиннее 5000 знаков осилить нелегко, особенно посреди рабочего дня под надзором начальника или с телефона в метро — а так их и будут читать чаще всего. Если не укладываетесь в этот объем — подумайте, не стоит ли разбить ваш текст на серию статей?
Личные мнения — расскажите всем, за что лично вы ненавидите JavaScript. Поверьте, это будет гораздо интереснее, чем сохранять беспристрастность — вы не журналист, вы можете себе это позволить.
Как облегчить жизнь редактору
Мы не используем ё, зато используем «кавычки-елочки» и длинное тире — вот такое.
Числительные до десяти лучше писать буквами, тысячи сокращать то тыс., а миллионы — до млн — кстати, после этого сокращения точка не ставится.
Используйте слово «этот» вместо «данный» — так писали только в учебнике по алгебре.
«Однако» — когда в последний раз вы слышали, чтобы кто-то произносил это слово вслух? Вот и в текстах оно тоже не нужно.
«Являются» обычно привидения. В реальном мире это слово почти всегда можно заменить безглагольной фразой: гордое «Я — программист!» вместо неуверенного «я являюсь программистом».
Пожалуйста, избегайте страдательного залога. «Я задеплоил новый билд» вместо «новый билд был задеплоен мною».
Не перегружайте текст причастными оборотами. Если предложение невозможно произнести вслух, не сбившись с дыхания, скорее всего, его сложно будет и дочитать. Сделайте предложения короче, при этом используйте больше глаголов.
Избегайте штампов и канцеляризмов. Они вызывают доверие только у читателей районных газет, в интернете же реакция обратная — сразу кажется, что автор не разбирается в вопросе и поэтому прячется за шаблонными фразами.
Нашли новый непонятный термин в тексте? Объясните его в паре слов. Если нет времени объяснять — залинкуйте. Важно: линк должен вести на проверенный сайт («Википедия», официальный сайт компании или сервиса).
If you have found a spelling error, please, notify us by selecting that text and pressing Ctrl+Enter.