Як написати статтю на LinkedIn як IT-професіонала
Шаблони прив’ язки, технічна надійність без перевантаження жаргоном, CTAs і словниковий запас для написання професійних постів LinkedIn англійською мовою.
Більшість інженерів, які починають писати на LinkedIn, роблять ті ж дві помилки. Перший - це написання статей, які виглядають як внутрішня документація - технічно точні, але настільки щільні жаргоном, що тільки їхні безпосередні колеги можуть їх слідкувати. Друга - копіювання мотиваційного стилю бізнес-інфлюенсерів - широкі твердження і риторичні питання, які не мають нічого конкретного сказати. Сладка точка знаходиться між цими двома: написання, яке є технічно достовірним, читається широкою професійною аудиторією і достатньо конкретним, щоб бути справді цікавим.
У цьому посібнику наведено конкретні шаблони — гачки, структуру, словниковий запас — які роблять публікації LinkedIn корисними для фахівців з інформаційних технологій.
Перша лінія: лінія 1
LinkedIn обрізає пости після двох-трьох рядків, показуючи кнопку «дивитися більше». Перший рядок — це все, що вам потрібно знати — якщо він не змушує читача переглянути статтю, решту статті не буде прочитано.
Ефективні шаблони для технічних повідомлень
** Конкретний результат: **
- “Ми скоротили час розгортання з 45 хвилин до 6 хвилин. Ось як ми це зробили»
- “Три месяца назад наша задержка P99 была 800 мс. Сегодня 90 мс. Це те, що змінилося»
** Контр-інтуїтивне твердження: **
- «Ми вилучили 40 000 рядків коду в минулому кварталі і наша система стала більш надійною»
- «Найкраще архітектурне рішення, яке ми зробили цього року, було не використовувати мікросервіси»
Урок, який здобув з великим трудом:
- «Я провів чотири роки, уникаючи Kubernetes. Ось що нарешті змінило моє ставлення до цього»
- “Ми зробили помилку при перенесенні бази даних, яка коштувала нам шість годин простою. Я хочу поділитися тим, що ми пропустили»
Спостереження або тенденція:
- «Щось, що я помітив після 12 років перегляду коду: коментарі, які відчувають себе найбільш незручно, зазвичай є найціннішими»
- «Ніхто не говорить про те, як важко підтримувати кодову базу Terraform з 20 інженерами на ній»
Крюків, яких треба уникати
- “У сьогоднішньому швидко змінюючомуся технологічному ландшафті…” - цей відкривач використовувався так багато разів, що викликає негайне відключення.
- “Я радий поділитися тим, що…” — починається з ваших емоцій, а не з інтересу читача.
- «Як інженер-програміст з 8-річним досвідом…» — веде з вашими реквізитами, а не з вашим змістом.
Постструктуралізм
Структура з 3-х частин для технічних позицій
Частина 1: Гачок і контекст (1-3 рядки) Вкажіть проблему, результат або спостереження, що обрамляють статтю. Це те, що дає читачеві можливість пройти крок «дивитися більше»
Частина 2: Суть (4-10 рядків) Фактичний зміст - що ви зробили, що ви дізналися, як щось працює. Звідси й технічна надійність. Будь конкретним. Числа, терміни і конкретні результати є більш правдоподібними, ніж узагальнення.
Частина 3: Запитання або питання (1-2 рядки) Закінчуйте або конкретним уроком, питанням, яке заохочує до участі, або рекомендацією.
Прикладна структура на практиці
Гук: «У нас був виробничий інцидент, який тривав 4 години. Основной причиной были две строчки кода. Ремонт занял 30 секунд. Ось справжній урок»
Суть: «У січні наша служба оплати почала періодично викидати 500 помилок — не на кожен запит, а на близько 3% з них. Повідомлення про помилку не було корисним. Мы потратили несколько часов на изучение журналов, отслеживание распределенных следов, перезапуск служб. Врешті-решт ми знайшли: умова гонки в логіці оновлення сеансового токену. Дві програми go записували в одну карту одночасно без блокування. Виправлення полягало у додаванні мутекса. Дві лінії. Але справжня вартість була не 30-секундний фіксацією - це було 4 години трьох інженерів не в змозі відтворити його надійним чином, тому що умови гонки не є детермінованими. ”
Зауваження: “Якщо ви запускаєте Go-сервіси і ваші помилки є переривчастими і непоясненими, спочатку перевірте одночасний доступ до карти. Прапорець -race в testing існує саме для цього. Тепер ми ввімкнули його в нашому CI pipeline»
Технічні характеристики без огляду на вагу
Проблема для IT-професіоналів на LinkedIn полягає в калібруванні технічної глибини. Ваша аудиторія складається з різних груп: деякі з них — це спеціалісти, які цінують точну термінологію; інші — це менеджери продуктів, засновники, рекрутери і інженери у сусідніх галузях, які знають загальні поняття, але не специфіку.
Принцип калібрування
Написати для розумного читача, який не є спеціалістом у вашій галузі. Припустимо, що вони розуміють, що таке розгортання; не припускайте, що вони знають, що таке StatefulSet.
Якщо ви вводите технічний термін, який може бути невідомим для неспеціалістів, коротко визначте його:
- «Ми використовуємо функціональні прапори — конфігурації, які дозволяють нам ввімкнути функцію для 1% користувачів перед тим, як розгорнути її широко — щоб випробувати нові потоки платежу»
- «Проблема була умовою гонки: два процеси працюють одночасно, обидва намагаються змінити один і той же шматок даних»
Ви нічого не втрачаєте, додаючи визначення з трьох слів. Але ви втрачаєте неспеціалізованих читачів назавжди, якщо не робите цього.
Специфіка як сигнал довіри
Неясне: «Ми значно поліпшили нашу роботу» Конкретно: «Ми зменшили середній час відповіді API з 340 мс до 95 мс»
Vague: «Ми перефакторизували нашу базу коду» Конкретно: «Ми розбили моноліт на п’ять доменів протягом восьми місяців, мігруючи один обмежений контекст за раз»
Специфічність робить дві речі: вона сигналізує, що ви дійсно зробили щось (не просто що ви читали про це), і вона дає читачам щось конкретне, з чим можна працювати.
Словник для занять
Запрошую до коментарів
- «Мені цікаво, чи інші потрапляли в це — як ви з цим впорались?»
- “Ви бачили таку схему у вашій команді? Я б хотів почути різні підходи»
- “Який твій погляд на цей компроміс? Немає очевидно правильної відповіді»
Поділитися думками
- «Я думаю, що індустрія недооцінює, наскільки складною є операційна складність мікросервісів»
- «Я вважаю, що…»
- «Я прийшов до думки, що…»
- «Я раніше думав про X, але після [дослідження], я тепер думаю про Y»
Остання модель — зворотна думка — є однією з найбільш привабливих структур на LinkedIn. Це сигналізує про інтелектуальну чесність і навчання, і це створює оповідальну дугу в короткому пості.
Признаю несогласие
- «Я знаю, що це суперечливий прийом — деякі інженери категорично не погоджуються»
- «Не всі погодяться з цим підходом, і я розумію чому»
Ці фрази не ослаблюють вашу позицію — вони запрошують до обговорення, а не до оборонних реакцій.
Позначається як частота або частота
Length
Повідомлення LinkedIn добре працюють в двох довжинах: короткі (менше 150 слів) і середні (300-500 слів). Дуже довгі статті (700+ слів) втрачають читачів на платформі, створеній для прокрутки. Якщо ваш вміст є справді довгим, напишіть його як статтю (формат блогу LinkedIn), а не як пост.
Для більшості технічних статей, 250-400 слів є оптимальним: достатньо місця, щоб дати реальний контекст, достатньо короткий, щоб прочитати за менш ніж дві хвилини.
Frequency
Один високоякісний пост на тиждень ефективніший, ніж п’ять посередніх постів. Для не-рідних носіїв, написання одного уважно створеного посту щотижня також є більш стійким. Кожен пост — це вправа з написання, яка поєднує: ваш словник, ваше відчуття того, що звучить у вашій аудиторії, і вашу впевненість у собі — усе це покращується з послідовною практикою.
Писання в LinkedIn - це навички, як і будь-які інші - вони покращуються з свідомо практикою. Найкращим місцем для початку є написання про щось справжнє: проблему, яку ви розв’ язали цього тижня, помилку, яку ви зробили і з якої ви дізналися, технічну концепцію, яку ви нещодавно зрозуміли на глибшому рівні. Автентичність і специфічність цінніші за польську. Начни с этого.