我们常听说“工夫在____之外”，下划线处是个填空题，一切跟技艺相关的事情都可以填入。这本源自宋代大诗人陆游的典故。陆游为教导其儿子如何行文作诗，在《示子遹》中指出，“我初学诗日，但欲工藻绘，中年始少悟，渐若窥宏大。……汝果欲学诗，功夫在诗外”，以此告诫其子除学习作诗基本知识外，还要在生活中不断提升修为、学养、操守、道德等。之后，“功夫在诗外”慢慢被修改成“功夫在功外”，对于我们软件工程来说，也可以说：软件技术，工夫在软件技术之外。缘何有此感，且听我娓娓道来。

        最近，甲方频繁因为收不到违章检测数据而找我，经反复仔细查看日志，前端卡口抓拍机采集设备数据拿到了，我也入库了，违章图片也如数上传到甲方的Ftp服务器上了，整体逻辑也没问题，但就是时有时无，经过多轮的debug，我的耐心已消耗殆尽，处于十分恼火烦躁的状态。违章图片数量和甲方收到的违章事件列表数量有出入，这是一个十分隐蔽的错误。后历经反复核对数据对象的各个域，终于发现原来是车速过快时，影响车型识别准确率，明明是标准的小轿车，却标识成未知类型。这本也无伤大雅，任何采集设备都有精度和调优问题。但我要说的是，我因为自己自作主张的“好心”，而误了事。为啥这样说呢？因为我在一系列的过滤违章逻辑里，加上了一个排除“行人、二轮车、三轮车以及未知车型”的逻辑，这就导致本该纳入列表的事件，因为车型未被识别出来，而被我滤掉了。于是我欣喜之余，总结出了一条还算能弥补我心灵创伤的经验：以后TMD严格按照甲方需求文档开发，多一分少一分都不要。免得生事端。

        冷静后，仔细思量这个问题，以上结论不对。作为一个工程技术人员，对承包方负责、以一个审慎的态度思考问题，并无过错，这恰恰是该提倡的态度。那么问题何在呢？其实恰在于这个自做主张，所谓的好的发心，事前并未和甲方对接人商量沟通。你凭啥断定人家对于非机动车型的超速没有使用价值？凭什么给人家滤掉，不如实上报呢？……如果有什么好的优化建议、不良后果提醒，这些都该事先沟通明白，一则统一口径，厘清权责，不至于事后落埋怨；二则人家多少还能知咱个情。真是“世事洞明皆学问，人情练达即文章”呀。这并不是教人圆滑、世故，而是合作需要透明化，事情要像“小葱拌豆腐”一样——一清二白。大家都清清楚楚做事，毕竟大方向是统一的，大家都是为了赚钱，承包方把活儿完成，乙方把钱赚到，甲乙方并无显著的对立。

        推而广之，做很多事都是如上。在处理人际关系亦是如此。以前以为很多事自己心里清楚就行，发心好就行，至于别人理不理解，不必要张扬，甚至暗自为他人的误解不买账显得自己灵魂高尚而暗自庆幸，现在想来，傻X一个.
        及时准确的沟通，使得可预见的问题前置，有病早治，这非常有必要。

        好了，这就是为甚我言：软件工程，工夫在技术之外的原因。