What are the characteristics of a bad software engineer? / 邁向頂尖開發者的道路上，你該避免成為下列十種討厭鬼

Reference:

https://www.quora.com/What-are-the-characteristics-of-a-bad-software-engineer/answer/Nachiket-Naik
http://www.inside.com.tw/2015/07/06/10-characteristics-of-a-bad-software-engineer


Nachiket Naik:
1) The Stack Overflow bot: This person ran into an error, did a quick Google search and applied the first solution they found. The problem here is not that of copying from Stack Overflow. I think there are more solutions on Stack Overflow than any reference guide or manual. Don't get me wrong, it's a wonderful resource, if not the best. The problem is the robotic application of it without understanding the consequences. The problem is the application of it without fully understanding the context of it and whether it really applies to the current problem at hand. More often than not, I have seen people believe more of what they see on online forums than the code/system in front of them.

2) The I-am-not-a-tester: I don't need to test the code; that is the job of the testers. I don't think that even in this age of mature Agile methodologies, this attitude has waned. There is still an inertia against testing their code. Part of it comes from lacking the interest to set up a testing environment and partly from lack of coherent knowledge of testing. (Is it also partly due to an unspoken stigma against testers in the developer community.)

3) The I-hate-documentation: Some people believe that code documentation must be poetic and hence they lack the skill to do it, ergo not their job. In my opinion, these are the #1 foes of sustainable software. Good software is not software that provides a million cool features. Good software is one that has a few good features that are used consistently by many people and read/updated/modified by a thousand. This brand of developers who believes less in technical communication and precise and detailed documentation is the greatest weed to a company's success.

4) The ugly: My code works, but:

• I have variables named x, flag, str, arr, etc.
• Most of what I write is in one giant method.
• There is no indentation.
• No consistent coding convention or style.
• Global variables spewed all over the place, etc.

This is the most annoying thing for me personally. It's not the issue that the code is bad. It could potentially be the greatest piece of code written. But if a diamond necklace is buried in the debris of the Titanic, nobody will find it, and nobody will want to clean it, wear it, use it.

5) The short-term investor: He codes. He deploys. He moves on. No attempt to learn the problem. No interest in the domain. Just give this guy a piece of code, he will slog on it overnight and hand it over. You got a fix/working software. Nothing more achieved from it. Sometimes, it's important that you have certain selfishness in the developer, one who not only cares about the deadline, but also cares about what he/she got to learn from it.

6) The protester: "I didn't do this". "This looks bad". "Not my problem". "This isn't related really to my fix, but someone way over there made a mistake". "I hate this (loop this sentence 10 times a day)", "I can't fix this, get the person who made this code to fix it".
The person who coded that mistake has moved on, when will you?

7) The dictator: My way or the highway is their motto. It's their "ideas" vs "your ideas", not "project ideas". It's their solution vs your solution. I bet there will be an argument for sure. Somehow they will keep coming back to a part of code that you implemented. It somehow discomforts them even if it works, tests, and looks perfectly fine. This person is a big bottleneck to productivity and will be the first person to crumble under pressure and start pointing fingers. This person is not good for the team, however experienced/good a developer he may be.

8) The overcautious: The Java developer who just froze when he learned that he would have to write a Python script. The developer who panicked on learning that something in the registry needs changing. The developer who cringes at having to input things in the database. These people will do anything to avoid getting out of their comfort zone. They have weird superstitions related to having to touch certain parts of the system. I have learned, from personal experience, that this phenomenon is common with new developers. Good developers show a tendency to slowly/swiftly move out of their comfort zone in exploration.

9) The careless: Forgets to take a backup, snapshots, has multiple working directories of code, leaves system out, prints in production code, etc. Again, this is a newbie tendency and gets better with more professional exposure.

10) The lazy pseudo-hacker: They pride themselves at being able to trick the system into working. They find magical solutions to seemingly complex problems. My experience says that 9 out of 10 times, it's just a facade. The hack is bad and will crash sooner or later and will cost much more than having to deal with it, with extra time right now.

EDIT: Please drop in comments. Maybe we could start a new follow-up question as to how a managers/peers/colleagues could handle these cases because almost all of them can be helped to become better. A design pattern of sorts for fixing programmer smells. :-)

---

軟體吞噬世界，開發者這個職業炙手可熱的程度前所未有，而且只會愈來愈熱門。許多人意識到這股潮流，加入寫程式的行列。不過別看矽谷工程師坐擁高 薪，這可是個強者如雲、充滿挑戰的環境。也因如此，開發者品質的優劣判斷總是在網路上引發熱烈討論。Quora 上就有這麼一道長壽的問題「糟糕的軟體工程師有什麼特徵」，亞馬遜軟體開發工程師 Nachiket Naik 的回答頗為中肯，獲得幾千名網友贊同。邁向頂尖開發者的道路上，你該避免成為下列十種討厭鬼。

