目錄
「Is This Thing On?」是表演者站上舞台時，拿起麥克風敲一下說的話。不是廢話，而是確認：訊號有沒有傳到觀眾那邊？
工程師在做技術溝通的時候，幾乎從來不問這個問題。
TL;DR
技術溝通的最大問題不是解釋得不夠詳細，而是沒有確認訊號是否成功傳遞。「Is This Thing On?」作為一個心智模型，提醒你在任何技術解釋之後要做一件事：暫停，確認對方真的理解了，而不是點頭讓你繼續說。
為什麼工程師的溝通常常失效
工程師解釋技術問題的時候，腦子裡有完整的上下文：為什麼這樣設計、踩過什麼坑、背景假設是什麼。對方通常沒有。
這個知識不對稱導致了幾個典型問題：
解釋太快：你說完一個概念，立刻進入下一個，但對方還在理解第一個。
用專有名詞沒解釋：對你來說 “eventual consistency” 和 “idempotent” 是日常語言，但你的聽眾可能沒有這個基礎。
沒有確認理解：說完一大段之後問「有問題嗎？」這種問法基本沒用——大多數人不知道自己哪裡不懂，或者不想在群體面前承認不懂。
假設圖表是自解釋的：你的架構圖在你腦中是清晰的，但對初次看到的人來說，它可能只是一堆方塊和箭頭。
具體應用場景
技術文件寫作
好的技術文件要假設讀者是一個「聰明但沒有這個背景」的人。每次你準備寫「如你所知…」或「顯然地…」，停下來問自己：這對哪些讀者是「如你所知」？哪些讀者可能根本不知道？
一個具體的做法：寫完一段文件後，把它給一個相關但不在這個子系統深耕的工程師讀。問他「有什麼地方讓你需要停下來重讀或去查資料？」這些地方就是你需要補充說明的地方。
Code Review 的回饋
「這樣不對」是最沒有價值的 code review 回饋。它傳遞了你的判斷，但沒有傳遞你的推理。更有效的方式：
# 不好的回饋
這個查詢會有效能問題
# 好的回饋
這個查詢在 users 表有超過 100 萬筆資料時會做全表掃描
（沒有 WHERE 條件用到 email 欄位的索引）
可以加一個 covering index: CREATE INDEX ON users(email, id)第二種寫法，對方讀完之後真的能理解問題在哪裡，下次遇到類似情況也能自己判斷。
技術分享和簡報
在技術分享中，每 5–10 分鐘做一次「Is This Thing On?」的檢查：
- 停頓，問一個具體的問題（不是「有問題嗎」）：「我剛才解釋的 CAP theorem，大家對『partition tolerance』的部分有沒有疑問？」
- 用類比確認：「我說的這個 event sourcing 的概念，可以想像成銀行帳本只記錄每筆交易而不是只記最終餘額，這樣的比喻有沒有幫助？」
- 問具體的理解確認：「如果你要實作這個，你會先做哪個部分？」
Async 溝通：Slack 和 PR
非同步溝通的挑戰是沒有即時回饋。發完一條 Slack 訊息或一個 PR 描述，你不知道對方是真的理解了，還是點了 emoji 就過了。
幾個做法：
- PR 描述要說清楚「為什麼這樣改」而不只是「改了什麼」
- 重要的設計決策在寫完之後，主動問：「這個設計的 trade-off 我描述清楚了嗎？有沒有你覺得我沒有考慮到的情境？」
- 如果你在解釋複雜問題，在訊息結尾加：「如果這樣說不夠清楚，可以開個 15 分鐘的 call 對齊一下。」
跟一般溝通技巧建議的差別
大多數「技術溝通」的建議都在教你怎麼「說得更好」：用更簡單的語言、用類比、畫圖。這些都有用，但都是單向的——從你到聽眾。
「Is This Thing On?」強調的是雙向確認：不只是你說得清不清楚，而是確認對方真的接收到了。這是主動設計訊號確認機制，而不是假設訊號自然會傳遞到。
在工程系統裡，我們會設計 acknowledgment、retry、和 dead letter queue 來確保訊息真的被處理。在人的溝通裡，我們卻常常沒有這個機制。
小結
「Is This Thing On?」不是一個複雜的方法，但它需要主動的習慣建立：在每次技術解釋後，花 30 秒確認訊號是否傳遞成功，而不是假設說完就等於溝通完。
對工程師來說，溝通能力的邊際回報往往高過再多一個技術技能。一個能讓五個工程師都理解設計決策的架構師，比一個只有自己理解的架構師更有價值。
參考資料
相關標籤