我花了好幾天，就為了把幾個 API 設計好。是有關模組的新 API，還有一種新的 Redis 資料型別。當我說*好幾天*時，我是認真的，光是為了 API 就花了這麼久。寫草稿、開始實作、形塑資料結構與呼叫方式，然後又全部打掉重來，用更好的方式再迭代一次，只為了改進設計與面向使用者的部分。

我為什麼要這麼做，甚至為此把功能延後好幾個星期？這真的有那麼重要嗎？程式設計師都是工程師，或許他們本來就應該去適應系統最方便提供的那種 API 就好。

我真的需要回答這些自問自答的問題嗎？不需要，在今天已經沒這個必要了，而這本身就是一大進展。

我想在這裡理所當然地假定，大家都已經默認了一件事：程式設計師同樣面對使用者介面，而且這樣的介面至關重要，甚至足以徹底改變人們對一個系統的觀感。資料庫查詢語言、函式庫呼叫、程式語言、Unix 命令列工具，它們全都有使用者介面的成分。如果你每天都在使用它們，對你而言，它們與其說是別的什麼，不如說就是 UI。

既然這些都是眾所皆知的事，我為什麼還要寫這篇部落格文章？因為我想強調「簡單」這個概念有多重要，不只是對圖形化 UI 而言，對設計給程式設計師使用的 UI 來說更是如此。反覆迭代以找到簡單的 UI 解法，這並不是一種完美主義，也不是徒勞的自戀。它更像是在設計*空間*中的探索，有時候這個空間非常巨大，由帶來巨大差異的細微變化所構成，也由能徹底改變觀點的巨大變化所構成。這裡沒有什麼規則可以遵循，能依靠的只有你的敏銳度。誠然，有所謂的良好實踐，但當你航行的那片海是設計的*空間*時，它們並不是什麼可靠的羅盤。

那麼，為什麼程式設計師應該享有擁有好的、簡潔的 UI 這種特權？當然，使用一件做工精良、順手好用、感覺*就是對的*東西，本身就是一種樂趣。但還有一個更核心的問題。透過 M4 巨集來學會設定 Sendmail，或是為了設定 Apache 虛擬主機而苦戰，這些都算不上是真正的知識。如果有一天這樣的系統不再被使用，你手上還剩下什麼，或者更準確地說，你的神經元裡還剩下什麼？什麼也沒有。這就是特定性的知識。它就像垃圾食物：只有空熱量，沒有微量營養素。

對程式設計師而言，微量營養素是那些能持續數十年的觀念，而不是這種一次性的垃圾。我不想交付垃圾，所以我會在發布前繼續打磨我的設計。你也不該接受垃圾，你的神經元更值得用來學習通用的觀念。不過，在某種程度上這是無可避免的：每個系統總會有一些非通用的、為了使用它而必須學習的東西。既然如此，至少讓我們把這種特定性的部分做得簡單一點，如果可以的話，甚至讓它用起來是有趣的。