10x程序员工作法笔记

╰+攻爆jí腚メ 2023-06-10 14:28 96阅读 0赞

# 持续更新，最近更新时间：2019.10.31 #

# 简介 #

我在[某平台][Link 1]上学习**10x程序员工作法**，特此记录下我结合工作中实际情况对**10x程序员工作法**的理解与总结

### [目录页面][Link 2] ###

--------------------

# 开篇词 #

作为程序员，我们将其看作一个值得全情投入的职业，希望能够把精力放在设计算法、改进设计、优化系统这些具有创造性与成就感的本职工作上。

### 两个概念：本质复杂度（Essential Complexity）和偶然复杂度（Accident Complexity） ###

*  本质复杂度就是解决一个问题时，**无论怎么做都必须要做的事**
 *  偶然复杂度是**因为选用的做事方法不当，而导致要多做的事**
 *  举例说明：比如你要做一个网站，网站的内容是你无论如何都要写的，这就是“本质复杂度”。而如果今天你还在用汇编写一个网站，效率是不可能高起来的，因为你选错了工具。这类选错方法或工具而引发的问题就是“偶然复杂度”

## 程序员现状：大部分程序员忙碌解决的问题，都不是程序问题，而是由偶然复杂度导致的问题 ##

## 一个思考框架、围绕这个框架的原则 ##

*  **原则：以终为始、任务分解、沟通反馈、自动化**
 *  你以为的“终”可能不是终，因为你只是站在自己的角度；你以为自己做了任务分解，在我看来，可能还不够，因为我希望你能够做到微操作；你以为的沟通反馈就是说话聊天，我想告诉你很多技术实践的存在也是为了沟通反馈；你以为自动化就是写代码，我会告诉你，有时候不写代码而解决问题，可能才是一个好方案。

## 不会工作方法没关系，可怕的是深陷泥潭而不自知 ##

--------------------

# 思考框架 #

#### 由于偶然复杂度造成的差距会有多大呢？ ####

1975 年，弗雷德里克·布鲁克斯（Frederick Brooks）出版了软件行业的名著《人月神话》，他给出了一个统计结果，优秀程序员的开发效率是普通程序员的 10 倍。40 多年过去了，这个数字得到了行业的普遍认同。

### 一个思考框架 ###

### 原文 ###

*  Where are we?（我们现在在哪？）
 *  Where are we going?（我们要到哪儿去？）
 *  How can we get there?（我们如何到达那里？）

**这三个问题实际上是帮我们确定：**

*  **现状**
 *  **目标**
 *  **实现路径**

#### 如果一个人能够清晰地回答出这三个问题，通常意味着他对要做的事有着清晰的认识 ####

## 结合具体场景 ##

在实际的工作中，这个思考框架会帮助我更好地了解自己的工作。比如，当一个产品经理给我交代一个要开发的功能特性时，我通常会问他这样一些问题：

*  为什么要做这个特性，它会给用户带来怎样的价值？
 *  什么样的用户会用到这个特性，他们在什么场景下使用，他们又会怎样使用它？
 *  达成这个目的是否有其它手段？是不是一定要开发一个系统？
 *  这个特性上线之后，怎么衡量它的有效性？

如果产品经理能够回答好这些问题，说明他基本上已经把这个工作想得比较清楚了，这个时候，我才会放心地去了解后续的细节。

我们用思考框架对照一下，为什么我会问这些问题。一般来说，一个新特性要开发时，现状我是知道的。所以，我更关心目标，这里“为什么要做这个特性？”就是在问目标，“给用户带来怎样的价值”是在确定这个目标的有效性。

接下来，我会关注实现路径，用户会怎么用，是否有其他的替代手段，我需要了解产品经理的设计是经过思考的，还是“拍着脑袋”给出的。衡量有效性，则是要保证我的工作不会被浪费。

#### 具体问题怎么问遵循四项基本原则 ####

**以终为始**就是在工作的一开始就确定好自己的目标。我们需要看到的是真正的目标，而不是把别人交代给我们的工作当作目标。你可以看出这个原则是在帮助我们回答思考框架中，Where are we going?（我们要到哪儿去？）这个问题。

**任务分解**是将大目标拆分成一个一个可行的执行任务，工作分解得越细致，我们便越能更好地掌控工作，它是帮助我们回答思维框架中，How can we get there?（我们如何到达那里？）的问题。

如果说前两个原则是要在动手之前做的分析，那后面两个原则就是在通往目标的道路上，为我们保驾护航，因为**在实际工作中，我们少不了与人和机器打交道。**

**沟通反馈**是为了疏通与其他人交互的渠道。一方面，我们保证信息能够传达出去，减少因为理解偏差造成的工作疏漏；另一方面，也要保证我们能够准确接收外部信息，以免因为自我感觉良好，阻碍了进步。

**自动化**就是将繁琐的工作通过自动化的方式交给机器执行，这是我们程序员本职工作的一部分，我们擅长的是为其他人打造自动化的服务，但自己的工作却应用得不够，这也是我们工作中最值得优化的部分。

这四个原则互相配合，形成了一个对事情的衡量标准。总体上可以保证我的工作是有效的，在明确目标和完成目标的过程中，都可以尽量减少偶然复杂度。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3ljaGd5eW4_size_16_color_FFFFFF_t_70]  
怎么把这四个原则用在工作中呢？我们回过头来看一下前面的场景，产品经理把要做的功能特性摆在我面前。站在**以终为始**的角度，我需要了解真正的目标是什么，所以，我会关心**为什么要做这个特性**。为了保证目标是有效的，我会关心**它给用户带来的价值**。

有了**任务分解**的视角，我需要将一个大的目标进行拆解，如果我要达成这个目标，整体解决方案是远远不够的，我需要把任务分解成一个一个小的部分。所以，我会关心一个一个**具体的使用场景**。

一方面，我会了解到更多的细节，另一方面，当时间紧迫的时候，我会和产品经理来谈谈究竟优先实现哪个场景。

为什么要学会**沟通反馈**？因为我需要明确，自己是否真正理解了产品经理提交的需求。所以，我要不断地问问题，确保自己的理解和产品经理交代的内容一致。

另外，我也需要保证我的产品做出来确实能够达到目标。所以，我会关心它**上线后的衡量手段**。因为我知道，这个行业里有太多代码上线后，从来没有运行过。

自动化的角度很有意思，**我们做的方案通常是一个自动化方案，但我们需要了解这个方案没有自动化之前是怎么做的**。如果不自动化，用户会怎么用。所以，我会关心是不是还有其它替换方案，比如，买一个现成的服务。因为很多需求的提出，只是因为我们有了一个开发团队而已。

#### 我们不是一个人孤独地在工作，而是与其他人在协作，想要做到高效工作，我们就要“抬起头”来，跳出写代码这件事本身。所以，我在开篇词里说，程序员解决的问题，大多不是程序问题。 ####

--------------------

我的个人博客网站是：[www.coderyyn.cn][]  
上面会不定期分享有关**爬虫、算法、环境搭建**以及有趣的帖子  
欢迎大家一起交流学习

**转载请注明**

[Link 1]: https://time.geekbang.org/column/intro/148
[Link 2]: https://static001.geekbang.org/resource/image/10/3e/10dfc61006956121316d73090ec9cc3e.jpg
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3ljaGd5eW4_size_16_color_FFFFFF_t_70]: /images/20230531/63f1589478fc41c0877a2f08c65d214f.png
[www.coderyyn.cn]: http:www.coderyyn.cn