原文出處：https://blog.niclin.tw/2019/08/26/how-to-be-a-bad-developer/
由作者Nic Lin授權轉載
原文出處：https://blog.niclin.tw/2019/08/26/how-to-be-a-bad-developer/
由作者Nic Lin授權轉載
每個人都有自己成長的節奏，對於成功的定義也是因人而異，在我們邁向所謂「成功」之前，我們應該瞭解何謂「失敗」。
在窮查理的普通知識一書提到，查理・蒙格最喜愛的一個美國老諺語：「我只想知道我將來會死在什麼地方，這樣我就可以永遠不去那裡」，聽起來很粗淺，但其實指的是你應該殲滅那些本就不該做的事，而只做該做的事情，也就是所謂的「不用試圖成為聰明人，而是持續試圖別變成蠢貨」。
那麼身為軟體工程師，在職業生涯的發展中，怎麼樣算是失敗呢？
也許是，你以為資歷十年的工程師，其實是一年的經驗重複了十次。
所以，這篇文章會說明要如何掌握訣竅的一步一步成為「失敗」工程師。
會動就好
coding 只要有一台電腦，搭配對程式語言瞭解的判斷式就可以開始撰寫了，這就和寫文章一樣，一支筆一張紙就可以寫出能夠表達的內容，然而文章的內容有的人可以寫出優雅的句子，也有人會寫出只有自己能懂得句子，寫程式也是一樣，並不是每個人都學習過如何「表達的優雅」。
所以有一類的工程師以 Get things done 為基準，只要能完成任務、完成老闆的商業邏輯，程式碼長怎樣不是很重要，反正其他的協作者只要花時間一定能看懂我的 code，看不懂是他能力不好。
總是 Work around 的訣竅
- 不要學習任何 Best Practice
- 不要學習任何 Design Pattern
- 邏輯採瀑布式撰寫，不需要抽象
- 不遵循任何 Convention
通常養成 Work around 的習慣之後，進階發展的技能就是 Hack around，一開始可能只是把東西寫死，但後來可能用各種奇淫技巧將程式盡可能搞到沒人看的懂得 Magic
自我風格命名
Naming is hard.
我們都知道面對各種的業務需求，在程式開發中的命名總是令人難以決定。
自我風格的命名不需要在乎其他協作者的感受，以自己鍵盤少敲為主，也不在乎什麼編輯器有自動補全。
讓命名失敗的訣竅
- 使用自己發明的簡寫
- 用自己懂的搞笑梗當作命名
絕對簡寫的命名
@ano = Announcement.last
# 但願所有開發者都能一眼看懂 @ano 是什麼
wd = Withdrawl.recent
# wd 是什麼？除鏽劑？
第一眼絕對看不懂的模組命名
module Kimoji
...
end
# 嗯，你 kimoji 了我並沒有
無法瞭解的使用者權限命名
User.last.rule
# Super saiyan <== 可以解釋一下超級賽亞人是什麼權限嗎 Orz?
用力替自己造輪子
在做選用套件時，往往會有技術評估，評估這個套件我們是不是要加進來做為使用，是否有社群維護來支持日後的升級？是否符合我們商業邏輯所需？
我們應該自己寫還是用別人寫好的？
成為造輪子高手的訣竅
- 無論如何，自己寫
- 相信自己寫的東西很棒，不需要寫 Unit test
- 如果開源的專案有漏洞，我們不會被影響
這樣一來，製造了更多的工作，成為了不可取代的造輪子工程師
喜歡手動勝於自動
懶惰且有能力的工程師會將日常重複的工作嘗試往自動化或是更有效率的方向發展，而有毅力的失敗工程師更樂於將經常性的工作視為日常任務。
成為手動王的訣竅
- 能手動 key 指令就不寫 script
- 能手動翻 Log 就不用 Error Tracking Service
- 就算團隊框架已經使用 ORM，仍堅持一字一字敲出純 SQL
- 能一個字一個字打就不用自動補全
- 有十台機器要裝環境，能手動裝機，就絕不用 devops 工具
總是給意見不給建議
在討論或是 Code review 時，總是給「意見」而不是「建議」
成為意見小霸王的訣竅
- 使用主詞都是「你」怎樣怎樣，或是「我」怎樣怎樣，不許用「我建議」當作開頭
- 提供自己未經求證的幻想理由要求他人需要按照我的意思
寧願百處寫不願一處收
當我們在專案內已經四處看到重複的程式碼或邏輯，當我們要再次寫出一樣或類似的東西時，我們不需要抽象或整理。
只要繼續 Copy paste 就可以了，絕對不要 refactor，到時候有 Bug 壞了的話算在我頭上怎麼辦。
到處寫的訣竅
- 不需要遵循 Don’t repeat yourself，重複十次也很好，正所謂數大就是美。
一試成主顧 Try Error Coder
寫不出來就一個一個嘗試，反正語法兜一兜結果出來是對的就可以了。
不需要瞭解自己的 code 是怎麼寫出來的，只要知道可以動就好。
成為 Try Error Coder 的訣竅
- 不讀 API 用法
- 寫 code 前不先思考邏輯，而是直接拼湊
- 上網直接 copy 範例，改看看能不能符合需求
OK 繃萬事都 OK
當發現有 Bug 時，直接在該處掩蓋問題，像是把 OK 繃貼起來一樣。
來一個問題修一次，來十個問題修十次，不需思考原因或改善架構的問題，只要能把程式弄到能夠正常運行就可以了，有沒有 Side Effect 也不是很重要。
成為 OK 繃王的訣竅
- 不需瞭解 Bug root cause
- 使用隱諱寫法，例如直接隨便包一個 Error exception 處理掉
- 有 Bug 直接進 DB 改資料，反正 application 不會再噴錯就好
技術才是一切
在公司實現業務邏輯時在乎技術細節高過於一切的想法，從不認為使用者角度重要，而以技術實現難度取決於是否實作。
成為技術王的訣竅
- 不需瞭解使用者或產品
- 反正幹的出來或是能用很潮的技術解決就行
- 沒有業務視角，只要有技術視角就行
沒時間寫測試
時間就是金錢，反正我沒有很多金錢所以不寫測試，因為寫測試無法直接帶來好處。
如果有手動沒測到的 Bug，修就好了大驚小怪什麼，爆一個修一個這是負責任的行為。
成為炸彈魔的訣竅
- 絕對的認為測試是 QA 的責任
- Code 手動測過幾遍就可以了，不需要自動化測試
霸王硬上弓
Git 推 Code 默認加 -f，不開分支直推 Master，如果衝突了就是刪掉你的部分，或是留給你解。
任何和團隊有關的操作只要我自己知道就可以了，其他人自己看 Log 或是通靈應該會知道的。
成為小霸王的訣竅
- Commit 直推 Master 不要浪費時間去開 PR
- 調整了機器上的某個設定調完自己知道就好，絕對不可以告訴其他同事
平行時空旅人
絕不參加社群，不和社群上的人有來往，不需要和其他人討論有關開發、設計的大小事，這樣就不會遇到比自己還強的人，只要自己認為對就是對。
成為時空旅人的訣竅
- 禁止參加技術會議
- 禁止參加 Meetup
- 禁止和自己不認識的人討論程式開發相關問題
小結
不怕一時的失敗，只怕日積月累到已和失敗習慣共存，想得到失敗的訣竅就是從不檢討自己，不從自己或他人的失敗經驗中學習，經驗是寶貴的，我們都希望自己能夠持續勝利和避免惡果。
我們都想成為更好的工程師（應該吧？還是其實你覺得還好 XD？），在此之前我們也應該要懂得如何成為他人或自己眼中的失敗工程師，畢竟知己知彼百戰百勝，想知道怎麼走到成功就要先知道怎麼達到失敗。
就我認知而言，我認為 coding 是一個沒有極限的職業，本文的例子是在漫漫開發道路上聽過遇過見過甚至是回想起以前的自己所蒐集的案例，希望在未來的日子我們都能警惕自己避免掉坑，並且不斷的精進自己。
最後，如果你想補充案例，歡迎留言 XD
原文出處：https://blog.niclin.tw/2019/08/26/how-to-be-a-bad-developer/
由作者Nic Lin授權轉載
Written By Felix Hsieh
