qq_37756660的博客

但是当人生一次次给你亮红灯的时候，甚至告诉你此路不通的时候，你就会慢慢后悔自己的选择，怀疑自己的选择，甚至再有机会到来的时候，你会彷徨纠结，总是对自己做出的选择唏嘘不已，也许山那边风景更好呢。那些我挣扎过的，奋斗过的，失败过的，迷惑过的，也是他们曾经经历过、体味过的。对我的读者而言，我之所以分享，是因为它记录的是我的成长，里面的道理，都不是什么标新立异的新道理，甚至不一定是绝对的正确；有些是走过之后回望的总结，有些其实是当前我认可的，我坚持的，我正在练习的。它记录的，不是我的顿悟，而是我的练习。

同时也要记住，在工作上，对自己力不能及的事情，提早说“不”，无论对人对己，都是负责任的表现。无论是自己当前正在处理更重要的事，或者是觉得自己不是最佳人员，亦或是因为其他原因不能承担某个连续的任务，都要开门见山，把自己的想法和事实清晰地表达出来，不要用借口，承认自己能力有限并不是什么丢人的事，继续努力就好了。2. 如果某件事的处理已经远远超出了你的能力，甚至职责范畴，不要只是为了别人高兴而充当滥好人，揽下来又做不了，或者达不到对方的预期，不仅会耽误人家的事，还会丢失自己的信用分。这时候也可以考虑说“不”。

那些有抱负、有上进心并取得过成功的人，同样会有各种坏情绪，只是他们自身的系统弹性比较好，可以很快地消化和处理这些情绪，而轻度的焦虑和失控状态，有时候更容易激发人的创造力，并保持机体的活力。前几天讨论过一个行为，英文叫做 Rumination，中文直译过来叫做反刍，在这里想要表达的意思就是：反复思量，钻牛角尖，用消极的态度不断地去思考自己的压力、逆境，以至于走不出来，最后形成了焦虑的情绪。别人比你强，也许也是装的呢？每个人都有乏的时候，偶尔放纵自己，也是弹性的一种表现，没什么可自责的，不要觉得浪费了时间。

初级程序员很容易犯这样的错误，比如忘记处理异常，没有考虑某些数值的边界值，没有进行安全校验等等，还有人因为没有仔细阅读产品文档，不知道产品设计已经改变了，也没有进行对应的调整。在竞争激烈的互联网时代，试错当然是好事，但了解错误成本，避免不应该犯的错误，最大可能地从错误中成长，才是我们应有的态度。总结一下，今天和你分享了“技术人如何从错误中成长”的话题，首先，谈到了工作中常见的四种错误类型：伸展错误、无知错误、粗心错误以及高风险错误。因地制宜、对症下药，让错误成为丰富的经验，为你的成长提供充足的养分。

今天和你分享一下我和周围一些朋友在职场曾经犯过的错误，供你参考和反思。基于表述的方便，会采用第一人称或我的同事或朋友的方式讲述，读者们无需对号入座。

从代码提交者的角度，在代码审核中需要注意哪些问题呢？第一，为什么要进行 PR？原因一定要在提交的时候写得非常清楚，才能帮助审核者理解这个改动是不是合理。上面说的四种提交代码的类型，具体是哪一种，应该写到 PR 的小结中，写得越详细越好。这在以后需要进行回溯或追踪系统变化时，也是很有益的。如果改的是前端代码，最好贴一个改动前和改动后的截屏，让改动效果一目了然。第二，除非是极其明显的单词拼写问题，尽量不要引入不是这个 PR 目的的改动。PR 要尽可能保持目标的单一性。

做为一名工程师，免不了与产品经理打交道，如果公司大一些，数据量多一些，还会有数据工程师这个角色。今天会和你主要聊一聊在工作中，产品经理和数据工程师在哪些方面对我们工程师的帮助最大，以及从他们身上都学到了些什么。

编程马拉松：技术创新与团队合作编程马拉松是一种激发创意和团队合作的技术创新活动，旨在在短时间内完成项目，探索创意和想法，展示技术能力。参与者有机会与不同背景的同事合作，建立特殊的纽带。文章分享了两个编程马拉松的故事，展示了技术团队的合作和创新精神。第一个故事讲述了一个项目从编程马拉松成为正式产品原型的过程，以及参与者在活动中结识的好朋友。第二个故事则强调了技术不仅体现在代码中，还包括产品增值和非程序员的贡献。这些故事展示了编程马拉松的技术特点，以及活动对个人和团队的积极影响。

