Редакционные правила
Как опубликовать колонку на Highload
Инструкцию, как завести блог на 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. Поверьте, это будет гораздо интереснее, чем сохранять беспристрастность — вы не журналист, вы можете себе это позволить.
Как облегчить жизнь редактору
- Мы не используем ё, зато используем «кавычки-елочки» и длинное тире — вот такое.
- Числительные до десяти лучше писать буквами, тысячи сокращать то тыс., а миллионы — до млн — кстати, после этого сокращения точка не ставится.
- Используйте слово «этот» вместо «данный» — так писали только в учебнике по алгебре.
- «Однако» — когда в последний раз вы слышали, чтобы кто-то произносил это слово вслух? Вот и в текстах оно тоже не нужно.
- «Являются» обычно привидения. В реальном мире это слово почти всегда можно заменить безглагольной фразой: гордое «Я — программист!» вместо неуверенного «я являюсь программистом».
- Пожалуйста, избегайте страдательного залога. «Я задеплоил новый билд» вместо «новый билд был задеплоен мною».
- Не перегружайте текст причастными оборотами. Если предложение невозможно произнести вслух, не сбившись с дыхания, скорее всего, его сложно будет и дочитать. Сделайте предложения короче, при этом используйте больше глаголов.
- Избегайте штампов и канцеляризмов. Они вызывают доверие только у читателей районных газет, в интернете же реакция обратная — сразу кажется, что автор не разбирается в вопросе и поэтому прячется за шаблонными фразами.
- Нашли новый непонятный термин в тексте? Объясните его в паре слов. Если нет времени объяснять — залинкуйте. Важно: линк должен вести на проверенный сайт («Википедия», официальный сайт компании или сервиса).
Сообщить об опечатке
Текст, который будет отправлен нашим редакторам: