“我只想做技术，走技术路线。”
“我对技术感兴趣，我只想做技术，走技术路线。”
这句话是不是很听过呢？请不要误会，这句话本身没有问题，但是说出这句话的软件工程师中，十有八九有一个误区，就是高估了技术本身在个人职业生涯中，起作用的占比。而我，曾经是其中之一。
我多次听到来自家长这样的评论，说是他/她的孩子不善言辞，缺乏沟通技巧，然而罗辑思维缜密，对于软件技术充满热情，想做一个出色的程序员。
我觉得，这样的言论，既对又不对。对的是，如果刚踏入职场，相当一个优秀的程序员，我觉得上述的优缺点，都很 “契合”，或者说，也许只需要学好技术，把确定的任务做完、做好，就能找得到工作的褒奖，就能胜任岗位。但是，随着你继续在职业生涯的道路上向上突破，基本坚定地走着技术通道（譬如我），上述能力的缺失，而造成的 “短板效应”，会越来越明显。
个中的原因，其实并不难理解。软件工程师，不是搞学术，而是搞工程，而工程能力，是一个非常复杂的多面体。比如提到的沟通合作的能力，是根本就绕不过去的。职场这些年来，我已经无数次看到那些所谓的技术 “牛人”，有着优秀的独立问题分析与解决的技能，却总是在贡献与晋升方面迟人一步，甚至多年过去，也难以在职业生涯的路线上，迈入更高的台阶。
除了沟通，再举一个例子，管理能力。我知道很多铁了心要做技术的程序员，也包括曾经的我在内，是对 “管理” 这个词有着不由自主的排斥。总对公司那些技术优秀的工程师，却 “转管理” 嗤之以鼻。
某些总失偏颇的媒体也报道，“国外”（他们口中，中国以外的世界仿佛没有太大的分别，统一以 “国外” 概括之）五十岁的工程师还在写代码，六十岁的程序员还在发光发热……我理解这样的想法，但是这里被忽略掉的一个事实是，即便在那样技术通道被极大地保护的环境里，即便继续走坚持技术路线，坚持写代码，随着职位的升高，管理的工作就是不可避免地越来越多的，这是软件之所以为 “工程”、而非 “工学” 的一个特性。
换言之，“沟通” 也好，“管理” 也罢，即便对于技术人来说，也都是逃不掉的。你要跨团队合作，你要带着一票人一起攻克项目，团队能达成的事情，在重要性上往往要盖过自己在努力啃着的特定的问题。
当然，工程这个多面体中，除了 “硬技术”，必备的 “软能力” 有很多，我只是拿这两个方面举了例子。那么，再说一条我认为比较重要的能力吧——对于实际问题、模糊问题的挖掘和剖析能力。
事实上，这一条也是我参与的软件工程师面试中，非常重要的一条考察项。实际问题总是模糊的，先要把问题搞清楚，抽象成一个软件可解的问题，再使用各种软件的工具（代码）来解决问题。
你看，这里面有两个步骤，而在我们所熟悉的教育体系中，后者被极大地强化——算法、数据结构、库、平台……这些涉及的技能领域，都在后者这个 “解决一个已经经过抽象了的问题” 上面；而对于前一步骤的学习，往往是不足的。
什么才是 “模糊的实际问题”？随便举个例子：
我们公司内部有大约 100 个服务（service），提供不同的功能，分别由不同团队维护。现在需要你带领一个小团队，来设计实现一套监控系统，统一监控管理这些服务的健康状况。你打算怎么做？
这就是一个非常模糊的实际问题，不是一个算法问题，也不是一个传统意义上的系统设计问题。但这是一个真正的、实际的 “软件问题”。
最后，我想说的是。日常的工作中，也许我们一猛子下去扎得很深，但是我们还是需要时不时地跳出每天琐碎的条条框框，站高一点审视一下，自己在职业生涯路线中的位置，尽量带着技术人的决心和热情，但不要带着技术人的封闭与迂腐。
作者介绍
熊燚，笔名四火，现于西雅图 Oracle 任首席软件工程师一职，负责研发云基础设施的分布式工作流引擎。曾先后任职于华为、亚马逊，做过多种类型的研发工作，从大小网站到高可用服务，从数据平台到可视化系统，他带领团队攻克过数个项目难关，在全栈之路上具有丰富的实战经验。
31天拿下K8s含金量最高的CKA+CKS证书！
Redis 官方可视化工具，功能真心强大！
一文带你掌握 Zabbix 监控系统万字长文，带你搞懂 Kubernetes 网络模型
K8s 选 cgroupfs 还是 systemd？这是一个问题Linux 运维工程师的 6 类好习惯和 23 个教训顶级 DevOps 工具链大盘点
某外企从 0 建设 SRE 运维体系经验分享
Nginx+Redis：高性能缓存利器
主流监控系统 Prometheus 学习指南一文掌握 Ansible 自动化运维Linux的10个最危险命令24 个 Docker 常见问题处理技巧这篇文章带你全面掌握 Nginx ！搭建一套完整的企业级 K8s 集群（二进制方式）
点亮，服务器三年不宕机