其他

自從《贏》，《基業長青》這些書出了之後，只要是個人，只要他還做管理都會關注文化這個事。這是對的，但關鍵是在這個事上不能走形式，不能在管理中做虛情假意的文化建設。不知道提到文化這事，每個人會對應到什嗎？可能有的人會想到宣講，有的人會想到集體活動（喝酒，唱歌，旅遊，培訓等），有的人會想到挂圖，曆史展示等。但事實上這些手段更類似一種枝節，如果沒有一個核心支撐，那就很容易變成虛情假意。這個核心支撐就是：你能很清楚的回答你的部下，你的員工在三年（或多年）後它可能得到什麼嗎？你能很清楚的回答你的部下，你的員

加班不給加班費的公司違背基本的道義，性質上和搶老大爺養老錢並無不同。一旦處在這種公司裡，第一要累積力量，第二要趕緊跳槽，沒什麼好多想的。今天想說的並不是這個，而是另一個話題：加班給加班費就好嗎？答案是否定的。假如說每個人畢業的時候都還處在剛剛開始成長的階段，那麼過度加班等於扼殺一個人全面成長的機會。這就好比一個人，如果始終生長在生產線上，並且只用右手，那麼10年過後右手必然會無比強壯，而左手則會無限萎縮。從生產線的角度看，這個人無疑是可以滿足生產需要的，但從個人的角度看，則自己無疑的是殘疾的。程

開源至少值得嚮往即使是許多開源陣營中的人自己，也未必認識到自己所做所為隱含的含義。西方社會的基礎是幾條非常基本的原則：自由交易，平等交換，多數優勝。平等交換即以價值相等之物進行交換，這條基本原則幾乎體現在任何一個角落裡，雖然價格與價值經常發生背離。在這樣的基本原則下，因為社會生產的需要，又產生了公司這樣的組織。公司對內向員工支付工資以購買勞動，對外則以交換為手段擷取利潤。利潤之於公司，便如血液於人，乃是生存之根本。這就是西方社會的基本形態。但開源是與此是相背離的。開源的第一驅動力是興趣下的志願，

一說到食物鏈很多人一定會想到狼吃羊，羊吃草。是的，我們說的就是這個。公司間的食物鏈雖然不像自然界那麼血腥，但確實存在。至少這是影響工作和發展的一個很重要的維度，不考察是對自己不負責任的。商業社會中的食物鏈可以做簡單理解：付錢的在食物鏈上端，靠別人給錢的在下端。壟斷的或接近於壟斷的在上端，被壟斷的在下端。比如說：公司A把業務分包了給公司B，那麼公司A在食物鏈的上端，公司B則在下端。比如說：公司G佔有了市場份額60%，其他公司分享其他的40%，那麼G在上端，其他公司在下端。為什麼食物鏈重要？因為在同

在敏捷測試中也有測試活動乃至專職的測試人員，但其主動式內容和目標是有顯著差異的。一般在傳統Team

自從Java虛擬機器這種東西出現後，作業系統的一部分功能事實上正在被剝離，而虛擬技術比如VMWare等的盛行正使這一趨勢越發的加劇。象Windows現在的一個巨大優勢並非在於作業系統，而在於生存於這個作業系統之上的各種應用。如果有一天各種應用程式徹底的變成了系統無關，比如都可以在Java虛擬機器上跑，那麼哪一天實際上是作業系統的末日。象微軟這種公司眼下面臨的也就是這樣一種尷尬。他推新技術就意味著推翻自己的優勢，他不推新技術那就意味著等著被別人推翻。如果將來微軟喪失自己的霸主地位，那麼根本原因必然

#如果有人聽了本文的觀點，但後果不太好，那本人也負不起責任。#所以聽或不聽，請君自決。雖然沒法知道究竟多少人會進外包相關的公司，但估計比例不低。因此花點時間說說外包。很難籠統的講外包好或不好，但如果你是技術狂熱者，或性格極度內向，做外包就有點不適合。簡單來講是，做外包時，技術上職業路徑沒那麼長，為求發展，必須做管理，必須學著和人溝通。外包出來的東西總體來看，技術含量偏低，但涉及的面可能很廣。形象的比喻是你不可能期望微軟把OS核心外包出來，而各種MIS系統則可能牽涉各種語言平台(Java,C#,各

這是敏捷開發般若敏捷系列的第八篇。（之一，之二，之三，之四，之五，之六，之七，之八，之九）正法，像法，末法任何事物，都會經過這三個階段，有的短至幾年，有的長達幾千年。正法時代一般是原創者掌握話語權的時期，因此能正確地解釋和傳播。正法時代傳播的是智慧和般若，而不是知識（方法，具體的實踐等）。本人先是學習了敏捷開發的方法，之後一年多才有幸讀到Ken Schwaber的圖書，其中一本大量介紹了以往他推廣敏捷開發的案例

這幾年用戶端程式在一定程度上被弱化關注的焦點更多的在於一些商務平台和網路架構一個表象就是傳統的用戶端開發利器逐漸沒落比如delphi和mfc等但實際上在未來幾年裡，用戶端程式並不會因為各大廠商的減少支援而失去光彩。估計某些新技術的湧現還是會以用戶端程式為根基。從串連品質上看網路終究是不穩定，而電腦內部的串連相比之下就更有品質。對於終端使用者來講體現在他自己電腦上的東西才有意義，而要想把某些功能體現在客戶的計算己上，那麼用戶端程式必然始終會扮演一個至關重要的角色。

