高级程序员的技能，对产品而言挺简单的，而初级程序员的技能，对产品反倒是最难的。这种错位意味着什么？ 第1页

这个题我会。

前段时间刚交流了一个CIO，非技术出生，自诩很懂技术。

也的确懂，讲起各种术语、技术、历史、趋势 我只能点头说是。

后来吃饭时，他说HIGH了，开始质疑觉得现在IT分工不合理，根本不需要什么产品和设计，他找一波会编码的人就行了。（我其实已经在心里腹诽了，那你找我们做什么，去招一些应届生写代码啊）

然后他问我，他和懂技术的产品经理有什么区别。

然后我就想起那个让程序员写个功能让程序颜色根据手机壳颜色变化而变化的梗了。

我就问他，为什么这个需求能引发产品经理和程序员大战呢？（实际委婉的多，毕竟他是老大……于是，他没听懂～～）

对我们这些人来说，为什么有中年危机，很重要的原因是我们扯的理念，现在是个领导都会几句。信息嘛，数据嘛，协同啊，数字孪生啊，印文化衫的都懂了。

我们的价值根本比不上会写代码的。

那么，我们的价值是什么？

用手机壳这个例子，就是能解释为什么APP不能根据手机壳变颜色，以及不会提出这种让技术人员返工再返工的需求，以及如果用户真要这个需求我们知道怎么出方案实现的能力。

当然，实际工作里，天天有人提手机壳需求。技术人员也讲不清楚为什么不行，就返工再返工，加班再加班。至于我们这些人带的团队，虽然少了这些折腾，也没有平行世界的对比，看不出什么差异来。于是，反正很少懂的人，就这么折腾吧。

1. 这不叫错位，这叫错觉。你以为A/B/C三套技能里C听着最简单，觉得你自己也能干。其实人家的能力需求不是C，是A+B+C。
2. 程序员必然需要照文档填代码，但不一定需要懂业务。能用傻逼听得懂的方式告诉傻逼他是傻逼为什么傻逼哪傻逼，并且有耐心日复一日持续这种对话的，在程序员里是珍贵的少数存在。
3. 不要浪费时间寻找能让外行简单粗暴判断内行段位的面试方式。道理很简单：你不具备追问技术细节的专业能力，无法判断对方的话是真是假、答案是对是错。
   如果作为外行你招的是非常初级的职位，可以考虑实操考核。不过参见上一条，作为外行你只能判断对方能否胜任最低要求。简单说你只有一个洗脚盆那么深的池子，能测出来他站在里边会不会淹死，但是没淹死的人他是只湿到脚脖子还是到腰甚至到胸口，你是无法确切判断的。虽然很多情况下也不需要知道那么具体。

我给你翻译翻译。

初级程序员：会写字。

中级程序员：熟悉比喻、拟人、排比等各种修辞手法；能写文章讲清一件事、讲好一个故事。

高级程序员：能把教材写的简洁生动、引人入胜。

你：我不会写字，也不认识字。但是我跟着师傅学过说书，知道什么时候该拍惊堂木什么时候丢包袱什么时候断章——所以我觉得初级程序员写字挺难的，但一看高级程序员的要求，生动，引人入胜：这事我擅长！

不。你并不擅长。你甚至连“知道他强在哪里所必需的基础”都没有——就好像你跟着师傅学会了“左脚一踏右脚背，又生生拔起三尺”就说的津津有味却看不到也理解不了为什么部分听众皱眉摇头一样。

正因为缺乏这个基础，你才会觉得“我都会翻身了，离飞起来还远吗？”

这种缺乏基础的、过于巨大的跨越，就导致民间故事里面常见的“治疗绝症的手段是吃掉特定的先生写的两个字”之类桥段，满满的脑筋急转弯风——更好一点就是“神拳无敌孙中山”：听不懂大人物的宏图还看不懂小人物斗殴了？！

当你在某个领域存在新生婴儿一样的巨大空白时，民间故事风自然避无可避。

换句话说，过度无知反而拉近了你和他人在感觉上的距离；一旦知道的多了，才会明白天有多高地有多厚——登堂入室的初级程序员才明白自己和中级程序员能有多大差距；而只有做到了中高级，你才会知道哪怕都挂着同一个“资深高级工程师”头衔的、同一个级别的同事，人家擅长的东西你这辈子都摸不到边（没错！哪怕是同专业相近的两个方向，照样可能隔行如隔山）。

事实上，如果你足够敏锐，那么会发现我说高级程序员写的是“教材”。

没错。初级程序员相当于刚刚接触了物理学、被各种反常识的推论搞的头昏脑胀的新人，所以不得不学着套公式——但即便在这个阶段，他们也已经不会犯“左脚踏右脚背”的低级错误了。

而中级程序员已经把物理学掌握的滚瓜烂熟，可以设计标定汽车发动机变速箱车架悬挂了——如何让它们更高效、更可靠、更安全，这是他们的任务。

至于高级程序员，他的任务更侧重于主导一个车型的开发——在他眼里，不仅仅是车辆外观如何、操控界面怎样设置这样你们产品熟悉的领域，而是在这个外观之下，发动机变速箱该如何布置、如何调整这些更深层次的东西，他都清晰的知道。

