以上就是 10× 程序员的由来。
有一段趣闻。
越线
来自设计师的思考，设计师如何做到 10× ？
可能主要聚焦下面 3 个手段
design systems
在高效的软件开发团队中，使用设计系统已经成为一大创新。
这是因为设计系统可以精确地完成：它们能增加或降低团队需要完成的很多常见任务的价值或难度。
其中一些变化，比如重复使用组件，大家都非常熟悉。
但另一些变化，比如自动化，我们还在探索中。
component
工作的价值可以通过提升其质量来打破常规的限制。
设计系统主要是通过让您反复利用同一组件来达到这个效果；
每一次运用设计系统的组件，都可以在付出很小的额外努力的情况下，大幅提高价值。
- 编写如何使用组件的文档，而不只是提供一个模型。例如，一个按钮，应该是有10像素的填充，并且拥有适当的悬停状态。尽管这样的文档可以帮助开发者初次实现组件的设计，但它并不能帮助增加组件的可复用性。如果你的设计系统尚未达到这样的标准，那你就需要开始制作有助于设计者和开发者使用你的组件的文档了。这些文档应当包含诸如包依赖项，所需配置的变量，以及可能遇到的错误等内容。同时，还应该确保你的组件在Figma，Sketch或XD等设计工具中易于搜索和找到，并且提供明确的指导，显示组件如何与其他的组件或插件进行交互。
- 不要做得过于专业，也不要过度简化。过于通用的组件，如<box>，需要大量的配置和调整才能在实际场景中起作用。过于特殊化的组件，如<SecondaryAutoCompleteModalCloseButton>，往往不适合重复使用，反而会给维护人员带来麻烦。我们需要在这两者之间找到一个平衡点。我个人喜欢用"三次原则"来判断一个组件是否适合被设计系统所使用。
在软件复用的过程中，存在着两个被称为"三的原则"的原则。
- 创建可以多次使用的组件的难度是创建一次性使用的组件的三倍。
- 在一个组件能够足够通用，以至于可以加入到重用库中之前，它应该在三种不同的应用中进行测试。
- 系统性思考。当你的工作开始转变，从一次性设置规格和建设转向创建可重复使用的组件系统时，你就在走向一个复杂且无法预测的领域。系统思维是一种可以帮助你应对这种不确定性的方法和技术。通过掌握概念，比如互联性、互动、出现现象、反馈环和因果关系，可以帮助你很好地预测设计系统的长期效果，即使这种效果往往可能违反直觉。
Automation
设计系统如何减少软件开发所涉及的工作量？
- Design tokens：设计令牌是一种自动化技术，可以方便地将常用的数值在不同度量单位、操作系统或显示模式间转换，大大减少了手动转换的麻烦。这个想法起初是由 Salesforce 的 Theo 团队提出的，现在 Style Dictionary、Knapsack、Diez 等工具已经在实践中运用这个概念。近期，W3C设计令牌社区小组完成了首份标准草案的撰写，为设计令牌技术标准化迈出了新的一步。这意味着，将来所有的设计工具都可以用一种标准化和互操作的方式来创建和分享设计令牌，从而降低了从事这些工作的团队和工具之间的协作难度。
- Design APIs ： 设计API可以显著减少设计师、开发人员以及面向用户的应用程序之间在决策和规格转换上的投入。我近期通过创建一个设计API来验证这个概念；尽管这项技术还处于起步阶段，但看到一个完全自动化的设计系统如何以最低的努力将设计和代码推向用户，的确非常激动人心。此外，像 Specify这样的工具正在不断涌现，使设计API更易被团队接纳和使用。
- 测试和持续集成工具，如 Storybook，让我们可以看到设计系统自动化测试的可能性。Storybook通过针对无障碍操作问题、设计一致性、功能性以及视觉回归进行测试，大幅降低了维护大型设计系统所需的工作量。在我们正在构建和发布组件时，测试会在后台进行，让设计师和开发人员有更多时间去专注于功能优化。
一个新产品 Specify：Your Design Token Engine
忘掉10倍的压力，让我们集中精力在结果上，寻找正向和负能量工作的平衡点。只要团队有意愿，他们完全有可能突破之前的生产力限制。再者，随着设计系统持续创新，我们现在已经有大量的高效工具和技术在握，只等着投入到设计师和开发人员的协同工作中。
这也就解释了为什么设计系统正在逐渐成为构建软件产品的重要工具：原因并不在于他们看起来多么美观（其实有些并不好看），也不在于看似多么高大上（其实大多并不优雅），更不在于他们多么有组织（事实上，这是绝对没有的）。而在于他们让我们的大部分工作变得稍微有些价值，或者说我们投入的努力稍微少一些，又或者两种情况都有。如果你能做到比大多数人更优秀，那你可能就是一名10倍的设计师、开发者或产品经理（无论你是什么身份）。但是，如果你的团队能找到很多小方法让他们的工作提供更多的增值，那么，10倍只是起步。
推荐