有人问，什么时候一个人的编程水平算可以了，算是小有成就？
我的答案很简单：就是当TA能跳出自己的角色，切换到用户视角来审视自己的软件时。
这个时候，作为一个旁观者，他就能深刻理解用户真正的诉求，从完全不同的角度来审视软件是如何解决问题的！
我们以Word排版为例，想必很多人都思考过这个问题。
在用户的认知里，需求很简单：我打一个字，它就该出现在屏幕上，紧挨着前一个字。如果光标到了“稿纸”边缘，就自动换到下一行。插入一张图片，图片就该显示出来。我可以调节图片的“环绕”模式，让它独占一行，或是像报纸那样让文字环绕图片。至于这些效果如何实现？那不是用户需要关心的事。
但从程序员的视角来看，这完全是一系列“矩形”的运算。每个字符都有其尺寸，占据一个矩形区域，需要在前一个字的“矩形”之后排列。图片本身也是一个矩形，独占一行意味着要把它扩展为占据整行的长方形，而环绕模式则需要在文字流中“抠”出一个矩形“窗口”来放置图片。
你看，程序员和用户看待同一件事物的视角，存在着本质的不同。
推而广之，几乎所有的技术人员与普通用户之间，都存在着这种视角鸿沟。
很多时候，用户觉得“理所当然就该如此”的简单功能，背后可能需要技术人员付出巨大的努力。就像驾驶汽车，我们踩下油门就能走，转动方向盘就能转向，但车内其实包含了防止车轮抱死的ABS系统、助力转向系统、上坡辅助系统等复杂机制。只有某个系统触发警告时，我们才会恍然：“哦，原来车里还有这个！”
我们享受的便捷体验，背后是大量工程师心血的结晶。
正是这种视角差异，导致技术人员和用户对同一需求产生截然不同的看法。用户觉得“易如反掌”，技术人员看到的却是实现成本、技术可行性、细节完备性等一系列问题。一旦技术人员因这些问题而拒绝或质疑需求，用户就很容易产生“这么简单的事都做不到，真难沟通”的误解。
上文探讨了技术人员与外部用户之间的沟通差异。
从另一个角度看，技术人员内部之间的沟通，往往要顺畅得多。
这种顺畅，很大程度上来源于“标准”的统一。
一段代码，只要它通过了既定的测试，满足了功能要求，就很容易获得其他技术同行的认可。技术领域尊重客观事实和运行结果。
当然，技术圈内部也存在“鄙视链”，比如写C++的可能看不上Java，用Java的或许觉得Python不够严谨，而Python开发者又可能调侃PHP。编程语言之间的性能比拼也从未停止。
但这种基于技术选型或语言特性的“鄙视”，通常不会构成实质的沟通障碍。因为我用Python，虽然执行速度可能不及Java，但在快速开发AI应用时就是更便捷。关于这一点，Java开发者通常也不会否认，最多回一句“各有各的应用场景罢了”。
这种“文人相轻”的现象，古已有之。
它更多是技术圈子内部的趣味性讨论或观点分歧，而非不可调和的根本矛盾。
最后，我们来做个总结。
“技术人员难以沟通”这个说法，其实是一个很大的误解。从某种角度来看，技术人员恰恰是非常容易沟通的群体，他们的职业特性决定了其务实、理性、专注于解决问题的特质。
只要需求本身是合理、清晰且具备可实现性的，他们不仅会尽力完成，甚至常常会主动完善细节，追求更优雅的解决方案。
想想看，相比于那些“舌灿莲花”的销售、那些“长袖善舞”的政客、那些圆滑世故的“老油条”，或是那些关系复杂的“社交达人”，大部分技术人员的沟通方式简直像清泉一样直接，他们更愿意用代码和逻辑说话，散发着务实而纯粹的光芒。
专挑老实人欺负，捏“软柿子”，是一种极大的不公。
欢迎在 云栈社区 的 开发者广场 板块，分享你对技术团队协作与职业规划的见解。
发表于 昨天 06:01
|
查看: 5|
回复: 0
