分析一下四个医生，

a）属于新手类型，能力有限，经验不足，主要能完成功能就可以。bug会比较多，代码也不规范。

b）属于创造类型，既然能想到新技术和新方法，说明必然有一定的经验。但是创新虽好，也可能失败，成功可能性跟自己的能力有关。

c）属于熟练类型，对于代码的实现相当熟悉，能够快速的实现功能需求。

d）属于糊弄类型，相当之不靠谱，明眼人都知道，但有时瞎猫碰见了死耗子或者民间高手也有可能出现。

 

 

我会选c类型的医生，虽然创新不能保证，但可以保证最基本的功能需求。但是更想要在架构层面厉害的程序员。他们经验丰富，对相关框架和工具等都很熟悉，“完成功能”“稳定性”“性能”这些已经不再是他们的追求，更优美的代码、更合理的架构才是目标。

 

软件工程师需要有正式的职业证书才能上岗么?

 

如果是作为一般的程序员，俗称打工的，个人认为只要精通某一种语言，可以帮助团队完成功能就行，不一定要相应的证书。但如果是深入某一个领域，应该要有相应的证书，对于找工作时的个人和企业双方都有好处。

 

 

个人认为软件开发首先应该先是一门工程，在保证基本的工程质量情况下，某些优秀的软件以及代码可以上升为艺术。

 

 

在这个方面个人认为软件设计跟文学是有极大地不同的。而且即便是文学作品，关于“重字”这件事，在不同类型的文学作品中也是不同的。比如小说中的重字绝对要比古诗词要多得多。同样的软件在代码复审时，代码量很大的大型软件同一个简单的helloworld小程序中的重字也没有可比性。况且在软件中代码的重用不可避免，一个函数也会被调用多次。合理的对代码进行重用，应该也是一件艺术性的工作。

 

 

绞刑架故事就是在职业发展道路上的困难。各种技艺、职业、事业也是如此。有了困难，才能拦阻与淘汰掉一切不如我们的竞争者。

 

 

主动向老板、同事解释清楚更改设计的原因，主动承担责任是首要做的。一个项目做得好是所有人努力的结果，如果出现问题，黑锅往往是一个人背，孰轻孰重，应该能看的懂。

 

 

在我等学渣眼中，代码量跟工程师的水平就是线性关系。当然像Norris这样的大神专门做了研究，提出了程序员瓶颈这样的概念。的确刚开始的时候瓶颈可能在2000行，随着成长变成20000行。在理解了结构化编程以后可能还会遇到20万这么大的瓶颈。所以代码量和工程师的水平是阶段性的关系，突破瓶颈意味着质的飞越。

 

 

软件工程师在企业中不应该是劳动密集型的工人，而应该是有独创性的专业人士。但是在中国的诸多企业中，包括外企，往往都是专业人士带领着一群劳动密集型的工人在工作。但是正如adobe内部那样，普通的程序员再聪明，也没有能力在大方向上改变公司的决策。因此软件企业的成败不应该由软件工程师来负主要责任，如果要把这个责任强加到软件工程师身上，那么至少也要给软件工程师同等的发声权利。