Hedging Language in IT: How to Sound Confident Without Overpromising

Хеджування — це використання мови, яка кваліфікує твердження — вказує, що воно не є певним, не є абсолютним або не є вашою особистою думкою. В академічному і науковому письмі хеджування є обов’язковим. У повсякденному професійному спілкуванні, це знак компетентності та інтелектуальної чесності.

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

У цьому підручнику показано, як правильно обмежити себе у технічному спілкуванні.

---

Чому воно так важливе для нас?

У професійному спілкуванні з приводу інформаційних технологій ризики хибної впевненості є високими:

• • « Це займе 2 дні » * → якщо неправильно, ви створили пошкоджене зобов’ язання
• • « Система стабільна » * → якщо неправильно, ви створили хибну довіру перед розгортанням
• • « Ваду виправлено » * → якщо ваду виправлено лише частково, ви створили розчарованого користувача

Відповідне хеджування захищає вас професійно і дає змогу читачеві ясно побачити те, що ви насправді знаєте:

• “Це повинно зайняти близько 2 днів — я дізнаюся більше, як тільки почну.”
• • “Система виглядає стабільною на основі поточного моніторингу.” *
• “Видалення вирішує основну причину — будь ласка, перевірте в стаджі перед випуском.”

---

Три рівні хеджування

Рівень 1: Висока впевненість (мінімальне хеджування)

Використовувати, якщо у вас є переконливі докази або обширні тести.

Прикметники: напевно, ясно, безсумнівно Модальні дієслова: *буду, *моїм

“Тести пройдуть — я запустив їх локально у всіх середовищах.” “Це, безумовно, умова раси — я відтворював її послідовно.”

Рівень 2: Помірна впевненість (стандартне хеджування)

Використовуйте для більшості професійних повідомлень, де ваша оцінка є обґрунтованою, але не абсолютною.

Прикметники: може бути, можливо, зазвичай, типово, зазвичай Модальні дієслова: should, would, ought to Дієслова: появлятися, здатися, свідчити, вказувати

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

Рівень 3: низька впевненість (сильне хеджування)

Використовувати, якщо у вас обмежені дані, ситуація неясна або ви тільки спекулюєте.

Прикметники: може бути, можливо, можливо Модальні дієслова: може, може, може Дієслова: дивуватися, підозрювати

“Це може бути пов’ язано з недавніми змінами в інфраструктурі — я ще не підтвердив це.”

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

---

Звичайні хедж-патерни

1. Європа Обмеження сфери дії за допомогою “намагається”, “в більшості випадків”, “зазвичай”

“Цей підхід добре працює для служб з передбачуваними шаблонами трафіку.”

• “У більшості випадків збільшення кількості з’ єднань вирішує цей тип помилки.” *
• “Збирання зазвичай завершується за менше ніж 5 хвилин.” *

Ці фрази запобігають тому, щоб ваше узагальнення було сфальсифіковано будь- яким винятком, який може прийти на думку читачеві.

2-й. Приписування погляду: “Я думаю”, “Я вірю”, “На мій погляд”

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

Ці фрази сигналізують: це моя професійна оцінка, а не перевірений факт.

3-й. Сигналізація неповності: «наскільки я можу сказати», «наскільки мені відомо», «на основі…»

• “Наскільки я можу сказати, це єдине місце, де з’ єднання відкрито, але не закрито.” * “Наскільки мені відомо, цей кінцевий пункт не обмежений швидкістю — але вам слід перевірити.”
• « За даними поточних показників, система добре справляється з навантаженням ». *

Ці фрази повідомляють, що ваше твердження залежить від ваших поточних даних.

4-й. Умовне хеджування: “якщо”, “припускаючи”, “при умові, що”

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

5-й. Признаючи альтернативи: “одна інтерпретація”, “інша можливість”

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

---

Коли не слід хеджувати

Хеджування має свої витрати. Сигнали перехеджування:

• Недовіра, коли довіра є обов’язковою
• Неохота придерживаться определенного мнения
• Ухилення від відповідальності