今天，和你聊一聊硅谷互联网公司的开发流程。之前很多文章里就或多或少涉及过这一方面的内容，最近又全程参与并负责了两个大项目，对流程有了更深一步的理解，今天就在专栏里系统地和你探讨一下。总的说来，开发流程包括这么几个阶段：1. OKR 的设立；2. 主项目及其子项目的确立；3. 每个子项目的生命周期；4. 主项目的生命周期；5. 收尾、维护、复盘。

建立明确的责任制，让责任制变得有效而不是形同虚设，最后一点，让员工产生归属感，给他们足够明确和远大的目标，建立独特的企业文化，让优秀的员工与公司一同前行。想要优秀的人产生归属感，仅仅靠丰厚的薪酬待遇和舒适的工作环境是不够的，他们还需要远大的目标和坚定的信念，只有真正伟大的创见，才能让这些优秀的人与公司一起往前走。在硅谷的很多公司，工程师们不仅仅写代码，他们会参与产品和设计的讨论，负责自己模块的架构设计，编写代码实现，然后测试上线，其中任何一个环节都是连续的，并不是工程师们写完代码扔给测试就不管了。

今天和你聊聊 Java 语言，这也是使用最久最熟悉的编程语言之一。读博士的时候我做过两个领域。刚刚进入莱斯大学的时候进的是程序语言设计组。组里当时有两个教授，分别做两个领域。一个是瓦利德·塔哈（ Walid Taha ），主要研究领域是类型系统和嵌入式系统的程序语言设计。另一个是罗伯特·卡特赖特（ Robert Cartwright），他喜欢大家叫他 Corky，主要研究的是 Java 的理论和实现。Corky 教授的研究项目中，有一个叫做 DrJava 的项目。

比如，你需要一个能够带着自己往前走的老员工，那你就要知道，对新人的指导会花费老员工很多时间和精力，当你这样要求的时候，是不是可以提供一些力所能及的回馈呢？你可以和你的领导者一起为你的“成功”或“进步”定义一些可测量的标准，制定可执行的行动计划，然后记录你的发展，按时和你的领导者进行一对一沟通，讨论你的进步，反省做得不够和不好的地方。我在国内的公司工作了将近一年，感觉公司里很多东西以业务为主，而团队的成员结构新人居多，最后做出来的东西感觉业务逻辑满屏皆是，业务代码很重，重复性的东西也多，加班还厉害。

总结一下，今天，从硅谷公司的“多样化”规定讲起，首先谈及了为什么要保持员工的多样化，市场多种组成和用户的多样需求促成了员工的多样化，然后分享了如何保持人才库多样化，最后从人才的多样化谈到了领导者应当具备兼容并包的思维，只有人才的多样化和领导的包容性并存，团队才会越来越好，越来越有活力。最后，员工的多样化也体现在团队的创新思维上。用 Airbnb 的用户群体举例，有的人希望找到比宾馆便宜的落脚点，有的人希望体验一下别人的豪宅，有的人则更想拥有和当地人一样的体验，还有一些人可能仅仅是喜欢尝试新鲜事物。

关于 Java，后面我会写一篇“Java 开发的中常见问题”，下面会来简单聊聊自己对软件工程和编程语言的一些看法，有的是点评别人的观点，有的是我自己的观点，分享给你，希望可以给你带来一些启发。很多时候工程师们争论的问题，不再是对和错、是与否的问题，而是每个人的观点应用到相关的场景中的时候带来的优劣比较。所以，基本掌握了一门语言的功能和语法特性之后，要去做实践和练习，能写生产代码了，再回过头来去看编程语言的本质，了解这门编程语言的设计原理，能力边界和高级功能，这样有助于你更快更好地掌握其他编程语言。

自己的上下级是职场中最无法避免的人际关系，因为各人性格不同，可能你和有些人更容易在看法和决策上达成一致，而有些人则经常不能很好地理解对方意图，需要多次沟通，采用对应的沟通方式。但是，若想职场进阶，一直往前走，到了某个阶段，比如需要你去做更多的协调和沟通工作而不是仅仅写代码的时候，如何处理人际关系就成为了一项必不可少的软技能，重要性不比技术上的硬技能低。总之，人际关系是一个特别复杂的话题，因人而异，更因情形而异，那么如何处理人际关系呢，在这里，我有几点建议，内容可能更偏向于个人感悟，仅供你的参考。

