Як написати технічний блог коментар відповідь англійською мовою

Дізнайтеся, як відповідати на технічні коментарі у блогах англійською мовою: виправляти помилки елегантно, розв’ язувати суперечки і відповідати на наступні запитання.

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

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

** Підтвердження ** — короткий початок, який підтверджує, що ви зрозуміли думку коментатора перед тим, як відповісти, що сигналізує про залучення, а не про відкидання або захисну реакцію. “Хороший лов — цей приклад передбачає вбудований в Node 20 fetch, який мені слід було викликати явно.”

** Виправлення (граціозне) ** — відповідь, яка виправляє помилку у початковій статті без надмірних вибачень або захисних дій, зосереджена на тому, щоб запис був правильним для майбутніх читачів. “Ви маєте рацію, у цьому зразок коду є помилка — await відсутній у рядку 12. Я оновив пост; дякую за його фіксацію. ”

** Питання для пояснення ** — питання, яке запитується у коментатора, якщо його думка неоднозначна, використовується для того, щоб уникнути відповіді на питання, яке він не ставив. “Тільки щоб переконатися, що я відповів правильно — ви запитуєте про продуктивність у масштабі, або про коректність у цьому конкретному випадку з краєм?”

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

Поважна незгода — відповідь, яка відкидає технічну твердження коментатора без відкидання, заснована на конкретних міркуваннях або доказах, а не на авторитеті. “Я б, власне, трохи відступив від цього — під час мого тестування різниця була ближче до 5%, ніж до 30%, які ви описуєте, хоча мені було б цікаво, які параметри ви використовували, щоб побачити цю різницю.”

** Етикет для подальшого обговорення гілок ** — практика продовження публічного обговорення конструктивно, включаючи знання того, коли пересунути докладний технічний обмін на більш відповідне місце (система стеження за проблемами, електронна пошта), замість того, щоб дозволити гілки коментарів розширюватися. “Це перетворюється на глибшу дискусію про дизайн, ніж тут можна було б прокоментувати — не забудьте відкрити проблему в репозиторії, щоб ми могли продовжити працювати над нею там?”

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

  • «Хороший постріл — ти правий, і я виправив пост»
  • «Тільки щоб пояснити, ви питаєте про [X] або [Y]?»
  • Це справедлива точка зору, хоча вона трохи виходить за рамки того, що цей пост намагався покрити»
  • «Я б трохи відступив від цього — ось мої аргументи, але мені цікаво про ваше джерело»
  • «Це варте глибшого обговорення, ніж дозволяють коментарі тут — чи не завадило б перенести його на [місце проведення]?»

Приклади речення

Виправлення помилки, на яку звернув увагу один з коментаторів: “Ви абсолютно праві — в оригінальній статті використано старішу версію бібліотеки. Я перезапустив їх і оновив пост з виправленими цифрами; дякую за вловлення цього. ”

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

Переспрямування довгої технічної гілки: “Це перетворилося на справді цікавий крайній випадок, і я не хочу втратити його в гілки коментарів — чи не були б ви відкриті до того, щоб подати його як проблему, щоб ми могли розібратися в деталях з кодом?”

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

  • Відкрийте з справжнім ** підтвердженням ** перед виправленням або незгодом — це змінює тон усього обміну і читає як співпрацю, а не бойовий.
  • Робіть ** виправлення ** елегантними і короткими — дякуйте коментувальнику, вкажіть виправлення і продовжуйте; розширені вибачення читаються як більш захисні, а не менш.
  • Використовуйте ** роз’ яснююче питання ** замість того, щоб вгадати неоднозначний коментар — відповідь на неправильне питання марнує час обох людей і може бути прочитана як відкидаюча.
  • Знайте, коли викликати ** етикет подальшої роботи з ниткою ** — перенаправлення глибокого технічного обміну на систему стеження за проблемами не означає відкидання когось, це надає обговоренню місце, яке йому підходить.

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

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

Розрізняють плавальні і неплавальні плавальні

Будьмо чесними – не всі згодяться зі всім. Особливо, коли обговорюють складні технічні концепції онлайн. Ваша мета не обов’ язково полягає у тому, щоб перемогти у дебаті, але пропонувати конструктивні відгуки, визнавати різні точки зору і зберігати професіоналізм, навіть коли ви категорично не погоджуєтесь. Ключовим є початок з емпатії; визнання намірів коментатора - чи це справді пошук роз’яснення або представлення інакше вираженої точки зору - може зменшити напругу. Фрази на кшталт «Я ціную вашу точку зору на це…» або «Дякую за позначення…» демонструють повагу перед тим, як зануритися в розбіжності.

Важливо, щоб розбіжності розглядалися як різниці в розумінні, а не обов’язково як неправильні відповіді. Уникайте абсолютних тверджень на зразок « Це неправильно » або « Ви не розумієте ». Замість цього використовуйте фрази, які запрошують до пояснення і демонструють ваш власний процес мислення. Наприклад, замість того, щоб сказати «Неправильно», спробуйте «Я розумію, що ви маєте на увазі щодо [спеціфічного аспекту], але я думав більше в напрямку…» або «Щоб переконатися, що ми зрівнялися, чи можете ви розглянути…» Введення хеджування мови - «здається», «потенційно», «може бути» - пом’якшує потенційну критику і дозволяє спільне дослідження альтернативних рішень.

При представленні контр-аргументу, завжди вступайте до нього з визнанням чинності початкової точки * до певної міри *. Фрази на кшталт «Це дійсна точка зору щодо [аспекту], однак…» або «Хоча я розумію вашу початкову оцінку…» визнають точку зору коментатора перед тим, як запропонувати свою власну. Потім, чітко і коротко скажіть * чому * ви маєте інший погляд. Сфокусуйтеся на фактичних доказах, логіці і демонстрованих міркуваннях, а не суб’єктивних думках. Уникайте жаргонних і надто технічних слів, якщо це не абсолютно необхідно, і завжди визначайте всі використовувані вами терміни. Пам’ятайте, ясність переважає авторитет.

Нарешті, активно слухайте відповідь — справді слухайте. Не формулюйте своє наступне заперечення, поки інша людина говорить. Запитуйте прояснюючі питання, наприклад: « Чи можете ви розповісти мені більше про…? » або « Чи можете ви допомогти мені зрозуміти, чому ви прийшли до цього висновку? » Це демонструє справжнє бажання взаєморозуміння і часто може призвести до рішення, де обидві сторони відчувають себе почутими і поважаними. Простое, искреннее “Дякую за разъяснение ваших соображений” поможет разрядить любой потенциальный конфликт.

Поширені запитання

Про що ця стаття "Як написати технічний блог коментар відповідь англійською мовою"?

Дізнайтеся, як відповідати на технічні коментарі у блогах англійською мовою: виправляти помилки елегантно, розв’ язувати суперечки і відповідати на наступні запитання.

Чи безкоштовна ця стаття?

Так. Усі статті на CoderSlingo, включно з цією, доступні безкоштовно без реєстрації.

Скільки часу займає читання "Як написати технічний блог коментар відповідь англійською мовою"?

Приблизно 7 min.