工作渐渐展开之后，就是平静如水的生活，每天上班，吃饭，睡觉，日子也过得很快。刚开始，由于懂得东西少，所以每次任务下来后，都是积极的去完成，因为害怕自己做不完。但是渐渐的，当自己清楚该怎么做的时候，人会产生疲倦，因为每天都做一些差不多的劳动。慢慢的，做事情就喜欢拖拉了。当分配一个任务后，自己先估量一下这个工作自己大概需要多久，一般老板给的时间会多很多。所以喜欢把工作先放着，去看看网页，逛逛论坛什么的，等到剩下的时间差不多了，需要开始工作了，就懒洋洋的进入工作状态，但是往往完成工作质量都不怎么好，很多提交后会有些BUG。不过我也没怎么在意。因为和老板关系好嘛，像我这样，再怎么说也属于元老级别的。就这样慢慢的工作了几年。因为小公司什么都要做，技术也积累了很多。包括各种主流数据库的用法，。NET，CSS,JAVASCRIPT,PHP,JAVA,perl,FLASH, 等等，其间，自己独立开发项目的时候，总想找出一种架构，加快自己下一个项目的开发进度。但是每次开发完后，发现上次设计的架构真垃圾。开发过很多项目，每次都想了一些新的架构方法。到现在沉淀下来的还值得用的架构思想也没多少。记得在做JSP的时候，感觉JSP里面服务端代码和HTML混在一起，很难看。不如。NET的事件驱动好用。就去写个模块，让JSP也实现事件驱动的模式。结果写到后来，也没得到什么好处，并且感觉有点不伦不类，后来项目慢慢做大了，才渐渐明白面向对象的用意。当一个项目很小，逻辑很简单的时候，用面向对象的方法设计用处不大，反倒是组件用处更大。因为项目小，基本上都是建几张表，改改HTML的工作。但是项目一大，逻辑变复杂了，如果你要理清楚逻辑，这里就需要一种方法论。我一开始写算法的那种方法有点不适用了。原来那种是从顶层开始，向下细分。是一种至上而下的设计方法。而面向对象不是，它是一种由点及面的设计方法。面向对象是先找出一个个对象点，然后再找出每个点之间的关系。在实际的项目中，你很难从上至下的设计。因为项目需求往往刚开始很不全面，很多项目后来改得都是面目全非。从上至下的设计不适合这种平凡的修改。并且当需求很大时，他涉及东西太多，你也很难从一个俯视的角度去全面的看这个系统。所以从上至下的设计不能满足要求。打个比方，记得一个项目已经做了80%，结果客户觉得用得不方便，要改一下。很多原来做的功能都不需要，并且提了几个新功能。但这几个功能也只是对原来的功能稍加改动。但是逻辑上看却是大相径庭。人脑不是电脑，如果想着这个代码，去改那个代码，势必到后来让自己也搞糊涂了。所以需要抽象出几个对象出来，是按照客户的思维方式。然后抽象出来的对象里面包含原来的功能。这样做起来就事半功倍。
在工作的磨练中，慢慢的发现了普通的程序员与优秀的程序员的一些差别：
1, 普通的程序员遇到问题喜欢张口就问别人，问之前没经过大脑想想。这是一个不好的习惯。其一，自己都没仔细想想，就算别人帮你把问题解决了，你自己不多久就会忘记。下次遇到，照样是不会。因为这个问题你没有经过大脑。其二，能够回答你问题的人，多半是有一定经验了。他们或许很会安排好自己的事情，管理好自己的时间。如果时常去打断他们，他们会觉得你很烦。
优秀的程序员多半会先到网上查找一下相关问题，看看网上有没有相关解决方法。经过一翻查找，他会把这个问题记得比较牢。
2，在一个项目的合作开发中，普通程序员往往只了解自己开发那方面的东西。项目做完后往往对整个项目有哪些功能都不太清楚。可能会有人抱怨，自己工作都做不完，哪有时间去了解整个系统。但现实多半是，花大量的时间去网上闲逛，却不愿花时间去增进知识。 如果总认为项目的设计是设计者的工作，自己没必要去了解。那么这样的程序员只能是手工劳动者。
优秀的程序员会对整个项目有认识，对一些自己感兴趣的功能会去做一下了解，更优秀一点的，会去对整个项目的架构设计做一下了解。自问如果他是项目设计者该怎么做？ 去学习项目设计的优秀之处，去发现设计的不足之处。触类旁通，把优秀的地方用在自己将来的工作当中。
3，普通程序员往往有很大的惰性。不能自觉的去学习知识，增进能力。所以每天耗费大量的时间在一些消遣状态中。所以时间往往白白的浪费掉。
优秀的程序员往往会安排好自己的工作和学习。在工作中学习，在学习中工作。能够感觉到自己每天都向着自己的目标在前进，状态佳，动力足。他们因为每天工作情绪很高，所以研究的东西也多，时间比较宝贵。因此他们会善于利用一些工具来操作自己的电脑，大大来的减少琐碎的电脑操作时间。更有胜者，会开发一些符合自己的操作习惯的小程序，来提高自己的效率。说不定这些小程序放到网上共享，可能还会有意想不到的收获。
我现在做项目管理，看着手下的程序员，时常也让我想起原来做程序员时候的坏毛病。比如，上班迟到啊，工作时间上网闲逛啊，交上来的程序BUG成堆啊！看到这些，我时常都是会心的笑笑，可以理解！ 不过我也时常提醒他们，如果你们想将来成为IT界的精英，而不是等到30岁感觉自己无路可走，那么请你们珍惜自己的时间。如果你们自己都不珍惜自己的时间，那么别人更不会去珍惜你的时间。
今天花了两个多小时，写了一篇短篇自叙。感觉值得，把自己五年多的光阴回顾了一遍。从前的故事历历在目。写下来过五年后再来回顾一下，说不定会是另一番感受。
扩展阅读
1.从程序员到PM,是一条脱变的路，事实上程序员走的路最终不应该是项目经理。首先有一点需要明白的就是，一定规模的项目中，项目经理不需要太懂技术，他可以是一知半解。项目经理的任务不是在技术方面，技术相关的应该交给SA去做。项目经理更多地是做管理，沟通等工作，你如果可以的话到书店查看一下关于项目管理的书籍，你就会明白。当然对于小项目来说，有可能是PM,SA是同一个人，而这样的项目经理更多只是SA加上一些管理工作。要做项目经理，你就首先告诉自己不再去碰技术细节了。程序员并不是一个培养项目经理的好环境。所以没有什么从Coder到什么developer再到SA然后是PM的路，这是一条比较悲哀的路。在大公司，SA下一个目标不是PM,而consultant,然后是seniorconsultant,PM走的是另一条路，所需要的技能不是技术，技术给PM带来的能力提升是很少的。在项目中你最后能分清楚PM与SA的关系及各自在项目中的分工与用途。
2.其实我蛮同意gzlucky（Lucky）的看法的，确实是我们公司不少项经理就是不很能跟得上现在的一些技术，因为很多人都快年近四十，儿子都上高中了，要他们再学新技术真的难度比较大，他们的工作基本上就是天天找手下的程序员，布置这个任务，询问那个任务做的怎么样了。不过我的头倒是和我一样编程，他手下写代码的就我一个人，他自己也会ASP和JSP,但是可能对。NET不熟，就由我来主负责了。我觉得项目经理还是像他这样的好，自己也能懂不少技术，可以服人。但是我的头儿好像在沟通这一块不是非常出色，当然也有可能是俺太内向，不太与他沟通，所以他也只是在交待任务后就不再多询问，而不像别的项目经理天天追程序员后头问。我想问问各位，你们看哪种项目经理才是比较好的，像我的头儿这样的，还是像某些喜欢追程序员后面问进展的。
3.原来在一个小公司做过半年的DM,一年的PM,后来为了让自己的技术更扎实一些，离开了原来公司，现在在大公司做程序员，开始后悔了，在大公司里很难接触管理方面的东西，也很难晋升，个人认为在小公司做DM,PM,有经验后直接找大公司的PM,这样也是一条路。
或者考PMP之类的证书，然后直接找管理的工作。
希望过来人能给予更好的意见和建议，我也现在想往管理层发展。
技术很硬了再去做PM,这种想法是错误的，我就犯了这个错，边搞好技术（为了生计）边学管理知识（为了将来）,慢慢向管理发展，不能等。有句话说的好，机会是属于那些有准备的人的。利用业余时间多学些管理方面的东西，所谓人的差异在业余时间。
要走向管理层，英语一定要学好。
沟通很重要，要做好管理者，先学会做人。多跟下属沟通，多为下属着想，而不要去巴解讨好上司。体谅下属，把项目计划做的尽量合理，不要让下属加班，给下属发展和晋升的空间，这样才能是下属有干劲，才能把项目做好，你才有更高的升迁机会。
只有把自己知道的不断的让你得力下属知道，只有提拔起一些得力的下属来，你才有时间和精力去向上爬，不然你抱着不放，就没有升迁的机会。
管理不是喝酒抽烟那么简单，那只是过去的那种不思上进，耽误自己前程。
吃尽苦中苦，方为人上人。
做PM不是混，是要把项目做好，这跟做人是一个道理，这也就是为什么做管理要先学会做人的道理。
pm的整个工作重点是什么？如果做为一个PM,技术不高怎么对付组里的牛人
我们经常会因为公司里的顶尖人才、个性化太强，不能与其他人合作而感到棘手，要解决这一问题其实也是有法可寻的。
一、在肯定其价值和优势的前提下，明确地制定改进的目标；
二、顶尖人才能够面对中肯的，明确及一对一的批评作正面反应，所以要加强与他沟通的力度；
三、可以根据具体情况调整考核目标，加强与其他员工合作的内容；
四、把顶尖人才调到相对能独立发挥其才能的岗位，减少与别人发生矛盾的机会。
当时看算法本身的文档，然后又回头看线性代数，终于理解了算法，并用程序表达了出来。由于是嵌入式用的，又花了大量时间进行算法优化。
后来跳槽时终于尝到甜头：
１。薪水高，基本上一应聘就是Senior的职位
２。稳定，这个一般大街上招一个程序员是做不来的
３。机会多，这个怎么说呢，反正只要是大公司招人，象微软、Google等，除了问一些语言本身的问题外，基本上就是算法和数据结构的问题。
通常面试那些时间你写源代码是来不及的，基本上就是写伪代码。或说明你的算法基础和思路。答的好一两句话就解决了。
想走这条路的朋友，我首先建议好好读读《数据结构与算法：C++版》，里面所有常用算法和经典算法及数据结构必须烂熟。其次，建议将大学课本找回来，几本高数好好复习复习。《线性代数》《概率和数理统计》《微积分》《常微分》等等。
我们不是大牛，基本上创造不出新算法，但是我们能够将别人的算法实现或者能把一个具体问题分解成已知的算法，那么你就是一个很不错的算法工程师了。
说实在话，语言只是工具，是很容易掌握的。99年2000年泡沫时期，不是很多人突击那么三个月就可以上路做programmer么。就象刀法是很容易学会的。要应用精熟，也不过是长时间的积累而已。
对语言的理解实际上就是对刀法的领悟，有人是顿悟。但是多用总是会渐悟的。
最重要的是基础，就是数学能力，那可是内功。可以这样说，你要想真正和其他程序员拉来差距就在这里。
我朋友的孩子想走计算机编程这条路，考大学我就推荐考数学系！
再有就是多做那些大公司的面试题，一是锻炼自己的大脑，二是熟悉这些算法的应用。
好了，现在能想到的就这几点，这里给几个面试的例子，看看能不能用最简单的描述解答
1.如何生成一组正态分布的随机数？
2.有一个二维迷宫，如何找到出口路径？
3.有数据库存储一股票每五分钟的实时报价，如何生成每小时，每天，每周的股票价格变动曲线？
====我的建议答案
１。生成二维随机数，只取落在正态分布包络线内的数
２。二维连通图深度优先遍历
３。傅利叶变换
第三部分，未来职业生涯规划、家庭环境分析、例如经济状况，家人期望等。感谢您阅读《大项目、小项目都是程序员成熟之道[2]》内容，职场资讯网小编向您推荐一些职业规划知识，欢迎参考，希望能帮到你。
而我今天说的项目大小是从软件项目本身来确定的，与客户对项目大小的定义没有什么太大的关系。我认为项目大小可以从以下几个维度去考虑：资金、开发人月、项目复杂度。
1、 资金
我认为在当今物价状态下，5万以上50万以下为小项目。50万以上为大项目，500万以上为特大项目。
2、 开发人月
同理，2.5个人月到25个人月以下为小项目。25个人月以上为大项目。
3、 项目复杂度
软件项目的复杂度还可以用软件的用户使用人数、数据库中表的数量、表的记录数来衡量：
软件使用人数：10-1000人为小项目，1000人以上为大项目。
数据库表的数量：20-100张为小项目，100张以上为大项目。
表中的记录数：10万-1000万为小项目，1000万以上为大项目。
此外，项目运行能够给客户带来的收益大小、项目的业务逻辑的复杂度都可以成为项目大小考量的内容。
如果项目都不能达到小项目的水平，我们这里就不把它看作项目了，因为低于小项目的项目很多是个人编程，这与项目众人参与的特点有点不符。
所以我对程序员的建议是：
1、 要主动参加项目
无论大项目还是小项目程序员都要努力参加进去，因为只有做了项目自己的能力才能提高。不要静静待在那里，等待别人挑选，而是积极主动表示加入项目的愿望。在我负责过的项目过程中，我对主动要求加入项目的程序员往往给与更多的机会，因为这样的程序员具有主动性，工作更好开展。一个项目的出现就是一个机会的出现，把握项目就是把握机会。机不可失，时不在来。
2、 不要放过小项目
程序员不要以小而不为，只有做过若干个小的项目后，程序员才能去做大项目。那些想一步就做大项目的程序员，往往会失去小项目锻炼的机会，往往参加到大项目后，感到力不从心。项目虽小也同样可以锻炼人，程序员可以有更多机会体验项目负责人的脚色。学会从整体角度上来看待编程。
3、 要积极准备参加大项目
对于已参加过小项目的程序员，一定要把握机会，积极准备参加大项目，项目越大，越锻炼人。在大项目中要学会摆正自己的位置、虚心向团队其他成员学习。要在平时没有项目的时候，要多做些技术准备，多关注可能的大项目开发内容。在项目开发中，则可以把重点放在体会不同功能模块之间的关系上。学会从关联的角度上看待编程。
根据我的经验，我认为程序员要经过5-6个小项目的锻炼才能入门，而经历了3个以上的大项目的程序员才开始成熟。当然我们不能排除程序员的天才成分，有的程序员会再很短的时间达到一个很高的水平。但是，绝大多数程序员成长是必须通过项目来催化的，尤其是大的项目催化更加重要。说白了，项目如同阳光，程序员如同禾苗，关系就是那么简单。
今天，根据自己的体会，我来谈谈项目经理的初始化阶段。
新人工作一段时间后，或长或短，可能一至两年后，有可能出任项目经理。此时，考验你能力的时候真正来临。项目分很多类，如基础研究项目，大型综合性项目。这里我们选取小的商业应用型项目为例。
刚开始，我们是没什么经验的，好在有热情。但这是项目，是一个讲究人与人之间配合的技巧性的活，光靠热情是难以持久的。退一步说，你是能力很强的聪慧之人，什么都拿得起放得下，那你充其量只是个精兵，而不是一个好的管理者。管理者的目标让整个组织的效率更高，管理者是没有那么多时间老是冲锋在前的，请深刻体会这一点。 因此我们得掌握一些基本的技术，讲究一些策略，力求避免未做勇士，先做烈士。
需要先补的课程是，项目的三要素：时间、成本、范围。
第一：时间
如果三峡项目做得很漂亮，质量很高，专家也很满意，惟一不足的是项目比预期推迟了两年半，那么这个项目的考评可能从A+会直降到C-甚至D-。因为这样一个大项目群，耽误一天便产生数以亿计的成本损耗。我们的项目虽然小，但道理是相通的。所以在执行项目之前。项目的时间至关重要。
客户有个时间表，老板有个预期的时间表，每个项目成员都有个时间表，作为项目经理，必须把这些协调起来，达成一个各方满意的结果、按照利益相关方的优先级别排序。这里有个分析的小技巧：请注意，老板说是下月底完工，你得有两手准备。一方面：alpha版一定要在下月上旬先给老板看下，给他一个初步印象，避免到时心里落差过大，情绪失控，万一有错，也来得及修正。另一方面，不要做得太细太完善，既浪费时间，又不给领导提意见的空间，领导只会怪你不会做事。于是，你得留一些简单的易于完成的小破绽给领导。是不是很委琐？！我相信这 样做，对项目组有利。当然，看具体的人，看性格。
第二：成本
项目花下去多少成本，预算时要心中有数。多大的西瓜多大的秤。这个成本包括时间成本、人力成本、费用成本等。在项目中间要勤计算挣值 。这是一个很关键的指标。投入与产出必须有一定的正相关系数关系。人有多大胆，地有多大产的教训在我身上太深刻了，记住，什么事都不要拍脑门，项目中没有任何板上钉钉的事，特别在公开会议上，要控制自己的情绪和言行。 有时候，一时不必要的斗气，让项目成员苦不堪言。
第三：范围
有了时间、成本的到位分析。范围就是一件简单的事了，简单的说，范围就是项目需要完成的程度。时间长、成本允许，可以内外兼修，各环节都做得漂亮，各方满意，自己也挺有成就。这是理想中的理想，基本上在实际中属于空想的范畴。所以，如何控制好范围，而又保持好项目成员的积极性，是一门学问，水很深哪！项目经理的一个基本观念是：项目是独立核算的，项目的考评是本项目完成到什么程度，而不是为了别的项目组或者为了下一次项目做了多少。如果这个项目可能为了别的项目组做出一些牺牲或额外努力，请尽量避免！如果必须得做，也需要在项目组 会议上言明，为自己项目组争取既得的回报，不一定非得物质的，比如领导的心知肚明，客户的理解和感激等，这些会帮你加分。千万不要偷偷摸摸的干，把项目成员的暗中努力不当回事，我是雷锋我怕谁已经不能用来唬人了，这是个讲究科学、兼顾效益的商业社会。
有人会问，在这三者冲突的情况下，如何取舍。建议很明确：先砍功能，也就是范围，把一些能推到项目二期的先往后推，向范围要时间。所以，在项目开始之前，要给项目孵出20%左右的可压缩时间，这个只有项目经理自己清楚，不必言明。
最不可取的就是项目经理挥刀自宫，让整个项目组在低成本下高速运行，这样的项目最后成败我们先不说，在项目成员的眼中，你基本上与黄世仁无异，甚至不用等到项目结束，就已经牺牲了。所以在第一次项目中一定不要让项目成员感觉跟你就是为了体验雪山草地，他们配合你，一是出于利益，二才是看你这个人值不值得跟。都看着你呢。所以，遇到不顺事先忍着，抓重点，回头再总结。这就是前文所说的做人、做事的原则：为什么级别的事情，就得付出什么级别的代价！
其实，第一次，不要将成败看的太重，教训要自己书写。有人说，哪怕只打一次仗，一个兵才会淬火成为真正的军人。谁没有第一次呢？做人，要经得起失败，但得明明白白地失败。
有人说 程序员的人生有三重境界。第一重、见山是山，见水是水。刚入门的程序员基本只能看到表面的东西，由于各种原因，没法了解更深入。第二重、见山不是山，见 水不是水。成长并有经验后，看到的表面现象渐渐有头脑中成型，犹如行军详细地图已经了然于胸。第三重、见山亦是山，见水亦是水。大悟之后，举重若轻，外松内紧，处事看似笨拙，实则暗藏玄机，惜语如金，然字字珠矶。此时，胸中亦有各种框图，然表面内敛以藏拙，见人说人话，见鬼与鬼语，谓之通灵也。
要想修炼到气定神闲的第三重境界，那就用心和智慧体验吧！
职业规划是对职业生涯乃至人生计划的过程，职业生涯规划的好坏可能将影响整个生命历程。感谢您阅读《项目经理眼中的合格程序员》内容，职场资讯网小编向您推荐一些职业规划知识，欢迎参考，希望能帮到你。
一、合作与团队精神及计划性
服从分配的工作，并在保证质量的前提下尽快完成任务。如果接到的新任务没有给出工作量估计，首先估计出完成任务所需要的工作量，并有责任向领导说明其估计的合理性，如果接到的新任务已经给出工作量，除非能提出充分的理由，否则必须接受该工作量估计。提前完成任务时，应该及时通知上级。在同时承担几个模块任务时应能根据优先级的变化及时调整自己的工作时间分配。
二、需求理解能力
在开发过程中，要在需求细节不明的情况下，有责任设法搞清楚，积极学习编程思想和方法，并在设计、编码工作中自觉应用，对有一些复杂程度的设计，主动申请设计审查。并能在开发用户界面之前，尽可能使用界面原型方法获取用户的确认。
三、测试意识
在工作负担允许的情况下，采用测试驱动的编码方式，及时把完成编码的部分提交测试，并及时排错。不断通过自己的测试来驱动程序质量的提升。
四、规范化，标准化的代码编写习惯
良好的文档是正规研发流程中非常重要的环节，作为代码程序员，25％的工作时间写技术文档是很正常的。缺乏文档，一个软件系统就缺乏生命力，在未来的查错，升级以及模块的复用时就都会遇到极大的麻烦。
对正规的企业，会有完整的编码规定，代码的变量命名，代码内注释格式，甚至嵌套中行缩进的长度和函数间的空行数字都有明确规定，良好的编写习惯，不但有助于代码的移植和纠错，也有助于不同技术人员之间的协作。代码具有良好的可读性，是程序员基本的素质需求。
五、总结与全局观
以项目全局为重，采取尽可能简捷的解决方案，把完美方案的设想提交设计人员，有问题时首先向同事们征求解决办法，不鼓励花大量时间解决难题，并鼓励给同事提供技术支持。项目结束，做出个人小结，以利个人和集体的改进。
第二个提法，我觉得目前女性就业困难，关键还在女性自己。
目前大学里面有句话：干得好不如嫁得好！,我想大家都听说过。其实是人就有惰性，也有一些劣根性，都想找一些活少拿钱多的工作，舒舒服服地赚钱，这种思想，其实不管男人女人都有。我自己也有，呵呵。
关键是，社会是公平的，一分贡献，一分收获，哪有那么多不劳而获的事情。但现在的女生，我觉得普遍有点问题，都想走捷径，都想一次革命成功，目前大学校园中，傍大款的不少，很多女生一门心思嫁个好老公，认为这辈子就有靠了，不需要奋斗了。
因此，在求职市场上，很多女生不是找不到工作，是根本没有一心一意地去找，因为对女生而言，通常都有第二选择，可以靠家里，靠男朋友，等等。这种求职态度上的不坚决，其实无形中，已经给自己关闭了很多企业的大门。有个现象，同等条件的两名女生都面试，一名犹犹豫豫的，一名态度极其坚决，一定要拿到这份工作，通常都是后者获胜，因为企业认为这个人既然这么需要这份工作，那不管能力怎么样，进来后起码会拼命做事。
那我们再来比较男生和女生，就可以看出显著差异了，其实男生有时候也想靠，但是没得靠啊，反而，还有个女生在靠自己，自己还要撑起一片家庭，那么，你说男生求职拼命不？
但我还是得说，前面女生的这种思维是严重错误的，夫妻也是经济共同体，双方需要共同完成家庭建设，这样的家庭才稳定。一个女性，如果觉得职场艰难，就打退堂鼓，那，不管是不是程序员，其实我觉得她什么职位都找不到的。
这样还有潜在的恶果，现在有很多闪婚族，出了校门就结婚，我认为和女性的这种依赖思想有一定关系，但这样的婚姻，是不是稳定呢？
其实我不讲，大家都应该清楚，女性凭借个人的外貌实现魅力，男人更多的是凭个人的内涵和事业的成就实现魅力，这就决定了，一个女人，魅力最大的时候，是18~28这个年龄段，而男人恰好相反，一个男人最有魅力的时候，是35~45岁这个年龄段。这中间有落差。
一个女性，如果坚持以漂亮为本钱，早早地就嫁人，在家里相夫教子，那么，在她30多岁，年华老去的时候，情况就比较危险了。首先，男方逐渐进入事业巅峰，很多更为年轻漂亮的女性，会青睐这种男人，男人面临的诱惑在加大，其次，这个家庭，十几年其实都是男方一点点赚出来的，女方是享受者，不是建设者，在这个家庭里面渐渐就没有发言权，经济基础决定上层建筑，不要说对方爱你就会一辈子听你话，很多事会变的。
如果此时女性再不注意，试图通过控制经济等手段压制男人不会变心，或者采用跟踪，哭闹等极端方法，往往适得其反，最终导致男人离他而去。一旦出现这个问题，女性的问题就比较危险了，十几年没有上过班，自己的专业能力，恐怕仅仅剩下一张文凭了，知识都还给老师了，那她在社会上可以说没有任何竞争力可言。那么，她以后靠什么生存？
第四级 一般的程序员
这类程序员的优点在于，他们很清楚地意识到了自己可能这一辈了也无法成为一个伟大的程序员。天才只是很少的一部分人。如果这类程序员有一些商业和人员管理能力，他们也会在公司里相当的成功。认识自我并不简单，这并不是一般人能做到的，能够认识自己的人已经是很不错了，找到自己的长处，并像那个方向努力，一定也会很成功的。因为在公司里，并不只有程序员一种职位，经理，PM，流程，SQA，技术支持，售前，管理员，测试人员等等都可能会让这类程序员有更为广阔的天空。
第三级 业余的程序员
这类人员不管是不是计算机科班出身，基础如何，他们对编程有着特殊的爱好，他们可能会是一些很有前途的学生或实习生，也许他们可能会给开源做一些贡献（比如说提供一些语言包或是一些插件什么的），有时候，他们也会写两个小工具软件放在网上让人下载，也行有些时候就是为了玩玩而开发一些小程序而打发一下他们空闲的时间。他们完全是靠热情和承诺来编程。兴趣永远是最好的老师，也是最好的一件事，因为兴趣而引发的热情通常会让这些程序员成为骨干程序员。
第二级 不知名的程序员
这一级的程序员是典型的为大众所知的程序员，他们有一定的编程能力，但并不出众，也许他们会在一家大公司里工作，只程序员只不过是他们的工作而已，并不是他们人生的全部。当然，这样的程序员也挺好的。必竟，平凡地人还是大多数，平凡地活着也没有什么错的。
第一级 糟糕的程序员
这类程序员不知道为什么就走上了编程这条路，他们甚至连最基本的编程经验和能力都没有。所有被他们碰过的事情都需要他们的同事重头再返工一遍，他们根本不就是程序员。程序员这个职位对于他们可能就是一个错误。
正如原文作者所说，这些级别并不是很严肃的，也并不是每个程序都会去思考一下自己的未来，但是这些级别可能会让你去想一想从事程序员十年/二十年/三十年后，自己可能变成什么样。
看了程序员系列文章，颇多同感。做为一个从业13年，一直做软件开发的人，我想给那些已经、将要和有志于走上这条路的朋友一点点忠告。
首先，说说程序员和软件工程师。虽说都是编程的干活，但是还是有一点高下区别。
主要说来区别是程序员programmer是将程序（已经有流程，伪代码或设计模板）写成代码；需要熟练掌握至少一门编程语言。而软件工程师则要将目的描述成程序语言并实现的能力。例如将数学算法、自然语言、思维模式描述成程序算法，程序流程／类或／和人工智能，并写成代码的能力。
对初入行的人，当然重在语言，要做一个合格的程序员，首先要熟练掌握语言。包括语言特性和实现的能力。例如使用尽量中文说的面试题，就要求面试对象掌握C++中的类的封装；构造函数的重载和运算符重载。
做过一两年后，要想继续吃这碗饭就必须提高自己，首先当然是深入了解语言，特别是语言的思维方式，编译器的工作方式和常用设计模板。就拿C++的多态性来说，很多公司面试就会问什么是虚函数／纯虚函数（思维方式）？用C如何实现函数重载（函数指针和了解编译过程）？接口类／工具类／工厂类和 Sigleton类的实现（常用设计模板）。另外还有一大块就是内存管理了。
如果能做到深入了解语言本身，那么恭喜你，你现在Title至少是高级程序员了。
在对自己的语言有信心后，下一步就想一想自己要想哪方面发展。是管理方面（项目经理）还是技术方面（软件工程师）。既然这里讨论编程，我们就先不考虑项目经理。想发展为一个软件工程师其实也有两条路。一条是走系统软件工程师或者叫架构工程师的路；另一条就是算法工程师。
在国内的朋友我建议走架构工程师的路。要求就是知识面广，对整个系统熟悉，能很快了解和分析客户／设计需求，很快估计工作量、风险和所需要的资源（承担相当部分项目经理的任务），能根据现有技术人员储备提供一个解决方案。当然还需要一定的表达能力和文档写作能力。例如我当年走访某省农行，和对方聊了银行卡和医院医疗卡的联网，当天晚上就和市场部的人合作，搞了一个通宵，写出了60页的技术方案和外加40页的基于此方案的标书。
一般来讲，要做到对整体系统的深入了解，没有两三年的时间是做不到的。所以给国内程序员的建议是不要频繁跳槽，尤其是不要频繁跨行业跳槽。踏踏实实地将本行业的软件吃透，最好每个部门或模块都工作过。如果有这个想法，一般情况下你可以和项目经理沟通，通常他们会鼓励你这样到各个部门／模块工作。
我出国后，发现情况有点变化，由于语言和文化的区别，对自己走系统工程师的路没有很大的信心。只好转向走算法工程师的路了。
确定了这条路后，突然发现自己的数学能力太差了。不得不重新恶补线性代数，概率和数理统计等高等数学。同时将《数据结构与算法：C++版》好好从头到尾读了一遍。然后终于蒙混到了一个职位。
当时第一个任务就是在一个嵌入系统中写一段程序将bmp压缩为jpg。各位可能会问了，这个在网上满大街都是源代码，为啥还要自己写呢？其实这就是我不太建议国内工程师走算法这条路的原因。除非你是数学大牛，有自己原创的算法。否则在国内实在没有算法工程师很大的生存空间。但是在国外有很大的不同，稍正式的公司基本上都禁止使用open source。因为open source也是有版权的，有的是不能商用，更有的copy left是那些公司碰都不敢碰的。因为copy left要求你使用了他的代码，你也必须公开你的代码。
当然，我们可以看那些open source，然后自己重写。不过相信我，通常情况下如果你不是想简单做些变量替换就交差的话，看原代码不如看这个算法文档本身。
职业规划就是对职业生涯乃至人生进行持续的系统的计划的过程。一个完整的职业规划由职业定位、目标设定和通道设计三个要素构成。
一下子就跨到了新年，时间真快呀！言归正传，今天谈谈项目问题。
我们常听到同行说自己做过什么项目，说某某做过什么项目。一谈到项目就会眉飞色舞，兴高采烈。而不少新进单位的新大学生、一些编程新手，往往不知道什么项目，不知道项目与自己成长的关系，有的甚至声称编程好几年了，还都没有做过项目的经历。情况确实如此，只有参加过项目的程序员才是真正的程序员。那些没有做过项目的虽然自己编制了不少程序，虽然得意过自己的程序，但是，毕竟和做过项目的程序员有很大的差别，这些差别主要在于：
1、 程序的价值
没有做过项目的程序员，编写程序的目的主要是学习，通过编程来提高自己的编程能力，编啥、怎么编都由自己主观决定，自己能做什么不能做什么都不是太清楚。至于程序能否被别人使用，程序能否卖出价钱，程序员并不太关心。
做项目的程序员则不一样，他编写的程序不是用来学习的（尽管他是抱着学习的态度参加项目的），而是作为商品的一部分出售的，编出的程序要投入日常运行的。他别无选择，必须完成程序功能。程序员的价值通过程序出售的价格以及程序使用来体现。
2、 程序的时间要求
没有做过项目的程序员，编写程序的时间长度是由自己决定的，自己高兴什么时候编好就什么时候编好，遇到其它事打搅，拖个十天半个月也无所谓！
做项目的程序员则不一样，他必须在规定的时间内完成编程，只能提前不能延后，否则整个项目进度就会被它拖后腿，而由于项目延期不能按时交付给客户，其结果就有可能因延误被罚款，甚至取消项目。
3、 团队
没有做过项目的程序员基本上是单枪匹马地编写程序，程序功能相对简单，一个人多花点时间也能完成。
做项目的程序员则成了项目组的一个成员，他只是负责整个项目的一个部分，或者说只编写其中的一段程序，而不是全部。因此，他的程序必须要和其他人编制的程序对接、他的程序必须读别人的数据，他的数据也可能被别人读。这里的每一个环节都不能出错，一个地方出错就会影响整个项目。所以，他必须和团队的其他人很好协作共同来完成自己的程序。
4、 学习氛围
没有做过项目的程序员学习靠自学，靠网上google去学，学的内容随意性很强，学好学坏没有人监督。
做项目的程序员不但靠自学、靠网上google去学，还必须向项目负责人去学、向项目组其他人去学、向客户去学。而且学的东西都有针对性。向项目负责人去学习程序设计详细方案、向项目组其他人去学习程序接口、数据接口、向客户学习业务及需求等。程序的好坏要通过测试环节和用户使用加以验证。
所以，通过参加项目程序员可以克服自以为是的错误观念，树立为客户编程的思想，以软件销售价值来衡量自己的价值；树立团队意识，把自己融入到团队之下中，以团队荣为荣，以团队耻为耻；在项目中学会从大局看待程序设计、学会评判程序难易之处，学习更加实用的程序方法和算法。
那么是什么项目？这里所指的项目可能和一般的项目定义侧重有所不同。这里的项目一般是指客户提出需求，软件公司或企业内部项目小组按照需求进行设计、开发，投产、维护等工作的总和。它只包含软件相关的费用，其他硬件、网络、软件环境费用不在此考虑之列。
项目是有大有小的，有的大的项目以亿为计，有的小项目以千而计，千差万别。由于没有标准，不同的人对项目的大小定义是不同的。例如，有的企业把一百万以上的软件称之为项目，把1千万以上称之为大项目。有的小企业把1万元以上的软件称之为项目，把5万元以上称之大项目。这些项目大小主要取决客户对资金管理范围和等级，一般而言，项目越大，需要单位或企业越高的领导层批准。
4、对代码的信任
作为项目管理者，你怎么相信他们的代码。有些程序员，你可以对他们说：我星期五就要结果.--星期五到了，你收到了这样的Email:代码我都已经检查过了，现在就等着测试了。你很放心，只会有很少的瑕疵在质量确保的团队被查到。当然，还有些轻率的例子，一些程序员在邮件里是这样说的：我还没弄完，星期一上午我会最先完成它.你不太确信这东西，发现很多Bug,很长时间基本上不能用。又得花上几个星期清理代码中的Bug.
关键：你对一个开发人员越有信心，他离成为一个伟大的程序员的距离就越近。想象你是你的管理者，如果他并不担心你的代码，会给你多少信心和勇气！
5、对方案的信任
和对代码的信任是一回事--如果你手上有伟大的程序员，你就会对解决方案有信心。这些程序员同时也是伟大的建筑师。他们剖析整个问题，指出问题需要怎样去解决。这就不只是用伟大的代码编程的问题了，很大程度取决于你怎样构筑解决方案。这是关键，而且会让你在软件世界里出类拔萃。
6、满足客户需求
一天下来，你写出了最棒的代码、用了最好的框架和最好的解决方案，但这真的能迎合用户的需求吗？恐怕根本不是那么回事儿。你搞砸了。尽管现在多次失手，一个伟大的程序员还是会正中靶心，找出客户需要的，给用户逐步展示他们所需要的无bug的最终版本。需求正中靶心的同时，用户满意了。
7、不断升级
伟大的程序员会积极主动地把自己的技术升级。他们对知识的态度就像饿猫见着了牛奶，他们从不用上级催促给自己设定目标、不用经理要求他们完成任务，因为他们自己就已经安排OK了。
他们发现自己想要参加的大会就会给公司写Email本人非常想参加今年的Tech-Ed大会。我将用心研习，并对作出贡献。我预计这可节省金钱/其他原因.如果可行，不知公司是否帮我支付此行？如果我收到这样的邮件，我不仅会帮他支付参会费用，他的路费我也会全程买单。
伟大的程序员们永远会关注例如。net用户组或Java用户组的所有用户群体。他们参加本地的技术会议，并从中汲取知识。你会看所有最新博客和最新的杂志吗？现在列出你最喜欢的前5个开发博客。你能做到吗？你应该像参加基督教青年会那样轻松做到。做到这些，可以很好的帮助你延伸你的思路！你将会不断获得更好的点子！你会得到更好的回报！
在技术的选择上，是敏捷敏捷再敏捷！数据库尽量db4o,前台尽量sl/flex（面向最终客户的就不能选择sl）.工具软件尽量用C#开发。尽量只做自己擅长的，不做别人擅长的。
我有一个特点，就是会一大票语言，能用来干活的就有C,C++,C#,Java,Python,matlab,actionscript,javascript,tcl.去上班的话，这是缺点--泛而不精。自己干的话，这反而成了优点了。因为我接的项目，很多属于偏门项目，这些项目往往都有开源的实现，但这种实现，要么只有C版本，要么只有Matlab的，要么只有Java的，会这些语言可以最大范围的参考，降低技术风险。缺点在不同环境下可以成为优点。
第五关：团队
通过前面的不断切入，形成了一系列案例，也积累了良好的信用，业务量是翻番的在长，最后自己的时间成了瓶颈。前两天小试了一把，谈了5个项目（2个flex,2个图像处理，那2个flex项目的核心也是图像处理）,4个有合作意向，自己干不完，没办法，只能选择1个。
这就到了第五关了--一个人干不过来，得团队了。
但我前面说过，本地是人才沙漠。我的观点是宁缺勿滥，仔细挑选，从头培养。俺的挑选标准是：有激情、品德要好、数学基础要好、有自学能力。目前在带徒弟，看成长情况怎么样。
不着急，用不着太多的人，培养团队的同时开始摸索渠道。那个也得时间。
第六关：渠道
我最终想做的是产品。而在偏远地区做产品，想做成功，渠道和推广非常重要，不然的话，就算做出来了，也只能拿小头。在国内，还要考虑盗版因素。我现在只是有大致的产品方向，做也是玩票性质的，目的是摸索渠道和商业模式，想摸摸国内的和国外的两种市场。国外的只有试探性的探索。国内的，嘿嘿，前面的开发已经形成了一系列的推广工具了。
第七关：产品
做了这么多年项目，累死了。最终的目的还是产品和平台。我的征途是星辰大海（搞技术的，也得有技术的浪漫）目标是5-10年后，互联网3D化之后的虚拟现实（切入点？俺已有一个初步考虑的切入点）.短期（5年内）是开发一些工具类型的产品和推广平台。
我是学材料的，在纳米材料界有一个名言--Build The World Atom By Atom.那么，在可见的未来，虚拟世界就是--Build The World Bit By Bit. 协议、图像、机器视觉、3D、语音，正是构成虚拟世界的因素，前面的种种，都是为这个做铺垫。未来的制造业将是分子制造，于是Atom和Bit将会碰撞--Build The World Atom By Atom, Bit By Bit!
但还是那句话，只做小，不做大，做点做线不做面。
什么程序员30岁之后转行之类的鬼话。俺到今年，才开始感觉进入了程序开发的大门，写程序时开始有一种美感，有那种几十人骑着战马冲击奥山大桥的壮烈。做一辈子的技术又何妨。
上述路径相当保守，指导思想不是胜利，而是避免失败。无恃其不来，恃吾有以待之，无恃其不攻，恃吾有所不可攻也。
高级项目经理
同他的名字，就是比项目经理更厉害的项目经理。有时高级项目经理是老板对跟随自己多年的老功臣的安慰，有时只是为了让薪水拉开距离，有时是只有高级项目经理去做大项目，也有的时候高级项目经理来管理项目经理，它是项目经理的老板。总之具体的工作还是那些只不过更高级了，就像有些人的职务前加个资深。我在公司做的就是高级架构师但是做的就是架构师的工作，给个高架的职位是老板对你安慰，而且他还不让你写代码，如果不做开发时间长了很多东西就会逐渐流失落后。
我们来说说项目管理类的职位会用到哪些工具，最基础的就是Word和Excel，不要小看这两样，他为项目管理提供了最基础的数据，每份统一了格式的文档，每份精心设计的Excel都是项目的重要成果，包括各个项目周报，个人周报等等。然后就是专门用于项目管理的软件如MS Project。软件生产是智力密集型的活动，其产品无物理外形，生产状态也不可见，因而难于检查和驾驭。如何管理项目的计划、调度、通信、费用估算、资源分配以及质量控制等。软件项目管理工具就是要使这种生产过程成为可见、可控的过程。使用它能帮助进行成本估算、作业调度和任务分配，并制定出成本较低、风险较小的项目开发计划；同时能设法在预计工期和经费之内适当调整项目的安排，以节省时间和人力，从而对软件生产的各个环节进行严格、科学的管理，使项目开发活动获得最佳的进程。 使用专业的项目管理工具不仅有效的帮助项目管理，而且它还能规范你的管理过程。
QA工程师
如果一个软件企业正在实施CMMI或者已经建立了研发管理体系都会在项目组中加入一名QA工程师。在我的工作经验中只有到达软件企业的公司，组织规模在300人以上，才可能去实施CMMI，就算去实施CMMI，最后也只不过是为了拿个CMMI的证书，QA工程师很多时候都是为了CMMI才存在的。不知道是咱们的软件公司不重视研发管理还是CMM和CMMI不适用于中国人。CMMI标准文件说，QA是高级经理的ears and eyes。研发人员眼中的QA往往也是警察，QA的作在于发现和报告项目的问题。一个合格的QA在项目中会充当三种角色：
角色1-老师，具备学习和培训的能力。
角色2-医生，通过度量数据对项目过程进行诊断，帮助分析原因，开处方。
角色3-警察，以企业流程为依据，但要告诉大家流程背后的原因；如果和项目组针对某些问题意见相左，可以直接汇报高层。
但在我的工作经验中却没有看到过这样的QA，虽然我的项目组也有为QA，但是主要为了实施CMMI而设置的，她是一位女性，不参与我们的讨论，只是默默地看着听着，然后回去写她的文档，只有在项目组研究去哪里吃饭庆祝阶段成果时就是看到她积极踊跃发言。
营销法略的法，将产品营销拆解为面向机构客户采用一目标（CUTE）、二手段（建网10-30-60法则、达情1-3-6法则）、三宗案（赖式、袁式、牟式）的国情式流程，面向大众客户采用美式营销的普遍真理（6大要素、经典8P、当今新法）与中国市场的具体实际（本土特征、本土各P）及IT特殊的鸿沟现象相结合的差异定位专业式流程，以及不收客户的钱还能赚钱的出奇守正的第三方流程。
关于为将者的产品人修炼，智（坐知立行）、信（合作共赢）、仁（客户至上）、勇（勇于创新）、严（品质保障）五大素养，在成就企业产品的同时，也成就自我人生的成功。
程序员第二定理，不妨俗称为看远定理,或时间定理,即程序员应就职涯之世论技术之时.古人云，不谋万世者不足以谋一时，这个世就是职业生涯的全景，这个时就是当前的技术实现。反映到程序员需要做的心智模式的第二个战略转变是就职涯（世）论技术（时）.
程序员可以选择职业路径，始终做工程技术，其职涯大致的到达路径是研发、技术方面的首席技术官CTO或工程、项目管理方面的工程管理副总VP Engineering;也可以选择职业路径二，从技术端向商业端走，其职涯大致的到达路径是首席产品官CPO、首席营销官CMO或销售副总VP of Sales.一般情况下，这几个职务中能到达CEO的只有从CPO、CMO或VP of Sales上去，从CTO和VP Engineering一般上不到CEO,即CEO更偏向商业，这大抵也是商业驱动技术的写照，美国的CEO九成以上是从有过销售经验的营销或产品人员中产生。
长江后浪推前浪，创新的技术、产品和企业不断涌现，IT行业最大的敌人是周期性的创新衰减，或曰创造性毁灭，即你可以通过创新毁灭别人，新企业也同样通过创新来毁灭你，如微软之于IBM、Google之于雅虎，以及现在打得火热的微软和Google.
企业如斯，人亦如是。IT业人的最大的敌人是因年龄增长引发的激情与创新的衰减，随着年龄的增大，谈婚论嫁、成家生子，你会发觉刚毕业时整晚都可以呆在电脑前的激情逐渐消失了，曾经被自己嘲弄的没有志向的朝九晚六之人，现在又多了一位，而在你心有旁骛之时，长江后浪滚滚而来，就要把你拍死在沙滩之上。
企业应对周期性衰减有三类方法，第一类是依靠技术性垄断延长生命，如微软；第二类是阶段性自我颠覆，如IBM的老沃森、小沃森、郭士纳等领导的三次战略转型；第三类是通过兼并完成自我重塑，如思科。
IT业人亦然，第一种，用人单位就只有你能搞定这个产品或技术，地球离开你就不转，你就是微软，号令天下，莫敢不从，倚天不出，谁与争锋；第二种，跟着新技术潮流，不断学习，与时俱进，完成阶段性的自我颠覆，如原来在DOS下编程，后来Windows,再后来。Net、SOA、云计算等；第三种，从技术领域通过兼收并蓄其他领域的知识和技能，完成自我重塑，如成为PM、成为产品经理、成为营销业务人员。
不谋全局者不足以谋一域，不谋万世者不足以谋一时，这就是程序员的时空定理。
职业规划是对职业生涯乃至人生计划的过程，职业生涯规划的好坏可能将影响整个生命历程。感谢您阅读《如何从优秀的程序员成为伟大的程序员[5]》内容，职场资讯网小编向您推荐一些职业规划知识，欢迎参考，希望能帮到你。
15、组织技巧
把所有事情整合在一起的最关键要素是组织。你可能是世界上最好的程序员，但如果你不善于组织你所做的事儿，你的工作将陷入瘫痪，最终丧失优势。伟大的程序员保持自己工作平台的整洁有序，保留所有的笔记并调理清晰。他们标出自己的会议日程表。他们有专门的收件箱给日程邮件、会议和新任务分类。他们保留文档并能在需要时迅速找到所需。
额外要提到的：激情
伟大的程序员如果没有热情，那么他的工作也并不伟大。好的程序员有了热情来对待他的工作、方案和团队，那么他比伟大的程序员还要伟大。
在回顾的时候，我用这些标准来评判我的开发团队。我给我的团队尽可能最好的环境，作为回报，我想要他们都成为最伟大的程序员。你可以用这些标准来评判你的团队，或者你本身就是一名程序员，请用这张列表来尽可能地改造自己来超越同侪。
备注：Generics是程序设计语言的一种技术，指将程序中数据类型进行参数化，它本质上是对程序的数据类型进行一次抽象，扩展语言的表达能力，同时支持更大粒度的代码复用。对于一些数据类型参数化的类和方法来说，它们往往具有更好的可读性、可复用性和可靠性。在设计集合类和它们的抽象操作时，往往需要将它们定义为与具体数据类型无关，在这种情况下，使用Generics就是非常适合的。
相关文章
最新更新
06-28 03-26 03-26 