举例来说，你说发动机舱能不能再短10个公分，这样看起来更好看更爽利——很简单，纵置发动机改成横置不就行了吗？

但在他眼里，事情没有那么简单。首先结构强度可能存在问题；然后悬挂车架都要重新设计；再接下来变速箱也得大改……其实重新发明一款反而更快；改了变速箱发动机也要改，然后发动机变速箱都要重新标定——所有这些他都做过、也都知道需要怎样才能做出来（换句话说他已经在脑子里把中级和初级程序员要做的事做了好几遍了、确保方案没有瑕疵）。

没错，这你也能听“懂”。但你这种懂仅仅是不识字的说书先生死记硬背物理学科普文章的那种懂——能把它写的轻松生动，让你这样的文盲都懂，这是高级程序员的功底，不是你的。

打个比方的话，冰山露在水面上只有1/10；初级程序员画下了它的轮廓，中级程序员在上面安装发动机；高级程序员心里装满了整个冰山，甚至还掌握了它的剖面图——所以他可以吼中级程序员“别往那装！那里是冰山的薄弱区！装那一开机就碎掉了！来，往这里装！注意这里存在一个解理面，方向是xx-yy，你要针对这个设计方案！”

而你呢，跑过去一看，冰山顶上大红布拉了个横幅“慈禧XXX岁大寿冰山驱动计划II期工程”——好了记下来……啊不对，发动机装这里看起来不好看？能不能换个地方？

高级程序员一听，行，讨老佛爷……啊不，讨用户欢心你擅长。来，换地方！注意冰山那看不见的9/10，换好看地方要加配重，同时这里那里都要加固……这得重新做个方案……没事加预算就是。

于是，你觉得这事挺简单的：不平衡了找平衡、可能开裂就加固，多简单点事……上回书说到哪了？哎呀新的一章还没出来，要不我自己续一个？

到这时候，你才知道，其实你还是那个连为什么“左脚踩右脚背”会被听众嘘都不知道的、不识字的教书先生——你不仅不知道水面下那看不见的9/10，甚至也没走过物理学道路的1/10000。

人家能说的简单清晰、引人入胜，是因为人家对整座冰山、整套物理学结构力学材料力学了如指掌，因此才能删繁就简、把99.9999%的艰深内容统统略去、只给你讲当前面对的问题本质：啊，这里有个看不见的解理面，所以我们必须给它加个固……你一听，啊懂了懂了，也没啥值钱的嘛。

轮到你了，你是基本的物理知识没有、冰山水面下是啥两眼一抹黑、剖面一无所知、材料性质听都没听说过、结构力学……能吃吗？好不好吃？怎么吃？

那么，你闭上眼睛东贴一条西拉一道有什么用？反而把解理面撑裂了知道不？

这种错位意味着你的认知有问题。

我是一个数学、科学工作者，同时是一个从0写出一整颗GPU心脏仿真程序以及仿真心脏模型的程序员。

我是定义我们的产品，解析我们的功能设计，解耦我们的系统程序架构的设计者，是个某种意义上的程序+产品经理。

我是个为了搞硬核科技事业自掏腰包数百万成立企业的创业者。也是为了企业的更好发展撮合各路投资人大量融资的“皮条客”。

我认为自己可以算得上是个problem solver。

但我从来不认为，我们泽森科工从来不认为这样的素质是“高级程序员”。

术业有专攻，越高级的程序员，他的心境，他看待问题和解决问题的技法，他思考问题的点，是越纯粹的。纯粹地就犹如一柄利剑。“一剑霜寒四十川”。

可以闭着眼睛写程序，可以把c++的高级特性如数家珍，在写程序不会写的时候问他们问题比查stack overflow还管用，如同行走的c++百科全书，能够把眼花缭乱的c++技法和模版操作嵌套出如同脚本语言语法的框架端调用，所产生的框架语法写出来的代码能无差别的运行在cpu和GPU上，造福于我们自己的算法和求解器开发工程师。或者能包装和实现出无比繁杂的包括了可视化、编辑、编译等子系统的框架，能把一行行的代码最终转变为易于使用的工具。

这样的人才是高级程序员。在泽森，不管哪个阶段，这样的人的工资必须比行政管理人员高，更比我高。

寻找这样的高手，我们的面试一向是公式化的方法。这是我们的机密。

事实上我发现，凡是能在整个流程中应答如流的人，不管搞什么都能搞成极强的体系化的系统。打个比方，哪怕是让这样的人拧螺丝，他都能拧出一种高精确度的，高自动化的，高定制的，批量化拧螺丝系统。

科技公司的使命和担当永远是且仅是用科技去击穿一个行业，解决一类问题，并成为那类问题的解决方案中的佼佼者。对于科技公司而言，高级程序员就好像核弹头，你往一个有问题的地方扔一枚核弹头。一旦确定好怎么扔，怎么飞，怎么打，核弹头到那儿一炸，那个问题肯定不存在了。

很多领导或者管理者，之所以指望高级程序员会这会那，更多的因为自己啥也不会，甚至还出现自以为自己和高级程序员也55开的产品经理，这样的肯定不在少数，如此认知实在太浅薄了。