在我看来，与问题本身的难度相比，解决问题的方式、步骤以及反思的程度，才能体现出一个人的职业素养。

在某些需要说“不”的场景中，可能的最好结果，是你和你的经理共同追求的目标。最关键的是要找到那个共同目标，而这往往有赖于协商。双方需要坐下来讨论预期冲突的产生原因以及潜在应对方案，前者用来重新梳理流程，后者用来面对客户。

有时候，提供太多细节，只会招致更多的微观管理。

没有“试试看”这回事。如果你此前并未有所保留，如果你没有新方案，如果你不会改变你的行为，如果你对自己原先的估计有充分的自信，那么，从本质上讲，承诺“尝试”就是一种不诚实的表现。你在说谎。你这么做的原因，可能是为了护住面子和避免冲突。

我发现，要精熟掌握每项技艺，关键都是要具备“信心”和“出错感知”能力。

代码必须能够帮你解决客户提出的问题。很多时候，客户提出的需求其实并没能真正解决他们自己的问题。这有赖于你去发现这些问题并与客户交流，以确保代码能够满足客户的真实需求。

程序员大多自负、固执、内向。我们不是因为喜欢和人打交道才做这一行的。大多数人之所以选择以编程为业，是因为喜欢沉浸于弄清各种细枝末节和摆弄各种各样的概念，以证明自己拥有这个星球上最发达的大脑，而厌恶陷入与他人交流的错综复杂的混乱之中。

在每分钟进行许多次编码/测试的状态下，你身上的肌肉记忆了要敲哪个键。意识中较基础的部分识别场景，在百分之一秒的时间内做出合适反应，大脑则可放心思考更高层次的问题。真正的挑战是把一个题目练习到炉火纯青，你可以窥见其中的韵律。

在工作中，有一种现象叫观察者效应，或者不确定原则。每次你向业务方展示一项功能，他们就获得了比之前更多的信息，这些新信息反过来又会影响他们对整个系统的看法。

模糊不只来自于分歧或争论。有时候，业务方会想当然地认为看文档的人懂得自己的意思。

“凡是不能在 5 分钟内解决的争论，都不能靠辩论解决。”争论之所以要花这么多时间，是因为各方都拿不出足够有力的证据。所以这类争论依据的不是事实，而是信念。有时候，最好的办法是抛硬币来决定到底如何选择。如果问题解决了，这个选择就是对的。如果遇到了麻烦，你可以退回来选择另一条路。明智的做法是，选定一个时间点或者设定一系列标准，来决定什么时候放弃。

专业开发人员能够清楚区分预估和承诺。只有在确切知道可以完成的前提下，他们才会给出承诺。此外，他们也会小心避免给出暗示性承诺。他们会尽可能清楚地说明预估的概率分布，这样主管就可以做出合适的计划。控制错误的办法之一是“大数定律”。意思是：把大任务分成许多小任务，分开预估再相加，结果会比单独评估大任务要准确。

今天发呆的时候思考了一下目前使用的面试框架，发现实际上还是存在无效面试的问题。面试的主要目的在于区分候选人，所以实际上包含多个不同衡量指标，比如：技术能力、沟通能力、理解力、个人发展意愿与团队匹配性等等。

可以看到，单独某一个指标很难体现候选人的“可用性”，或者说仅专注于某一指标的面试流程并不能很好地体现候选人的综合能力。毕竟 “team work” 不是单纯的一问一答，而“八股文面试”便存在这个问题。在一个复杂环境中解决问题实际上需要多种能力的结合，这在候选人与公司的双向选择过程中需要尤其注意。有一些措施可以用来改进面试流程：

• 阅览候选人的博客、GitHub 等来了解他的代码习惯、学习能力；
• 基于候选人的既往项目经历来评估其综合能力（若有开源项目，可以让其尝试讲解某段代码）；
• 可以使用白板算法面试，但不局限于可运行代码，更多理解思路；
• 其他硬指标（工作年限、英语要求、技能匹配程度）可依情况变动。

SVG 相关

• viewPort：相当于显示器屏幕；
• viewBox：相当于在屏幕上截取一小块，放大到整个屏幕窗口；
• preserveAspectRatio：指定 viewBox 与 viewPort 的对齐方式和缩放方式。
  • <align>：
    • none：不进行强制统一缩放；
    • x(Min|Mid|Max)Y(Min|Mid|Max)：参考实例 Demo。
  • <meetOrSlice>：
    • meet：保留宽高比、viewBox 在 viewPort 范围内可见、尽可能放大 viewbox；
    • slice：保留宽高比、viewPort 覆盖 viewBox、尽可能缩小 viewbox。

D3 API 架构（playground）