Thoughts on When Moore's Law Ends

My Tactics with Research Projects

Mon, 01 Jan 0001 00:00:00 +0000

Research projects often come with a lot of unknowns. Many engineers find this unsettling because it’s less straightforward than math or digital realm. However, I think we should welcome these uncertainties. They reflect the real challenges of real-world task and provide a chance to showcase our capability, making our work more engaging and lively.

Here’s my strategy to handle a research project:

Clarify requirements thoroughly

It’s important to know not just what is needed but also why it is needed. Finding out why can be tough because people might not want to explain their core motivation, which could be personal or office politics related sometimes. But knowing this helps make better decisions.

Check your inventory

Project Planning Process

Mon, 01 Jan 0001 00:00:00 +0000

1. Have a Vision: Without a clear vision outlining the final goals, how can we measure our progress? And it’s essential to clearly communicate this vision with all team members.

2. Break Down into Tasks and Milestones: To turn our vision into reality, we must break it down into tasks and establish milestones.

3. Identify the Critical Path(s): With goals, tasks and milestones in place, we need to identify the most critical path(s). What are the determining factors for them? They could be technical unknowns, resources constraints, or external dependencies. What are the associated risks?

Software is King, Especially in AI

Mon, 01 Jan 0001 00:00:00 +0000

“Software is king”#

It’s a hard statement to make, as a veteran hardware engineer. Lots of pride and ego to swallow. However, it’s truly based on my observations in the industry. Allow me to reason it with the following arguments:

(1) Software has direct impact on user-experience

It is the last layer that users interact with. And user-experience is the first and last thing will make you standout in the business world with so many competitors. Software directly decides how your users use your product.

System Performance of Edge AI Applications is Beyond Models

Mon, 01 Jan 0001 00:00:00 +0000

After working on enabling use-cases for edge AI accelerator for more than 2 years now, here is some of my thinking about system performance.

Thoughts: Much More Beyond Model#

One of the biggest challenges we’ve been facing is how to improve overall system performance. (While the other is how to quickly enable a model from CPU / GPU backend to custom AI accelerator backend.)

According to my observation, system performance of edge AI has the following attributes:

思考：建立信任的几种方式 (How to gain trust?)

Mon, 01 Jan 0001 00:00:00 +0000

这一段时间在学习B站上资深HR专家王新宇的沟通课，其中有一个主题正好切入到了我工作中遇到的困惑。如何建立信任？

为什么？#

作为团队中的Senior IC（individual contributor），我的日常工作中百分之五十以上的时间需要跟不同团队的manager或者engineer打交道。为的是获得他们的支持或者是合作。而其中很多时候是需要跟陌生的面孔打交道。如何能够快速获得其他团队的成员的支持常常基于最基本的利益以及两者之间的信任关系。利益问题是根本的，与组织架构和项目本身的性质有关，很难短时间内由个人左右。而快速建立起信任关系则很有可能成为项目成功的关键因素。

为什么说利益问题是根本？假设一个场景，如果合作方能够获得正向激励，那么项目伊始对方就有比较强烈的意愿进行合作，则信任度能够很快建立起来。而相反的，如果合作方会利益受损（他们会因此失去一些scope甚至headcount），那么抵触情绪则会令另一方的建立信任的努力完全成为对牛弹琴。

但是利益格局也不是完全不可改变的，双赢的机会是需要去发掘的。这个时候成为一个好的Story teller就很关键。

怎么做？#

首先总结一下，后面再展开：

信守承诺
展现专业度
个人亲近程度

信守承诺#

从长期的角度来看，“信守承诺”是唯一可行的建立并维持信任的方法。当然是越重大的事情、越困难的承诺在对方的心目中越有分量。但是在交往初期，从小事开始信守承诺是快速建立起信任的方法，比如说守时。

展现专业度#

在工作关系中，高专业度往往可以简单有效的另对方产生信任。专业程度的考量往往因人而异，是相对的。这也很容易理解，因为对于初入职场的人而言，他们往往对于专业还不甚了解，那么这个“是否专业”的阈值就比较低。而要在顶尖的专家所擅长的领域展现专业度，则是非常困难的。这个时候不妨另辟蹊径，从其他的方向出发，比如说运动、艺术等领域先入手。这个时候如果有一些业务擅长的兴趣爱好就能达到较好的效果。而且如果这个领域也恰好是对方感性的方向，则更加事半功倍。

个人亲近程度#

想要快速提升信任度则可以借助于个人亲近程度。可虽然见效快，但很容易饱和，且不容易持久。对于刚刚展开的工作关系，闲聊有的时候能够快速拉近亲近关系，以此建立初期的相互信任。所以，有的时候：“沟通的目的就是沟通本身。”

思考：研究与工程(Thoughts about Research and Engineering)

Mon, 01 Jan 0001 00:00:00 +0000

