陈皓文章之记录与摘要

之前写过一篇文章叫陈皓给我的一些启发，在这篇文章中我提到了他给我的八点启发：

• 第一、注重基础原理，基础原理的重要性不容忽视；
• 第二、坚持不断学习、善于思考、乐于实践；
• 第三、一定的批判精神；
• 第四、善于借助工具提高效率；
• 第五、提高效率(学习效率、工作效率)；
• 第六、不给自己设限；
• 第七、对编程的热情；
• 第八、乐于分享。

同样我也提到过他的34篇文章(是我个人看完以后，很有感触的)。我之前阅读过程中也记录了一些笔记，现在将一些笔记摘要分享给大家。

一、加班与效率

加班与效率

1.关于加班

认为加班是公司的核心竞争力，或是超越对手的手段，是一种相当可笑的想法。这说明管理者们已经想不到自己公司的核心价值了。

引用《Rework》提到的两点：
● 条件受限是好事，因为条件受限可以让你小材大用，让你没有办法再用蛮力来完成工作，让你必需去思考使用知识密集型的解决方案来更聪明的解决问题。
● 工作狂往往不得要领。他们花大把大把的时间去解决问题，他们以为能靠蛮力来弥补思维上的惰性，其结果就是折腾出一堆粗糙无用的解决方案。

2.关于效率

很多人不知道什么叫效率，他们以为效率就是：单位时间单位人数下干更多的活。这是错的！效率不是比谁干得活多，而是比谁干得活有更大的价值。效率的物理公式：有用功/总功。换句话说，效率就是：单位时间和人数产生的价值。所以，提高效率，并不是加人，也不是干更多的活，而是，你这么多人干出来了多少有价值的东西。

如何提高效率？
● 1.增加有用功。
● 2.降低总功。
● 3.形成合力。

二、什么是工程师文化

什么是工程师文化？

1.为什么要工程师文化？

计算机和互联网已经渗透到了这个社会的每一个角落，各式各样的计算机技术成为了整个世界发展的强大引擎，各式各样的创新，无论是业务创新还是技术创新，都是依托于技术的快速演进，技术成了解放生产力提高社会运作的效率的中坚力量。

陈皓认为这个世界上有三种商业公司？
● 运营或销售驱动型的公司。
● 产品驱动型的公司。
● 技术驱动型的公司。

2.工程师文化的特征有哪些？

(1)自由

● 自我驱动。
● 灵活的工作时间和地点。
● 信息平等。
● 不害怕错误。
● 宽松的审批系统甚至没有审批系统。
● 20%的自由时间。

(2)效率

如果你因为一个程序员花大量的时间开发自动化的工具，而认为这个程序员没有效率，对之批评甚至惩罚的话，那么你就扼杀了提高效率的文化。

人类之所以比别的动物聪明就是会使用和发明工具。

一个公司的强大之处在执行力，而执行力的强大之处在于你有什么样的支持工具。这些，已经不是工程师文化，而是人类发展的文化。

效率的具体表现有哪些？
● 简化。
● 残酷无情的推行自动化。
● 避免无效率的组织架构和无效率的管理。
● 正确的组件抽象。
● 开发高质量的产品。
● 不断的提高标准以及招聘最好的人。
● 创建一个持续改善的文化。

3.工程师文化如何落地？

● 通过政治手段：你需要把住三个地方 招聘-绩效考核-升职。
● 通过经济手段：让不做这事的成本大于要做这个的成本。

工程师文化要落地，还有以下几个小条件：
● 团队要小，Ownership很重要。
● 热爱学习和尝试。
● 老板更多的相信技术而不是管理。

三、我看绩效考核

我看绩效考核

1.陈皓对绩效考核的主要的观点是什么？

● 第一、制定目标和绩效，目的不是用来考核人的，而是用来改善提高组织和人员业级和效率的。
● 第二、人是复杂的，人是有状态波动的，任何时候都不应该轻易否定人，绩效考核应该考核的是事情，而不是人。

陈皓认为:
绩效分应该打给项目，打给产品，打给部门，打给代码，而不是打给人。然而现在的管理体制基本上都是打给人，而很多根本不擅长管理的经理和HR以及很多不会独立思考的吃瓜群众基本上都会把矛头指向个人，所以，当然会有开批斗会的感觉。

2.陈皓基于绩效考核对公司和管理者想说的话

KPI本身是一种被动的、后置的考察，在工作完成之后考察员工的行为是否符合标准。因此，员工对于公司的目标漠不关心，只关心自己的KPI，因为这才是自己的最大的利益，为了达到KPI，有的员工开始不思考，并使用一些简单粗暴的玩法，其实这样既害了公司，也害了自己。自己的成长和进步也因为强大的KPI而抛在脑后。

