对不起，今天中午的盒饭我超过5块钱了

首先请允许我摘抄一段别人的文章：
“如果你看过一些比尔盖茨，乔布斯，鲍尔默这些人的八卦和传记，也是出了名的"fuck","dick"之类的常挂在嘴上。而我认为（和看到的），任何一个能力强悍的软件开发项目经理或团队Leader都不可能的是一个好脾气。我并不是说他们在某方面小有建树就有资格对菜鸟们呼来呵去，但我敢保证，如果你有一天成为一个能独当一面的真正认真负责的一线Leader的时候，你的脾气绝对不会比我好到哪儿去。所以高手并不像有些菜鸟说的那样如此超脱，淡定，谦恭...那是圣人，你有问题的时候不会叫“圣人，替我做主啊～～”，你只会叫“大人，饶命啊！”。你的直接团队Leader才是“大人”，他才能给你调Bug帮你擦屁股。作为“圣人”的董事长，技术总监虽然都是笑呵呵的，但他不会解决你的任何实际问题。就拿我自己来说，我也知道有时候我脾气不是很好，在团队沟通中说话很直，有时候甚至很暴躁。我也尝试了好几年，上到儒释道，中到西方哲学，印度灵修，下到什么办公室处世之道，看不少...就想变得淡定一点，变得有点高手的仙风道骨...可悲剧的是,我在大家心目中的形象还是这样的。 ”
如果你看到过这么一段话，那么它来自于一个女程序员的博客。我很随意的看到这么一段话，并且很认真的发现文章的描述与中国软件行业的规律如此贴切。其实我并不想在我的技术博客写这些东西，毕竟熟人太多，本人也不玩sina微博、人人、QQ空间、校友等等社交网站。所以从来不会写什么性感类文章，那么这就算是第一次了。
我是程序员，先从这个岗位开始讲起，在我身边就遇到很多外行对“程序员”的理解，他们肯定能会修电脑、装系统、做优化、能刷机、还代买各种手机等数码产品。你们把程序员看的太神了，在百度百科输入“程序员”，它的定义是：程序员(英文Programmer)是从事程序开发、维护的专业人员。一般将程序员分为程序设计人员和程序编码员，但两者的界限并不非常清楚，特别是在中国，软件从业人员分为初级程序员、高级程序员、系统分析员和项目经理四大类的方法。我们再做一个尝试，搜索一下“程序猿”，你会”惊喜“的发现文中有这么一段描述：程序猿是被诅咒的悲惨生物，它们受到的诅咒有：过度的劳作、永远不足的睡眠、低廉的收入等等……
对于上面的描述，我想对于"程序员"的理解我可以跳过不做过多解释，现实的问题就在于别人对程序员的藐视已经猖狂到“不就是for循环吗，我在大学也学过，要是我做几天我也会”，真人真事！真人真事啊！放在几年秉着前对于事情的较真我还会辩论几句，现在我只能笑而不语。
从出来到现在算算已经有几年了，但是从来很少有程序员的编程态度让我心服口服过，除了坛子的”马桶哥“【去他CSDN空间】和我现在公司的头儿，所谓一个IT人，人品往往大于编程的技术也决定了编程的深度。不管是生活还是工作我也得罪了不少人，我不会溜须拍马，也不会跟风符附和，当然，别人优秀的一面我肯定会非常赞赏。在我的态度中就是否定，不断否定，否则别人错误的东西，也不断否定自己。得罪很多人所以也是很正常，我也从来不会为此觉得自己就是错误的，因为我就是这么一个人，你喜欢或者不喜欢，我就在这个地球跟你一样活着。也有很多人在明着暗着想教我怎么做人怎么做事，但是对不起，除了我妈教我“要想人不知，除非已莫为”和“自力更生，丰衣足食”外， 没有人能很完整的告诉我你教我的你同样做得到，并且还是正确的。
很多人说过我脾气臭，生活中我很少有脾气，除非是可忍、孰不可忍的时候，开发时间稍微长点你就会被打磨的没有脾气，这个都懂的！但是从最开始的一段话已经描述的很清楚，项目指定了责任人，也就指定了项目责任，角度对换，理解别人的时候考虑一下别人的”责任风险“，责任风险你懂的！系统推进过程中的各种业务和技术问题除了Leader，谁有义务去擦屁股。刚刚看了一下博客园的4月刊，有这么一篇文章是对于项目失败的总结：
一、需求如空中漂浮的羽毛（团队跟着需求跑，跑久了就变成疲军之师）
二、职责不清、人浮于事（项目经理作为项目的核心人物，应类似与古代分封制下的诸侯，在项目组内具有生杀大权）
三、令行不止（例如“代码必须通过编译才可上传SVN”，这样的制度对与他人的工作是有影响的，如不遵守那么就导致他人工作受影响）
四、人心散了
五、领导干预过多（避免在项目经理也懂一些技术的情况下，一有空就越过技术负责人对技术问题指指点点）
六、人员成分复杂（项目成员包括外包人员、实习生、应届生、工作1～3年的人员，那么项目离失败只有几步之遥了。）
七、追赶项目进度（时间被不断的压缩）
我很认真的分析这几条总结，并且感到压力很大。IT行业确实有“程序员相欺”这一说法，但是始终是技术和工作层面上的，人性本善，在为人处事的角度没有任何人对另外一个人有否决权。我确实说过我分发出去的任务总是不能按要求收回，也反思过在工作中自己决定的合理性，从制度上和现实上所有问题最终只能由自己买单，并且对于不能完成的部分任务回收后再平均分配到能力强的人身上，这是一个很现实很无奈的举动，并且我相信很多人也遇到过这种情况。
反过来从项目的源头来说。IT项目管理的三要素：时间、成本、范围。任何一个三维空间的拉扯都不是均衡的，造就了项目的尴尬。时间压缩，成本不谈，范围波及大（对于业务方肯定是功能越多越好），软件本来就是一种逻辑实体，充满了很多不确定性，严格上讲没有开发人员参与决策的业务，根本无法控制它的计划和实现目标，项目不拖死人才怪。同样，理论上项目管理中员工回报也分为三种：物资回报、身体回报、心理回报。我们团队一女程序员特强悍的做了很多事情，后期每次分配我总是说累了很长时间，让她休息会儿，少分配点起一个调节作用，可是如上文所说，无法回收的任务还是需要再平均分摊，她肯定也躲不过，这样的情况你能说是谁的错？没有一个公司会很主动的说给你转正、加薪什么（例行加薪除外）。我无法给自己申请，但我至少要为别人考虑，因为我觉得上面批准不批准是上面的事情，我反映不反映是我的非条件义务，一个不考虑团队成员付出与回报的Leader带项目的过程必定是磕磕碰碰，项目结束了，人心也就散了。一个不尊重员工的公司必定不会有长远发展，奖罚措施不完善也势必会影响项目的结果。
很多时候我想抽出时间自己封装一套东西，能方便别人也方便自己，可是我没有时间啊！也别告诉我时间是挤出来的，如果你能平均每个月阅读2本书，再教我挤时间。我自己有做开源的东西，我支持开源，但从专业上来说我使用别人东西的条件与构件的条件一样：自描性、可定制、可集成、连接机制，缺一不可。所以不管任何人，给我推荐或教我使用别人东西的时候如果满足不了这些条件，我宁愿使用自己东西。别告诉我代码量会多几行，如果你不懂软件复用的原则就不要随便推荐东西往项目里面扔。我见过很多没走过OO流程的人谈面向对象，也见过很多对服务器控件机制和Net运行机制完全不懂或者一知半解的谈效率，甚至有连敏捷宣言都背不出来的人教别人敏捷。你可以想象这是一个多么可怕的IT生态圈。
程序员，对于身边不懂你的朋友、恋人、和，你最好不要说话，话多无益；对于IT人，不懂你的更不要说话，有可能让你吐血身亡。做事尽心、尽力就好，做人有做人的人格，程序员也有程序员的尊严。随时否定自己，每天提升自己。最后调戏的说一句，“对不起，今天中午的盒饭我超过5块钱了”。