在一个尚处于快速发展和迭代的领域，例如AI，由于各种新方向的不确定性，研究和工程常常很难互相配合甚至互相纠结掣肘。从而导致，要么工程实现犹犹豫豫、方向摇摆不定；要么研究做得差，无法做到引领方向、开拓新领域的作用。

工程实现的主要矛盾是执行效率。所以它不能够常常进行大范围的功能变更，同时要以最终产品（deliverables）作为主要导向。而且最终产品的功能（functionality）和质量（quality）是其主要量化衡量标准。因此工程实现中的流程化是非常重要的手段。良好的流程能够提高大规模组织合作效率，提升可追溯性以及可重复性。

前沿研究的主要矛盾是创新性以及量化评估。创新性很好理解，就是需要跟踪业界的最新发展动态，并在此基础上发展出符合自身情况的创新性想法，并加以实现。量化评估则涉及到一个系统能够快速准确的对不同的创新性想法和实现方法进行量化分析，并得出不同条件下的最优选择结果。因此研究过程中就不能循规蹈矩，需要跳出条条框框（think out of the box）。所以前沿研究是反流程的，而且需要反流程。但是需要注意的是，公司内部的研究团队毕竟和大学不一样，它们需要为最终产生经济效益而服务，并且有较强的时效性。因此能够对创新性想法进行原型化（prototyping）是非常重要的。

研究与工程的共同点就是需要非常强的Ownership意识。研究团队更多的分散作战，类似游击队。每个小团队多则数人，少则一人，他们为自己的方向选择、成本控制以及原型化负责。团队之间的互相配合主要在于分享思想，所以他们的组织架构更适合自下而上的组织方式。工程实现则类似集团军会展，团队规模依据项目不同从数十人、数百人到上千人，需要很好的纪律性以及互相配合，责任分工需要非常明确。所以他们的组织架构更适合自上而下的组织方式。

为促进研究与工程的相互理解和交流，以及比较好的做法就是借助于矩阵架构，鼓励人员内部流动，防止出现结构性的组织壁垒。在矩阵架构里，应该以纵向的项目负责人或者负责团队为主导，在组建项目实施团队的过程中，他们需要“说服”研发人员加入他们的项目。而横向的人员管理（people manager）则应该处于配合角色，主要侧重横向不同领域的人才招聘、团队建设、职业发展和领域内信息交流。由项目负责团队和人员管理团队互相商讨确定项目实施团队的规模、日程计划和日常化项目管理。

思考：过度沟通（Over-Communication）

Mon, 01 Jan 0001 00:00:00 +0000

沟通的重要性自不必多言。对于任何规模的组织来说，沟通对于该组织的成功都是必不可少的。因为人类的合作是基于沟通的，至少在脑机接口和人类之间的心电感应成熟之前。正确的沟通能够让信息流通，并因此产生正向的合力。

有很多关于沟通的文章，我在此不再赘述如何正确沟通。在此我想提出另一个概念称为“过度沟通”。“过度沟通”中的“过度”不是贬义，而是指在正常程度以上再进一步多加一些努力，多一些重复。

为什么需要在“正常”程度以上再做努力？因为人性。

人是懒惰的

如果你曾经有过这样的经历，你就不难理解了。会前将提前阅读（pre-read）的资料发下去了，并多次强调请参会人员在会前提前阅读，以便节省会议时间。但是在开会中，仍然有80%的人没有认真阅读过，尤其是当提前阅读资料本身就非常多的情况下。

这个时候可以学习Amazon的规程：

精简提前阅读（pre-read）的资料，去掉可有可有的部分，并提炼出大纲方便大家索引。
会议开始后单独辟出10～15分钟，用来给参会人员阅读资料。

人是健忘的

尤其是需推行方案与其内心所假设方案不完全契合，或者本身就对整体方案不甚了解的情况下，很多细节都容易被无意忽略掉。

这个时候就需要重复沟通：

不假设所有人在所有时刻对所有细节都了解，对于重要细节重复沟通和确认。
对于低层次feature需要形成测试用例，并加入CI/CD系统反复测试。
对于高层次feature需要形成checklist并设置单一责任人，在各个项目里程碑重置并做逐项检查。

人是有局限性的

人的知识背景和经验积累都是有局限性的，尤其是在复杂项目中，参与人员会有不同的专业背景，也会有不同的经验积累程度。

这个时候就需要：

将细节形成文档，并公开文档以供参考。
文档需要由专人负责维护并更新。
- 初稿应由技术主管（tech lead）起草，后续由专职文档写手（technical writer）负责维护和更新。
- 文档也有生命周期，在周期过了之后，需要decommission。
文档不仅需要包括what，还需要包括how，以及最重要的why。
- 不同的文档听众会有不同的查看权限，因此需要区隔开来。
- 文档的复杂性导致它不可能一蹴而就，因此需要有耐心长期更新。

Final words

因此，当你为沟通不畅而感到烦闷的时候，思考一下是那些人性弱点导致了这些问题，然后对症下药。此处仅抛砖引玉。