程序员的灯下黑：重知识轻技术
电视《雍正王朝》讲了这么一个故事：大将军年羹尧奉命到青海平叛，清军因路途遥远，军耗巨大，因此力求速战速决。但叛军避开锋芒，东躲西藏，年羹尧没有办法找到叛军决战。这时，朝廷内外压力越来越大，年羹尧陷入困境。这是一位谋士对年说：我知道叛军在那里。年大喜。这位谋士指出，敌人就在不远处的一座皇封寺庙里。年不信，谋士不慌不忙地说：这就是灯下黑，离自己越近就越不可能意识到，但却是最可能的地方。果然，大军一出，大获全胜。

我想讲一些关于程序员对自身认识的故事，这些故事都和灯下黑有关。只要正确认识自己，道理非常简单，但是，到处都可以看到灯下黑的故事。



某程序员，有一天接到一个任务：公司的有一个产品的文件太大了，要求采用压缩算法，减少尺寸，最好能压缩20%。

程序员兴高采烈地接受了任务：以前没玩过压缩算法，这下可以学习新东西了！研究了几个月后，他觉得差不多了，就交给了项目经理。项目经理正等着呢，高兴坏了，拿着演示文件就去找产品经理。产品经理开始挺高兴，看完脸就拉下来了。打开文件，把所有的文件尺寸一算，很淡淡的说：“才压缩了10%，有什么用啊！”

程序员愣住了，“不会吧！我看过的，压缩了 20%！”

产品经理指着文件列表说：“你看，某文件是压缩了20%，可你的压缩算法增加了一个动态库文件，尺寸还不小，总共加起来，不就只减少了10%吗？”



各位看官，这是不是软件公司里经常发生的情形？

这种失败的成因当然是复杂的，有沟通管理方面的问题，也有程序员能力的问题。我今天想要说的是程序员认识方面的问题。

继续故事：

项目经理很没面子，回去就和程序员找原因。项目经理是老程序员了，直话直说；终于弄清楚的事情的本质：

第一，这位程序员一个的时间读了很多关于压缩算法的书，会了不少算法。可是从来没比较过算法的优劣。这老兄觉得研究算法很有趣，乐此不彼，写了好几个实现。

第二，这位老兄在最后几天才想起来20%的目标，也没太放在心上，看看差不多就拿出来了。



这是典型的程序员的认识问题，重知识而轻技术。



先从是么是知识，什么是技术说起。

知识就是知道，你知道了某件事是怎么回事，就是有了知识。

技术就是你能做出来，做得好叫技术好，做的不好叫技术差。

怎么写操作系统？看完操作系统原理，再苦读完源代码，这叫有知识了。如果有本事把任务调度、内存管理、IO什么的都写出来，还能写得稳定，快速，可扩展，那是有技术。有知识和有技术可差远了。早年我在工厂实习，要挫一个圆孔，拿着内锉刀干了一天，只挫了一个椭圆；师父来了，三分钟，比冲床冲出来还圆！我是个好学徒，使用锉刀的知识全记住的，可以写一篇内圆挫使用大全。知识是有了，可没这个技术。

程序员也一样。什么C++，Java，.net，什么STL，Struts，Spring，就是门门都满分，这也就是有知识。算不算技术好呢？差远了。软件工程师界就专门出这种不会写程序的“高手”。我遇到一位老兄，精通Java知识，从虚拟机到各类框架，概念，无所不同，谈起Java来，没人说的过他。可是他的代码永远Bug最多，而且都是最简单的Bug，什么逻辑不对啊，功能没实现啊，UI不对啊。他的领导只有又好气又好笑。问下去，发现这老兄写了几个程序文件以后，就不感兴趣了，因为所用的技术没什么不知道的了。所以马马虎虎交差。

说到底，写程序是个手艺活，就和古代的匠人一样，是要讲工艺的。比如一个玉匠，能打造栩栩如生的玉孔雀，那得打的好！要是一个玉匠说，这些手艺我都知道了，重复做东西没劲，将就着给客人做出来吧！那他还不吃西北风！

可是，十几年来，程序员界有的是这样的人，还引发大规模争论。象什么C++和Java之争啦，J2EE和.Net之争啦。你看里边的帖子，不停有人赌这个阵营那个阵营，有发誓一辈子做C++的，有发誓打倒.Net。我还奇怪了，专门没人效忠机器码的，那不是最难最有“学问”吗？这都是在争论什么知识最重要。可是啊，很少有人谈谈怎么做好产品的。



现在程序员最大的问题就是太看重知识，拼命追逐新玩意，而忽略了身边的够得着东西。好，什么C++，Window API都知道了，东西也弄出来了，可是三天两头崩溃，还找不到原因？为什么？有没有看看代码，看看是不是某函数写了2000行，自己都看不懂？是不是全局变量乱用？是不是没考虑前后兼容性？没考虑冗余和故障恢复？



