程式設計=翻譯?
本文作者Alvaro Videla，他是FaunaDB的核心開發人員，在瑞士的家中工作，他還是RabbitMQ的核心開發人員，也是構建德國最大約會網站之一的團隊的首席開發人員。他是RabbitMQ in Action的合著者。
將現實世界轉換為數字抽象需要蒸餾提煉。而且，程式設計與文學翻譯一樣，開發者必須瞭解他們自己存在的偏見。
隱喻Metaphor 是處理新問題和尋找創造性解決方案的有力工具。讓我們這裡使用一個隱喻：我們如果將程式設計視為翻譯能夠從中學到什麼？
更具體地說，程式設計將領域問題（如商店庫存，公共圖書館目錄，票務預訂系統）轉換為計算機程式。
當我們將系統從現實世界適應數字世界時，許多因素開始發揮作用。將模擬轉換為數字需要離散化，留下一些東西；過濾掉一些東西，或者我們關注一些東西，這些取決於我們的偏見。
傳統翻譯如何處理偏見問題？程式設計師可以從中學到什麼？
點選標題見原文，大概思想如下：
1. 從根本上說，翻譯是一種解釋行為。
2. 翻譯不僅改變和增加了它的表達，它也影響了原作所用的語言
3. 某個詞並不是你認為它 的意思，從程式設計角度來看，在處理遺留程式碼時，這尤其具有挑戰性。作為程式設計師，我們應該問自己：我們在程式碼中表示實體的程度如何？如果將來閱讀，是否可以理解程式碼實際上要解決的問題？哪個匹配此程式碼的可能世界？
4. 在程式設計中，我們需要引入靈活性元素。我們在平常語言對話過程中具有內在的靈活性、適應和協調我們的對話者我們使用的詞語的含義（上下文）。讓我們在我們的程式設計工作中做同樣的事情。
Steven S. Skiena曾經不得不設計一種演算法來尋找從城市X到城市Y的最便宜的航班。他將這個現實問題轉化為程式的第一種方法是使用Dijkstra的最短路徑演算法。在這裡我們看到他的偏見：這是一個圖形問題，我將通過使用最短路徑來解決它。他的客戶很快就清楚地表明，Skiena錯過了重要的背景-即航空業規則。他們繼續交流，直到Skiena用優先佇列解決問題。他不得不拋棄他的偏見並學習新的知識焦點。最終他的解決方案“事實證明，它足夠快，可以為使用者提供互動響應，”Skiena說。他學到了什麼“幾乎相同的事情”真正意味著這個問題。
5. 我們需要以一種理解態度來對待編碼，即改變和適應是不可避免的。
那麼，從翻譯提供的框架中看到程式設計，我們學到了什麼？
我們從業務角度看，有很多方法可以將現實世界轉化為我們的程式。通過詢問客戶希望解決我們的問題並有助於我們更快，更直接地滿足他們的需求。
從程式設計的角度來看，我們看到我們的世界會翻譯成新版本，可能的願景投射到同事的腦海中，因為他們試圖理解我們的程式碼試圖解決的問題。我們選擇了正確的抽象嗎？我們是否專注於問題的正確部分？
最後，從道德的角度來看，我們看到將現實世界轉化為程式碼會影響我們計劃中代表的現實世界實體以及與之互動的使用者。
當我們錯誤地描繪人們的生活或特徵時，代價會很高。
最好的翻譯是對正在翻譯的原始作品的重要貢獻。最好的程式也可以作為關於現實的關鍵文字。如果是這樣，那麼程式設計師有責任幫助改善我們所代表的現實。