Деякі контексти вимагають прямоти:

Рішення засідань: ❌ “Може бути, це буде хороша ідея, щоб розглянути можливість переходу на PostgreSQL.” ✅ “Я рекомендую перейти на PostgreSQL. Він краще обробляє наші шаблони запитів, і команда має більше досвіду з ним.”

Реакція на інцидент: ❌ “Сервер може бути перевантажений, що може спричинити деякі проблеми з затримкою.” ✅ “Сервер перевантажений. Ми збільшуємо масштаби зараз.»

Взяти на себе зобов’язання працювати: ❌ “Я, можливо, зможу поглянути на цей квиток в якийсь момент.” ✅ “Я візьму цей квиток — я отримаю оновлення до кінця дня.”

** Правило: ** Захистіть свій рівень впевненості. Не закрывайся на свою готовность взять на себя ответственность.

---

Розробка в конкретних контекстах

За оцінками

Context	Weak (no hedge)	Strong (over-hedged)	Balanced
Time estimate	”2 days"	"Somewhere between 1 and 5 days probably"	"Around 2 days — I’ll know better once I’ve read the code”
Deadline	”It’ll be done Friday"	"I might be able to finish it possibly before the weekend"	"I expect to finish by Friday — if I hit a blocker I’ll let you know by Thursday”

У коментарях перегляду коду

Too assertive	Appropriately hedged
”This is wrong."	"This might cause issues when the list is empty."
"You should use a Set here."	"I wonder if a Set might be more efficient here — worth benchmarking?"
"This will fail under high load."	"I’d be concerned about this under high load — have we load-tested this path?”

В отчётах о состоянии

Overconfident	Appropriately hedged
”We will deliver feature X by Friday."	"We’re on track to deliver feature X by Friday, assuming no major blockers."
"The system is stable."	"The system appears stable based on current monitoring."
"The bug is fixed."	"The bug appears to be resolved in staging — we need to confirm in production.”

В отчетах о вскрытии/инциденте

Хеджування особливо важливе, коли ви все ще розслідуєте:

• “Попередні дані вказують на витік пам’ яті у обробнику з’ єднань. Мы пока не исключаем, что причина в изменении конфигурации. Розслідування триває».*

---

Фраза «швидка» вживається в описуванні швидкості

Purpose	Phrases
Signalling probability	”likely, probably, should, would, might, may, could, possibly”
Limiting scope	”typically, usually, in most cases, generally speaking, tending to”
Attributing to yourself	”I think, I believe, in my view, it seems to me”
Signalling incomplete info	”as far as I know, to my knowledge, based on current data”
Making it conditional	”if, assuming, provided that, as long as”
Expressing approximation	”around, approximately, roughly, in the region of, about”
Flagging a hypothesis	”one possibility is…, this could indicate…, I suspect…”

---

Practice

Переписати ці речення, щоб додати відповідне хеджування:

1. • “Аплікаційний програмний інтерфейс поверне відповідь за менше ніж 100 мс.” *
2. • “Ця рефакторизація зменшить використання пам’ яті на 40%.” *
3. • « Вада у модулі автентифікації. » *
4. • “Перехід на Redis вирішить проблему з кешуванням.” *

** Пропоновані перезаписи: **

1. “API має повернути відповідь за менше ніж 100 мс при звичайному навантаженні.”
2. “Засноване на нашому профілі, це рефакторизація повинна зменшити використання пам’ яті приблизно на 40%, хоча фактичне число буде залежати від виробничих трафіку моделей.”
3. “Доказ вказує на модуль автентифікації — я хотів би додати більше журналів, перш ніж підтвердити кореневу причину.”
4. “Перехід на Redis, ймовірно, вирішить проблему кешування — варто перевірити це з допомогою піка перед затвердженням.”

---

Зв’язані ресурси

• Модальні дієслова в технічній літературі: must, should, may, may
• Як не погоджуватися ввічливо в технічних зустрічах
• Англійська мова для перегляду коду
• 10 найпоширеніших помилок, які роблять професіонали