Англійська мова для написання технічного блогу Post Introduction That Hooks Readers

Більшість технічних вступів до статей блогів зазнають невдачі ще до того, як читач досягне другого абзацу, оскільки вони починаються з загального висловлювання, яке читач вже знає — « Кешування є важливою частиною сучасних веб- програм ». У цьому підручнику розглянуто англійські методики написання вступу, який заслуговує уваги, а не марнує її.

Ключовий словник

** Загальний вступ** — речення, яке можна застосувати до майже будь- якого повідомлення на цю тему, не надаючи читачеві нової інформації або причини для продовження читання. ”« Бази даних є необхідними для сучасного програмного забезпечення »— це загальний початок — він не говорить читачеві нічого, в що він не вірив до натискання посилання.”

** Специфічний гачок ** — початок, який говорить про щось конкретне, несподіване або негайно корисне, надаючи читачеві причину продовжувати читати у першому реченні. “Специфічний гачок: ‘Ми зменшили нашу затримку P99 на 340 мс, змінивши один індекс — ось саме те, що ми знайшли і чому це працювало.’”

** Проблема- перший початок ** — починаючи з конкретної проблеми, яку розв’ язує стаття, описана достатньо конкретно, щоб читач з цією проблемою відразу розпізнав її. “Проблема-перше відкриття: ‘Якщо ваші запиту Postgres сповільнюються після масового імпорту, цей пост пояснює чому — і це, ймовірно, не причина, яку ви думаєте.’”

** Обіцянка (посту) ** — чітке твердження про те, що читач зможе дізнатися або зробити до кінця, встановлене на початковому етапі, щоб читач міг вирішити, чи продовжувати читати.

• “До кінця цього повідомлення ви зможете діагностувати проблему з запитом N+1 з виводу EXPLAIN ANALYZE менш ніж за дві хвилини.” *

** Сигнал надійності ** — конкретна, перевіряема деталь (число, реальний сценарій, інструмент з назвою), розміщена на початку, яка робить читача впевненим, що стаття заснована на реальному досвіді, а не на загальній порадами. “«Це засновано на виробничому інциденти, який знизив оплати для 40 000 користувачів на 12 хвилин» є сигналом надійності — це конкретне і перевіряються, на відміну від «з мого досвіду». “

Звичайні фрази

• Якщо ви коли-небудь [спеціальний розчарований сценарій], цей пост для вас
• «Ми [конкретний конкретний результат] за допомогою [конкретної дії] — ось як»
• «До кінця цього посту, ви зможете [конкретний, перевірений результат]»
• «Це не звичайна порада про [спільний підхід] — ось що насправді працювало»
• “[Конкретна цифра/деталь] змусило нас усвідомити [дивовижний взірець].”

Приклади висловлювань

Загальний початок, переписаний як специфічний гачок:

• Загальне: « Обмеження швидкості важливо для безпеки API. » Конкретно: «Ми відправили обмеження швидкості, яке працювало ідеально в кожному тесті, а потім один неправильно поводячийся клієнт знищив наш API в виробництві. Ось розрив між «тестованим» і «правильним», який ми пропустили». *

Відкриття з першої задачі, яке дозволяє правильному читачеві негайно самостійно вибрати:

• “Якщо ваші тести інтеграції пройшли локально, але з перервами зазнають невдачі у CI, і ви вже виключили можливість неправильних мережевих викликів, у цьому повідомленні буде розглянуто категорію помилок, яку ви, ймовірно, ще не перевіряли: спільний стан між паралельними тестовими працівниками.” *

Яскраво і конкретно сформулювати обіцянку посту:

• “До кінця цього повідомлення ви зможете читати плам’ ячий графік достатньо добре, щоб знайти конкретну функцію, яка спричиняє пік процесора, не будучи експертом з профілювань.” *

Використовуючи сигнал надійності без хибних обіцянок: “Цей підхід обробляє близько 40 000 запитів на секунду в нашому виробничому середовищі на одному екземплярі - не тому, що наш код винятковий, а через одне архітектурне рішення, яке ми майже не зробили.”

Професійні поради

