這又是一個說起來平平無奇的道理，但又剛剛好是很多小夥伴忘記的道理。
在工程師的日常工作當中，其實常常會有機會跟PM爭執、跟上司爭執、跟架構師爭執、跟UX爭執、跟隔壁的工程師小夥伴爭執，首先我要讓你知道的是，這些都是對的，身為工程師如果不會捍衛自己的觀點，其實你寫出來的東西也只會是行屍走肉；程式碼這東西呢，老實說還真不算是什麼藝術品(起碼除了同行之外是肯定沒有人欣賞他的)，那如果你把東西寫成了行屍走肉，沒有自己的靈魂，他後面運作起來很可能也不會照你的期望運行。
所以我會說，如果你是一個為了捍衛自己的認知跟別人爭執的工程師小夥伴，我真的要恭喜你，起碼你已經具備成為下一個階段工程師的基本特質了，但這樣子還不夠，你需要蛻變才能晉級，爭執的重點不在爭贏爭輸，而在彼此陳述自己的觀點之後，共同找到一個能解決問題的方案，菜鳥工程師只有在這個過程當中不斷蛻變學習，直到有一天你發現怎麼大部分的問題，你都能夠很快透過跟你交手的小夥伴的對談中快速抓到重點，並且很快給出解決方案，真正恭喜你，這時候你肯定是具備成為下一個階段工程師的能力了。
如果上面的描述太過形而上了，下面我們來舉例個情境：
需求：程式可不可以幫我把這篇文章編輯時候的狀態不斷存起來，以免用戶斷線的時候文章消失。
前端工程師：好，那我就寫一隻程式，每秒不斷發送ajax請後端幫我存檔。
後端工程師：nonononono，你怎麼可以這樣，你這樣我後端的程式光是處理你的需求就飽了，會造成效能問題。
前端工程師：PM，後端說做不到每秒儲存，那麼改成每分鐘存一次可以嗎？
PM：(為難)這樣用戶的資料就有可能會不見耶，沒有別的方法嗎？
後端工程師：不行，系統的穩定度是最重要的，何況用戶已經每分鐘都存一次了，最多就是掉這一分鐘的資料，問題不大，兩害相權取其輕也。
好，這個故事就先寫到這樣，首先，我用了一個非常淺顯的情境，解法之多這篇也不談論了(不是本文重點)，應該大多數有一點經驗的工程師都有好幾種解法可以解決這個問題，而這樣的溝通被簡化過，類似的討論其實是日常天天在發生的，而且還可以修改為PM比較強勢、前端工程師比較強勢甚至是UX比較強勢的版本，看起來值得稱讚的是他們沒有翻桌就找到了一個共識，但很顯然他們沒有透過適當的爭執去捍衛自己的職能，造成其實使用者的需要沒有完全被滿足，這樣的情境頂多只能算是完成工作，但還沒有到解決問題的地步。
在這個故事當中，如果所有職能在堅持自己職能的己見的同時，把使用者的需求放在心中，就必然能夠找到一條能滿足使用者需求的適當解法，撇開能力不談，文中的後端工程師是失職的，雖然受限於能力，看起來他提不出更好的解法，但是他太快放棄了，沒有站在用戶角度試著去尋求能真正解決用戶問題的可能性，同時也就錯失了一次自己成長的機會，積少成多，如果每次的問題他都是這樣去完成他而不是解決他，就算讓他做五年也不會變成資深工程師的。
但願有緣看到此文的工程師，都能記得這件事，只有不斷要求自己往前更進一步，你才有機會成長，不要成為只是把工作完成的工程師。