每个程序员都应该给自己写本书理想流

因为看的书相对比较多，最近又写了一本，感觉多少有点发言权，因此把自己的经过和感受写出来，供想写书的做些参考。

现在浮躁的人比较多，所以我先说写书不能达成什么目标。

我们还是先从功利的角度来说，接下来再补充点人生价值，算是由实到虚。

第一点，写书的过程是系统的归纳、分析并总结某一方面知识的过程，这一过程中知识结构中的各种不足都会暴露出来，这有助于程序员的升级，当然你得别糊弄自己。这个时代的特征是分工不停细化，而在分工无限细化的年代里最佳的生存之道其实是专业，你老拷贝粘贴，没有思考，那就和生产线上的操作工类似，怎么专业？程序员是差异非常大的群体，牛的可以驾着游艇周游世界，落魄的就没隔夜之粮。如果划个比例，那很可能是前30%是从来不用担心什么青春饭问题的。要想升级途径很多，写书来深化自己的知识结构，把某块知识挖深，也锻炼自己的表达能力是其中一种方式。当然，多写程序也是升级的一种方法。这两种方式的差异在于，写书是个系统工程，对打基础更有帮助。想象一下，一个人得写什么样的程序才能把一门语言的所有关键字都用一遍？在需要配合，需要专业的时代里，这几乎是不可能的，我们实际用往往总是某门知识的一个部分。而反过来，真要成为牛的程序员，全面扎实的基础知识是必要的，看书是一个方式，而在自己的主营，自己的专业方向上写书可以帮助挖的更深。

为达成夯实基础这样的目的，有几个关键点要注意：最关键的是不能蒙事，不能糊弄，这点不必细说。其次是题材和写作方式的选择上，这时候不能写那种手册翻译性的书（比如：大部分从MSDN翻译），作者只进行简单罗列，而要选个自己主攻的技术领域，深挖了，有自己想法的地方写书。一般来讲这过程中要阅读很多书，要翻来覆去的改改稿子，否则的话就可能是不要思考，手册性的书。最后，别写我这次写《完美软件开发：方法与逻辑》选的这种体裁，这类讲本质，练内功的，一是难写，二是整不好容易把人整虚了，年纪小的时候还是慎入比较。

第二点，写书其实可以是种社交方式。程序员生活大多比较闭塞，这在一定的人生阶段可能会表现为一种劣势。而产生社交又不能单纯的靠电影、游戏这类闲散话题。写本书等于是立论，也在诸多同行面前亮个像，等于是自己有了一张额外的名片，可以多点和大家的交流。这点刚毕业的时候，可能还感受不到必要性，但年纪越大，感受就越深。按照李炯明先生公布的数据，30%的人换工作是要靠介绍的。

第三点，说虚一点，写书很可能是很多人可能独立完成的，属于个人的唯一作品，因此可以是自己非常有价值的一种回忆。到一定年纪后，回头一想自己一直是个路人甲，大多时候，感觉不太舒服。而写程序显然完成不了这个目标，大多时候程序只能是写作后的作品，知名产品大家记住的往往也是产品经理，这个时代已经和求伯君，王志东他们那个时代不同了。年纪大了回头想想，主要是写了一堆不知道扔在那里了的代码，冤不冤的慌。

所以说，只要还有可能就给自己写本书吧！

这里面最关键的可能是出不出的问题。

我感觉这个问题不用太担心，IT这块出书门槛相对比较低，而对出版社而言出书首先是种生意，只要你的书有现实意义，又是水准以上，就我观察大多时候可以出。有一点要注意，第一次写书争取要写那种市场定位明确，解决具体问题的书，比如：Hadoop实战，Linux源代码解析这类，而不要写务虚的，需要较大社会影响力的书，比如后者从出版社的角度看很容易担心销量。我个人属于运气还行，要不然很可能出不了。如果实在担心能不能出的问题，也可以先向出版社提交选题，签合同，接下来再写作---这是一般出版社的公开流程，具体的可以参照博文视点的说明：

接下来可能是信心问题。

最后补充一点，写书不是说就不用写程序，而是说把写程序得来的东西归纳总结出来，让自己升级。就我观察，单纯靠写书吃饭是不太可能的了。因此我虽然认为应该写书，但我不认为写书应该影响工作，我也不认为谁应该从专职程序员转行做专职作家。如果谁想反正我写本书，换个工作没准就容易了，当前工作蒙混下也不打紧，那就基本会吃大亏。

--------------------------------------------------------------