• Замінити загальні категорії (“X важливо”) на спеціальну заяву, число або сценарій в першому реченні — це єдина найвища редагування для слабкого введення.
• Використовуйте ** проблему першою **, коли ваша стаття розв’ язує вузьку, специфічну проблему — це дозволить правильному читачеві негайно розпізнати себе і взятися за читання, а неправильному читачеві швидко покинути ваш блог, що є нормою.
• Зазначте обіцянку статті явно біля верхньої частини — читачі вирішують, чи інвестувати свій час протягом перших декількох речень, і явна обіцянка допомагає їм правильно вирішити.
• Використовуйте ** специфічні, перевіряються деталі ** як сигнал надійності на ранньому етапі - реальна кількість або сценарій є більш переконливим, ніж прикметник, наприклад, «значний» або «головний»
• Не починайте з ** риторичного питання **, на яке читач вже знає відповідь (« Чи ви колись замислювалися, як працює кешування?») — це буде сприйматися як заповнення, а не як запитання.

Практичні вправи

1. Переписати загальне технічне речення для початку блогу у певний гачок з конкретною деталлю.
2. Написати відкриття з проблемою для гіпотетичної статті про вузький технічний випадок.
3. Напишіть речення, у якому буде виражено обіцянку статті у блогу — що читач зможе зробити до її закінчення.

Національна мова: англійська, для не-національних письменників

Отже, ви створили блискучу ідею — глибоке занурення у особливо розумний алгоритм, посібник з усунення постійних помилок або дослідження нової архітектурної моделі. Теперь пришло время написать введение. Але давайте будемо чесні, переклад технічних концепцій * і * написання цікаво англійською мовою може бути складним, особливо коли ви не цілком впевнені в ідіомах і фразуваннях, поширених в професійних середовищах розробки. Легко впасти в надто формальну мову або, навпаки, використовувати неформальні терміни неправильно. Мета не лише в тому, щоб передати інформацію; це з’єднати вас з аудиторією - колегами-розробниками, які хочуть чітке, коротке пояснення, надано з авторитетом.

Однією з найбільших перешкод для носіїв англійської мови, які не є її рідними носіїв, є розуміння того, як технічні дискусії формуються. Розгляньте це повідомлення Slack: « Цей PR вводить шаблон введення залежностей для служби автентифікації. Це значно зменшує сполучення і покращує перевіряність. » Людина, для якої мова є рідною, може негайно розпізнати це як стандартний спосіб опису змін у архітектурі. Але для когось, хто вивчає професійну англійську, вона може здатися густою і абстрактною без контексту. Ключовим є визнання того, що технічні дискусії часто проникнуті в встановлений словник - такі терміни як “з’єднання”, “перевіряемость” і “залежность введення” не є просто модними словами; вони представляють конкретні підходи з визначеними значеннями в індустрії. Не бійтеся шукати пояснення, якщо ви зустрінете термін, який ви не до кінця розумієте. Попросити пояснення не є ознакою слабкості; це демонструє прихильність до розуміння проблеми і ефективного спілкування.

Іншим поширеним сценарієм є отримання коментаря перегляду коду: «Назва функції processData неоднозначна. Чи можете ви надати більше контексту щодо того, що ця функція насправді * робить ? “Знову ж таки, проблема не обов’ язково в самому технічному завданні (обробка даних), а в тому, як це повідомляється. Рецензент ввічливо просить про пояснення щодо * мет функції, підкреслюючи, що чіткі правила і описи назв є ключовими для підтримки і співпраці. Він підкреслює важливість не тільки написання коду, але і документування його намірів - принцип, який часто ігнорується в поспішних середовищах. Розвиток вашого словника навколо таких концепцій, як « намір », « ясність », « підтримка » і « вплив », буде вам добре служити, коли ви пояснюєте технічні рішення іншим.

Нарешті, під час написання опису запитів на звантаження пам’ ятайте, що це перше враження, яке залишить запит на звантаження на потенційних переглядачів. Замість простого повідомлення « Виправлено помилку у реєстрації користувача », яке є технічно точним, але не має значного впливу на роботу програми, розгляньте щось на зразок: « Ця публікація розв’ язує проблему критичної вразливості розпізнавання за допомогою реалізації обмеження швидкості і покращеної перевірки паролів, зменшуючи ризик несанкціонованого доступу ». Зауважте, що у цій версії використано більш сильні дієслова (« адреси », « зменшення ») і чітко зазначено * перевагу * зміни — безпеку. Сфокусування на результатах і перевагах, а не лише на описі дій, є потужним способом передачі цінності у вашому технічному написанні.