#如果有人聽了本文的觀點，但後果不太好，那本人也負不起責任。#所以聽或不聽，請君自決。有時候會被問到找工作的事，寫點東西給即將畢業的同學參考。畢業生找工作首重方向（即行業）。公司錯了可以換，收入低了可以搏，方向錯了，轉起來代價太大，甚至沒法轉。男怕入錯行就是這個意思。軟體聽著是一個行業，但裡面的分野太大，和不同行業也差不多。比如：網站開發和驅動程式開發幾乎是兩個行業。這裡的關鍵是一旦你做了3年網站開發，你很難再做驅動程式，年頭越多，這種轉換越難。一個人要是做了10年網站開發，接下來突然說要做驅動

作者：陳勇來源：blog.csdn.net/cheny_com    合成謬誤由薩繆爾森提出：倘若每個人都基於自身作出最佳選擇，所有人選擇的合成結果極有可能是大家的公用福利受到傷害。    合成謬誤的一個典型的例子就是公地悲劇（tragedy of the commons

#青春飯這現象其實很淒慘。#大好青春，挑燈夜戰卻換來兩手空空，滿頭白髮，即對不起老婆孩子，也對不起老爹老媽。#誰也受不了。#這是真的殺人不見血。寫篇文章為苦悶中的人提點建議吧！這世上有些基本規律在限定條件下不容違反，比如辯證法，比如萬有引力定律。而其中和大多職場中人直接相關的一條則是價值規律。這條規律可以簡單描述為：當一個人自身的價值和他的酬勞明顯不相匹配的時候，這個人最終將被淘汰。在中國，過去很多年裡IT行業被稱為吃青春飯的行業。30多之後還做程式員，大多人心裡怕就有些惶恐。這種現實既然真實存

本文是“松結對程式設計”系列的第三篇。（之一，之二，之三，之四，之五，之六，之七，之八，此系列之九及之後文章請見欄目總目錄。）估算是經久不衰的管理話題，大致分為兩種流派。第一種是領導指派，領導說這是10天的活，就必須當是10天的活來幹，如果乾不完，可以用加班、損失品質、功能縮水等各種方法曲線救場。另一個變種是大家自己估算，但是交給領導審批；領導審批其實就是砍一半的過程，還好大家之前就已經加了一倍，所以不怕。第二種是自我管理派（偏敏捷），就是由具體開發的人員自己說開發工作量，領導和他人不干預。儘管

軟體這個行當裡曆來有個謠言：專案經理不懂技術沒關係。有人說這事兒是外國的先進經驗，但我懷疑這是杜撰的。這一觀點的潛台詞是：專案經理是管理者，指揮下屬就行了，幹嘛要懂技術！這就像說班長不用拿槍上戰場一樣可笑。持這個觀點的可還記得：”將軍起於行伍，宰相拔於州郡“這一說。我的觀點是，專案經理一定要懂技術，並且還要有比較紮實的功底，雖然在專門領域上不一定是專家。在這篇文章裡，我們將列幾本用來打根基的書，這些書要精讀而不能翻翻就算了。這些書的用途，不在眼前，但卻最終決定你的成長高度。沒這些根基，如果站得太

總結瞭解決multiple definition of的方法：問題原因：（1）    當多個檔案包含同一個標頭檔時，並且你的.H裡面沒有加上條件編譯#ifndef TEST_H#define TEST_H#endif就會獨立的解釋,然後產生每個檔案產生獨立的標示符。在編譯器串連時，就會將工程中所有的符號整合在一起，由於，檔案中有重名變數，於是就出現了重複定義的錯誤。方法1：    給每一個標頭檔加上條件編譯，避免該檔案被多次引用時被多次解釋，這是個應該是習慣。這個方法會解決大部分低級問題。方法2

這是敏捷開發般若敏捷系列的第四篇。（之一，之二，之三，之四，之五，之六，之七，之八，之九）敏捷開發中有幾個地方相當創新，或者說儘管之前的方法中可能也有涉及，但卻從來沒有像敏捷開發這樣提升為“根本大法”來對待。一個是“擁抱客戶價值，擁抱變化”，一個是TDD/結對程式設計/自動化測試為代表的開發與測試的融合，一個是“團隊協作/結對程式設計/共同估算/代碼共同所有制等自組織團隊實踐”，還有一個則是認為協作重於流程，溝通勝於文檔。傳統開發的困局在敏捷開發之前，儘管沒有成文的說法，但客戶與開發人員整體是個

 本文是敏捷開發產品管理系列的第七篇。（序言及設立迭代目標，產品版本規劃，產品使用者群規劃，新產品研發，預估會議，Product Servant，Product Owner團隊，產品線管理），也是敏捷Team Dev管理系列（擬）中的一篇。目的在之前的《Product

 本文是敏捷開發產品管理系列的第六篇。（序言及設立迭代目標，產品版本規劃，產品使用者群規劃，新產品研發，預估會議，Product Servant，Product Owner團隊，產品線管理）馬與馬車夫的故事這是心理學上的一個比喻。馬拉著車向前走，它說：控制車去哪裡的是我，我走，車就走；我停，車就停；我轉，車就轉。馬車夫笑了，他說：控制車去哪裡的是我，我讓車走，車就走；我讓車停，車就停；我讓車轉，車就轉。后座的客人笑了，他說：難道你不是以送客人回家為生？當我們成為Product Owner的時候，

本文是敏捷開發產品管理系列的第五篇。（序言及設立迭代目標，產品版本規劃，產品使用者群規劃，新產品研發，預估會議，Product Servant，Product

本文是敏捷開發產品管理系列的第一篇。（序言及設立迭代目標，產品版本規劃，產品使用者群規劃，新產品研發，預估會議，Product Servant，Product