主题：【原创】一个程序员的自白 -- 荆棘探兴
“深挖洞，广积粮” 是眼下的策略。
就算在一个行业里面，每个公司用的工具、平台都不一样，手机的公司就是如此。因此换个公司也得有很长时间的适应过程。
当然了，如果你特别牛，就例外了。这个我是做不到了。
朝系统分析员这条路走，并不是说要一定要当个什么头目。
可惜现在单位一般没有系统分析员这个独立的职位，类似的工作都是项目经理来做。
后来再也没用过。
C才是王道。
严重同意，不送花不行
其实做程序员也没什么值得自豪的，全世界的工种都一样，我们也不必砖瓦匠要强多少，但是对于自己在做的事情，应该要看到里面的乐趣。
写程序其实比和人打交道舒服多了，至少我在前公司就没少和人事部的吵架。
后来发现在数据里面找自由真的很不错，虽然我还只能说入门。
写成了，特别是某些复杂算法的东西的成就感特别的好，上帝在第七天的心情估计和我一样吧。
后来再也没用过。
现在还是一线程序员。
basic都不教,饭特了.
俺也是C老程序员了,或者是老的C程序员,呵呵.
不过C一般应用不吃香啊,还是OOB/OOD,象.net, Java, C++应用面广.从list的职位比例就看出来了.
貌似很庞大，
这两天正在看别人的程序。
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聊天呢。
在实际中，更多的是中间类型，交给一个任务，然后在他不断问你，你不断提示中完成了，既不会象甲那样不动手，也不会当乙那么就自个去完成。这时，大家考察新员工最主要还是看他能不能记住已经教过的东西，这一点上真的可以看出重点院校和那些二流院校的区别，好学校出来的孩子一点就通，而某些学院毕业的人有时候真会让我们感到绝望。