末了再回到开头的故事：

项目经理回去和程序员再重新设计，又多花了一个月，终于达到了目标。但因为这个部分是一个大项目的一部分，整个项目不得不延迟了一个月。

年底考评的时候，项目经理给程序员打了一个及格；程序员不服，告到总经理那里。总经理说：“你知足吧，给你打及格已经看在你干的很辛苦的份上了，因为你没有按时完成，整个项目延迟了一个月，这帐都没找你算呢。”程序员颓然。






Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1046817

[点击此处收藏本文] 寸锐斋发表于 2006年08月10日 16:57:00


加密狗,使你的软件免受盗版侵害
软件开发商可以用加密狗对软件进行加密，从而保护您的软件不被盗版，保证您的市场免受盗版的侵蚀。 开发商可以利用加密狗控制软件的发布。 使用加密狗，软件开发商可以设置软件的试用期限。

http://cn.safenet-in... CSDN邀您共同发展
好工作好前途尽在CSDN,快来试试吧
http://job.csdn.net/... CSDN项目外包平台
软件项目外包,软件交易,发项目接项目一切轻松搞定
http://prj.csdn.net



Carol 发表于2006-08-11 08:44:00 IP: 65.110.3.*
身边这样的人很多，这样的人适合面试不适合干活:)


Neil 发表于2006-08-11 08:54:00 IP: 61.154.14.*
很有道理。我同意。


yan 发表于2006-08-11 09:00:00 IP: 219.239.35.*
同意。想要作出一个完整的产品，完成一个完整的项目不是只有“知识”就够了的，需要细心，有耐心，遇到问题得钻，要为项目着想，最后这一切积累起来才会是你说的“技术”吧.


movingboy2 发表于2006-08-11 09:25:00 IP: 219.135.164.*
别把责任都推到程序员身上，此项目经理也有很大的问题：

1.没有对产品成果制定出更为明确的约束，而通常这些约束不会是只有一个方面。仅仅是一句简单地要求把算法效率提高20%仍是不足够的，案例中经理和程序员对此的理解就出现了差异，这是导致项目延期的一个重要因素。对于考评结果，总经理肯定是帮强势的项目经理而不是弱势的程序员：在双方的观点都不能说100%正确的的情况下，肯定是帮项目经理而不是程序员。为一个程序员而开罪一个项目经理，值吗？
2.没有及时控制项目进度，完全放手给程序员。个人的经历告诉我， 只安排了任务而不给出明确的工期，不对进度进行管理，这客观上会助长程序员的技术完美思想而忽视了进度
3.没有预留适当的进度风险余量，在任务可能延期时缺乏应变措施。既然这个算法对项目很关键，项目经理更应该评估相应的风险并给予足够的准备，而案例中的项目经理很明显缺少这种预见性

综上所述，追求技术完美是每位负责任的技术人员的自然思维，当然聪明的程序员懂得在技术和进度之间平衡，而案例中的程序员只是不够聪明。另一方面，项目经理的管理工作存在很明显的缺位，而把这些过错完全推卸给他人更是不负责任：公司因此会对一位员工失去正确的评价，自己的管理水平也不可能提高。



brucesea 发表于2006-08-11 09:39:00 IP: 210.94.41.*
程序员的思维方式有时的确很奇怪。
可能是天天和代码打交道不和人打交道的结果吧。


iDeas wHizz 发表于2006-08-11 09:41:00 IP: 218.79.136.*
TrackBack来自《zz: 程序员的灯下黑：重知识轻技术》：

程序员的灯下黑：重知识轻技术


seeker 发表于2006-08-11 09:49:00 IP: 210.21.6.*
是呀,你说的太对了,虽然我从来不和别人争论是j2ee好,还是.net好.但是,我发觉我还是犯了你里面说的一个错误,就是太看重知识了.呵呵,不过,这也反应了一个国内这个行业的一个整体的风气.因为有很多公司,在拿到一个项目的时候,只要是现在流行的技术,他都用上.他从来不考虑应该用什么.这从某一个程序上讲也给国内的程序员增加了更多负担呀...


suxiaoguai 发表于2006-08-11 09:58:00 IP: 219.134.2.*

有的程序员员只适合忽悠人，不适合写项目。

其实他们也不是写不好，只是不想写好。

我很久就有你一样的感觉了，可跟你不一样，我不能写出这样的文章来来。

这同样就是“知识”与“技术”的区别吧。

写作，也是一门技术啊。


HOGNDONG 发表于2006-08-11 10:07:00 IP: 61.48.10.*
我也说点吧。

首先明确几个概念或者说问题吧。

