Top 7 programmers bad habits

程式員的七個壞習慣

1.- The all code is crap, except mine,

1 所有的代碼都很爛,除了我自己的.

I have bad news for you buddy, all code is crap. No matter how much effort you put on it, there is always a majority of programmers who are going to think that your code sucks and that they could have done it 10 times better. I have already covered this topic in previous posts, you can find more information of what exactly I mean when I say that all the code is crap here and here.

朋友,我有一個壞消息要告訴你,所有的代碼都很糟糕.無論你多麼努力,仍然有大多數程式員認為你的代碼很糟糕,并且他們可以做的比你好10倍.在以前的文章裡,我就已經讨論過這個問題了,在那些文章裡你就能知道為什麼我現在說所有的代碼都很爛.

How to fix it: Don’t criticise others people code, it could be yours the one in the spotlight, try to make objective and professional observations instead, but don’t judge. Be humble and try to learn from everyone around you, hopefully then your code won’t be so bad.

如何改正:不要批評别人的代碼,因為有一天你的代碼也會暴露在聚光燈下(讓别人評價),最好就是做一個客觀而專業的觀察者,同時不要做評論.謙虛地像你周圍的所有人學習,并且期待一會你自己的代碼不會那麼糟糕.

2.- The “I fix that in a second” catastrophe.

2.-"我能很快地修複它"  這是一個大災難

Taking shortcuts is very tempting, everyone has done it. There are actually situations where they are necessary, but in overall, they are dangerous, very dangerous and should be avoided. A shortcut which goes wrong may save you a few hours, but may cause months of pain.

走捷徑是個很誘人的東西并且我們每個人都用過.确實,也有很必要

使用快捷鍵的情況,不過總的來說,快捷鍵很危險應該避免使用.一個快捷鍵的使用錯誤有可能給你節省了幾個小時,但是後果是在以後幾個月的時間裡你都得為它頭疼.

How to fix it: Don’t trust yourself when carrying delicate activities. Ask someone else to review what you are doing. Make sure that if you are about to take a shortcut, you make very clear to the stakeholders what the reasons and the risks are. Try to get a manager to sign off every time you are about to take a shortcut, aka “cover your ass”.

如何改正它:當你在完成精細的子產品時不要相信自己.請别人來審查一下你自己的代碼.如果你自己計劃要走捷徑,最好讓你的負責人知道這樣做的原因和風險.在每次你決定做捷徑的時候,盡量讓你的經理簽字,也就是讓他給你擦屁股(aka “cover your ass”).

3.- The “That will only take a second” misconception.

3.-這隻需要幾秒鐘. 絕對的錯誤觀念

Being Barcelona my hometown, I am very proud of the Sagrada Familia Cathedral, which is very well know for its beautiness, and also for the time is estimated it will take to complete, (in construction since 1882), but that’s probably because they didn’t ask a programmer to estimate, otherwise the estimate would probably have been somewhere around 2 weeks.

在我的家鄉Barcelona,我為神聖家族教堂而驕傲,因為美麗她聞名于世.同時還有她的工程預估期(始于1882年,到現在還沒有完工)但是這也有可能是因為沒有讓一個程式員的估計,否則,程式員給出的建構時間有可能就是兩周左右.

How to fix it: For starters, is important to understand that accurate estimations in software development for non trivial solutions are impossible, we can only guess. Also remember that is very likely that you will find so many things which you didn’t foresee when you start developing that is worth multiplying the estimate to cover for those, I usually go with 1.5 or 2.

如何改正它:首先,要明确一點,那就是要精确地估計那種大型的軟體開發項目的時間是不太可能的,我們隻能猜測.同時也得記住,在項目中你會遇到很多前期沒有預見到問題,而就是這些問題,會讓你的預期日程加倍,我認為通常是1.5倍到2倍.

4.- The ego spiral.

4.-以自我為中心

