上周，地里有消息称：Reddit layoff 10% is coming。
在LinkedIn上看到有post了，据Blind说法是一些组已经开始slient layoff，下周开始massive layoff across teams.
1月25日，有一位reddit员工在地里表示，自己已经被裁。
本来在裁员阴霾下，Reddit的裁员并不意外，10% layoff的数据也并不特殊。
但这位reddit员工被裁后的一些职场感言，却让人陷入深思。

@sunnyafterstorm

讽刺的是，两三个月前的performance review, 我依然被归为strong performance的一类， 独立的开发了好几个影响挺大，用户非常喜欢的feature， 在reddit的网站上得到很多用户的高度评价。manager 和 PM 数次把用户的留言放到ppt上在整个产品部门show off. 可能做决定的大佬们没有留意下面的小字感谢名录。时至今日， 我已经不能meet bar了。
工作期间，我从来没有被manger或其他team push过，因为我总是可以如期交付。现在回想起来，这甚至给了我虚假的安全感，觉得自己应该不会被裁。大家不都说，员工最重要的两点就是听话，出活。我做到了呀！
当有cross-team的工作时，我爱读他们的原代码，直接开始开发胜于和他们讨论设计方案。他们批准了我的PR，但却并不认识我。我也很少做demo，manager说我过于humble，但是我总觉得你做的东西要新颖，用的技术要前沿或者有启发性才好去demo，看到很多人改改button文字，加入i18n支持，或者在后台加一些prometheus metrics , alerts什么的，我老是觉得这种demo我会不好意思。而且我做的产品偏业务逻辑，所以demo讲业务逻辑的实现好像大家会无聊。我也不爱参加meeting或者party，能躲就躲，也许潜意识里我有点回避社交。
这位被裁的Reddit用户感叹：也许在经理和上面的人看来，我只不过就是一只埋头干活的黄牛，现在市面上也许能找到干活更快，也更会来事的狮子老虎，所以黄牛没啥稀罕的。
勤勤恳恳工作，到底怎么样才能被认可和发现？

地里的一位用户，针对职场中埋头干活的人，给出了以下这些中肯的建议。

@qkang：软件开发中的大忌——闷声发大财

在软件开发中，项目早期的曝光度（early visibility）是非常重要的。Early visibility意味着更早的反馈（early feedback），也就意味着更早发现问题，解决问题。我们中国有句老话叫做闷声发大财，不鸣则已，一鸣惊人。这在软件开发中是非常危险的，特别是对于那种单人驱动的项目来说，一个人埋头苦干而其他人却蒙在鼓里可能会导致两个严重后果：
第一是：项目因为未及时发现的问题导致被推迟交付。越是复杂的项目，后期调整的难度越大。你做了一大半最后发现有问题，推倒重来，白白浪费那么多时间，项目自然延期，对客户、团队和你自己都是很大的负面影响。
第二是：Technical debt (技术债务）的堆积。大家有没有过这种经历，组里的某个同事在做一个项目然而你对他的思路全然不知，然后有一天他突然发了一个巨大的CR (Code review), 里面各种不符规范的写法和糟糕的设计，你告诉他这些都不符合组里的coding standard，他却说马上要deadline了，修改的成本太高，必须要尽快上线。你没办法只能先approve，于是technical debt就从这里开始堆积了，你发现你们永远没有时间来重构这段垃圾代码，因为总是有更重要的活，不仅如此，相关的其他feature还必须保证和它兼容，于是越来越多的bad practice被迫出现在你们的代码库里，最后变成几乎完全不可逆的代码“屎山”。
那么我们如何贯彻early visibility呢？
一个核心：一个项目成功的关键，是早点让人们看到你在做什么，并支持你这么做。
我觉得可以从以下几个方面应用：
如果你想搞一个新项目，请提前征求上级的意见。阐明这个项目可以带来多少收益，需要多少时间，得到肯定的答复后再行动。千万不要有“我要给老板一个惊喜”的想法，自作主张。
提前和你的上游（upstream）和下游（downstream）沟通。我们经常需要使用别人已经写好的库，调用其他的service来为我们服务。在做决定用哪个库之前，我们需要咨询它的技术支持这个东西能不能够满足我们所有的使用场景，如果不能，是否有workaround?
反过来，如果我们的服务会被其他组使用，那我们做改动之前需要让他们知道我们的计划。这种上下游之间的visibility不仅可以规避开发中的兼容性问题，还可以给双方足够的时间计划，过程中提出的一些问题也可以给双方带来额外的启发。
开始写代码前先发送一份设计文档（Design doc）并让大家审阅。它不一定需要很正式，不一定需要各种fancy的流程图和接口，有时候甚至一封email就行。
此外，设计文档并不是只在设计新系统的时候才用，只要是具有一定规模和复杂度的任务都适用，就拿开头小明的性能提升项目为例，app目前的性能指标如何？有哪些瓶颈？对应的改进措施，预期收益，action items和ETA都可以被记录在设计文档中。关键是清晰阐述你的思路并让人们理解你要做什么，为什么这么做。尽可能邀请比较senior的人review，包括你上下游的partner engineers，这样才越有可能发现问题，我建议找你认识的最挑剔，最严格，bar最高的人来看。千万不要为了图省事找只一些标准较低的人看，这样就失去了review本身的意义。
发Code review的时候，先发一个小的CR验证你的写法是对的。我把这种方式称为“探照灯”。它其实是一个你整个feature中某一个模块的实现草稿，它的好处是你可以及早发现代码的问题，并一次性把收到的feedback应用到这一模块的所有其他类似的地方。
比如，你需要用React开发一个页面的新功能，那么你可以先发一个CR，里面只包含了一个组件，但是包括了其需要的全部内容，比如styling，数据请求，状态管理等等。这样任何关于这个CR的反馈都可以被应用到之后所有其他组件上，相当于为其他组件树立了一种规范。相反，如果你第一个CR里就写了10个组件，那同样的feedback你都必须把10个组件全部修改，直接浪费了10倍的时间和精力。你可以对每个模块都采用这样的“探照灯”方法，直到整个feature完成。
定期追踪项目进展。对于重要的，耗时较长的项目，定期召集大家跟进是很有必要的，不管是会议、邮件还是其他形式，你需要让所有stakeholder知道以下信息，这样你们可以迅速做出调整，比如向上面争取更多时间，改变优先级等等。
1.目前的进度和成果2.当前的困难和阻碍3.下一步计划和ETA4.可能存在的风险
我们在coding interview的时候，都知道第一件事是clarification，然后告诉面试官自己的想法，面试官认可后才动手写代码。这其实就是early visibility的一种体现。我们要将这种工作方式运用到每一次任务中，这让你和你的组员避免日后花额外的时间精力来弥补因为缺乏及时沟通导致的损失，让项目得以更安全、顺利地推动，最终deliver results。多花10%的时间在前期沟通，让后面90%的工作收益，何乐而不为呢？
更多内容，请阅读：《软件开发中的大忌——闷声发大财》（点击阅读原文）。
职场上勤勤恳恳的态度值得点赞，但是努力也需要被认可和看见。
本文源于一亩三分地的多位用户，如果你有相关的看法或见解，欢迎点击下方小程序卡片，进原帖讨论。

今日推荐

新闻来源一亩三分地用户，版权归原作者所有

本文禁止任何形式的转载，请与一亩三分地联系
继续阅读
阅读原文