最近一直在閱讀，吸收來不及吸收的各種知識，重新審視過去我視為理所當然的觀念，哪裏需要修正，哪裏需要以不同的角度重新解釋一番，其中之一，是 animatin studios 裏頭 RD/TD，或再泛稱一點，所謂的技術人員，他們應該怎麼自處，應該在工作心理與技術能力上學習些什麼。

Coding for love 這個 blog 的主人翁，是一位在動畫產業工作的工程師，裏頭的 Stupid Things That Should Be Fixed 很好笑，雖然只有短短的三篇：

拿 Securing Failure in Tools Development 這一篇來說：

如果，你是一位在動畫公司工作，有負責（間接或直接）開發一些工具的 TD/RD 的話，你常常會遇到你的使用者，也就是非程式設計師們，對你說：「怎麼這個程式這麼難用呀；他好像一下子就當了也；可以幫我看一下，你的程式好像不聽話唷；能不能加個什麼功能呢…」相信我，這些話你應該常常聽到的。

程式設計師的最終目標之一，是寫出一種非常酷的程式，可以把一些工作，幾乎全部給自動化，不需要任何人的界介入，就是「自動化的極致」。打開我們寫過的清單：preview render, final render, attach prman shader, create spot light through camera, auto rigging setup, auto convert textures between low res & high res, auto fix texture uv seamness, auto make animation curve’s end infinity, … what else? you name it.

然後呢，我們也常常失敗在這個「自動」上頭。使用者假設你的程式真的很「自動化，百無一失」，你也慢慢被要求成要寫出這樣的程式，但時間的壓力，加上不完善的程式開發環境，導致你永遠寫不出這樣的程式來；另一方面，比女人還要善變數百倍的動畫製作流程朝令夕改（這是種非常誇大，但很容易貼切人心的說法），讓你的程式永遠趕不上變化萬千的流程。於是呢，使用者繼續遇上問題，繼續質問你的工具的可信度，然後你繼續覺得很悶，覺得有修不完的程式，不健全的程式…

原作者舉個有趣的例子：

如果你在非常好的動畫公司，那動畫人員會坐下來，認真地看待開發工具這件事，並且有打算長時間和你一路一起研究，找出一種在各方條件下，最折衷的工具樣貌出來，並且與你做某種程度上，盡量完整的測試與試驗，然後再把它的限制與優點記下來，最後教給他的其它組員們。如果你在一家非常爛的公司，那動畫人員不覺得開發工具與他們有啥關係，所以工程師你自行開發，最後再自行推銷。如果你在一般的公司，那可能動畫人員會幫你做點測試，然後偶爾和你聊一聊，接下來還都是你的工作。

最遭的情況，應該是「一般的公司」，因為前兩者很乾脆，工具開發起來反而單純。很棒的公司下，會慢慢磨出很棒的工具來；而很爛的工作環境，那就是程式寫出來，美術人員只有聽話使用的份，也沒什麼好挑三撿四的。最有趣的是第三種情況，不上不下，於是雙方有不一致的預期，然後災難就來了。

我看到這，忍不住想到處找人聊聊這件事，實在太有趣，也太貼切了。

回過頭來，我可能無法一直持續擔任只鑽研技術的技術人了，只好把這份榮耀與成就感委託其它更優秀的技術人員，然後呢，我要去好好想想怎麼做好「技術的形而上」的問題去了~