如何评价王垠在微软「罢工」？
事件背景回顾：
首先，我们需要回顾一下事件的大致脉络。王垠（Wang Yin）是微软的一名高级软件工程师。他在2017年左右，在微软内部的通讯平台（如Yammer，一个企业社交网络）上，发表了多篇言辞激烈、带有批判性的文章，表达了他对微软内部管理、技术方向、组织文化等方面的不满。他尤其批评了微软在某些技术决策上的保守，以及公司内部的“官僚主义”和“虚伪”。
其中最引人注目的是他撰写的《为什么我不同意微软的裁员》等一系列文章，以及他对微软在某些项目上的“政治正确”和“形式主义”的质疑。他的言论在微软内部引起了广泛的讨论和关注，一部分员工表示支持，认为他说出了很多人的心声，而另一部分员工则认为他的言论过于极端、不专业，甚至对公司造成了负面影响。
最终，王垠因为其在内部平台上的言论，被微软以“违反公司行为准则”等理由解雇。
评价王垠“罢工”事件的几个关键维度：
1. 表达方式与内容：
大胆与直言不讳： 王垠敢于在公司内部公开表达对公司战略、管理和文化的质疑，这本身就需要很大的勇气。在很多大公司，员工普遍倾向于保持沉默，避免与管理层发生直接冲突。
批判性与尖锐性： 他的文章内容具有很强的批判性，直指公司存在的问题。他使用的语言非常尖锐，有时甚至带有攻击性，这可能是他被指控“不当言论”的原因之一。
核心诉求的合理性： 从技术人员的角度来看，王垠提出的很多问题，比如对技术决策的质疑、对创新氛围的担忧，都是非常切实的。很多技术人员确实会关心这些问题，并希望公司能做得更好。
“罢工”的定义： 需要明确的是，王垠的行为并非传统意义上的“罢工”（即集体停工以争取权益）。他更多的是一种公开表达异议，并通过文字向公司内部进行“思想上的抗议”。因此，称其为“罢工”可能是一种比喻性的说法，强调其反抗姿态。
2. 公司管理与文化：
容忍度与开放性： 微软作为一家大型科技公司，其内部的沟通渠道和容忍度如何，是评价此次事件的重要标准。一个健康的公司文化应该鼓励建设性的批评，允许员工表达不同意见。王垠事件暴露了微软在接受异议方面的可能不足。
沟通机制的有效性： 如果公司内部存在有效的沟通和反馈机制，员工可能不会选择通过如此激烈的方式来表达不满。王垠的行为，或许也折射出公司内部沟通渠道的不畅或无效。
“政治正确”与“形式主义”的讨论： 王垠对微软“政治正确”和“形式主义”的批评，触及了当下很多科技公司面临的挑战。如何在多元化社会中平衡言论自由与包容性，如何在追求效率的同时避免形式主义，是企业管理者需要思考的难题。
对员工个体权利的尊重： 公司有权管理员工的行为，但这种管理需要符合法律法规和公司自身的行为准则，并且要考虑到对员工基本权利的尊重。解雇一个表达意见的员工，可能会引发关于公司是否过度压制不同声音的讨论。
3. 个人影响与后续：
在技术界的声誉： 王垠事件在技术圈引起了广泛关注，并对他在某些圈子里的声誉产生了影响。支持者认为他是一个有良知、敢于发声的技术人；批评者则认为他破坏了团队合作，言行不当。
对微软的潜在影响： 尽管微软解雇了王垠，但他的言论可能在一定程度上促使公司反思其内部管理和文化。很多员工可能因此开始更认真地思考和讨论类似的问题。
个人职业发展： 被这样的大公司解雇，对任何员工来说都是一次重大的职业打击。王垠后来的职业发展轨迹也成为了人们关注的焦点。他之后加入或创办了新的公司，继续从事技术工作，也表明他没有被这次经历完全击垮。
正反两方的观点总结：
支持王垠的观点：
他敢于说真话，挑战权威，揭露公司的问题，是技术人员良知的体现。
他对公司技术方向和文化提出的质疑是有道理的，许多员工可能也有同感但不敢说。
公司的解雇行为是对言论自由的压制，是一种“秋后算账”。
公司应该建立更开放、更包容的沟通机制。
反对王垠的观点：
他的言论方式过于激烈、极端，缺乏专业性，不符合公司员工的行为准则。
他的批评可能对公司士气和团队合作造成负面影响。
公司有权管理员工在公司平台上的言论，尤其当这些言论可能损害公司声誉或利益时。
他应该通过正规渠道反映问题，而不是在公共平台宣泄情绪。
综合评价：
王垠的“罢工”事件是一场关于“言论自由 vs. 公司管理”的典型案例。
积极意义： 王垠的事件提醒了大型科技公司，在追求效率和统一性的同时，不能忽视员工的个体声音和建设性批评。它促使人们反思，如何在快速发展的科技行业中，平衡多元文化、言论自由与企业内部管理之间的关系。一个健康的科技公司，应该能够容纳不同的声音，并积极回应员工的关切。
消极方面： 从个人角度看，王垠的选择虽然直接且具有冲击力，但在表达方式上确实存在提升空间。过于激烈的语言和公开化处理，可能适得其反，使其核心诉求被淹没在争议之中。在大多数企业环境中，有效的内部沟通和建设性的反馈机制，通常比公开的“抗议”更能带来实质性的改变。
最终评价，往往取决于评价者的立场和视角：
如果你更看重技术人员的个体权利和对公司文化的监督，你可能会高度评价王垠的勇气和直言不讳，认为他是一个为技术群体发声的勇士。
如果你更看重公司运营的稳定性和团队合作的效率，你可能会认为王垠的行为是不专业的，给公司带来了不必要的麻烦，并对他的处理方式提出批评。
总而言之，王垠在微软的“罢工”事件是一个复杂且多层面的案例，它不仅仅是关于一个员工的去留，更是对现代企业文化、沟通机制以及员工权利的深刻拷问。无论如何评价，这起事件都为我们理解科技公司内部的运作以及技术人员在其中的角色，提供了一个重要的观察窗口。
网友意见
王垠成为今天这样，很令人惋惜。
我本科学化学的时候就听说过王垠，那时候我一行代码也不会写。几年过去，如今我平均每周写40小时代码，从AI到NLP到前端全都涉及。Apple的产品换了好几代，微信早已比QQ更流行，国内外的互联网巨头也已经换过几把交椅。而王垠好像没变，连抱怨的语气和理由都与当年退学时类似。
我一直觉得王垠的名气和当年退学引起轰动害了他。记得看过一个理论说起年少成名的危害就是人的心态和状态就会留在成名辉煌时而很难成长。所以这大概解释了王垠的心态为什么这么多年一直这样。只要发文抱怨就会引起关注，在别的方面不能带来心理满足和成就感时，这些关注就好像毒品一样能带来快感。当然我不了解王垠本人还有怎样的苦衷，大家可以觉得王垠这样是不忘初心stay young.
时间过去而人还留在原地，这种事只适合长者而不是年轻人。
王垠在 craftsmanship（手艺）和 engineering（工程）这一纬度上缺乏灵活性而且看起来只能做 craftsmanship。如果你看他这篇《一个人的罢工》（ www.yinwang.org/blog-cn/2017/04/11/strike ）和里面链接指向的另一篇《更新》（ www.yinwang.org/blog-cn/2017/04/06/update ），基本上他最不满意的事情就是自己代码写得比 Principal 好但自己只是 SDE2。我觉得对于这件事情观点可以有两种：
- 因为王垠代码写得比 Principal 好，所以王垠至少应该是 Principal。
- 为什么 Principal 要跟王垠比代码谁写得好？
如果你持有第 1 种观点，而且你不觉得第 2 种观点的那个问题值得问出来，那你可以不用看下去了，因为这个答案不是写给你看的，请你点左上角链接回到知乎首页找别的东西看吧。
我的观点是 Principal 不需要代码写得比王垠好，因为别人有更大的问题需要解决，而解决手段有很多种。写代码或者不写代码，写好代码还是写烂代码，这些都只是解决问题的手段而已，别人需要考虑的是什么手段更适合解决这个问题，而不是跟王垠比写代码。
很多人不明白一家大公司是怎样来运作的，打个比喻来说：国家主席需要思考这个国家未来几年的发展方向是什么，思考的结果可能是「我们要继续提升这个国家的竞争力，尤其是经济上的竞争力，因为未来几年很有可能还是和平，为此这个国家应该制定如下经济增长目标」。接下来他就需要看各个部门如何能够作出相应的贡献，使得这个经济增长目标能够得以实现。铁道部长可能会说，「如果经济按照这条曲线增长并达到目标的话，我们必须预期旅客和货物的运送量按照这样的曲线增长，因此铁道部要制定如下的运力增长目标。为了实现这个目标，铁道部需要增修这么多的铁路，需要这么多的预算，创造这么多的就业机会。」这些目标会被继续分解下去，有人负责某条铁路新线路的项目，有人负责这条新线路上一座铁路桥，有人负责这座铁路桥的施工……任务被分解得越来越细，当然最终有人要负责在把砖头从 A 点搬到 B 点。
大公司的运作方式是类似的：CEO 做的是战略层面的决定，例如 Microsoft 一开始的使命是「使得每张书桌上都有一台 PC」，结果这个使命完成了公司也赚了很多钱。然后各个 VP 要制定自己部门的战略来对 CEO 的公司战略作出贡献，例如 Windows 部门应该规划出 5 年后一款具有竞争力的 OS 应该是什么样子的，如何花 5 年时间做到。接下来 Windows 部门里面负责存储的人开始思考 5 年后的 OS 应该拥有怎样的存储系统——到时候用户的存储需求是什么、5 年时间的硬件性能提升能否满足需求、是否需要重新设计文件系统……任务分解到最后，肯定要有人负责战术问题，例如把某某算法写成代码。
现在值得讨论的是，如果有个搬砖的人说桥梁结构工程师砖搬得不如他好，并且觉得他才配得上工程师的职称，那接下来该怎么办？你先不要笑「为什么一个搬砖的人会懂得结构力学并且能够保证桥不会倒」，真正有意思的地方在于为什么这个搬砖的人不去跟铁道部长比搬砖？不去跟国家主席比搬砖？因为按照他的逻辑，国家主席搬砖也比不过他啊，为什么不让他来当国家主席呢？我觉得根本问题在于他对不同头衔的期望不一样。他心里清楚国家主席干的事情跟他干的事情毫不不相关，但他认为他干的事情和工程师干的事情本质上是一样的只是难度不一样而已。
王垠的问题在于他不知道 Principal 是干什么的，因此他认为 Principal 做的事情本质上跟他做的事情是一样的，从而推导出 Principal 代码必须写得比他好才行。然而 Principal 实际上要做很多他不懂得做也不懂得衡量事情，这些都存在于他盲点当中，所以他只能衡量他能够看得到的。这到底是谁的问题？我觉得个人肯定有问题但也存在系统性的问题。
首先说系统性问题。在我看来很多公司无法向不同级别的员工清晰解释职称体系中不同的级别对应的能力和责任是什么，以及员工要如何才能获得晋升所需的能力和责任。你思考一下：你知道你经理掌握什么你不掌握的技能吗？你知道你经理承担什么你不需要承担的责任吗？对于比你级别高的工程师，你又知道吗？其实很多人是不知道的，公司职称文档那几行字怎么读都读不出个所以然来。
这个级别要能够「设计和实现一个大型系统」，那个级别要能够「成功带领一个团队完成战略目标」，你来给我解释一下系统如何划分小型中型大型？或者说什么样的目标才算是战略目标？存在这种问题的公司不是个别现象，而是整个行业都如此。排除掉那些真心用职称来忽悠人的公司，正规管理的公司为什么不把这个问题解决掉？因为这是个普遍存在的系统性问题，没有办法解决掉。
程序员眼中理想的等级划分就如同数学考试一样：一年级学生懂得做加法运算，然而不知道乘法运算的存在。在他眼里，二年级学生必然在做更多的加法运算，或者对更大的数字进行加法运算。然后老师就会告诉他，「除了加法还有乘法，除了乘法还有指数，除了整数还有小数，除了小数还有虚数，然后还可以有向量和矩阵」。这时候学生就可以问老师「乘法是什么啊？」老师可以给他一本二年级课本让他自学去，如果他能把作业做出来那他可以跳级。这时候就不可能存在一个二年级学生质问「为什么我乘法算得比他快但他是四年级我只是二年级」。你有能力你可以跳级啊。那课本你确实看不懂，那作业你确实做不出来，那你就不要在这里吵了。在这个理想的世界里，王垠可以说自己就应该是个 Principal，让公司给他一个 Principal 才能完成的任务，然后证明他真的胜任，或者真的不胜任。
然而现实世界的职称体系就好像语文考试一样：你把一道高考命题作文交给一个小学毕业生写，他能不能够写？有些人可能直接被吓到了，觉得字数肯定写不够。但有些人会觉得自己能够写，无非就是要想办法增加字数而已，把作文写成长长的流水帐总可以吧？就拿经典题目「诚信」来说，对于一个小学毕业生来说，诚信可能就是「妈妈说我在做完作业之前不能玩游戏，所以我就拼命先把作业完成了，而不是偷偷去玩游戏」。你可以说这离高考命题作文的要求差太远了吧，但一个小学毕业生确实不知道差在什么地方了，因为他无法理解。在他看来他给出的答案就是对题的！同理，如果给王垠一个 Principal 任务，比较好的情况是他直接意识到自己做不到，比较坏的情况是他觉得自己做得到并且还真做了，只是结果跟 Principal 能做出来结果相去甚远，然后他还是不理解为什么自己不是 Principal。
说完系统性问题再说个人问题。很多程序员总是不愿意去理解跟人相关的问题，单纯地认为级别比自己高的人就比自己更厉害，级别比自己低的人就不如自己。这是典型的数学考试世界观。但其实这个世界就如同一个巨大的分布式系统，每一个人都是这个系统上跑着的一个服务，而且每一个服务都充满了 bug。级别比你高的人，只是一个吞吐量更加大的服务而已，不代表他们 bug 比你少。他们吞吐量大可能是因为他们的算法优化的好性能特别高，也有可能是因为他们能够把任务分发给其他服务来处理。
王垠属于那种性能超好的服务，估计能够接近单个服务吞吐量的上限。同时王垠充满奇怪的 bug，例如说他喜欢在 stderr 打印出一大堆信息来抱怨这个 assert 没有通过那个 assert 没有通过，但其实他能够 try-catch 所有这些问题然后继续跑下去。王垠不理解为什么 Principal 性能不如他好但是吞吐量比他高，因为这种情况理论上来说是绝对不可能发生的。其实这个「理论上」只发生在单机环境中，在一个分布式系统里你不一定要自己处理所有的任务，有些任务别的服务处理起来比你快多了，你可以交给他们来处理，前提是你能够正确识别他们的调用方式。
当然调用其他服务说起来简单实现起来难。有些服务的 API 设计得很不好，你发一个请求过去说「做这个任务」，然后收到回复说「这个任务不够有趣我要换一个任务来做」，那你怎么办？有些服务可靠性很差，同一个请求有可能秒回，也有可能永远不回，你自己要设一个 timer 来跟踪这个请求是否应该算作超时。有些服务看起来很可靠，还主动提供一个 event 来不停地通知你任务进度，但问题是这个进度到 92% 就不再前进了，让你觉得很想要重启这个服务，可惜你没有 sudo 权限。
一个吞吐量非常高的服务必须有足够好的算法来优化对其他服务的调用，甚至是优化其他服务之间的调用关系，从而提高一堆服务作为一个系统的吞吐量。在极端情况下，一个高吞吐量服务可以是一个前端 load balancer（负载均衡器），自己不处理任何实际的任务，但必须掌握后端所有服务的状态从而灵活调度。说到这里，肯定有人要跳出来说「某些人就是前端 load balancer，什么活都不干，就是抢 credit」。对呀，某些系统把 load balancer 去掉后也能跑，那你就应该把 load balancer 干掉啊。但某些系统把 load balancer 去掉后会导致后端服务雪崩，结果是你得不到好处还连累了自己。
回到我最开头说的 craftsmanship 和 engineering 的问题上来。王垠只专注于他自己作为一个单机服务的优势，而从来不考虑一个大型分布式系统怎样运作，这本质上就是 craftsmanship 和 engineering 的区别。拿木工为例子：我只需要做好我手头上这一件家具，把它做成艺术品，这就是 craftsmanship。我需要让这件家具做成适应流水线上的快速生产，并且能够在打包进集装箱时尽量省空间，最后运送到全球各地的 IKEA 销售，这是 engineering。
我之前也说过，王垠这样子下去唯一的出路就是找一个很重视他的经理或者高级工程师罩着他，只挑他喜欢的活给他做，并且照顾好他的心情保证他一直开心，让他一直高效产出。用直白的话说，王垠需要一个 load balancer 在他前面，这个 load balancer 能够在一个更大的范围内跟其他 load balancer 协调好，保证适合王垠做的任务总会路由到他这里来。同时这个 load balancer 还要能够正确的解读和过滤王垠的 stderr，只向上一及调用者返回真正重要的信息。不过考虑到王垠自己不理解 load balancer 的价值也不认为 load balancer 有存在的意义，所以这个问题很可能是无解的。
这个世界是一个网游，但王垠偏要当作一个单机游戏来玩，那不管你 PvE 打得有多厉害，你出了新手村就注定被 PvP 虐死。
P.S. 链接打不开的请自行使用 Google Cache。Google Cache 已经失效的话你自己想办法吧。
王银是知乎野生版的李笑来，吐口唾沫都能引发热议，过来开live肯定人满为患，万人空巷，趋之若鹜。不过王银是好样的，再怎么样也不到知乎找存在感，反倒是有些人就因为年少失意，磨磨唧唧，抑郁至今，还搞来一群人口口声声弄出来一个什么x学，搞得好想这事这辈子就完不了了，又劝退又自杀又投胎的，这是人说的话？？知乎不少高中生，听了你的寻了短见你负责？？？非得一堆子人陪着他唉声叹气才好？？？从这点看来，王银做的很好，自己不爽就不爽，最多骂骂对方有眼不识珠，不像一些人，还得拉帮结伙的学习他如何失败落魄，末了还沾沾自喜，小家子气十足，不成气候！
就酱。
类似的话题
本站所有内容均为互联网搜索引擎提供的公开搜索信息，本站不存储任何数据与内容，任何内容与数据均与本站无关，如有需要请联系相关搜索引擎包括但不限于百度，google,bing,sogou 等
© 2025 tinynews.org All Rights Reserved. 百科问答小站 版权所有