读《Software Engineering at Google》（02）

🤔☕️🤔☕️🤔

• 读《Software Engineering at Google》（02）—— How to Work Well on Teams

• 📖：协作三宝 = 人性（Humility）+ 尊重（Respect）+ 信任（Trust）

  🤔：把对方当个人，把团队成员当个人，听起来很沉重，实际上真的很容易，一个不小心就把人当工具，时刻提醒自己不为过。最能体现把人当人，就是尊重，我的想法，他的想法，实际的环境，找出交集，做出选择，并且对选择负责。人是否被尊重，不需要任何言语表达，身体就能感受到。只要能感受到尊重，信任才可能建立，也更容易建立。

  🤔：团队协作，看到这个词，抬头就看向对方。错。看到这个词，要默默从口袋里掏出镜子，看着镜子里的自己，才是谈协作的零启点。想一下我现在是什么（What），想一下我进团队后我将如何（How），想一下我进团队的原因（Why）。三想后自己更明白，再谈团队协作，忽然间有种踏实感，有种实诚感。

  🤔：一个人埋头干，还是尽快跟人分享，我都尝试过。实际经验发现，自己想到的好点子，赶紧在口袋里的小本子上记下来，否则很容易忘记。不过，也没有必要跟别人去分享，因为，大概率冒出点子的兴奋感，会掩盖掉把点子清晰表达所需基本准备，结果往往是对方不太理解，反而会产生一种至于如此的错觉。如果一个念头经常冒出来，口袋小本子也记录了好几遍。这里得插一句闲话，如果觉得口袋里小本子搁腿，就拿出来翻翻，会惊讶自己曾经居然这么胡乱想过。把其中记录了好几遍的念头，就是所谓心心念的那种，规划个初步实现的思路，描一下最终会是怎么个样子，然后就该干起来。如果干着干着就没了，那就没了，说明这个点子，实际上确实激不起自己持续的热情。如果一直在干，一直推进，持续在投入热情和精力，真的会做出些东西，会打磨出个样子。到那个时候，再去分享和交流，特别容易理解的不是对方，反而是自己在其中哪部分有待改进，也特别能够认可人家给出的中肯意见，自己也会发现最得令自己倾佩的地方。这样产生的协作感，即使有时空的差异，也会非常深刻。忽然间明白，为啥都是作家会钦佩作家，他们从来没有见过面，却在字里行间协作出人类思考的杰出作品。

  🤔：DevOps，代码到运维打通，直接需求来自“优惠券快速发放”，实际好处却是给开发带来“真实的勇气”。正如极限编程里的两个关键词“勇气”和“恐惧”。让开发成长的是修改代码的勇气，修改后越快知道结果，越能增强勇气，越具备勇气，越能突破成长的边界。让开发停滞不前，出现在丧失修改代码的勇气，直至对修改代码产生恐惧感，彻底断掉成长的链路。自然也就只会在当下原地踏步，前进任何一步都极其困难。所以，如果把 DevOps 当作一种协作方式，那就属于开发和自己的勇气之间的协作。

• 📖：在一个专业的软件工程环境，批评从来不是个人化行为，只能是整个过程的一部分。

  🤔：批评，这有点丢人，既然考虑到人性，那就会想到私下里，或者在非公开场合沟通。不过，反直觉的是，把批评作为整个过程的一部分，公开去讨论批评，反而所谓是更专业的软件工程。再想想也对，如果专业是指稳定性，那么在过程里公开的批评，必定比个人私下交流更稳定。只要在过程里，必须去解决这些待批评的问题，那么大家就会坦然去开展批评，也就不存在啥丢不丢人。这样的场景里，反而是没人搭理我，没人批评我变成很格格不入的样子。

    —— By 术子米德 @2022.04.10