2021三月底, 我用视频记录了来到新公司的沟通瓶颈. 因为语言环境的改变, 知识领域的变迁, 我们势必会在新公司进步缓慢. 那期视频, 以公司会议为切入点, 聊了三个可攻可守的角度: 1/ 把控会议的开头, 2/ 提前了解沟通的对象, 3/ 会议后总结跟进.

话语权的建立, 填坑

我是2020年挪的坑. 也许是疫情阻碍了进一步交流, 直到次年三月, 我还在等待与组员的无缝沟通.

我还在寻找自己的话语权.

最近几个月的磨合中, 渐渐有成效. 倒不是我的表达能力突飞猛进, 也不仅是高效的会议帮我赢得大家的尊重. 促使现状改变的, 是项目职责外, 我遇到了可以填的坑.

• 比如代码结构有缺失, 那么从从根源找到问题, 出一个万全之策

• 比如运行速度不够快, 那么就去解决速度问题

这些机会有时会被旁人点拨, 也需要自己够胆, 够时间.

一旦顺利填坑, 在这个我们研究透的领域, 我们就是绝对的主角. 此外, 学到的就要教人: 若别人在我们的提点下进步, 还能进一步巩固我们的话语权.

冷静, 保持中立

在技术讨论里, 我们都曾遇到这样的场景: 我们准备了设计文稿, 苦口婆心地标注各类方案, 列举需要大家回馈的话题…

会议一开始, 就变成了两方的争斗. A坚持最正确的工程理念 best practice, "武林至尊，宝刀屠龙!", B觉得自己的设计更胜一筹, 快准狠 high efficiency, "倚天不出，谁与争锋!"

夹在中间, 我很想说, "什么有的没的, 这些我早就考虑过了, 你们到底看文档没有? 玩去!"

但是, 喝住了A, 等于站了B的立场, 反之亦然.

在计划项目的时候, 我通常会把任务分析透彻, 描述得通透, 然后再发出去给别人做. 仿佛写入的细节越多, 接到项目的人成功率就越高.

逐渐, 我发现工作中有两种人: 1/ 不需要你的分析, 他也很快琢磨明白. 2/ 你分析得再透彻, 他还是很混乱, 甚至看不懂任务明细.

咱们今天避开后者, 不讨论. 失败的理由千千万, 不稀奇.

我最近在权衡: 当遇到了第一种人, 效率高, 反应快, 该如何培养这样的工程师? 我大致的想法是:

遇到骨骼清奇的人才

• 1/ 用两到三个项目来磨炼

• 2/ 而后让他单独带一个项目

这些项目平均而言1 - 1.5 年可以轻松完成的. 遇到高效的人, 可能会加快进度.

计划项目的想法

• 如果机会给的太慢: 即便有"卓越的表现"也会随着时间的推移而变成"稳定发挥", 可能会打击积极性

• 如果机会给的太快: 经验不能够支撑他独当一面, 可能适得其反

假设每个项目需要三个月, 这里写下一些潦草的计划, 帮助我们观察工程师的成长进度. 这里我们说的新人, 包括"刚毕业的新人", 以及"跳槽的新人".

项目A: 引导

• 需要其他工程师的直接引导, 帮新人找足资料

• 项目: 细节全部标明, 手把手带上路. 不会有太多挑战.

• 引导: 在这一阶段, 教他做项目, 写代码的基本规范(每个组每个公司规范不同)

• 期待结果: 不懂的问题全部问清楚; 按时完成.

项目B: 协助

• (如果项目A做的不好, 继续第一个项目的策略, 但注意, 新人进度可能有些慢了)

• 项目: 简略细节描述; 要求他自己研究余下的细节

COVID 元年, 我拿了 4 个 offer: Google, Facebook, Uber, Asana. 其中 Uber可圈可点, Offer最为阔气, 忍痛拒绝.

这篇News Letter, 回顾了我最近一次面试的心态, 经历, 和对每个公司的看法.

首先, 简略描述我在亚马逊的 4 年, 以及 2019 年底准备面试的状态.

5 YEARS AGO

接offer, 是我生日(3/20)的前两天. 在亚马逊的第一天, 是5/23/2016. 现在想起来, 很美好.

2016年时, 拿下Amazon的工作. 我还记得那时拿到offer的彷徨, 忐忑, 还有和中了彩票一般的欣喜, 以及入职后的Imposter Syndrome (水货综合症).

虽然不是毕业第一份工作, 但进入亚马逊是入行的第一次认证: “别人可以, 我也能行!”

那时高兴地能飘起来.

在西雅图这座春雨洗过的城市里, 五月, 万物生长, 泥土清新.我仿佛被种进一块肥沃的土地, 终于有个地盘给我成长.

对, 没错, 就是那种感觉, 一切都为你准备好了, 全是新的, 就等你使一把劲.

2 YEARS AGO

人要是不动, 那么迟早有天是要平庸的.

我的人生在2018年稍微失控, 而后整个2019年都在寻找自我的怪圈里. 为了保持心态健康, 也为找个分散精力的事情, 我开始做视频. 一做就是两年, 斜杠程序员土汪: B站, YouTube.

我曾酷爱文章. 续过人家的小说, 编过自己的故事, 琢磨过用字, 也自诩高明地打过笔仗.

后来我写代码了. 代码无情, 有结构但没故事, 有语法但没偏好. 代码的完成意味着一个过程的结束, 而非拉开一场演出的帷幕. 这些都跟写文章写小说差之千里.

生活中我逐渐远离了写作; 我想, 除了入了行的人, 大家可能也都远离了超过5分钟的文字. 随着表达工具的延展, 文字不再具有往日的冲击力. 如果能通过图片在0.1秒内抓住你的眼球, 文章可能需要你阅读至少5分钟.

码字的年岁见长, 工作中逐渐形成另一套写作的天地: 既要严谨的逻辑, 也得在情理中折服众人. 这中, 除了对文字的权衡, 也有对观众的把握, 还要对结构深思, 配上那0.1秒的冲击(图片), 最后需要作者现场的表演来完成文档的使命.

这就是表达工程思想的必经之路: 文档. 可能是工程设计文档, 可能是项目计划文档, 可能是教程文档…总而言之, 能把文档写得漂亮高效, 整个人都觉得神清气爽.

抛砖引玉, 今天我们聊聊写文档的结构.

平时我都在英文环境下做文档, 那么就以此为大纲, 然后加以解释.

假如说, 今天我要写一份教程文档, 譬如一个项目完结了, 我们要记录它的架构, 方便后人理解.

Overview 概括

这部分, 一定要简略: 不需要看你文档的人, 看完这一段可以离开. 需要看文档的人, 让他知道你到底要表达什么.

1/ 简短描述这个文档的意义! (很多人会忘记这一点, 并不是所有人都能立刻明白你的文档作用为何)

2/ 简短描述这个项目是什么

(举例) This document covers the technical design of the chat feature on WeChat. The chat feature allows two or more users to send text messages over the internet instantly.