在如今專業化分工逐漸成熟的軟體業中，編制與招募依照職能劃分已是司空見慣，而某些團隊中可能為了消化較多樣的業務，也有培養成員成為不同領域專家 (Domain Expert) 的文化。能夠盡可能提高研發角色的工作內容的同質性，提高效率的同時有助於專業累積固然是好事，但同時也會讓知識落差的問題更加明顯。
合作中實際上會阻礙進度的有八成以上並不是些演算法、Linux 指令、package 用法等等，上網查能查到或是看同事的 source code 就能懂的東西，而是像 payload 欄位意義、magic number、有等於沒有的 error message 之類的，原作者不解釋我還真通靈不出來的情況。
這也讓我對於知識落差造成的困擾有很深的體悟，間接影響我後續成為團隊中相對願意主動改善 README，也堅持讓所有介面設計符合 best practice 的角色。
隨著待過的團隊變多，我個人大致把企業文化在這些問題上的表現分布在光譜上，一端是把責任放在「知識的需求者」身上，另一端則是期望「知識的持有者」負擔更多的責任。長話短說，我個人更為偏好後者的風格。
在一個由「知識的需求者」承擔更多責任的文化中可能會遇到這些情況：
- README 完全空白，因此不熟的人有疑問可能需要花費數十分鐘至數小時研究 source code
- 由於不清楚 request body 必要欄位有哪些，只好在測試環境不斷 try and error 數次至數十次，有時候甚至會不小心把系統弄壞
- 只收到了 400 的 http status 但沒有 error message，只好找維護者幫忙查 log，在對方回覆原因之前完全無法推動進度
在一個由「知識的持有者」承擔更多責任的文化中可能會遇到這些情況：
- 需要對 slack 訊息積極回覆，不容易維持高品質的 focus time
- 研發團隊需要有額外心思持續更新文件並讓它易於理解，README 和 wiki page 有寫不一定代表有用
- 為了最大程度地遵循 best practice 而需要更多辯論與重構的時間，無法適應快節奏的時程，在招募上也需要留意人選價值觀是否合適
以一個個人貢獻者的角度來看，傾向前者的文化無非會直接在新人入職前幾週就給予極大的折磨，長期而言對峙是外部化會構成明顯阻礙，導致評估是否重複利用其他 team 現成系統功能有所顧慮，每當有資深成員要離職交接時也會有段陣痛期。
偏向後者的文化雖然可預期的需要付出些生產力上的成本，但是和價值觀相符的緣故因此讓我的接受度較高。然而回到現實面來說，仍是這些知識落差造成的問題難以量化，也鮮少有軟體企業落實將其他下游 peer teams 合作效率和感受納入績效評核的緣故。