这里面提到了这么几个东西：
人员角色：产品经理，项目经理，某程序员
成果分类：项目，程序

这样来看，若产品有问题那它的责任是“产品经理”而不应是“项目经理”，更不可能是“某程序员”

也就是产品出问题首先是你“产品经理”有问题，得去负这个责任;项目出问题当然是“项目经理”负这个责任了，而程序出 问题肯定是得“程序员”负这个责任了。

从上面这个例子所看，“产品经理”和“项目经理”在程序员交付这个时，他们还都不知道是做个什么，它会有些什么特性。 这显然问题已很明显了啊。

再往如说吧，文中作者也说到了一些现实中的活的干法。那说就说说盖楼吧，不能说按这个模式来进行啊：“产品经理”说我 要盖个大楼，好的他把这个命令下达给“项目经理”，“项目经理”领命后找一个或若干个砖瓦匠，对他们说你们都听好了， 我要盖个大楼，两个月完工，我要看到东西，你们现在就去整吧，否则拿你们是问。

呵呵，可笑不，我都想笑了。首先这个楼肯定是盖不起来的，当然被拿来是问的也成了那个“砖瓦匠”。

原来能力由上到下“产品经理”，“项目经理”，“砖瓦匠”的一个梯度，现在却变成了“砖瓦匠”的能力是最大的了，因为 他们事关大楼能否盖起来，或盖成什么样，盖出什么质量。

就这么多吧，问题已很清楚了，再说就多了。



bestread.cn 发表于2006-08-11 10:16:00 IP: 221.218.123.*
阅


cunruizhai 发表于2006-08-11 10:27:00 IP: 61.191.27.*
同意HOGNDONG和movingboy2关于责任的观点。责任不仅仅是程序员的，项目经理大有问题，PM也没有把事情定义清楚。但本文主题主要是针对程序员。

另外，不认为产品经理、项目经理和程序员是个能力从大到小个关系。他们是平等的主体。

删除了一些重复的帖子。CSDN的程序，唉。


brucesea 发表于2006-08-11 10:31:00 IP: 210.94.41.*
到底是程序员的问题还是项目经理的问题，
其实楼主只是虚构一个例子而已，可能例子欠妥，
但你知道人家的意思就可以了，
而且现实当中程序员也的确常常有此种问题。
在这上面讨论没有太大意思。

没把握总体思想就在细节狠下工夫，是不是也是程序员的思维方式呢。
谁让写代码错一个字符也不行呀。


十八哥 发表于2006-08-11 10:35:00 IP: 202.106.86.*
很多问题是在管理（技术管理）、设计方面出了问题，但是问题暴露出来是在程序员实现以后。
承担责任却只有下面做事的人。
不幸的是这样的问题几乎每天都在发生.....


tangl_99 发表于2006-08-11 11:14:00 IP: 218.88.41.*
到底是知识与技术的差别还是理论知识和实践技术的差别？
崇尚经验主义，实践主义，而忽略理论知识的指导，可能就连那10%都压缩不了。

"什么C++，Java，.net，什么STL，Struts，Spring"，这些也无非就是一些实践技术，实践工具而已。



qgq 发表于2006-08-11 11:33:00 IP: 200.50.36.*
看主题能够明白楼主想表达的意思,但楼主的文章确实有很多地方值得商榷,文章内容并不能站在一个公证的立场来阐释它的主题, 研究几个月啊,这几个月的时间项目经理没有做跟进么? 如是一个比较正规的公司最起码每周都要开个会,项目经理做一下跟进调查的, 我们这里要求程序员每天都要写一个工作总结不用太详细10分钟就好了,如果根据这个规章制度的话我就不信那个程序员 几个月的总结就是研究调查吧,每周的会议项目经理就没点建议?? 如果真是如楼主所说的情况的话干脆去做外包吧, 大家都省心,留个产品经理写个项目需求, 项目经理和程序员另求发展


yesmsn 发表于2006-08-11 11:37:00 IP: 218.244.111.*
www.yesmsn.cn


qgq 发表于2006-08-11 11:38:00 IP: 200.50.36.*
忘记补充了,中间还没有提到质检部门的事情

"这是不是软件公司里经常发生的情形？"
肯定的回答是这不是一个正规软件公司里应该发生的事情，


antliu 发表于2006-08-11 11:42:00 IP: 58.49.232.*
我从来不认为中国程序员缺乏的是技术，恰恰相反，他们缺乏的是知识。现在看来，软件业也缺乏知识，软件工程知识。


captainwh 发表于2006-08-11 11:46:00 IP: 218.27.72.*
撇开楼主的例子有偏颇之处不提， 现实中的确很多这样的程序员

