• 提出疑问及为之寻找完善的解答，就是推动哲学前进的力量。
  • 思辨的时候，我们首先交换的并不是立场，而是论证。
  • 哲学家们特别致力于追求的，是理解与明晰性。
  • 对每一个哲学问题，只有在理解了问题及其中包含的概念之后，我们才能启程寻找解答。
  • 所以，哲学也总是试着厘清本身使用的基本概念，并借此对人类生命与思想的根本范畴进行理解，这就是哲学家们的核心任务。
• 但是哲学概念该怎么厘清呢？哲学观点又该如何论证？哲学家如何思索人生的重大问题？他们具体来说怎样进行这些工作
  • 哲学的方法，就是完全靠思索。
  • 他们有秘密武器，就是思想实验（Gedanken experimente）。
    • 哲学家们让真实与不真实的情境在思想中上演，从中探查出根本概念的意涵，推翻不同的理论，或者为新的思想建筑打下基柱。
    • 借由这些具体的例子，我们得以认识重要的哲学立场，包括它们有什么长处与缺点
    • 但是最重要的一点是：思想实验给我们提供了独立思考的空间。

• Leading & Lagging Indicators

  Leading

  Influence future performance

  • Inputs
  • We have direct control
  • Fast feedback

  Lagging

  Analyze past performance

  • Outputs (outcomes)
  • no direct control

• Recommendations

  Don't treat leading indicators as goals

  Do pair leading indicators to lagging indicators

  Don't measure just one lagging indicator

  Do understand how lagging indicators affect each other

  Don't measure things without a dilemma that drives them

  Do decide what is your reason for using metrics, and what you are trying to change

When defining OKRs, I find it hard to choose which key results to measure. This talk shed some lights for me by teaching me the differences between leading and lagging indicators.

• Lagging indicators are great candidates for Key Results, since they are out of our direct control but still can be influenced by our hard work.
• Leading indicators are not very suited for Key Results, since they are controlled by us directly and thus can be cheated easily.

That being said, leading indicators are still useful. We can use them to guide our actions. The message here is don't treat them as our goals.

If you want to learn more about metrics, I'd highly recommend this talk.

• Principles From Beyond Space And Time
  • Keep the work parallel, the groups small, and the resources local.
  • Prioritize the development of force multipliers.
  • If possible, factor work products into independent modules; if not, grow slowly and optimize.
  • Scale organizational efforts across a portfolio of synergistic products.
  • Keep responsibility assignment matrices small, sparse, and local.
  • Prioritize asynchronous information distribution over synchronous.
  • What happens inside the boundaries is important.
    • Companies are groups of people being compensated for having to spend some of their finite lifetimes not being with their partners, children, pets, or super weird hobbies.
    • They deserve to be members of organizations which honor that time by ensuring that their work has value and meaning.

IMHO, most management problems come from scaling (a.k.a managing more people). When your team has only 10 people, everything's fine and moving fast. When you grow to 50, that's another problem. When 100, another completely different problem. This post explains why scaling is the root cause of these problems (from a mathematical perspective) and more importantly, some principles to guide us fight these problems.

If I want to help other persons to write all sorts of programs, should I design a small programming language or a large one?

In this interesting talk, the speaker demonstrates the power of a small language with the talk itself.

• A good programmer does not write program
  • a good programmer builds a working vocabulary
  • a good programmer does language design

This quote resonates with me the most.

• “What does DigitalOcean’s tech debt look like?”
  • Software engineers asking about a company’s tech debt is the equivalent of asking about a credit score.
  • It’s their way of gauging a company’s questionable past and what baggage they’re carrying.
• simply because something is “legacy” does not mean it is dysfunctional and should be replaced.
• a three-pronged plan for rectifying the situation:
  1. Decrease the number of direct connections on the database
  2. Refactor Scheduler’s ranking algorithm to improve availability
  3. Absolve the database of its message queue responsibilities
     • StranglerApplication
     • MySQL -> RabbitMQ

A great post to learn how engineers at DigitalOcean deal with tech debts.

Should I make an estimate?

• Is time estimation the right tool for your team?
  • One consequence of time estimates is that they create a de-facto deadline
    • "lurking deadlines"
      • not explicit
      • often arbitraty
    • there are no real consequences for taking an extra week to get it right, and many stakeholders are happy wait a week for a stronger product.
  • The problem arises when estimating becomes a default part of the process for every new feature, regardless of what (if any) value it adds.

Two takeaways from this post:

1. Maybe you don't need estimate when developing a feature: How to Build Software Without Estimates
2. Always question the process: Say NO to Processes