Source, 之前私下里也和一些同学讨论过「如何才算是好的领导」，答案各有千秋。这篇文章的作者基于自己近距离接触过的几个优秀领导者（包括乔布斯、皮克斯创始人等），总结了他们的一些共同特征。
里面提到了贝佐斯的一个例子，基于三个核心构建的战略体系：更低的价格、更多的商品、更快地送达。
我常被問一個問題：「在接下來的 10 年裡，會有什麼樣的變化？」……但我很少被問到：「在接下來的 10 年裡，什麼是不變的？」我認為第二個問題比第一個問題更加重要，因為你需要將你的戰略建立在不變的事物上。
在亞馬遜的零售業務中，我們知道消費者會想要更低價格的產品，10 年後仍然如此。他們想要更快的物流，更多的選擇。很難想像，會有顧客在 10 年後跑來和我說：「Jeff，我喜歡亞馬遜，但你們的價格能不能貴一點，或者到貨時間再慢一點。」
…… 所以我們將精力放到這些不變的事物上，我們知道現在在上面投入的精力，會在 10 年裡和 10 年後持續不斷的讓我們獲益。當你發現了一個對的事情，甚至 10 年後依然如一，那麼它就值得你將大量的精力傾注於此。
越是重要岗位的人才，越要多花时间挑选，据说 Uber 的 CTO 被「面」了两个礼拜，聊了近 30 个小时。
里面提到的一个判断方式：如果你私下的行为和沟通对员工完全透明，会不会因为某些话或某些事而感到尴尬。想起了 Gitlab 的这次删库事件，很好地践行了公司的「透明文化」，对于提升团队成员之间的信任会有不少帮助。
Great leaders treat these challenges as opportunities to build trust. They ask themselves which course of action and which style of communication will increase the trust that employees have in them. When faced with a difficult challenge, they optimize for trust.
Buffer 是一家针对分享进行优化的公司，可以定时发送分享、查看分享数据等，目前已有 300 多万用户，公司提倡「透明文化」，包括薪资体系（每个人拿多少钱都是透明的，包括 CEO，有意思的是薪资排名第 4 的居然是一位 iOS 开发同学···）。就目前的各种数据来看都可以算作成功的公司，但在 11 年申请 YC 孵化时，还是遭到了拒绝，当时每月只有 44 个付费用户。
YC 的回复也是挺讲究的，一再的强调自己可能会错过一些优秀的公司，让被拒者的感受会好很多。
文章里附上了当时申请 YC 时的原文，YC 的一些问题也是挺有意思的，比如会问：创始人之间认识多久了，是不是都见过面了；最成功的一次 hack 非计算机系统的经历。
Who are your competitors, and who might become competitors? Who do you fear most?
– Losing our focus on what the customer needs and focusing on whom we fear most is what we fear most.
最近在逛 Chromium 官网时发现了不少好货（上面的内容真是多···），随便挑了个 Disk Cache 的 Design Doc 喵了眼，非常细致，结构也很清晰，表述方面只要有基本的计算机经验基本都能看明白。摘录最开始的一段 Overview（可以看到作者考虑到了很多的点）
Overview
The disk cache stores resources fetched from the web so that they can be accessed quickly at a latter time if needed. The main characteristics of Chromium disk cache are:
* The cache should not grow unbounded so there must be an algorithm for deciding when to remove old entries.
* While it is not critical to lose some data from the cache, having to discard the whole cache should be minimized. The current design should be able to gracefully handle application crashes, no matter what is going on at that time, only discarding the resources that were open at that time. However, if the whole computer crashes while we are updating the cache, everything on the cache probably will be discarded.
* Access to previously stored data should be reasonably efficient, and it should be possible to use synchronous or asynchronous operations.
* We should be able to avoid conflicts that prevent us from storing two given resources simultaneously. In other words, the design should avoid cache trashing.
* It should be possible to remove a given entry from the cache, and keep working with a given entry while at the same time making it inaccessible to other requests (as if it was never stored).
* The cache should not be using explicit multithread synchronization because it will always be called from the same thread. However, callbacks should avoid reentrancy problems so they must be issued through the thread's message loop.
还是从 Chromium 官网翻出来的（Chromium 的开源真是彻底···），这是一份真实的 Chromium 项目的 OKR，来大概瞄一下:
可以看到
- 不是所有的 Key Results 都要可量化的，有些技术点确实很难量化。
- 虽说 0.6 - 0.7 是比较合适的得分，但还是有不少同学拿到了 1 分。
- 一个 Objective 下，可以有多个人对 Key Results 负责。
Source, like this
我自己也维护了两个类似的 Board，一个是 Personal，还有一个是 Work，同时使用了最近上线的「完成」功能，这样就能知道这一周大概做了哪些事，方便写周报···
Source, 作者提到了 5 点，深有感触。
很多新技术并不见得有多大的使用场景，而且会很快变成旧技术，与其花时间在这些上面，不如在基础知识／专业技能栈／大公司出品的流传较广的项目上多下点功夫。
花在一个 Feature 上的时间包括调试和后期维护，这样一算的话，在前期多花点时间（比如写 Design Doc、单元测试）会划算得多。
通过透支体力来赢得信任，终会因为疲惫不堪而辜负信任。
the real heroes are the ones who are consistently reliable. They say what they’ll do and do what they say. The only way to be that kind of hero is to manage expectations.
时间花费是一项投资，找到合适的目标也是一项艺术，也就是做前多思考，做这个的收益如何，有没有更高收益的事情。
人的注意力资源是有限的，高效工作的时间通常不超过 4 个小时，多留一点时间给生活和家人。
很不错的 InfoGraphic
Gitlab 的数据库意外被删事件，相信都有所耳闻，他们甚至在 youtube 上开启了直播修复过程。大概过程是一位运维人员在晚上 11 点「疲劳驾驶」，误删了线上的 db，而五重备份全部失效，只能从 6 小时前的数据进行还原。过程比较漫长，吃瓜群众们看得也是津津有味，虽然是一个低级错误导致的严重问题，但 Gitlab 的一些关键举措还是挺值得点赞的，因为 Gitlab 以「透明文化」著称，所以无论是修复过程，还是事故报告 都可以看到，对于「肇事」员工的处罚也是颇为有趣，罚看 10 小时的彩虹猫···
PS: 有人找出了「硅谷」里的一段视频来描述 Gitlab 当时的场景，还是蛮贴切的···
整个事件我认为对于 Gitlab 是加分的。
git commit -m "fixed issue with fan"
工程师懂的···