遇到自以為是的程序員怎麼辦?
我所說的自以為是,指的是當面和你討論贊同某個最佳實踐,可過後還是按照他自己的那一套去做,一般做什麼事喜歡憑自己感覺,很少和別人討論和請教別人。有時候甚至不和你溝通,特立獨行,直接按照自己的那套去做。
這種人分兩種,一種是牛人,另外一種就是我說的這種自大,我感覺大部分屬於後者。 遇到一種情況,Java 裡面稍有經驗的都知道,組合優於繼承,Effective Java 裡面也提到過,當面辯論討論同意過,可是過後還是亂用繼承,不願意從別人認為更好的設計模式角度改進,頭疼。這樣會經常做出超出自己能力範圍的事情,比如設計,最好的辦法就是用結果說話,可是架構設計的影響不是能夠立竿見影產生的,等結果出來了,就需要付出不小的代價。有沒有更好的辦法?
「當面和你討論贊同某個最佳實踐,可過後還是按照他自己的那一套去做,一般做什麼事喜歡憑自己感覺,很少和別人討論和請教別人。有時候甚至不和你溝通,特立獨行,直接按照自己的那套去做。」
個人覺得有幾方面考慮:- 很多時候都是因為雙方的信息不對稱,所以要想辦法充分共享信息,別急著爭,把注意力暫時放到對方為什麼這麼想上;
- 你指的他沒有遵守的「那一套」,是不是團隊里成文的「那一套」,如果團隊里還沒有「這一套」,如果你是團隊管理者,就需要和大家正式討論一下,問題暴露出來也是好事,特別是技術的實踐,程序員每一個的經歷和技術知識掌握都不同,在實踐上有差異是正常的,重要的是你要及時把不好的實踐暴露給所有人,給大家傳達確定的訊息,比如代碼這樣處理在整個團隊都應該避免,為什麼是這樣這樣,說細,說清楚;我的體會是即使這樣,很多時候都達不到效果,改變程序員的習慣沒有那麼容易,改變任何人的任何習慣都沒有那麼容易,有點耐心,持之以恆;
- 他找你聊了最佳實踐但還是按照自己的「那一套」做了,這裡暴露的最大問題並不是技術上你沒說服他,他選擇自己的那一套,主要還是因為ego,而不是技術上的優劣,程序員不一定總能意識到這一點;重要的問題他還沒有信任你,還不能夠把你放在眼裡,接受這個事實,用你的行動和坦誠來贏得他的信任,比如你花上一周的時間寫出一偏小論文給他,為什麼那樣做不好,他仍然可能不同意你,但他不可能不開始尊重你。信任的問題沒有別的操作方法,這種時候是他自尊心最脆弱的時候,只能靠你自己的心,你敬他一分,他敬你一分,團隊的一些規約包括你的「最佳實踐」才能逐步推開來;
- 你指的「最佳實踐」,我自己也是技術人員,我認為可能存在,也可能不存在,或者說這些「最佳實踐」只是籠統地存在著,你也是技術人員,我相信你能理解我的意思,不是「精確的存在」。比如你說的Java裡面Composition比inheritance要好,我也同意,但是這個「好」有多少,是好很多很多,還是好那麼一丁點兒;我覺得你並不需要去說服他Composition比inheritance就是好,你需要做的是展示給他好多少,什麼情況下C不比I好,什麼情況下I反而會更好,很多技術討論假如你實現假設A比B好,只會限制了大家的視野,而不能加深他們的認識,只知道C好有什麼用呢?能把C和I平等地拉出來討論比較,才有好處,嘗試把一時的技術爭論轉化成團隊內的討論,目的不是要確定誰好誰壞,目的是讓大家體會到(realize)什麼時候誰好,什麼時候誰不好,為什麼好,為什麼不好
- 很多情況不像說的那樣容易,他做的和你說的就是不同,那就得讓時間來解決一部分問題,一個不好的技術設計終究會在某一個時候暴露出缺陷來,當這些缺陷暴露在設計者面前的時候,他才會真正地意識到你「當初的意思」,這個時候再來討論可能是更好的時機,也能增強彼此的信任,這個時候這個事才是純粹的技術問題,因為他最終可以心平氣和地來聽取別人的意見了,所以「等一等」未必不是好辦法,很多涉及個人情緒的事都不適合你死我活的爭論,放一放更好,但是別忘了;統一實踐很重要,但不應該損傷士氣,後者比前者重要;
總結一下,這裡的重點是暫時忽略他的技術處理上的所謂「錯誤」,而把這當成一種管理場景來對待,技術問題現在沒那麼重要,想辦法獲得他的尊重,建立信任,讓他最終去決定用什麼,用什麼都不是那麼重要,以後可以改進。
竊以為不自以為是的程序員不是好程序員;作為程序員如果唯資深者是從才是真有問題;程序員在沒有完全理解只是被要求的情況下做出來的實現往往會有問題。
如果架構師關注某個功能的實現方式,最好是不要空談,直接的就事論事的討論或者挑戰實現者,把成本、效率、維護性等所有因素拿出來。這樣戰一場,無論勝敗,雙方達成一個共識,再下手去做。
作為有經驗有追求的程序員其實往往喜歡自己的代碼被挑戰;作為架構師,被挑戰既能提高團隊的技術水平也能驗證/改進/改正自己的技術設計;同時也在雙方之間建立信任。"指的是當面和你討論贊同某個最佳實踐",討論的氛圍如何?他是不是無可奈何才」贊同「的?
程序員做事有自己的偏好,這太正常了,比如在C/C++/Java中,開始的大括弧是和if/while語句在一行,還是換行和下面的結束的大括弧對齊,這個不同的人有不同的偏好。
你舉的例子里的組合和繼承的關係,討論時的結論是什麼?具體實踐中」亂「用繼承又是怎樣的,有沒有就這個問題繼續溝通?具體的問題有時候和一般性的結論還是不一樣。
作為管理人員要求執行公司的編程設計規範這沒有錯,但是在不影響大面的情況下,給程序員一點空間使用自己的偏好。還有一種可能..他很自卑,他想證明自己....我碰到過..
我的客戶找了一個和他們合作了10幾年的老程序員,專門來給我找來各種難題。
我現在還在頭疼中,所以這個問題,只能觀望了。不過我的基本觀點是:請convince我,否則,我可能最多只會「屈從」結果:我要不就需要足夠能夠convince你,要不我需要思考是不是我的解決方案真的存在問題,如果雙方都無法convince對方,我大概會是「屈從」的一方。:P另外,不要有ego,如果對方是出於ego的挑戰,那麼我一笑置之。曾經遇到過,完全無法和團隊融合,特立獨行,頭疼的要死。。
有本事你就把核心框架做好,讓他只能實現你的介面,剝奪他設計的空間。
Push他,讓他解釋每一個決定背後的原因。
如果能夠完整的解釋,那說明他確實是有道理的。如果push到某一步解釋不下去了,他就會知道自己的想法存在問題。
不過設計上的一些選擇,往往並不存在絕對的壓倒性的好與不好。一個更加靈活的設計,有時會意味著更多的工作量。看起來垃圾的實現方式,也許已經完全夠用。
最後做出什麼樣的決定,需要根據項目的具體情況來tradeoff。也許之所以做出不同的決定,分歧並不在於應該如何做這個決定,而是在於出發點和目標的不同。實打實的PK下,讓他認識到怎麼做才是最好的,
我理解中,程序員如果採用了其他方法,是他遇到的技術障礙。一般情況下程序員都是愛惜羽毛的人,他們不是那種,喜歡會上說一套,背地裡做另一套的人。和他一起研究具體的技術問題或者是解決之道。程序員的自尊心有的時候也是他們主動溝通的障礙。
我覺得這件事情跟是牛人還是自以為是沒有什麼關係. 這是職業素養和團隊精神. 已經討論定下來的事情, 那是這個團隊的決定, 不是某個人爽或者不爽能夠更改, 更改只有一個途徑, 把不爽提出來, 再討論更改. 這是對團隊的尊重, 是對別人的工作的尊重.
進實驗室,用測試結果說話!話說有太多喜歡自己造輪子的人。。。
一般來說,很多小孩只看書本,而沒有嘗試過,就憑自己的想像做出一些看起來很厲害的設計,等他們碰壁了就知道了。只是現實是,我們也沒有太多時間給他們犯錯的機會,所以,通常只需要強制執行就行,以後他會明白的,無需討論。
如果已經是多個跟頭摔過來的,應該比較牛了,否則就是沒摔過跟頭的,合作久點,多溝通就好了
以技術手段解決說明還不是一個架構師。
我會先檢討,自己是否自以為是,正如上面說的,可能沒有精確的最佳實踐。當然一個團隊大家都堅持自己的最佳實踐,那就是個災難,不記得是誰說過,如果大家都往一個地方錯,結果也可能不錯。
這邊也有個類似的,處理方法很簡單。
每次群體討論完成之後都會出一個文檔,等代碼寫完了之後如果發現他亂來直接把文檔甩給他,重寫! 還得必須在時間限制之內,要不然自己看著辦吧。當然通常定製這個文檔的時候盡量不會定製的太死,一般都會給每個人留下點空間,畢竟也會有討論的不夠細緻的時候,而且通常這種程序員都會有挺好的創新能力,盡量給他保留點空間搞不好還能出現些很意外的好效果。
"做什麼事喜歡憑自己感覺,很少和別人討論和請教別人","當面辯論討論同意過,可是過後還是亂用"
組織不同對同樣一個問題的解決辦法也會不同。一種辦法就是充分交流。譬如在私下的場合,把這些意見和他進行單獨溝通,同時也聽取他的想法,爭取達到互相的諒解。需要注意的是溝通的氣氛,就事論事…充分交流無疑是解決問題的有效途徑之一,但是也會存在難於溝通的場合,譬如在一個上千人的項目里。那麼就必須把這種"不這麼做就不行"的事情寫到開發方針中,反而,如果沒有寫到開發方針中的事情就可以做的。對於 "架構設計的影響不是能夠立竿見影產生的,等結果出來了,就需要付出不小的代價" 這種無法馬上判斷優劣,而又必須記入開發方針的問題,一般有三種辦法:1. 通過製作模擬程序等方法進行調查分析,得出一份比較調查報告,評估兩種方法的優劣以及給項目帶來的風險;2. 組織會議進行討論,在會上通過投票等方式得出結論;3. 聘請第三方專家(擁有公信力的),給出意見作為結論。總之,可以先評估一下這個問題給項目帶來的風險,然後再決定採取什麼方式處理。程序員都是知行合一的人。你遇到的不是
請細心問他每一個決策後的道理。牛人會告訴你為什麼,還有所有他的關注點,相信從他的關注中,你也能學到很多。自大狂么。。應該不會有什麼建樹。如果你覺得他自大,但是又揪不出他的毛病,那就是嫉妒咯。
推薦閱讀:
※在公司學習知識被領導看見不好?
※領導讓保密的事情該不該告訴同事?
※在這個社會,是選擇做一個實幹者,還是出於某些原因做一個在別人看來整天拍馬屁的人?
※職場新人如何做一份高大上的ppt?
※新人入職,同事總是提起這個職位前人做得如何如何出色,應該怎樣不留痕迹的噎回去?