当然，KPI绩效考核一般来说，不一定会毁掉公司，相反，对于喜欢使用蛮力的劳动密集型的公司来说，可能还有所帮助，然后KPI毁掉的一定是团队的文化和团队的挑战精神，以及创新和对事业的热情，甚至会让其中的人失去应有的正常的判断力（分不清充分和必要条件，分不清很多事的因果关系）。

3.陈皓基于个人如何面对公司给的绩效考核呢？

用一颗平常心来面对公司给你打的分数，因为那并不代表你的整个人生。但是，你要用一颗非常严肃的心来面对自己的个人发展和成长，因为这才是真正需要认真对待的事。
换句话说，如果要给一个人打绩效分，那不是由一个公司在一个短期的时间打出来，而是由这个人长期的时间里所能达到的成就得出来的。

我们每个人都有适合自己的环境，找到适合自己的环境才是最关键的。与其去关注别人对自己的评价，不如去寻找适合自己的环境。

一个特定环境的绩效考核并不代表什么，而那些妄图用绩效考核去否定一个人的做法，或多或少就是“法西斯”或“红卫兵”的玩法。

考试分数不是关键，别人对你的评价也不是关键，自己有没有成长有没有提高有没有上一个台阶才是关键。KPI不是关键，OKR也不是关键，有没有在做正确的事，这才是关键。

四、如何做一个有质量的分享？

如何做一个有质量的技术分享

1.好的技术文章应该是怎样的？

● 1.把复杂的问题讲解的很简单也很清楚。
● 2.有各种各样的推导和方案比较，让你知其然知其所以然。
● 3.原理，为什么、思路、方法论让人一通百通。

2.一个好的技术分享有哪些应具备哪些因素？

● 1.先描述好一个问题。
● 2.How为What更重要。
● 3.一定要有Best Practice或方法论总结。

模型：问题->方案->总结

五、MEGAEASE的远程工作文化

MEGAEASE的远程工作文化

1.宏观管理

(1)努力找到好的人

团队管理的头等大事是找人，没有之一。

远程团队需要的人一般需要有这些特质:
● (1)能独挡一面。
● (2)沟通能力很强。
● (3)能自管理和自驱动。

(2)设定共同的目标和使命

(3)倾向使用小团队

陈皓结合自身经验的看法归纳如下:
我工作的这20多年来经历过很多公司，尤其是创业这几年来，看过的公司更多了（50+以上了），我发现，人数越多的团队，基本上来说，就更偏劳动密集型。劳动密集型的一个特征就是，大家整天想，得整点什么事给这么多人，好让他们忙起来。而人数少的团队，因为人不够，所以每天都在想，什么样的事更重要，什么样的事可以自动化，怎么做更有效率……..小团队和大团队的关注点就这么不一样了，所以做出来的事也就不一样了。

2.微观实践

