※ 引述《dreams (Dreams)》之銘言：
其實我也有疑問
為什麼IT要跑去學非自己領域的Domain knowledge
不會覺得很事倍功半嗎?
如果說這是IT爬到高位的必經之路，那不是根本就繞遠路嗎
我自己先在科技業待了三年才因為興趣轉IT
現在寫程式也兩年了
真心覺得IT碰到user端的Domain knowledge真的很淺
淺到我覺得待兩年學到的還比不上工廠的半年
像IT不會知道某個常數是為什麼要從0.2改成0.3
頂多知道是因為某次客戶要求變更的
但是背後的定理、推導根本不懂
要比Domain knowledge怎麼可能比得過user
因為寫程式的經驗不久
不知道為什麼板上說IT的Domain knowledge不是往架個乾淨好維護的系統走
或是寫出漂亮的套件
反而是越俎代庖跑去學別人的皮毛
這樣不是很沒效率嗎

技術力是IT的基本, 沒有就無法生存, 所以不會強調domain是IT能否更上一層的關鍵, 就像搞會計沒人在比記帳審計更上一層就會強調對稅熟之類的IT搞懂產業知識不是要取代掉user, 而是未來決定系統架構能思考的更全面

呃, 其實沒人硬把你擋在皮毛這一層啊...

在企業內部流程電子化這一塊, 有很多經驗法則存在, 不是說你coding天下無敵就想的到該避開什麼地雷否則只會設計出IT覺得乾淨/易讀/鬆耦合/擴充性無限大,但user最後不用

你一定沒遇過user跟你說:其實我也不知道這規格怎麼訂。然後自己要去幫user研究出來

做客戶的開發案不去了解那table怎麼開，都做維護那沒差

你是設計Android的或者是在Android上寫code的，差別在這裡這個地方有趣的點在於, 在Android上寫code的一直跟設計Android的說:你這個不重要..xd

user雖然懂 可能表達力不夠好 懂得問細節也很重要

IT的架構師，PM, SA, SD, PG這些都了解一下

user端經辦也會換,換一個不懂的,長官又押時程domain knowledge就重要了,至少自己懂就不用問人如果乙方驗收有時程的,delay要被甲方罰錢

有時候user不見得真的懂自己要什麼 你如果是老司機可能就會在製作之前發現未來可能的問題進一步討論改善問題

很多User真的不知道自己要的是什麼

哪有什麼knowledge 學學老賈 使用者根本什麼都不懂 只會放狗屁 抱怨東抱怨西 所以不用理會 我們出什麼他們就吃什麼

PM PG SA/SD要的domain knowledge深度不一樣啊，PG不懂know how程式還是能寫，PM不了解產業是要怎麼跟user吵架（x)

其實老賈是sales 只要出張嘴就好了

出什麼吃什麼也要你公司夠屌= =

domain knowhow 不重要 但implementation 重要舉例 寫遊戲遇到機率設計 寫醫療遇到真值表有些東西就是要 singleton 實現 有些要用 observer幾年後 內容是啥早就忘光 但方法經驗會長留在心如果有換工作的話 ==

推atpx所說的 IT只是基本 其他人認為你本來就該懂的 domain know是IT更往上層 不管是未來往SA或SD走