Many programmers discussions look more like rooster fights than human discussions. This usually happens in design and architectural meetings. It is actually quite easy to detect this ego spirals, you just have to substitute most of what the contenders are saying with COC! COC! COCOCOOCCC! COOC!

許多程式員在讨論問題的時候就想一隻鬥雞而不是一個正常的人類.這通常發生在對設計和架構的讨論會議上.你很容易就能看到他們自負,你也可以把競争者的話直接換成"咕咕咕 咕咕咕 咕咕 咕咕"

How to fix it: Leave your ego at home. Big egos are one of the biggest non technical issues for any programmer. Keep in mind some basic considerations when making decisions.

如何改正:把你的自負放在心底.對于任何一個程式員來說,自負是最大的非技術問題.在做任何決定之前,都要確定心裡有個基本的構想.

5.- “It wasn’t me!”

5.- "這不是我的錯"

In my opinion, other bad habit from most programmers is the lack of accountability. We always have an excuse… It’s like if we were saying that under normal conditions we would never make a mistake, which honestly is quite hard to believe.

在我看來,大多數别的程式員的壞習慣都是确實責任感.我們總是有理由...就想總有人說,在正常情況下, 這是不會錯的,但實際情況下,這很難讓别人相信.

How to fix it: No need to cry, or to perform seppuku, (aka harakiri), when we make a mistake. Having a healthy attitude where we can you just say something like: “yeah, sorry, now we need to do this to fix this issue, my fault” is a very professional attitude, and it will help you to build a reputation and to be better considered by your colleagues.

如何改正:其實在出了問題的時候,我們不需捶胸頓足,也沒有必要切腹自殺以謝天下.其實,隻要一個健康的心态說一句"哦,對不起呀,我們得修複這個問題,這是我的錯誤"這才是專業的态度,同時這也會幫你建立名譽也讓你的同僚更加地尊重你.

6.- The demotivated genius.

6.-消極的精神狀态

Repetitive and simple tasks are not the best motivators, but they need to be done, programmers tend to get demotivated and very unproductive when they need to complete them.

簡單重複的認為不是最好的激勵方式,但是這些事還都得做,當程式員要完成這些任務的時候,就會變得很消極,效率也會很低.

How to fix it: Discipline. Unfortunately, there isn’t any other remedy I can think of.

如何改正:紀律.很遺憾,我也想不出其他的什麼補救方式.

7.- The premature programmer.

7.-不成熟的程式員.

 If programming was sex, there would be a lot of unsatisfied computers. You can just not go in, do things halfway through and then fall sleep.One of the concepts that I find most programmers struggling with is the concept of “Done”. Remember that done means: tested (and not only unit tested), documented, committed, merged…

如果把程式設計看做是做愛的話,肯定有很多欲求不滿的電腦(汗 大汗 瀑布汗).你還沒有進去,隻幹了一半就呼呼大睡了.(你可以看看上面的英文......)我發現有一種理念是大多數程式員都認同的是"完成".記住,完成意味着:測試(不隻是單元測試)還有文檔解釋,注釋,系統內建.

How to fix it: This one is tricky, the complexity of non apparent necessary tasks to fully complete some functionality is quite high and usually requires discipline and training. Probably the two easiest ways to help a programmer understand if some code is done are peer reviews and demos.

如何改正:這是一個很麻煩的問題，相對于完全的完成某些功能性問題而言，這些并不是顯得很有必要的任務會很龐雜和難處理，通常需要你有紀律性和受過教育訓練。也許有兩個更簡單的方法能幫助程式員判定他們的代碼是否已經寫好那就是互相複查和示範.

原文位址

www.makinggoodsoftware.com/2011/05/23/top-7-programmers-bad-habits/

參考翻譯

http://user.qzone.qq.com/289065406?ptlang=2052&ADUIN=460795365&ADSESSION=1370779283&ADTAG=CLIENT.QQ.4375_FriendTip_QzoneFolder.0#!app=2&via=QZ.HashRefresh&pos=1358335322