1. 只會複製貼上的機器人

程式設計問答網站 Stack Overflow 擁有非常豐碩的資源，很多人寫程式碰壁了就會上去找解答，Stack Overflow 本身並沒有錯，它是工程師的得力助手。但是如果只是複製貼上，改個參數，不去了解前因後果，不去弄懂為何這樣的解法到底是不是真的適用於現在面臨的問題， 那當然很難進步。有不少工程師寧可相信他們在網路論壇看到的說法，而不願意費心思考眼前的程式碼或系統。

2. 懶得測試

「我不幹測試這種事，那是測試工程師的責任。」即使在敏捷開發方法如此盛行的時代，這種態度依舊層出不窮。工程師不願測試的惰性還是很普遍。有可能是他們討厭設定測試環境，也有可能是缺乏測試的連貫性知識。當然，也或許是，測試工程師在開發者社群中總存在著不能說的污名。

3. 不寫文件

有些人覺得程式文件（code documentation）應該如詩一般簡潔美麗，他們沒能力做到這樣，就乾脆不做了。可我認為這樣的心態是軟體開發的頭號公敵。傑出的軟體，不需要有 幾百萬個酷炫的功能，傑出的軟體，應該是要提供幾個讓人「離不開」不斷使用的功能，而且這幾個功能背後有幾千個人閱讀、更新、修正。輕視技術溝通、文件精 確度、忽略細節的開發者，肯定是公司獲得成功最大的絆腳石。

4. 程式寫得很醜

我的程式能跑，但⋯⋯

• 有些變數被命名為 x、flag、str、arr⋯⋯
• Most of what I write is in one giant method.
• 忘了縮排
• 缺乏連貫的程式慣例或風格
• 把全域變數噴灑得到處都是

對作者來說，這簡直是最惱人的事。雖然某段程式碼不見得差，甚至有可能是寫得最好的部分。只是，如果出現上述情況，就像一條鑽石項鍊被埋葬在鐵達尼號的殘骸中，沒人找得到它，也沒人想清理它、佩戴它、使用它。

5. 只能衝刺而無法跑千里

他寫程式、他部署、他繼續前進，絲毫沒有想要學著解決問題的意願，只要給這傢伙一段程式碼，他就會沒日沒夜奮戰，隔天就交出成果，你會得到一個修復 好、能執行的軟體，除此之外別無所有。有時候，選擇開發者的時候你得有些私心，找個不但會在大限之前完成任務，而且也有旺盛的求知慾的人。

6. 一天到晚怨天尤人

「這不是我幹的」、「這不是我的錯」、「這跟我修復的部分無關，一定是有其他人搞砸了」、「這東西真的很煩！（無限迴圈）」、「我不知道怎麼修復這邊，找個會的人來啦」⋯⋯
那個犯錯的人可能早就修正向前走了，你還在大肆抱怨什麼勁呢？

7. 這個世界唯我獨尊

「不照我的方法做就拉倒」，是這群人的座右銘。在他們心中，這是一場他的「點子」與你的「點子」之間、他的解決方案與你的解決方案之間的競爭，不為 整個專案著想。他們會來來回回仔細你植入的程式碼，即使他們運作正常、經過測試、看來完美無缺，仍讓他們覺得芒刺在背。這類傢伙是阻礙生產力的大麻煩，在 壓力來襲時，他們也會是最先落荒而逃的人，就算經驗再怎麼豐富、技術再怎麼厲害，也別輕易嘗試找這些人加入團隊。

8. 不願踏出舒適圈

寫 Java 的 A 開發者一聽到他得寫一段 Python script 就愣住了。B 開發者一聽到設定檔裡某個部分必須改正就慌了。C 開發者一聽到他得在資料庫裡輸入東西就畏縮了。這些人傾向趨吉避凶，不願離開舒適圈。他們有很奇異的迷信，不想接觸系統的某些地方。這個現象尤其容易出現 在菜鳥開發者身上，出色的開發者或快或慢，都會渴望跳出舒適圈，探索陌生的事物。

9. 粗枝大葉

忘掉留存備份、快照存檔、一堆未歸檔的程式目錄⋯⋯這些都是菜鳥容易出的狀況，隨著你愈來愈朝專業者邁進，這些漫不經心的狀況都應該避免。

10. 偽裝成駭客的麻煩精

這些人能夠耍些小技倆，「騙過」系統使之運作，沾沾自喜。面對複雜的問題，他們彷彿變個魔術就能解決，但就作者的經驗，10 次有 9 次都只是表面功夫，實則漏洞百出，而且遲早都會當掉，導致後來還要花更多成本處理。