不少优秀的软件工程师都有很强的技术敏感性，
他们会在一切可能的场景中，用技术手段解决问题。
比如，编写软件解决业务相关的问题，
编写软件解决生活中的问题，
甚至编写软件解决编写软件过程中遇到的问题。
这是一种很值得推荐的做法。
因为优秀的工匠不但会制造工具解决问题，
还能制造另一种工具来制造工具。
然而，遇到问题总是一心向技术领域中寻找答案，
就是迷信了，
这会绕很多远路，让人看不清问题的根本原因。
不要强行绕过正确答案
如果某个问题，已经有了正确答案，
那么通过强行否定这个答案，
去寻找其他答案的尝试都可能是徒劳的。
例如，在如果团队发布的软件，代码质量偏低，缺陷频出，
那么最好的办法就是加强自测，增加同行评审，
而不是考虑，如何在不自测不评审的前提下，用软件手段解决问题。
虽然软件手段并非不会缓解问题，
只是不够直接，甚至可能南辕北辙。
代码质量偏低，本来是软件开发过程不注重自然规律，
或者需求管理不善，所导致的结果，
强行对这些病痛的症结视而不见，就会诱发新的问题。
给代码增加静态检查，但仍然不注重自测和需求管控，
无疑是一种性价比极低的解题方式。
因为代码缺陷只是漏洞的一种，更多还有逻辑漏洞，甚至需求不清的情形。
有些问题根本就不是技术问题
很多软件相关的问题，说白了不过是人的管理问题，
如果否认了这个事实，仍旧想通过软件工具解决它，
反而会制造很多不必要的麻烦。
例如跨团队之间的沟通，相信不少人有过这方面的经验，
如果被依赖方的接口频繁修改，就会导致依赖方成本剧增。
这时候我们应该怎么做呢？
大部分团队都会想办法限制被依赖方的变更行为，
这样确实解决了表面现象，但是同时也增加了其他的隐患。
那怎么才能算是正确的方法呢？
这就需要向非技术领域寻找答案了。
首先我们需要分析的是产生频繁变更的原因，
而不是一开始就考虑不准这件事发生。
频繁变更的原因，可能是系统架构的分界处不太稳定，
更可能是团队职责的划分不合理，
组织架构决定了系统划分，所以最好的办法是将变化囊括到一个团队内部完成。
拯救世界的不是技术人员
很多问题的问题本身都是不确定的，
如何确定问题，比如何给确定的问题寻找答案，更难。
因此虽然进展比较重要，但是方向性无疑更为重要。
所以技术人员的价值其实并没有我们自己想的那么重要。
能改变世界的，是那些有商业头脑，
对人文和社会都非常了解的精英人士。
程序员只是工人而已。
有很多程序员虽已从业多年，却仍然不知道为什么要做那个软件系统，
也不知道有哪些人在用它，
更不知道当前系统给用户带来了哪些困扰。
这样看来，仍然将注意力停留在如何编码之上的程序员们，就有些短视了，
看不到团队遇到的问题，看不到用户遇到的问题，
而只是在不遗余力的解决自己假设出来的问题罢了。
是的，写出无可挑剔的代码，没有真的那么重要，
尤其是在投入超支的情况下，
如有必要，一份文档或一次对话，其易理解程度胜过了千百行自解释的代码。
结语
尽一切可能用技术手段解决问题，是一个好习惯，
但是否认其他可能性，就是偏见了。
有时候我们这些软件工程师们，确实应该跳出代码的世界，
找到我们在整个社会大背景中所处的位置。
软件是由人来编写的，用来解决人的问题，
软件的编写过程中，也会涉及人的管理，沟通和协作。
值得多考虑一些非技术手段。