这不我公司前阵就招了一个， 两年多vc经验， 谈起各种流行的技术来头头是道， 开始我还挺高兴， 以为总算能有个不错的帮手了

结果参加到项目中来才发现代码写的一塌糊涂， 简直是不能看

现在国内的确有重理论轻实践的趋势， 满天飞的是各种新奇的理论， 思想， 架构。。。
可是我们的程序员很多代码细节都处理不好

都说理论是基础， 但在我看来， 程序员不仅需要各种技术理论做基础， 同样也需要大量的代码实践， 这样才是扎实的基础


midthinker 发表于2006-08-11 12:55:00 IP: 218.1.190.*
我到以为，中国程序员更多的是重技术而不重知识，做事往往不求甚解，按巧合编程，程序恰巧可以运行了，就不再细究其原因，最后导致问题换了个模样又发生了，但程序员还以为又遇到了新问题。

上面的案例出在
1。约束上，约束没有描述清楚，听过且过。
2。任务成果没有及时回报，虽然看上去是一个任务，但却也做了好几个月，一个任务如果超过3天，则计划是必然的，并且在每个计划点结束时进行评审（评审可以仅仅是一个review，而无需搞的文山会海）
3。任何时候都应该交流，大多数时候需求约束不是立刻就能确定的，需要不断的去交流和提炼，但我不知道几个月的时间里，他们交流过几次？还是像求伯君时代一样，一个人在黑室蒙头解决问题？
4。职业素养，一个任务首要保证的是按时按质按量完成（让任务创造价值），第二位是个人经验与技能积累，但显然程序员有些本末倒置了，即使到最后任务完成都没有进行review，这不是一个职业程序员应有的态度。

归根结底是程序员职业技能的缺失，而不仅仅是技能的问题，企业的管理也存在很大的问题，一个任务就会造成如此多的误区，那么一个项目会怎么样呢？
@.@||~


Shawn 发表于2006-08-11 13:01:00 IP: 221.10.24.*
的确值得我们思考.


fdshenjia 发表于2006-08-11 13:02:00 IP: 218.1.127.*
纸上得来终绝浅，要知此事须躬行。
我做程序的体会。

楼上很多人谈什么项目经理，产品经理，程序员谁对谁错，离开了楼主所要表达的意思，就像文中的程序员一样，没有理解整个项目实际目标一样。


trd 发表于2006-08-11 13:06:00 IP: 221.224.47.*
楼主只是要说明这位程序员的动手能力不好。这又和知识与技术这两个笼统而又庞大的概念有什么关系呢？难道楼主是要说理论知识与实践经验？
技术本身就是一种知识，确切的说是一种通过实践中总结出的知识。
从实用的角度来说，这个程序员是失败的；从治学的角度说，这个程序员是成功的，因为他态度严谨。
软件编程首先是一门科学，其次是一门艺术。
如果要举例子来说明某个问题的话，就尽可能找一个没有什么漏洞和歧义的例子，因为你总不能要求每个人都去猜你的意思吧。


fdshenjia 发表于2006-08-11 13:08:00 IP: 218.1.127.*
纸上得来终绝浅，要知此事须躬行。
我做程序的体会。其实做任何事情都是这样的。

楼上很多人谈什么项目经理，产品经理，程序员谁对谁错，离开了楼主所要表达的意思，就像文中的程序员一样，没有理解整个项目实际目标一样。


rongren 发表于2006-08-11 13:20:00 IP: 218.247.0.*
HOGNDONG，说的有道理。
做为一个产品或项目的负责人不应将自己定位为一个官吧，而是应对你所做事情能负得起责任，并且有能力负起这个责任。这才是公司花比程序员高出很多倍价钱请你们来重要原因啊，单传个话谁不会，用不着花那么多钱吧。


figo 发表于2006-08-11 13:39:00 IP: 59.40.208.*
我感觉你们在讨论什么程序员，项目经理，产品经理各自的是与非，就象是程序员在讨论。NET与JAVA，阅完全部评论以后，我糊涂了，真不知谁讨论的对。


walker 发表于2006-08-11 14:05:00 IP: 222.66.34.*
迷茫，我想大部分都偏离了作者想要表达的意思.....虽然关于项目经理、产品经理、程序的责任也有一定的道理。


bucciarati 发表于2006-08-11 14:41:00 IP: 61.186.104.*
强烈同意！！！


Surge 发表于2006-08-11 14:43:00 IP: 220.165.193.*
程序员应该是知识与技术的结合。
只讲知识，不讲技术，等于只有理论，没有动手能力。


guangmingshizhe 发表于2006-08-11 14:49:00 IP: 58.56.38.*
的确，在我身上也存在这样的问题，知道不等于能够灵活运用组合出理想的产品，要想达到一个比较理想的境界，还需要很长时间的磨练