今天和你聊一聊管理的粒度问题，在进入正题之前，先来说说自己的故事。第一个故事发生在离开 Square 之前不久。那时候正值 Square 准备 IPO 的前期，公司频繁重组，很多人的顶头上司在短时间内可能更换了好几个，我也不例外，最后的那个老板，我和他的共事时间一共也就一两个月。他的主要背景是前端，而我一直做服务器端和系统架构相关的工作。成为我的老板的时候，他刚刚转为管理者。

线上支付系统是一门巨大的生意，支付领域的战争正在全球如火如荼地展开，这个领域内的方方面面绝不是我一篇文章能写完的。今天，主要是从一个支付从业者的角度，和你聊了支付领域的技术和生态，包括支付的概况、支付的市场，接下来我讲了讲钱包系统相关的技术点，举了 PayPal、支付宝和微信支付的例子，并简单介绍了 Square 的技术和产品介绍，最后简单展望了支付技术的发展趋势。在现代社会，几乎所有互联网相关的业务模式都和支付有关，支付已经成为很多产品本身的一部分。

在“管理者不用亲力亲为：关键是什么”一文中，介绍了授权和任务分配的重要性。那篇文章的重点有两点：第一我们要有效地把任务分配出去，第二我们要保证分配出去的任务能够被圆满完成。作为管理者，我们平时在项目管理的过程中，更侧重的是要保证团队成员能够按照你的期望值完成任务。今天的这篇文章里，我会进一步展开讲一些项目管理的技巧。这些技巧一部分来自我个人的思考和实践，另一部分得益于我的老板的悉心指导和启发，真实可行并且有效，希望对你的日常管理工作也有帮助。

更重要的是，面试官也是人，难免有一些主观看法，进行两轮面试，两个人的反馈意见就可以相互有个参考，比如应试者是不是两轮都出现同样的问题或者失误，对同一领域的不同问题是不是都有正确的见解等。如果一开始你就比较慢，或者解题比较挣扎，可能面试官就会直接放弃你，虽然他在当时没有明确拒绝，但心中已经给了你 NO，所以剩下的时间，即使你觉得自己把第一部分答得很完美了，然而真相是你根本不知道还有二和三，也就不知道为什么觉得自己把题解出来了，最后却拿不到 Offer。有的时候，两轮面试官意见相悖，加试一轮的情况也并不少见。

在一个初创公司成长的过程中，作为工程师的你也许常常会遇到下面这样的情况。有一天，你看到一个段代码或一个算法，觉得这些代码不大经得起推敲；于是你用 git blame 命令去寻找代码的主人；结果发现，原来作者是如今早就不写代码的 CTO 或 VP。之后，在一个偶然的机会里，你和他讲起这件事，他会自豪地告诉你：“哦，那时候我们必须在一天之内做出这个产品特性。当时也就我一个程序员吧，一天的时间，这是当时能做出最好的方案了。” 说完，他便陷入了对美好时光的怀念里。你也可能听说过这样的故事。

比如，在什么时间内完成什么样的任务，你对这个任务成功的定义是什么样，如果有取舍，哪些是重要的，哪些是次要的，哪些是可以妥协的。另一方面，我那个时候的状态也不对，整个人陷到所有的细节中无法自拔，没办法做到退一步海阔天空，只能紧紧盯住眼前的事，无法看得更高更远，甚至常常在度假的时候也要处理工作上的事情。很多优秀的工程师最初都是独行侠，他们单枪匹马完成了很多丰功伟绩，也更习惯自己独立工作，但一旦他们发现团队协作可以做出更大的成就时，就会从亲力亲为转变为授权模式，帮助别人成功，团队才会获得更大的成功。

如果你的存在能够让别人的工作更好地推进，让别人更容易取得成就，久而久之，伙伴们就会很自然地认可你，信服你，有问题的时候，也会想到要咨询你的意见。在谈判的过程中，你可以让步，但是要让对方明白，这是自己的一个让步，希望对方理解，并在一些自己无法让步的方面提供支持。当然，谈判力是一种不能速成的软技能，但是作为技术人，保持你的逻辑清晰，懂得适度取舍，就是一个好的起点。

几年前，加入了风头正劲的 Square 公司。后来，又加入了涨势甚猛的 Airbnb 公司。在加入的时候，这两个公司都有上百名的工程师，网站和主要产品的核心功能也已齐备。两家创业公司从 0 到 1 的创业过程并没有亲身经历，但是两次都恰好经历了公司从 1 到 N 的扩张过程和业务拆分的过程。今天就和你聊聊，公司从 1 到 N 发展过程中的系统拆分问题。

