大多數程序員，據我所知，越是優秀，越是討厭沒有價值的任務。

尋找其工作的價值

這些年來，我看到很多頗有成績的軟件開發人員轉行去了管理崗位，或者其他完全不同的職業。有的時候原因很簡單，只是想拿更高的薪水。不過也有因為是 厭倦了總是需要不斷學習以跟上軟件開發步伐這樣一種疲于奔命的狀態。當然最常見的原因是感到無聊了，或者是對工作本身失去了興趣。這些人通常是因為工作對 于他們而言已經沒有了足夠的挑戰，認為他們是在將自己的時間和精力投入到幾乎沒有價值的工作中。

[[138292]]

我的軟件開發職業生涯也有低谷的時候：我花費了大量時間、精力和創造力的一個項目或者任務由于某些原因被終止或者被大大削減了其功能范圍。雖然我拿 到的貨幣報酬相同，但是我工作之前的期望是交付一個成功的產品，于是，我的感受不是滿意而是非常沮喪。這讓我感覺我付出的時間和精力沒有了價值。

取消任務并非幻滅工作價值的唯一原因。一些沒有必要的任務或其他繁重的工作也會加劇軟件開發的難度。這些事情總是看上去好像很有用或者對任務很有幫助的樣子，卻幾乎沒有價值。

進程

從眾多軟件開發人員的角度看的話，軟件開發生產力最大的敵人就是冗余的進程。在《Process Kills Developer Passion》一書中，James Turner這樣寫道，“對整個開發進程最佳實踐的盲目應用讓我們從一種創造性的流程變成了一種禁錮。”Turner表示所有的開發人員能力并不相同，所 以對待他們的方式也不能完全相同。“企業需要明白一點，開發人員之間有著本質的區別，所以你得確保設置給每個人的權重，至少不能有損整體的士氣和團隊的效 率。”

我想大多數淫浸這行多年的人都明白，一定程度的進程才是合理的，甚至是有益的。但是這個“程度”取決于項目、開發人員的經驗以及團隊的大小。標準化 和代碼約定是有很多優點的。單元測試和其他質量進程的益處更是眾所周知了。可以這么說，最好的開發人員能夠確定什么樣的進程適合怎么樣的情況，以及怎么樣 的情況是不適合的。

開會

只有那些時間短、運行良好的會議才能為我們提供巨大的收益，大多數的會議都只是在浪費時間，特別是如果會議還要晚點和加時的話。好的會議，應該準時 開始，只需要解決那些必須解決的問題即可。例如有的團隊成員不習慣于發表自己的意見，那么一些用于交流工作的簡短、非正式的會議就很有必要。而一些難度很 高的設計決策和架構權衡也可以放在會議上討論。可以這么說，運行良好的會議，產生的是積極的效果：能幫助開發人員確立更加明確的方向，提高團隊的整體效 率。

我以前也發過一個關于如何有效開會的帖子。要點是應該學會記筆記，記下什么時間有哪些人的參與，記錄下重大的決策以供將來參考，也可以作為材料借閱給那些沒有到會的人看。

不是每一個想法都應該實施

不是每一個想法都有價值。開發人員在被迫去實施一些糟糕或者沒用的點子時，往往會產生不耐煩的情緒。話說，我們很難讓自己心甘情愿地去制作一些可能永遠不會被使用的東西，或者更糟糕的是，直接影響用戶體驗。

繁瑣的腳本編寫任務

很多開發人員往往會另尋方法去解決特別繁瑣的腳本編寫任務，而不是手動執行，即使用于手動執行的時間和編寫的時間相差無幾。這也是可以證明大多數開 發人員討厭繁瑣任務的最好例子之一。對于開發人員的這種典型做法其實是有積極面的。首先，可能這個我們以為是一次性的任務又有了需要再次實施的情形。其 次，編寫腳本的行為比僅僅只是完成一個任務所產生的價值要高得多：既可以提高腳本語言的熟悉度，又能為以后解決相關問題提供很好的思路或案例。

使用常規配置

只有當配置信息和常規配置不同時，開發者才需要提供詳細地配置信息，否則只需要使用常規配置即可。這樣可以節省開發者的時間，減少許多枯燥的配置工作。

開始看上去沒價值其實不然

大多數的情況下，我們對于任務有無價值的判斷一般是正確的。但也有的任務，一開始看上去是無用的，但是后來則發現它確實能提供實實在在的利益，的確 是有價值的。這種情況也提醒我們需要對新點子的價值保持開放的心態，不要一棍子打死，應該仔細分析它的影響。所以軟件開發經理要做的就是將有價值的任務分 配給開發人員并確保他們能理解這些任務的價值。

執行力

即便是一種非常有潛在價值的想法如果沒有正確的實施，也會大大減少它的價值。同樣的，如果能正確使用代碼審查和代碼質量工具則能創造巨大的價值，反之就是負面的影響。

結論

當我們喜歡我們所做的工作的時候，當我們認為我們所做的有價值的時候，我們往往能將工作完成得很完美。而毫無價值或者低價值的任務則更容易被認為是 冗余的任務從而不能很好地完成。總而言之，如果開發人員毋須被強迫于毫無價值的任務，那么顯而易見的他們將更有動力更有開發的激情，也更開心。