主题：【原创】一个程序员的自白 -- 荆棘探兴
家园 有没有想过成为一个“天下谁人不识君”的人 所以跳槽并不一定是坏事。只要你技术能力强，人品好，总会有公司来挖你，换几个公司并不是坏事。呆在一个行业里，而不是一个公司里，也许会更加稳定。
家园 这个难度有点大。 “深挖洞，广积粮” 是眼下的策略。
就算在一个行业里面，每个公司用的工具、平台都不一样，手机的公司就是如此。因此换个公司也得有很长时间的适应过程。
当然了，如果你特别牛，就例外了。这个我是做不到了。
家园 你还没有参透。只有那个唯一的乐趣就是整天编码的大牛参透了。 在温饱解决之后，一个人工作的意义是什么？
不停地往上爬、不断地挣更多的钱，永远没有尽头。。。
只有自得其乐的那个大牛，才领会了人生的乐趣。
当你变得很老很老的时候，你可以说，我这辈子都在做我喜欢做的事情，活得的很过瘾。
不要到了那时候才说，我这辈子都在不得不做很多不喜欢的事情，像一只野狼一样不停地与别的狼只争夺羊肉----除非你喜欢的就是不断地竞争和征服。
家园 40岁的程序员是很少 不过关键的问题是.从中国有正式的计算机产业到现在,那时做编程的人,现在还没到40岁.从90年算起吧,在此之前开始做编程的,学什么的都有,就是没有学计算机的(自动化倒是有一批,但说实在话,还是不一样).
在国内，甚至在IT的理论界都有这种论调，意思是编程不如设计，于是一大帮还不知道程序如何编的菜鸟们就去做设计了，当然还有更大的一批所谓业务专家，根本没编过程序也去做设计了。所以真正的好程序员十分稀少，甚至有人把编程视为一种艺术。
其实程序员分为系统工具级程序员和应用级程序员，应用级程序员不需要太多能力，只要拿到模块按流程编就行了，而系统级程序员，是做工具平台，做出的程序是给应用级程序员来用的。则不但要熟悉相关的专业，对于IT的几门课也需要有十分深的研究（比如数值分析、数据结构、离散数学、计算机原理这几门课）。工具平台级的软件，很难象应用软件那样划分出十分细节的流程，因此有时候编程比设计还重要。
如果你做到系统级程序员，那么其实这条路就可以一直走下去，不需要转什么行了。编程中的乐趣还是十分强的，经常可以做出来一些工具程序，过去需要十几个人做一个月的工作量，现在只要一个人花半个月就能完成，而且以后所有这方面的工作全都简省了，这种成就感那是什么也比不上的。而且，你根本就不用考虑前程，此时，钱财是你的工作的副产品。
测试一个程序员的能力，有个简单的作法，能不能独立写出一个算术计算的程序，就是输入一个算式字符串（比如13+25或者3*5+4/2这样的），然后解析出来，生成结果。基本上国内的程序员，大多数是做不出来的。作为应用级的程序员也不需要做出来，但是系统级程序员，这个却只是一个基础。
家园 比如13+25或者3*5+4/2这样的 基本的入栈出栈的操作
不知道为什么很多人不会
家园 您说的俺不赞同 1. 我大学时代一些老师跟我描述他们当年的编程生涯，怎么使用打孔纸带来写程序，大部分发生在7，80年代。 你说的这个时间，至少要推到70年代。我大学实习时接触的pdp系统，软件开发也都是在80年代完成的，以前上班的地方，一些老家伙也都是80年代就开始从事开发工作的人。 只能说进入90年代以后，硅谷游戏的崛起加速了这个过程。至于硬件方面，80年代中期以前，国内半导体研究的地位其实要比现在高。
2.那个判别方法有点搞笑了， 基本只是一个科班学生的编译原理的一个小作业而已。一般工科学生，解决这个问题也很简单。而且说句笑话，对于函数式语言，或者目前众多主流语言都提供了lambda的支持的情况下，就是一句话而已。 记得以前做开发培训的时候，就拿这个做课堂作业，限时1，2个小时，大部分人也不觉得有难度。
3. 对你对应用程序员的看法不是很苟同吧。 其实应用程序员对算法，对计算机系统的理解也很重要，只不过这个重要在工作价值体现的点不同，更多的会体现在宏观上和解决问题的能力上。同样是做应用级别的编程，我接触不同程序员的代码长度可以相差近10倍，由此导致的质量和工作效率的差别就是大问题了。应用级别的编程，因为受限于条件，对程序员的算法能力要求是必须的，比如c++的标准库中已经自带了一些基本算法，而早期java,vb这类高级语言其实是没有的，为了数据的显示格式问题，就需要自己来实现排序算法。我的经验也表明，程序员对基本算法的理解程度和他解决问题的能力，对业务知识的领会能力是有直接线性关系的。 对算法的理解掌握过程就是一个思维训练过程，是否经历过这个过程的人，解决问题的能力是有差别的。相当一部分应用程序员转行，或者被公司所抛弃，本质上还是因为基础的问题。
那种误以为应用程序员只要熟悉业务，不需要懂多少技术的看法，其实是很多软件项目失败的深层次原因之一。
软件开发门槛低是没错，但是入了门以后往后走，要做好必须学的东西一点都不少，基础还是关键。
这个问题其实是以前我和顾教授争论的一个本质，计算机系统和工具的进步在我看来只是降低了门槛，但是并没有降低对从业人员的要求，应用级别的程序员现在不得不面临比传统程序员更多的复杂性，不仅仅是需求方面，技术的过度发展也导致了整个体系的复杂性增加，这些对人的要求都只会越来越高。比如15年前写点dbase，画几个窗口就很容易混口饭吃，现在你只会干这个，连汤都没的喝。做系统的，可能只需要精通c/c++和1，2种脚本就够了，而做应用的，要学习东西的广度就大了去，没有好的基础，这种持续学习的过程是很难坚持下来的。
现在国内一些大学，包括东北大学，武汉大学这样的学校，居然在本科阶段取消了数据结构的课程，简直是本末倒置。
- 复 您说的俺不赞同
家园 武大这么牛？ 有点不相信 不会是某些民办学院吧？
或者某些凑热闹的专业!
- 复 您说的俺不赞同
家园 计算机系本科不学数据结构和算法，不是搞笑吧，扩招都扩成这样了？ - 复 您说的俺不赞同
家园 工作经验不同呀. 一直都是负责技术队伍的组建,并且培养研发团队的工作.以上所写都是工作中的体会.也许经历不一样,感受就不一样.
不同的学校会有不同的经历。比如计算机系，有的是从自动化系分出去的，有的是从电子系或者数学系分出去的，这就决定了这个系的师资力量的构成。老家伙有他们的常项，比如汇编或者电路，但是很多的老家伙们确实对于如何编写高级语言十分陌生，特别是那些教本科生的。
而由这些老师所教的毕业生的水平是有目共睹的。对于公司而言，所有的新毕业生（包括硕士生）在一年之内（一般是三个月集中培训期，然后进入项目组）都只是培养对象，而不是为公司创造价值的员工。对他们的评价就是资质如何，可培养或者不可培养。
关于那个算术运算的程序。公司里大部分的程序员都不可能独立完成这个程序,甚至根本就没有对这种程序的认识。这不是一个小算法的事,如果你试着自己独立做,就会知道了,比如用C,里面涉及到指针,多层嵌套,迭代甚至会用到递归.按照道理来说,本科学完数据结构和编译原理之后,这个东西就能做出来,但从多少年经历来看,似乎没有几个人能够达到要求.
实际上在选拔好的苗子时，也不会用这个程序，测试是要分出高低的，如果谁都不会做那还分什么。
应用程序员和系统程序员的分法,你可以在《thinking in C++》中看到.当然这种理论估计也不是谁发明的,而是对很多公司已经存在的现象的一种总结.
系统程序员可不是指那些纯技术不懂业务的人.公司的开发平台是在对业务经验抽象总结的基础上完成的,让不懂业务的人来做,那是搞笑的事情.系统程序员是具有十分丰富行业经验,同时又对计算机技术十分精通的人.上面的算法就是用来测试一个人的计算机编程的能力的.
在实际的公司技术体系中,两年以内的程序员是不分体系的,一般都称为工程师,而两年之后,就开始分技术经理和项目经理体系.不论是技术经理还是项目经理,都具有业务经验.项目经理负责项目的实施,技术经理负责产品的研发,在大的项目中,除了项目经理,还会设系统架构师,系统架构师就是由技术经理担当.
有两年到三年项目经验,业务知识就会达到一定水平,可以担当项目经理,而技术经理则是指在实际工作中公认的编程水平高的人中选择.公司的开发平台或工具则是由技术经理中那些不但编程好,而且对于系统和算法都有相当精通程度的人来担当.这些人实际上就是我前面曾经提到的超级员工.
软件的门槛没有降低,只是现在能完成的功能比以前要强大多了，也简单很多了。举个例子，十几年前，在DOS时代，你写个菜单程序就算很牛，但是现在，这个根本就不需要你写，因为所有的开发工具都带，这就是工具的威力。但是程序员要了解的东西反而多了，以前也许只要懂基本语法就行了，就现在的工作经历而言,JAVA所要了解的东西比之C要多很多.
取消数据结构这门课，就是所谓的“软件蓝领”这一概念给闹的。好的国家不学，去学印度，学印度也就罢了，不去全面了解别人的软件工程经验，只去羡慕别人的最低层程序员是除了根据设计编代码外其它什么都不会因此成本也十分便宜的“软件蓝领”。然后，学了几年，才发现，还是被阿三给涮了。
- 复 工作经验不同呀.
家园 呵呵，体制不同吧 我们工作性质应该类似吧，我以前从事的行业对it技术应用的要求不会比银行业低，在国内算新技术应用最多，要求最高的行业之一了。银行那种环境我也有所了解，以前给某银行开发中心做过私底下的咨询，发现技术人员胆子都太小，学新东西畏惧心理严重。对比起来，我们最多就是集中培训1个月，而且是以做mini项目为主的培训，然后直接投到项目中去学习，一般3个月左右，已经也必须可以为项目创造价值了。
我不是开玩笑，那个东西，确实就是一般工作中就会做的，也必须会做的，比如sql的语法检查，就比这个还复杂一点。 而java语言的基础培训课上那个就是一个课堂作业来着（计算器，中缀转前缀）， 我手下大部分刚毕业的人给点提示都基本有能力做出来。对一个智力正常的本科生来说，做不做的出来的关键是有没有这个决心和想法要去做而已。
我曾经带过的2个1年左右经验的小朋友，当时交待甲去做一个sql的部分语法检查算法，甲说不懂，化了2个小时把思路讲给他，过了2天再问，还是说不懂，丫就化时间在看别人的代码，不肯动手做，总觉得难，折腾了1星期烦了，换人。 换了甲不太看得起的乙，然后乙同学一上来根本不要听我讲思路，直接跑去找了本书就开做了，折腾了一个星期交出一个蛮复杂的实现，基本能跑，有点小bug。里面一堆转置矩阵，换算之类的，我看不太懂，化了2个小时重写了扔给他看，他看了一下就哦了一下，说原来这么简单呀，我想复杂了。小伙子后来工作一直都不错，比那个只说不干的甲强多了，关键是敢干。
象这种类似的语法检查和一些自定义的规则运算，在我们做的业务系统里是相当常见的工作，早期缺少脚本引擎和类似antlr这样语法解析工具的时候，熟悉编译原理固然有优势， 完全不懂自己土法实现，按2，8原则分解以后也不是什么难事，关键还是心态。给一个星期时间，做不出来下岗，我看80%以上都没问题。
- 复 呵呵，体制不同吧
家园 经历决定观点，不过倒也相差不大 银行的人不是胆小,也不是对学新东西畏惧,而是根本就不想去学.人呀,如果太安逸了,就没有动力了.没有生存压力，每天晚上和朋友泡BAR、唱K可比学习有意思多了。
在我看来，一个人能不能优秀的关键除了素质，还有一个就是是否努力工作。很多人做IT这份工作只是为了挣一分糊口钱而已,对于他们,是编程序或者是开汽车,其实都无所谓.这就是一份能让他生活的工作.象这种算法,只要好好学习,怎么可能做不出来呢.即使自己开始做不出来,拿一个例子来看,看懂了不就可以了.但是问题就在于又有几个人真把学习当回事.
我觉得,对于IT行业,如果你不把它作为兴趣爱好,根本就干不好.公司的好处是你不学,工作也会逼你学.想了一下，金融IT更多是对业务流程的实现，难点在于业务的掌握，对于算法确实涉及很少。在公司的日常编程工作中很少遇到,因此只有那些将计算机当作爱好,并且喜欢琢磨的人才会去做.
你教人可够精细的,在我们对新生的培养体系中,三个月试用期也是观察期.在完成公司正式培训后,就会将新人分到各产品体系中,然后由老人进行传帮带，在这一过程中，会进行初级的业务知识和产品知识的培训。
可能金融类IT的工作方式和你们的不太一样,出差做项目是一种基础也是主要的工作,而在家里做研发的人则是很少一部分.也只有在项目里，才能和客户接触，并且对业务知识有比较深入的了解。因此金融公司的员工，业务和技术实际是在项目中同步成长起来的。
在这一过程中，就会区分出不同的员工了。甲和乙真是很典型，可以说是两个极端。
可能你出的题有些难了，由任何角度来看，乙都是很出色的新人，独立解决问题的能力，独立查询新知识的能力，独立思考的能力，除了对老前辈有些态度不好之外，我看不出他有什么缺点。这样的新人，很难得。
而甲则是另一个极端。这种所谓只看程序不编程序的工作方式，从另一重理解就是这位老兄大概一直在给你装样子，你来了他就在看程序，你走了他还不知道是在玩游戏或者QQ聊天呢。
在实际中，更多的是中间类型，交给一个任务，然后在他不断问你，你不断提示中完成了，既不会象甲那样不动手，也不会当乙那么就自个去完成。这时，大家考察新员工最主要还是看他能不能记住已经教过的东西，这一点上真的可以看出重点院校和那些二流院校的区别，好学校出来的孩子一点就通，而某些学院毕业的人有时候真会让我们感到绝望。
家园 还是体制问题么 至少我以前工作的环境，你说的上班qq，游戏之类的人还是没有的，大家都还是向往前走，都渴望多学习东西。甲只不过心态不正确而已，没有打通那种畏难心理，期望c&c能解决问题，后来换了个公司从头开始后来做的还不错，不过也只能so so了。乙也只是个二本，谈不上优秀，只能说是中等而已，后来转行做了销售。
我们的业务知识也未必比金融行业简单，也主要是玩的流程和规则。我们的分歧在于解决问题的思路差异，技术上有基础的，可以通过技术来解决推动业务的问题， 而技术上比较弱，就只能通过工作量来弥补了。和金融行业不一样的是，我们处理的这些流程和规则变动非常大，逼迫你不能单纯从工作量上去解决问题，所以你说的那种简单的应用程序员对我们来说是不存在的，或者说我们的要求必须更好一些，业务人员对技术的理解程度对工作量的变化影响是非常大的，业务越复杂，对人的能力要求就越高。玩技术就是一个坎，你能过了，就说明你的综合能力到了一个什么样的水平。
有个前同事也进入了金融业一家知名的it公司，他个人的感觉是在技术应用上，在开发管理上，几乎差了5，6年的距离，这里面的核心还是垄断行业带来的体制问题. 金融业利润高，自然就不需要逼迫内部挖潜来解决问题。
从成本上算，一个熟悉业务，技术下等的程序员，其工作效率可能只是一个比较熟悉业务， 技术中等的程序员几分之一甚至十分之一而已，而从时间上看一个技术中等的程序员学习业务的能力总是要强过一个技术下等的程序员的。又不是高精尖的航天科技，这点码代码的技术都玩不过，就一定能学好业务么？ 应用程序员，其实应该至少具备中等的技术能力，我一个朋友的原则则是派最好的技术人员去做业务。我以前公司的研发部门的同事，平均水平要低于我那个项目组，当然这算个特例了。
其实我们的开发管理架构类似，也是技术经理+项目经理的模式，成员也是技术+业务的组建和培养模式。事实是，我以前那些同事里精通业务的，技术一般都是中等以上。 那些所谓精通业务不怎么懂技术的人也不是没有，但是其实在我的看法里，他们的所谓精通都只是点上面的，缺少技术背景让他们很难融会贯通起来，因为任何信息系统的建设都是一个业务管理模式的重构而不是对原有模型的简单计算机拷贝，这需要业务人员必须对计算机应用技术也有一定深度的了解。
我和一个项目经理有过很不愉快的合作经历，他就是那种只碰业务技术很差的人，她不明白，所以她没能力引导程序员或者客户去完成这种重构工作，提出来的很多需求都是无意义的，唯一的优点是文档写的漂亮，我曾经检查以后取消了她一个2个月的开发计划，因为这些流程其实经过适当的调整和已经开发完毕的流程完全是一样的， 只是因为他看不明白又和程序员讲不清楚而已。后来离职的时候还抱怨我们不重视业务需求，只看重技术。
我大学读的是商学院，经管类专业的教育很看重计算机技术的应用，尤其是投资，会计相关的专业，很多代码高手就是这块的，我认识很多程序员都是商学院出身，这还是有传统的。
- 复 还是体制问题么
家园 呵呵,金融IT企业中有核心技术的公司少的很 看来应该换一个行业来做一做,不知道您是什么行业的.就你介绍的行业情况,看来金融行业的开发模式确实很有问题,有些也是条件所限,很难解决.这个行业出差的问题现在成了人才培养中最大的坎,常年出差,使得很多资深人士离开这个行业.十年来的技术积累几乎原地踏步.
就IT的本质而言,通过抽象形成模式,即通过所谓的模式设计来完成系统的构造，是一个理想模式.可惜就金融行业的实际而言,我们看到的是大量针对业务的直接编程,可以说就是简单的业务流程的堆砌,其中只有很少量的复用.不过这样的好处倒也有,就是每一个程序看着都是直肠子,比较容易看懂.
金融行业IT的利很厚,不过IT公司倒不存在垄断,竟争也很激烈,一个项目十几个公司争十分正常。就金融IT公司里面,除了极少数懂业务又懂技术的人外,大量地是对程序设计一直半解的人.比如编C语言的搞不清楚指针（如果取消了数据结构这门课，估计这样的人就更多了），这种现象十分常见.
金融IT行业，由于大部分人都是分散在项目中，因此无法形成有效的公司级资源，也就没有所谓的个人成长计划和组织成长计划，这种后果就是可以有很多熟悉业务的人（因为有客户业务人员交流），但是技术却提高很少，没有人带，基本都是自己琢磨。
你最后所说的那个项目经理的情况，在金融行业是一个比较普遍现象，如果在你的行业只是特例，这个真是让人羡慕。