10xxxx程序员，他们脑子里都是些什么？
软件行业的名著《人月神话》出版，书中提到一个很有意思的结论： 优秀程序员的开发效率是普通程序员的 10 倍 。40 多年过去了，这个数字得到了行业的普遍认同，成为 10x 程序员成为很多程序员的追求。
但工作产出并不只是由编码效率决定的，一些不恰当的工作方法，在很大程度上影响着你的产出。那么，10x 程序员究竟是如何思考问题的？
一个思考框架
这个是一个看似简单，但却非常有效的思考框架，它已经成为我工具箱里一件非常称手的思考工具。 这个思考框架包括三个问题，如果一个人能够清晰地回答出这三个问题，通常意味着他对要做的事有着清晰的认识。
-
Where are we?（我们现在在哪？）
-
Where are we going?（我们要到哪儿去？）
-
How can we get there?（我们如何到达那里？）
这三个问题实际上是帮我们确定：
-
现状
-
目标
-
实现路径
思考框架的应用
在实际的工作中，这个思考框架会帮助我更好地了解自己的工作。比如，当一个产品经理给我交代一个要开发的产品特性时，我通常会问他这样一些问题：
-
为什么要做这个特性，它会给用户带来怎样的价值？
-
什么样的用户会用到这个特性，他们在什么场景下使用，他们又会怎样使用它？
-
达成这个目的是否有其它手段？是不是一定要开发一个系统？
-
这个特性上线之后，怎么衡量它的有效性？
如果产品经理能够回答好这些问题，说明他基本上已经把这个工作想得比较清楚了，这个时候，我才会放心地去了解后续的细节。
四个思考原则
上面的思考框架，让你明白了为什么要提出问题，那么具体问题要怎么问呢？你需要遵循下面这四个思考原则：
-
以终为始，确定好真实目标；
-
任务分解，找到实施路径；
-
沟通反馈，解决与人打交道出现的问题；
-
自动化，解决与机器打交道出现的问题。
以终为始，即在工作一开始就确定好目标。注意，你需要看到真正的目标，而不是把别人交代给你的工作当作目标。可以看出，这个原则在帮助我们回答思考框架中“Where are we going?”（我们要到哪儿去？）这个问题。
任务分解，是指将大目标拆分成一个一个可行的执行任务，工作分解得越细致，我们越能更好地掌控工作。它是帮助我们回答思维框架中“How can we get there?”（我们如何到达那里？）的问题。
沟通反馈，是疏通与其他人交互的渠道。一方面，我们保证信息能够传达出去，减少因为理解偏差造成的工作疏漏；另一方面，也要保证我们能够准确接收外部信息，以免因为自我感觉良好，阻碍了进步。
自动化，就是将繁琐的工作通过自动化的方式交给机器执行，这是我们程序员本职工作的一部分，我们擅长的是为其他人打造自动化的服务，但自己的工作却应用得不够，这也是我们工作中最值得优化的部分。
四个思考原则的应用
怎么把这四个原则用在工作中呢？我们回过头来看一下前面的场景，产品经理把要做的产品特性摆在我面前。
站在 以终为始 的角度，我需要了解真正的目标是什么，所以会关心 为什么要做这个特性 ，为了保证目标是有效的，会关心 它给用户带来的价值 。
有了 任务分解 的视角，我需要将一个大的目标进行拆解，如果我要达成这个目标，整体解决方案是远远不够的，我需要把任务分解成一个一个小的部分。所以，我会关心一个一个 具体的使用场景 。一方面，我会了解到更多的细节，另一方面，当时间紧迫的时候，我会和产品经理沟通究竟优先实现哪个场景。
为什么要学会 沟通反馈 ？因为我需要明确，自己是否真正理解了产品经理提交的需求，所以，我要不断地问问题，确保自己的理解和产品经理交代的内容一致。另外，我也需要保证我的产品做出来确实能够达到目标。因此，我关心它 上线后的衡量手段 ，毕竟这个行业里有太多代码上线后，从来没有运行过。
自动化的角度很有意思， 我们做的方案通常是一个自动化方案，但我们需要了解这个方案没有自动化之前是怎么做的。 如果不自动化，用户会怎么用？我会关心是不是还有其它替换方案，比如买一个现成的服务如何？因为很多需求的提出，往往只是因为我们有了一个开发团队而已。
或许你在疑惑，说我问的这些问题似乎已经“超纲”了，远不是一个普通程序员应该关注的范畴。但这就是真实世界，它不像考试一样，有一个标准答案。
推荐阅读：