● (1)文档驱动。
● (2)自动化和简化。
● (3)Owner文化。
● (4)Review文化。
● (5)目标承诺。
● (6)自我管理。
● (7)闲聊和自行见面。
● (8)知识分享会。
● (9(就地奖励文化。
● (10)外包支持性的工作。
● (11)异步编程。

关于远程工具:
● 开发环境(AWS)。
● 协作工具(Github)以及Google全家桶。
● 通讯工具
○ 语音沟通(Zoom)
○ 工作沟通(Slack)
○ 吹水群(Telegram)

陈皓为什么要推荐这些国外的工具？
他倾向于让大家用上最先进的工具，这样我们团队中的每个人的品味才会被这些好的工具潜移默化。

3.远程工作会议

● Principles(原则)
○ Ownership & Leadership
○ Initiative(主动性)
○ Objectives Oriented(目标导向)
○ Insists On High Standard(坚持高标准)
● Practices(实践)
○ Online(在线)
○ Document Driven(文档驱动)
○ Design Review(设计评审)
■ Background
■ Objectives
■ Alternative Solution
● Reference
● Data
■ Conclusion
○ Simplification & Automation(简化和自动化)
○ Review & Re-factory(反思和重构)
○ Milestone Commitment（里程碑承诺)
○ Evidence Driven(证据驱动)
○ Demo Day(实际例子演示)
○ Effective Meeting(有效的会议)-提出议案-发现问题-共识结论
■ 项目类
■ 方案类
■ 问题类
■ 决策类
■ 信息类
○ 1-2-3 Escalation
○ 3PS Update
○ Disagree and Commitment

六、我做系统架构的一些原则

我做系统架构的一些原则

1.原则一：关注于真正的收益而不是技术本身

● 1.是否可以降低技术门槛加快整个团队的开发流程。
● 2.是否可以让整个系统可以运行的更稳定。
● 3.是否可以通过简化和自动化降低成本。

2.原则二：以应用服务和 API 为视角，而不是以资源和技术为视角

3.原则三：选择最主流和成熟的技术

● 1.尽可能的使用更为成熟更为工业化的技术栈，而不是自己熟悉的技术栈。
● 2.选择全球流行的技术，而不是中国流行的技术。
● 3.尽可能的使用红利大的主流技术，而不要自己发明轮子，更不要魔改。
● 4.绝大多数情况下，如无非常特殊要求，选 Java基本是不会错的。

4.原则四：完备性会比性能更重要

● 1.使用最科学严谨的技术模型为主，并以不严谨的模型作为补充。
● 2.性能上的东西，总是有很多解的。

5.原则五：制定并遵循服从标准、规范和最佳实践

● 1.服务间调用的协议标准和规范。这其中包括 Restful API路径, HTTP 方法、状态码、标准头、自定义头等，返回数据 JSon Scheme……等。
● 2.一些命名的标准和规范。这其中包括如：用户 ID，服务名、标签名、状态名、错误码、消息、数据库……等等。
● 3.日志和监控的规范。这其中包括：日志格式，监控数据，采样要求，报警……等等。
● 4.配置上的规范。这其中包括：操作系统配置、中间件配置，软件包……等等。
● 5.中间件使用的规范。数据库，缓存、消息队列……等等。
● 6.软件和开发库版本统一。整个组织架构内，软件或开发库的版本最好每年都升一次级，然后在各团队内统一。

6.原则六：重视架构扩展性和可运维性

● 1.通过服务编排架构来降低服务间的耦合。
● 2.通过服务发现或服务网关来降低服务依赖所带来的运维复杂度。
● 3.一定要使用各种软件设计的原则。

7.原则七：对控制逻辑进行全面收口

● 1.流量收口。
● 2.服务治理收口。
● 3.监控数据收口。
● 4.资源调度有应用部署的收口。
● 5.中间件的收口。

8.原则八：不要迁就老旧系统的技术债务

● 1.使用老旧的技术。
● 2.不合理的设计。
● 3.缺少配套设施。

对待技术债务的正确态度：

● 1.与其花大力气迁就技术债务，不如直接还技术债。是所谓的长痛不如短痛。
● 2.建设没有技术债的“新城区”，并通过“防腐层 ”的架构模型，不要让技术债侵入“新城区”。

9.原则九：不要依赖自己的经验，要依赖于数据和学习

10.原则十：千万要小心 X – Y 问题，要追问原始需求

七、别让自己”墙”了自己

别让自己”墙”了自己

1.不要限制了自己

(1)做有价值的事情

所谓的有价值，就是别人愿意付高价的，高技术门槛的，有创造力的，有颠覆性的。

(2)扩大自己的眼界，开放自己的内心

(3)站在更高的纬度

a.低维度

● 自己的薪水
● 工作的地点
● 稳不稳定
● 有没有户口

b.高维度

● 眼界有没有扩大的可能
● 竞争力是不是更强
● 能不能解决更大更难的问题
● 能创造多大的价值

(4)精于计算得失

精于计算得失的，就懂得什么是投资，不懂的只会投机。对于赚钱，你可以投机，但是对于自己最好的还是投资。

(5)用于跳出传统的束缚

2.引用庄子的三句话

(1)井蛙不可以语于海者，拘于虚也（空间局限）

(2)夏虫不可以语于冰者，笃于时也（时间局限）

(3)曲士不可以语于道者，束于教也（认识局限）

八、努力就会成功？？？

努力就会成功？？？

1.努力只是成功的必要条件之一而非等同于充要条件

2.“努力就会成功，勤劳就会致富”，不但符合那些低级管理者的利益诉求，同样也符合那些能力不足不愿意学习和成长的人的诉求。因为，他们混淆了行动与进展，忙碌与多产，他们以为能靠蛮力可以弥补思维上的惰性，靠拼命可以弥补能力上的不足……

3.我们应该努力地提升自己，而不是把自己当劳动力一样的卖了，在这样的一个时代，你要做的不是通过加班和拼命来跪着挣钱，而是通过技能来躺着挣钱……

4.努力工作与聪明工作的区别