来自：cnBeta.COM
今天看到微博上@hellodba发的一个帖子：“内部晋升越来越困难，但是外部来的大P越来越多，所以很多人都选择跳槽”，之后我从三个方面简要的进行 了回答：“外面来的总是有包装的，内部的都是肉身PK，此一输；外面来的总是小股人马，内部的一批批的，升谁都伤感情，此二输；外面来的通常都是大佬推荐 的，没有特别重大机会，人不会来，内部的就不解释了，成果都被大佬吸收，难有机会，此三输”。之后讨论不断，我也余兴未了，继续写来。
这个世界上有一类人特别苦逼，苦逼到什么程度呢？他们省吃俭用攒钱买房，结果房价越来越贵；公司外部竞争激烈，他们工作异常繁忙，披星戴月，日复一日；技 术更新行业罕见，他们要随时调整心情，随时学习知识；他们长期和机器为伍，大多比较呆傻，比较单纯；还有很多不一一例举，这一类人就是程序员。
而就是这么一类程序员过着这么苦逼的生活，在公司内部却难以获得公平的晋升机会，外来的和尚总是在不断打破平衡，甚至是刚毕业的新和尚拿得都比老和尚多，这是全行业都罕见的奇观，IT人有幸经历了。
某创业公司，某个程序员要离职，老板甚至不问问他直接领导的意见，就同意了，没有挽留，之后大骂不忠诚，这个人拿3k，拿了2年，他走了以后，老板用5k雇了个新面孔，但就是不愿意给这个老人晋升，不愿意给加到哪怕是4k。
某上市公司，游戏部门突然从外部空降了一个领导，原因是原大佬被挖走以后，剩下的人升谁都有意见，难以服众，不从外部请人来镇不住局面，这个人一来，大家是团结了，团结起来和这个人斗，但最后还是和解了。
某国际大公司，某人伪造简历，包装的如花似玉，获得高职，工作主要有下属完成，他只需要汇众汇报即可，越混路越宽，直到某天事发，依然是高官。
某IT企业，某清华同学离职时语重心长的对我说，XX（可以理解为网游，搜索，电商任意一种）是00-02年毕业的这些人清华人的机会， 我们就是比某人强十倍也没有机会，也得从下面做起，搜索的天时不属于我，此人去了某金融分析软件公司，目前是高管，同期留在某IT企业的其他同学依然过着 苦逼的生活。
举了这么多例子，我想说得是为什么不给你晋升这个问题，或者晋升很难，为什么？
1）大佬的问题
你晋升困难，最大的主观原因在你自己，最大的客观原因在你的直接上司。付责任人的说，目前很多企业的领导是不合格的，他们大多80后，没有为他人着想的思 想基础，一味的考虑自己，不顾下属，曾经我对某人说，你说你是合格的领导，你说出你下属每个员工租房在哪里，每月多少房租，我就同意你是合格的领导，结果 他羞愧不言。你晋升不了，很大程度上是你的领导没有帮你，连你每月房租多少都不知道，你指望他帮助你提高技术水平，帮助你晋升？
2）大佬的大佬的问题
你大佬的大佬，level很高，他需要引入新鲜血液，他知道这个队伍缺什么，这个是他思考的问题，他需要找牛的人来补这个缺口，于是一个光鲜照人的牛人进 来了（虽然两年后也会泯为众人）给队伍带来了新鲜的血液，但你的大佬升不上去，你大佬边上的位置被这个人占了，你的位置在哪？
3）公司的问题
各大企业给员工的再教育和培训都是不尽相同的，但大多口号是一致的，在工作中锻炼成长，这句话是最扯淡的，国外很多大公司是有很完善的培训和再教育计划 的，会给员工一个充电的机会，并且给其一个完善的培训后，以便于让他在新升职的岗位上能够很好的胜任。在国内大公司都在找牛人，就是不愿意自己培养，原因 是什么，不解释，你懂得。
4）你的兄弟
很多时候让你升不了职恰恰是因为和你一起战斗的兄弟，他们工作也很不错，你升职了，他们怎么办？这也是一个平衡的问题，你很努力，为什么你没有带动你的兄 弟一起努力，你上去了，需要你这帮兄弟的支持，他们会支持你吗？曾有一个说了一句话，我觉得很值得回味，“当大家都认为你该升职了，就是你升职的时候 了”，细细品味，很有道理。
5）你自己的问题
最后你升不了职是你自己的问题，每天工作很忙，没时间充电，每天工作压力很大，来不及学习，每天这个那个，一年下来碌碌无为。你提高了自己的效率了嘛？你 周围有朋友再帮你吗？你知道你要学什么嘛？你知道什么样的工作才能超出领导的期望?，你超出领导期望后却没有升职和领导沟通过吗？我曾在某企业，我周围的 几乎所有人加薪升职都是和领导沟通后才获得的。指望主动给你加薪升职，不如指望自己的沟通。
6）还是你自己的问题
你选择的这个行业是不是对的，公司是不是对的，就好像我说的这个清华的同学这个例子。如果你能耐大可以选大公司，PK到一票牛人上去，如果你能耐不大，去成熟大公司，还心理期盼高薪升职就不现实了，不如去一个有前途的中小公司，开创自己的事业。
从企业角度出发，如何创建一个合理公平的晋升机制呢？
1）第一流大佬才会招第一流的人，第二流大佬只会招第三流的人，因此公司一把手必须是第一流的，价值观才能靠谱，制度才靠谱，没熟读历史，不理解中国文化的，建议不要做公司一把手。
2）晋升的制度必须公平，面向每一个人，每一个层次，这往往很难做到，做前端的和做后台的不好比，但做前端的可以和做前端的比。必须要有公开公平的比拼，已获得升职机会。例如某公司做一个高维矩阵分解的难题，大家机会均等，性能最快，效果最好，胜出者升职，带领团队。
3）鼓励公司职员交流，传播和帮助他人的文化，一个人如果乐于助人，帮助他人提高技术水平，这个人升职升上来，大家都会顶，反之，你保守，不帮助他人，水平再牛，升职上来也没人支持。
4）可以给职员一些挑战的机会，提供更多的资源，比如某公司的闪电计划，超越了谷歌搜索效果，就是一个很好的例子，要敢于给一些勇于挑战的职员更多的资源，在严酷的战斗中考验，并提供充分弹药。
5）给予内训机会，邀请业界牛人讲座，送职员去美帝考察开会乃至工作等等。培训机会是发达国家企业的一种非常好的激励措施，一个岗位5个人培训，最好的上岗，这是一个很公平的机会，培训机构足够独立。
方法有很多，只要这第一流的大佬，心中有着这帮打生打死的兄弟，办法总是有的，不要总是考虑自己的业绩，考虑自己的乌纱帽，做到这一点很难很难，但制度不是只有这位大佬可以制定，任何职员都应该积极投身到制度建立的过程中，要敢于提出自己的观点，毕竟公司是大家的公司。
我就写这么多，我是一个十年一线程序员的身份写这篇博客的，我努力做到客观，但我相信我更多代表的是劳方立场。
作者/梁斌
程序员是伟大的职业。
新闻来源:PHP100
好的编程原则跟好的系统设计原则和技术实施原则有着密切的联系。下面的这些编程原则在过去的这些年里让我成为了一名优秀的程序员，我相信，这些原则对任何一个开发人员来说，都能让他的编程能力大幅度的提高，能让他开发出可维护性更强、缺陷更少的程序。
我不要自我重复 — 这也许是在编程开发这最最基本的一个信条，就是要告诉你不要出现重复的代码。我们很多的编程结构之所以存在，就是为了帮助我们消除重复(例如，循环语句， 函数，类，等等)。一旦程序里开始有重复现象的出现(例如很长的表达式、一大堆的语句，但都是为了表达相同的概念)，你就需要对代码进行一次新的提炼，抽 象。
http://en.wikipedia.org/wiki/Don%27t_repeat_yourself
提炼原则 — 跟“不要自我重复原则”相关，这一原则是说“程序中任何一段具有功能性的代码在源代码文件中应该唯一的存在。”
http://en.wikipedia.org/wiki/Abstraction_principle_(programming)
保持简单 — 简单化(避免复杂)永远都应该是你的头等目标。简单的程序让你写起来容易，产生的bug更少，更容易维护修改。
http://en.wikipedia.org/wiki/KISS_principle
不要开发你目前用不到的功能 — 除非你真正需要用到它，否则不要轻易加上那些乱七八糟用不到的功能。
http://en.wikipedia.org/wiki/YAGNI
用最简单的方法让程序跑起来 — 在开发时有个非常好的问题你需要问问自己，“怎样才能最简单的让程序跑起来?”这能帮助我们在设计时让程序保持简单。
http://c2.com/xp/DoTheSimplestThingThatCouldPossiblyWork.html
不要让我动脑子 — 这实际上是Steve Krug 关于web界面操作的一本书的书名，但也适用于编程。主旨是，程序代码应该让人们花最小的努力就能读懂和理解。如果一段程序对于阅读者来说需要花费太多的努力才能理解，那它很可能需要进一步简化。
http://www.sensible.com/dmmt.html
开放/封闭原则 — 程序里的实体项(类，模块，函数等)应该对扩展行为开放，对修改行为关闭。换句话说，不要写允许别人修改的类，应该写能让人们扩展的类。
http://en.wikipedia.org/wiki/Open_Closed_Principle
为维护者写程序 — 任何值得你编写的程序在将来都是值得你去维护的，也许由你维护，也许由他人。在将来，当你不得不维护这些程序时，你对这些代码的记忆会基本上跟一个陌生人 一样，所以，你最好还是当成一直在给别人写程序。一个有助于你记住这个原则的办法是“写程序时时刻记着，这个将来要维护你写的程序的人是一个有严重暴力倾 向，并且知道你住在哪里的精神变态者”。
http://c2.com/cgi/wiki?CodeForTheMaintainer
最少意外原则 — 最少意外原则通常是使用在用户界面设计上，但这个原则同样适用于编写程序。程序代码应尽可能的不要让阅读者感到意外。也就是说应该遵循编码规范和常见习惯，按照公认的习惯方式进行组织和命名，不符常规的编程动作应该尽可能的避免。
http://en.wikipedia.org/wiki/Principle_of_least_astonishment
单一职责原则 — 一个代码组件(例如类或函数)应该只执行单一的预设的任务。
http://en.wikipedia.org/wiki/Single_responsibility_principle
最小化耦合关系 — 一个代码片段(代码块，函数，类等)应该最小化它对其它代码的依赖。这个目标通过尽可能少的使用共享变量来实现。“低耦合是一个计算机系统结构合理、设计优秀的标志，把它与高聚合特征联合起来，会对可读性和可维护性等重要目标的实现具有重要的意义。”
http://en.wikipedia.org/wiki/Coupling_(computer_programming)
最大化内聚性 — 具有相似功能的代码应该放在同一个代码组件里。
http://en.wikipedia.org/wiki/Cohesion_(computer_science)
隐藏实现细节 — 隐藏实现细节能最小化你在修改程序组件时产生的对那些使用这个组件的其它程序模块的影响。
http://en.wikipedia.org/wiki/Information_Hiding
笛米特法则(Law of Demeter) — 程序组件应该只跟它的直系亲属有关系(例如继承类，内包含的对象，通过参数入口传入的对象等。)
http://en.wikipedia.org/wiki/Law_of_Demeter
避免过早优化 — 只有当你的程序没有其它问题，只是比你预期的要慢时，你才能去考虑优化工作。只有当其它工作都做完后，你才能考虑优化问题，而且你只应该依据经验做法来优 化。“对于小幅度的性能改进都不该考虑，要优化就应该是97%的性能提升：过早优化是一切罪恶的根源”—Donald Knuth。
http://en.wikipedia.org/wiki/Program_optimization
代码复用 — 这不是非常核心的原则，但它跟其它原则一样非常有价值。代码复用能提高程序的可靠性，节省你的开发时间。
http://en.wikipedia.org/wiki/Code_reuse
职责分离 — 不同领域的功能应该由完全不同的代码模块来管理，尽量减少这样的模块之间的重叠。http://en.wikipedia.org/wiki/Separation_of_concerns
拥抱变化 — 这是Kent Beck的一本书的副标题，它也是极限编程和敏捷开发方法的基本信条之一。很多的其它原则都基于此观念：面对变化，欢迎变化。事实上，一些经典的软件工程 原则，例如最小化耦合，就是为了让程序更容易面对变化。不论你是否采用了极限编程方法，这个原则对你的程序开发都有重要意义。http://www.amazon.com/gp/product/0321278658
评论 由 yeehe — 2011年08月18日 @ 9:33 下午