首先要提到我曾經在一家遊戲公司擔任遊戲腳本策劃的職位（雖然是研發崗位，但歸屬於策劃部門），當時的遊戲主程相當難以相處。
策劃部門和研發部門之間的溝通頻率相對較高，因爲策劃部門的許多想法需要研發團隊來實現。我們經常需要開會討論某個遊戲功能在底層的實現，盡管會議並不是經常召開，大約每個月一到兩次。通常只有在大版本更新時，部門之間才會召開會議。然而，研發主程經常推脫說沒有時間，或者干脆表示無法實現。是的，他們就是說實現不了。
因爲我們的遊戲採用代理制，主程表示無法實現我們的要求，與客戶交代起來也不方便。所以一般情況下，如果問題解決不了，就必須通過更高級別的部門進行溝通，這時他才會願意採取行動。
後來公司倒閉了，是的，倒閉了！之後我們從研發部門的另一位主管那裡得知，由於研發主程與我們部門的長官有矛盾，他故意不實現我們需要的底層功能！
我不能說公司倒閉與主程有多大關係，而且公司倒閉是在我離職一年後發生的，但我認爲主程難辭其咎。個人恩怨不應該升華到公司層面，我們在工作中應該做到對事不對人！
另外，我遇到的另一位程序員也非常厲害，他是研發部門的主管，但幾乎不親自編寫代碼，基本上把所有事情都交給手下的人去做。當手下的人遇到不懂的問題或需要搭建框架時，他才會出手。但他所寫的東西幾乎沒有經過測試，只有當手下的人拿著他的代碼去使用時，才發現根本無法正常運行。
雖然很多人可能不會測試代碼，但至少能讓代碼通過編譯才是基本要求！然而，他所寫的東西一眼看過去就是報錯，甚至連編譯都無法通過！
我真不知道他是如何混到現在的職位的，他所搭建的框架耦合性非常高，也就是說，項目A離開了項目B就無法正常運行，項目B離開了項目C也不行……
這其中可能存在一些産品經理在其中混水摸魚的問題。如果程序員無法解決問題，從項目的測試和部署方面更加認真一些，就不會出現漏洞。然而，項目與項目之間需要共享賬戶，但他設計的東西卻要求每個項目都單獨登錄。我曾經聽到一個有趣的客戶反餽：“要使用你們的産品，我得記住十幾個賬戶才行！”是的，這是客戶親自對他說的話。
所謂的“德不配位”意味著在自己的職位上盡責，無論技術如何，只要負責任就可以。有些人可能看似技術很高，但如果在項目槼劃能力上存在問題，也會成爲研發團隊的一大隱患。
