思考是一种奢侈的行为，丁丁出生之后深有体会，虽然大部分的事情是由家人处理，但是难免来回的奔走，至少，丁丁那里还是一个事情，还得记挂着。本文就在这样的环境中写成，打算弄出一些思想的火花，可惜我不能，因为我太朴实，不像一个能够忽悠的人（ 这话还不够忽悠啊？）。
本来开篇的时候我想写写这篇文章的背景，转过来一想还是不写了，为什么呢，和大家分享一下：回过头去看自己最近的表现，在谈话中所做的例证过多，这个说明什么呢，是我自己本身的自信力不是很强，对别人是否认可自己的观点存在一定的怀疑，而且也非常期望能得到认可。总体而言，这是一个危险的信号，这可能会导致我的热情被自己消耗掉。而造成这种情况的原因我想可能有几点：第一点，目前的状态有些不稳定，不久前，朋友问我，我曾经使用“翩翩如履薄冰”这样的怪异组合来形容目前我的心态；第二点，丁丁出生之后，看书的时间较少，家里的杂事多，很少能够安静下来思考，所以自己都感觉现在说话有些不考虑；第三点，大环境的锐进和浮躁造成的，这点我想就是这篇文章的主旨（可惜不能深入，我若然是马云或者李开复这等人物，自是不必顾及太多，而今还在屋檐下，难啊）。
我始终认为，我是一个技术人员，是一个程序员。我也总是让比我年轻的兄弟们选择当程序员的时候，一定要确定自己要当多少年的程序员，因为能够持久的当一个程序员的人不多，潜意识里面，我期望得到一些比较明确的或者说是看似诚实的热情，而我实际看到的更多的是对职业的下意识的伪善——这也无可厚非，我也如此，真小人是也。我在初期和同事交流的时候，曾经忍不住冒天下之大不讳说了一句大白话：程序员是需要引导的！当即惹来一些毫无恶意的玩笑，我立论有几点根据：
第一点，程序员的职责很不清楚，在我的面试过程中，我问了很多次这个问题，我发现很多应试者都没有考虑过这个问题，由是观之，基本很少有人能够主动考虑这个问题；
第二点，社会大环境导致程序员的外在定位较低，这直接导致了这个群体的自我保护意识空前加强，很多人认为30岁是个坎，直接的表象就是浮躁，不能够踏实的写代码；
第三点，由于前面的原因，分散了程序员自身的精力，同时程序员本身的工作的繁重，也导致没有时间进行学习，或言之，在紧张的环境之下学习的方式和方法存在一定的问题；相反的是，我面对的应试者大都会问到一些培训的问题，我反问“你希望能够得到以何种方式组织的怎么样的培训呢？”这个时候双方的对答可能都有些不得要领，因为我们始终没有忘记，工人——不管是怎么样的工人，都是必须要有产出的。
第四点，特别针对于一些新的程序员（工作时间在3年以下的程序员），个人的知识面不广，导致能力的折扣（同事对我的这个观点诟病很深），而这些开发人员已经在逐步的顺移到半开发半设计的阶段，这个时候就凸显了知识面的问题了。知识面包括技术知识、业务知识和相关、等同工作经验积累，的确，这都是个问题。
可能还有更多的原因，我也不再深究了。我想这几点可能大部分都能得到认同，而我被开玩笑的根本因由是“我”提出这个立论。我并非妄人，为什么在正式的场合提出这种不适合我来说的言论，而且我在之前也说了，这是一句大白话，原因就在于，我觉得技术人员的自我意识应该加强，而且整个团队中存在一些问题，而这些问题并非我一个人能够解决的——从某种程度上来讲，我犯了左倾冒进主义的错误。以我现在的资历和能力，我的确不能作为一个指导者而存在，我所能够提供的，可能只是一些经验性的实务，而非理论性的支撑——我们正是被这种思想给束缚住了，这里我提出本文的第一个论点：个人惯性思维对技术的负面影响。
首先我提出我对团队成长的观点：
只有团队个体的成长才能带来团队的成长！
TSP告诉我们一个自适应的团队是如何创建的，也提供了创建TSP团队所必须的手段和前置条件，似乎是按照这样的组织和约束就可以创建一个完整的自适应的团队，从这个角度来看，TSP和MSF并没有很大的差别。而在我看来，我更关注的是另外一个侧面，从约束之外的人性化的一个方面，我所关注的是如何让个人成长起来。诚然，在TSP和MSF等等的约束之下，团队个人也能得到成长，但是对于我所接触的团队而言，真正做到TSP、MSF的非常少（几乎没有），团员成长所遇到的阻碍更多的不是来源于团队的制度约束，而是来源于一些固有思想的阻碍。
论语在“泰伯第八”和“宪问第十四”分别提到“不在其位，不谋其政”和“君子思不出其位”，从字面意思来说，拿来做注脚最是合适。首先的惯性思维就是多一事不如少一事，从开发人员到管理人员都存在这个问题，而且非常明显，这可能和我们的文化有关系——孔夫子都这么说了，可能真错不了。可惜的是，这种思想体现在我们的开发人员的代码中的时候、体现在我们的设计人员的成果中的时候，让人觉得有些尴尬。我们所期望的软件，希望有够强的灵活性、适应性、扩展性和可维护性（极端的情况，我真希望一次Coding就能够不再修改），可惜大多数时候都不能如愿。即便我在此呱噪，我自己写的代码还是不少重新构造的，区别就在于我自己愿意重新构造，而更多的人不愿意重新构造，认为这是没有必要的。中庸的说法是，这个现象是无可厚非的，但是并不是说这种只管当前不管将来的做法是不可以更正的。
这个时候首先考究的是技术带头人的眼光和手段。技术带头人可能是架构师、设计师或者两者的结合(我还没有那么的高度，将技术带头人定位到CIO这样的职位，在我的理解，这个坐到CIO椅子上的人，第一不会写代码第二不知道架构第三不会搞设计，擅长的是忽悠和炒股，原谅我的愤青(*^__^*)...)，这个人基本决定了这个软件产品的总体质量如何，或者大而化之，这个人决定了他所管辖的产品部门的开发人员的生存环境。开发人员的眼睛都是雪亮的，如果带头人广开言路并且兑现承诺，则开发人员都会出谋划策，否则大有将主意烂在肚子里的趋势。至于产品的是否进行过度设计、过度设计的程度、产品的里程碑等等，都有专门的方法论支持，我就不在这里献丑了，我只想强调一点，那就是MSF里面的：Work toward a shared vision——做到这点何其之难啊，首先是这个vision难以确定，然后是milestone难以确定——所以，带头人的职责首先就是要破除团员的思想局限，群策方能广益。
然后应该考虑的就是团队环境了，团队环境中对外在事物的抵触其实并非是团员自身的原因，和领导的风格和方式密布可分。我想，出于公允而言，团员都期望能够学习和接触到更多的东西，那么在这种情况下为何还会产生抵触甚至恐惧呢？这就是从上而下带来的负面效果。试问一句，有几个领导能够真正开明的看待员工做私活的事情？我从业这么多年来，我看到的情况是，领导宁愿员工在办公室里面聊股票期权也不愿听到关于私活的话题，甚至，对于员工对于新鲜技术的研究也倍加敏感，在这样的环境之下，的确需要人们的谨小慎微——的确有些令人尴尬，从一个简单的HR领域的人员维系挽留（好熟悉的术语）转换成了制度化的技术苛责上。
坦率的说，我自己本身对于员工私活保持中立的状态，我只有一个要求，不要耽误自己目前的正职工作，如果私活和自己的工作一致，我倒是非常乐意分出一些时间给他做私活。我是诚心希望我的兄弟们能够成长，我希望他们能够学到东西，不管以何种的手段，因为他们才是真正写代码的人，光是我们知道技术知道观念有什么用？话又绕回来，软件是需要有产值的，没有产值的软件总归是废物，所以，其间的折中也是一门学问。
您看到我说的个人惯性思维了么？
我提出我的第二个论点：领导个性对技术的负面影响
明朝的历史，不管是正史还是演艺，对于袁崇焕和吴三桂这两个人的关注远远超出对关宁铁骑的关注，不管历史如何争论是否存在这样一个名号，可以确定的是肯定有这么一支强悍的军队存在过，这支队伍的强悍和这只队伍的领导人密不可分。管理书籍上总是拿军队来比喻管理的，我也俗气一个，呵呵。
我所经过的团队——包含我带的团队——都具有明显的个人性格特征在里面，我在之前的一些心得和体会中还在强调，一个团体不应该具备个人的印记，而我现在已经改换了思维：个人印记在团队中几乎是不可能消除的，而且，对于这个团队的成长举足轻重——所以我错了，在我学会思考之后，我将兄弟们就带入了一个尴尬的状态，汗颜啊。也有可能的是，个人印记正是管理中的乐趣所在。
很多的人对技术的管理，多是从研发逐步上来的，这好像是一个通例，快的两三年慢的四五年，总会有些官衔给顶着。而这里存在一些问题——可能会有些问题——那就是必要的技巧性的东西的匮乏。这个和其他的管理的职位可能要复杂一些，因为技术这个东西没有办法忽悠，太诚实了（这样我会得罪一帮人），而必备的这些技能在这个职位上很难补足，因为下意识的是，这个职位是一个能人坐的——一旦坐上去，缺乏时间进行整理和思考，会更加忙于实务。
而另外的一个方面，处事的风格和对待人的态度对团队的影响也是很强了，这对技术的最终实现来说，可能会影响到设计层面。举个简单的例子，我们很怕的那种直线管理，领导为了凸显自己的能干参与某些东西的设计或者构架，这个时候下属的尴尬来了，具体下属如何做是不是需要揣摩上意？的确，这个问题基本上没法解决（这句是病句，但是很通），我只是提醒而已。
而从小放大，程序员的惯性和技术领导者相关，那么技术领导者的惯性呢，这里顺势我提出我的第三个论点：公司环境对技术的负面影响。
在ITIL的实践中，很能说明问题，ITIL的推销说明也已经是很好的例证了，我就不再赘述了，直接引用如下
在大多数情况下，对于已受过 ITIL 培训、阅读过 ITIL 书籍或参加过 ITIL 专门讨论会的人来说，ITIL 所带来的好处是显而易见的。但是，让其他人相信 ITIL 对公司的好处却并非一件容易的事情。
IT 管理者往往无法在其公司内充分宣传 ITIL。某些推广活动只能停留在一个层面而不是在公司的多个层面上进行。还有一些人只是在关键部门努力，而不是让公司的所有潜在受益者都感受到成功实施的 ITIL 的作用。
重要的是知道 ITIL 的过程并不能一蹴而就，而 ITIL 也不会将低劣的 IT 基础架构在一夜之间变为最优秀的。需要时间、规划和投入才能从 ITIL 中充分受益。您和公司中其他关键人物的投入是至关重要的。许多人更愿意成为 ITIL 的狂热者和信徒，而不愿向 IT 团队中其他热情较低的人充分说明 ITIL 的实际情况。ITIL 需要高度的义务感，花费时间在整个公司中培养这种义务感是实施 ITIL 的关键因素。
公司的结构通常建立在三个层面上：战略层、战术层和执行层。每个层面对 IT 基础架构作用的看法和期望都有所不同。成功在于在公司内定义这些层面，确定其期望，以及说明 ITIL 是怎样帮助其达到预期效果的。
结语
和众多的批评者一样，我对于事情也只能看到现状，而不能找到解决方案；和他们不一样的是，我从自我的思考中看到问题，而且在开始着手修正和规避这些问题，已经在开始务实。但是文字之间还是狂悖不经，不知又会惹来多少祸端？
虽然很草，很零乱，但是错别字少，也写了不少的字，我很开心，也不准备改了，只是一个日志，无须兴师动众！
当一个普通的程序员的时候，希望自己不要这么累，开始的时候希望自己不要被客户打扰，能够安心的写代码；然后希望不要加班，给自己一点个人时间；当设计的时候希望自己能够多一些空间学习，希望能够管理管理，真正到了今天，我还是忍不住的编写代码，希望自己能够有个时间写自己的代码，有时间研究怎么把我和兄弟们都弄得升天，真是一个轮回啊，多少人能够安于程序员这个职业？我不能，汝能否？
谨以此篇纪念我的形而下的岁月！
----------------------------------------------------------------------------------------------------------------------
附注：
关于引文
对于本文所提到的《论语》中的“不在其位，不谋其政”和“君子思不出其位”，南怀瑾先生有个最好的注解：“宿将还山不论兵”；国人多以前面一句作为耍滑头的理由，其实谬误也，孔子的意思是，学以致用，学到的东西要和做事结合起来；同时孔子也告诫学生，对于不了解不深入的事情不要妄下断语。断章取义，何其谬也，我也不能免俗，汗颜啊。
关于我的代码质量
我个人最失败的一个软件是在贵州做的一个SQL查询工具，包含了元数据管理等等而最终的结果是脱离了环境就不能使用，到现在，我也不准备进行修改了，找网上的工具了，详情参看，我不讳言，我的代码质量一般，我尽量做到的是，能让别人看懂我的代码。
就目前而言对代码风格的偏好我侧重于当初Visual C++的匈牙利表示法，我知道这种偏好给我在JAVA领域中编码带来了很多的负面效应，也在慢慢的改。
而目前我所作的报表系统ERIS，确实是因为前期的短视，没有支持FireFox，现在修改起来，觉得困难，自作孽啊。
关于我对程序员的理解
我顺便说一下我对程序员的理解，程序员是解决问题的人，是软件系统中的基石，而不是制造麻烦的人。我的理解，所有和Coding相关的人员，都可以称之为程序员——即便是他们不直接写代码。温伯格老先生的《理解专业的程序员》和《程序开发心理学》是我作为圭臬的两本书。顺便提及，老先生的其他书籍也是值得阅读(我很慎重的选择了“阅读”而不是“看看”)的。
在之前的文章中，我大肆的对程序员这个职业进行了一次批驳，实话说，我现在还是不看好程序员这个职业（这可能又是被攻讦的因由啊），虽然我很想安心的写代码，但是外部的环境根本不允许。