软件开发这个行业往往是供不应求，这跟开发人员的素质有很大的关系，在这个浮躁的圈子里，能在一家公司呆上三年以上的程序员，通常就会把持领导岗
位，结果做出来的东西大多非常糟糕。这也说明了，程序员的能力不能完全靠工作年限来划分。怎么样才可以成为一名合格的高级程序员？今天为大家解析程序员的
几个成长阶段。
初级程序员
初级开发人员是这样的，刚从学校出来，就像坐井观天中的青蛙一样，自认为什么都会。突然间，你发现自己面对的问题，靠学校中的那点知识是远远不够的。问题要更复杂，更凌乱，没有理论上说的那么纯粹。你正处于放弃还是坚持的分叉路口，你不知道该怎么办。
对策就是专心致志，专心致志地竭尽全力学习。初级开发人员需要大量的指导、监督和辅导，否则他们将会在这一阶段呆上很长一段时间。因此，实际上你也可以将这一阶段视为策略和日常技术的吸收消化时期。
初级开发人员关注代码，而不注重开发，他们不明白两者之间的区别。如果一个程序员表示“要是代码不需要面向所有用户，那他们会更喜欢编码”，那么我可以判断这是一个初级开发人员。
一个优秀的初级开发人员给定一个已知任务之后，就能够迅速良好地执行。
中级开发人员逐渐能够意识到失败(通常是他们自己的失败)模式，并认识到比起实际构建匆匆忙忙去做重点任务其实所需要的时间和精力更多，并且也不会因为有人说要改一改而一下子垂头丧气。他们也经历过自以为写出了引以为豪的内容，实际上证明是垃圾的悲惨遭遇。
中级程序员
中级开发人员寻寻觅觅于用正确的方法去构建，去解决问题，他们会通过实验、文献和与其他程序员的讨论去发现这些正确的方法。这实际上已经是学习软件架构的水准，而不再是构建代码(我们在学校里学的就是这个)水平。
没有受到监督的中级开发人员构建的系统之所以失败的原因和初级开发人员的失败原因截然不同。初级开发人员会构建一堆稍微有点用的算法。而优秀的中级
开发人员会跳出《Design Patterns》和《Domain Driven
Design》的禁锢。虽然这些都是学习构建大型OO系统的好书，但是直接应用理论只会导致死板的设计结果，不重要的地方灵活多变，重要的地方却又死板无
法更改。
你可以信任中级开发人员构建的系统，他们的系统毫无疑问比初级开发人员做的要好，但是时间久了，依然会有各种问题出现，成为拦路虎。一个可悲的事实
是，绝大多数高级开发人员，甚至团队领导者其实都还只是——中级开发人员。当然，大多数人都没有这样的自我觉悟，原因是他们根本没有和更高水平的人一起工
作过。
一个优秀的中级开发人员应该懂得使用代码来解决问题只是一种手段而不是目的。然而，他们仍然深爱着纯粹的设计，仍然渴望寻求所谓“正确的方式”来构建软件。
优秀的中级开发人员依然需要少量的监管。毫无疑问，他们能够提升代码设计，并在设计讨论中发挥重要作用。他们是开发团队中的主力。但是，对于他们，进一步的指导和更高层次的监管依然至关重要。
高级程序员
高级开发人员熟悉失败。他们已经经历过编写的代码在低于设计和超越设计的情况下都失败的情况。他们深思熟虑，在面对问题时，能够心智成熟地评估成功与失败。高级开发人员已经跳出了中级开发人员深爱的复杂性，开始沉迷于简单。
高级开发人员悉知自己的长处和短处，力争尽可能地扬长避短。
高级开发人员深知理论联系实际的重要。他们明白，世上没有所谓的构建软件的“正确方式”，建立良好软件的唯一途径是要将理论适应客户、代码库、团队、工具和组织的需求。
高级开发人员理解并权衡领域涉及的一切，同时会思考如何去支持设计模式、库、框架和流程。
高级开发人员不仅仅了解自我，还知晓组织和客户的工作方式和价值观，以及对于组织和客户而言成功相关的重要和不重要的因素。一旦出现问题，高级开发人员会想方设法地去解决。“这不是我的工作”——他们永远，永远也不会说这样的话语。
高级开发人员心里明白，他们的工作应该是提供解决问题的办法，而不是写代码。
不像中级开发人员辛苦耕耘于枯燥的日常工作，高级开发人员会退一步，去思考是什么导致了这些无聊的工作。他们会评估修复根本问题的成本，要么直接解决这些问题，要么研究起来以便于最终彻底解决。
高级开发人员明白，单枪匹马是搞不定项目的。他们的主要作用是帮助团队变得更好，同时争取个人共同进步。
高级开发人员深刻理解，领导一职代表的不是权力，而是授权，不是方向，而是服务。
如果你的团队中一个高级开发人员都没有起到领导作用，那么你的项目是注定要失败的。一队伟大的中级开发人员固然能让你走得很远，但是他们构建的软件
的好日子却是屈指可数的，其最终结果要么是关门大吉，要么是高风险高成本的重写。高级开发人员才是唯一能胜任选择技术和平台的人。
简单粗暴的分类方法
我非常讨厌现在流行的根据工作经验年限来给程序员划分档次的方法。多年的经验的确能让你增加见识，但这都是一些几乎毫无意义的背景信息。
更重要的是，我们的行业需要刚从大学毕业活力四射的年轻人，也需要那些有着15—20年工作经验的老程序员。我们应该从团队和企业的角度来思考人才组成。
来源：51CTO