在十月SOHO期间，办公室的同事和我就密码的问题MSN了一段讨论，这段讨论引发了对软件工程师“专业性”的思考。
项目背景：我们项目组与美国一家著名的移动解决方案提供商有着一年多的外包服务合作，与对方的PM和资深技术人员沟通。作为他们的中国开发团队，我们的任务涵盖了开发测试等一系列任务，双方彼此非常熟悉。
角色：同事A，一年工作经验；同事H，新人。我，一年工作经验。
事件背景：在部署对方的Server产品时，出现莫名问题，要把Log和配置文件发过去让对方资深技术人员协助查看。配置文件里面写有我们SQL Server的明文密码，同事间争论的焦点在于该不该把密码变成星号。
同事H负责这次的配置文件和Log的收集和打包，而同事A看到后不解，要求同事H把密码改成明文（即Server运行时的样子），同事H以“密文更加Professional（专业）”拒绝修改。于是他倆开MSN讨论组到我这里，我了解情况后，决定改成明文，并向同事H解释了我这么想的理由，于是这个事情就过去了。
事后我一直在想，为什么工作一年的同事A无法让同事H折服，理由有以下：
1. 同事H技术比同事A好。同事A有的是经验，但是技术没有H好的情况下，说话没有太多分量。
2. 同事A只向同事H阐述以前我们是发明文，但是没有说明为什么。而以前这么做，不能成为很好的说服理由。
3. 同事H的“密文更加Professional”这句话很有杀伤力。
技术人员通常有荣耀感，会坚持自己的技术观点不动摇。这一点挺好，但是如果做出了一个错误的判断仍然将一句真理作为支撑自己的后台的时候，有管理角色的人就应该想办法让技术人员心服口服地改变自己把持的观点。所以焦点就在于如何反驳“密文更加Professional”这句看似的真理。
我是这样说的：
1. 密文确实显得比较Professional，可以避免把我们的SQL Server密码泄出去，安全意识很好。（先认同他的思想）
2. 但是要知道，我们合作一年多，就是一个大团队，做同样的事情，只是地方不一样，时间不一样。在办公室里面公用测试配置环境通常对所有项目组成员开放。一句话，对自己人“安全性”的重要性优先级很低。（从本质上反驳密文专业性的意义）
3. 这次我们的任务是希望对方资深人员找出问题，所以真正专业的做法是原封不动的将我们的配置发过去，让他们找出原因。就好像刑事案件现场，作为一个百姓，你做的最专业的事情不是把你认为不需要的东西清理掉给刑侦人员提供方便，而最专业的做法就是保护现场，原封不动交给刑侦人员，以期待犯罪现场重建（Bug 重现）。（结合事例阐述这样做的High-level原因）
4. 从技术方面说，配置文件的密码明文如果不按照规定写法，Server一样跑不起来。如果你将密码变成密文，那么资深人员就会很奇怪，并且不知道是不是当时的密码格式写错的原因。（从技术人员的荣耀的技术方面解析理由）。
就这样，将本环境下的“密文更加Professional”的伪真理去掉了。
不管是软件工程师，还是其他职业，专业性是显示其职业成熟度的一个重要指标。随着经验的积累，面对同一个事情所显示的专业性具体表现也会跟着改变。是为记。