喜欢工作的人，视工作如生命，他们是真的喜欢工作，加班并不是因为工作忙不完，而是因为热情，他们会享受加班过程中的思维碰撞，更喜欢完成项目时带来的成就感。这些人忙起来，比简单的“ 996 ”还要辛苦得多，他们每天工作 12 小时是常有的事，即使自己的工作忙完了，也会主动去跟技术经理要更多的任务和挑战，或者干脆自己编程学习。我属于典型的工作狂，非常喜欢工作给我带来的享受。其实，对在硅谷奋战的工程师而言，忙不忙完全是由他们决定的，是他们自己的选择，一切工作压力并不来自升职、同事或管理层，而源自每个人的内心。

以上，我介绍了在员工独立完成某项任务的情况下，分配工作时要注意的问题。如果遇到了大项目时，你分解后的项目需要一个团队去协作完成，作为管理者的你应该怎么做呢？这时候，你就需要指定一个团队负责人了，这个人也同样要具备分配任务的能力，很多事他不再是亲力亲为，而是采用本文提到的方法，把需要完成的工作，分配给最合适的人，团队成员通力配合，才能把项目做好。

只要是数据库，就有吞吐量的限制，而数据库访问瓶颈便是自然流量增长或者流量突增造成的。只要你的业务在增长，总有一天数据库访问就会达到一个上限。在这个预警到来前，你需要做各种垂直或水平扩展来提升这个上限，或者，你可以通过缓存和其他机制来对访问量进行分流，这里面可以做的工作就多了。流量的突增一般是类似分布式拒绝服务（DDoS）或市场活动带来的，也可能是因为某个黑天鹅事件造成的，这些原因都很难预料。如果是有计划的市场活动，就需要提前做好各种战斗准备。

不论是哪种情况，那个觉得意外的一方，或者是没有拿到好评的组员，或者是被认为不合格的管理者，都会感到委屈甚至忿忿不平：“我明明做得很好，他平时也说我做得不错，为什么事情最终会变成这样？我们常常只重视自己已知的，却忽略自己不知道的东西，我们关注自己想做的和能做的，却忽视他人的计划和环境。最后给你留一个思考题，你是一个技术团队的领导，你团队里的一个骨干工程师突然提出想去做其他领域的工作，原因是觉得现在的任务对自己太没有挑战了，而他的工作目前非常重要，别人接手会比较困难，还有可能造成项目延期。

1. 建立一定的流程。打开 Google 的官方网站，我们看到的是个搜索框，这个简洁的搜索界面，就是整个 Google 帝国的入口，是浮出海面的冰山一角，隐藏在下面的则是数以万计的工程师和庞大的服务器集群。一旦出现项目延期的情况，我们就能非常清晰地知道是哪个环节出了问题，能迅速地意识并了解这个延迟对整个项目产生的影响和后果，并在第一时间调整需求、计划、人员，重新让项目回到正确的轨道上。有的时候，项目的延期，是因为负责人没有做好计划，或者这个计划没有很好地分享给每一个对项目进度有影响的人，也就是项目干系人。

当然，除了算法导论中那些已成为经典的基本算法以及算法思想（Divide-and-conquer，Dynamic programming）等，其实我们每天接触到的各种技术中，算法无处不在。就拿人人都会接触的存储为例吧，各种不同的数据库或者键值存储的实现，就会涉及各种分片（Sharding）算法、缓存失败（Cache Invalidation）算法、 锁定（Locking）算法，包括各种容错算法（多复制的同步算法）。

因此，对于技术领导来说，团队的成功才是真正的成功。作为领导，你需要时时传达各种信息，比如公司决策、企业文化、项目信息、协作信息、产品信息等，你需要通过自己的表述让全组人员对某个决定或某个项目建立一致的认识，然后才能形成合力，让正确的事情持续发生。无论是工作中的、生活中的，还是情绪上的问题，都可以通过一对一的沟通进行缓解，甚至直接解决。后来，自己成为了技术领导，在与员工一对一交流的过程中，也会注意去模仿这些好的行为，尽管有的地方做得还是不够好，比如听到一些已经从别的渠道知道的信息时，可能会打断谈话者。

