我個人覺得遠距工作最大的困難就是有效的溝通。因為：
-
無法直接面對面討論
辦公室可能在千里之外，怎麼走過去拍拍肩膀問呢？
-
時區問題
一邊是白天，一邊是黑夜，白天不懂夜的黑。
古代飛鴿傳書，現代密我臉書，傳遞消息變得是載體，用的還是文字。文字幾千年下來了，仍然是最有效的溝通工具。寫作是遠距工作者非常重要的特質之一，如何清晰高效的溝通，全靠好的寫作本事。寫作怎麼寫的好又是另一篇了，這篇講「溝通」。
先講講兩種溝通，即時溝通與非即時溝通。
姜文：讓子彈飛一會兒。
事情很多時候，真的沒有那麼急！現代人把時間看得太重。
很多事情都忌「急」，急不得，有時候有朋友會問我問題，我其實不知道答案是什麼，我會先試探性地問一些問題，稍待片刻，通常發現問題的人可能被你的反問而啟發，進而自己解決問題。
真正急的事情當然還是得做，只是很多時候事情真的沒有那麼急。理清問題發生的根源，不要隨便來個「暫時解決辦法（Workaround）」，暫時解決辦法是程式碼品質下降的元兇，午夜夢迴被叫醒的原因。
生病了醫生會只看表面治病嗎？找到根源，對症下藥。但暫時解決辦法也不是不行，有時候真的很急。
同事手邊可能有極為重要之事正在進行，學會尊重同事，同事也會尊重你。
非即時溝通很難，很難忍住，有時候問題發生了，資深人士默默無語查記錄檔，分析問題所在；資淺的靠猜。快速解決問題固然好，但不要靠猜，僥倖命中不代表你厲害，這是運氣好。
我開始貢獻開源專案的時候 (rails/rails)，送 Pull Request 如搶演唱會門票一般，在 Pull Request 的頁面不停刷新，這是好事，代表我在乎，但是....
給開源專案送了一個 Pull Request 嗎？過了幾天還沒有下文？這時候許多人便急了，欸可以看一下嗎？為什麼不合併？有什麼問題嗎？要注意，每個人有每個人的生活，你我都是一個普通人，開源專案維護者也是，很多時候不是不回，可能這個改動太大，需要進行縝密的審校，或是有其它考量，理當尊重之。
遠距工作應該要避免進行即時溝通，程式設計師最討厭的事情之一便是「遭到打斷」。
打斷的成本極其高，越是複雜的問題越需要時間進入「狀態」，需要把所有的資訊重新載到腦一遍，建議先採用非即時溝通，來回數次仍有疑慮，便可考慮採用「即時聊天」、「視訊」等即時溝通方法。
-
Basecamp
-
GitHub
由於 GitHub 是「分布式」的原始碼管控工具，這也讓非同步溝通變得可能。
-
Hipchat
-
Slack
-
Skype
-
Screenhero
-
Gitter
-
各種專案管理服務
-
仍要注意標點符號
每一次寫東西，都要注意逗號，句號，各種標點符號的用法。讀得人舒服，也是自己的修煉。
-
大膽的刪
不需要知道的資訊刪掉，冗贅字刪掉，盡量提供需要知道的資訊就好。
-
提供上下文
有時候問題發生了，你看見根源所在但不知如何解決，這時候要好好的解釋問題發生的成因，時間，變數等。因為要替你解決問題的夥伴，不一定知道你所知道的啊！盡可能提供上下文。
-
自己先讀一遍
自己讀起來順嗎？人最大的敵人就是自己了，自己都讀不下去，你真的好意思讓同事讀嗎？
-
避免模糊的字眼
盡量用簡潔簡單的語句，不要使用縮寫。