其次，作者强调了在接收意见时需要了解自己内心的反应，并提出了克服情感上的抵触的建议。即便你有充足的理由认为对方说的不是实际情况，但如果有不止一个人提出过意见，或者你比较看重提意见的人，这个人可能是你的上级，或者一个德高望重、谨慎靠谱的队友——那你可能就要去思考了，虽然这件事我觉得自己没有做错或不合适的地方，为什么会给别人留下 “我做得不够好” 的感觉呢；4. 对意见里的信息进行分类和过滤，思考一下：哪些是误解，哪些是自己的不足，哪些是自己可以通过沟通去改变的，哪些是自己需要尝试改进的。

实际系统中，幂等是一个极为重要的概念，无论是在大型互联网应用还是企业级架构中，都能见到 REST API 被越来越多地采用，而正确实现幂等，往往是 API 中最难的技术点之一。假如客户端对同一笔交易多次请求，产生的幂等令牌并不相同，那么无论你其余的地方多么完美，都不可能保证 “一个操作如果具有任意多次执行，所产生的影响均与一次执行的影响相同”4. 这个请求到达微信支付端，并且支付交易成功，并且发回回执，然而因为网络原因回执丢失，客户端超时，微信支付收到这样的请求，处理成功，发出回执，但是客户没有收到。

此外，提意见要讲究合适的时机，最好是引导对方自己意识到问题。工作中，相信你一定有听同事展示或汇报产品、项目、报告等工作成果的经历，他们在说完之后，多半会表示有意见尽管提，但是这时候，如果你特别老实，真砸了一堆负面意见过去，换来的很可能是不欢而散。如果一个人给你的反馈 80% 是正面的，另外 20% 是负面的，人的潜意识会接受这个比例，不会产生 “这个人为什么总是挑我刺儿” 的感觉。有效讨论需要心平气和，你可以客观地去说观察到或者了解到的问题，比如在什么情况下，对方做了什么，说了什么，为什么你觉得可以改进。

以前做工程师的时候，更多是单打独斗，只要把自己的代码写好，把负责的项目做好就可以了。那时候，关注的更多是自身和相关的技术与业务。转型为技术经理之后，意识到，必须停止只思考自己的状态，我需要把更多的精力放到其他人和团队上面。一个优秀的技术管理者应该做哪些工作呢？我想，至少需要涵盖 3 个重点。1. 帮助团队成员迅速成长。这包括通过指导、反馈、监督、交流、协调资源等方式帮助下属提升能力，迅速成长。2. 明确地分解与布置任务。

另外，还提到了其他组的改动对A/B测试产生的影响，比较值的趋势必须是收敛的，而不是发散的，以及数据埋点和形成一个流程的重要性。换句话说，你在跑 A/B 测试比较 A 和 B 的优劣，另一个同事在跑 A/B 测试比较 C 和 D 的优劣，结果因为实现细节的原因，A 组中大部分样本同样也是 C 组改动过的样本。于是你通过 A/B 测试，让一部分用户体验新的 UI，另一部分用户继续使用旧的 UI，再对采集回来的数据进行分析，对不同组用户在这个页面上的转化率进行比较，观察在哪一种 UI 下，用户更愿意往下走。

针对这些情况，作者提出了应对错误的态度和措施：追究责任但不惩罚个人，改善流程和制度以避免同样的错误，反复追问“为什么”以发现问题的根本原因，以及建立相互信任和互帮互助的员工关系。如果你是一家公司的技术主管，团队里的一位工程师因为误操作删除了线上的用户数据，这时候你又发现，上个月数据的自动备份因为某些故障停止了，现在你该怎么办呢？在交流的过程中，有人问：“在你们的工作中，工程师的 Bug 或者失误引发的问题，会不会被追究责任，会不会扣工资，会不会被开除？”当时，我围绕着员工的素质、自觉性和责任心进行了回答。

但是，每次别人问问题，你都有现成的答案，或者能快速找到答案，就会渐渐导致两个问题：第一，在你这儿容易得到答案，愿意问你问题和各种琐事的人越来越多；我觉得，如果是一个新人，他刚进入全新的领域，或者所谓的答案就是某些知识点，此时不妨直接给答案或知识点。虽然最终的结果都是对方找到了想要的答案，但如果是通过别人的引导，自己摸索出来的，那么他解决类似问题的能力后续就会提升。欢迎你给我留言，和我一起探讨。获得引导帮助，对方甚至会结合他的经验，经过持续的努力找到更好的答案或者解决方案，甚至引发对系统的改进。