10倍程序员工作法

开篇的灵魂拷问：

 

我现在的水平

我要到达的水平

我该怎么做？

 

现在的水平：菜，贼菜，巨菜

要达到的水平：阐述一件自己平常的事情，旁人听来却像在吹牛*

该怎么做：睡觉。（梦里实现）。手动狗头hhhh

 

正经点，所谓的10x程序员，是说大佬程序成的工作效率是普通程序员的10倍。

也许有点夸张，但是重点思想是没错的，效率高效与否，最后结果真的差别很大。读过两本讲工作效率的事情，整体提高工作效率的方法总结起来都是一致的：

1、制定目标

2、分解目标

3、保证执行

 

1、以始为终

 

10x程序员专栏提出的一个理念是 以始为终 ，什么意思呢？就是说呀，在事情一开始就想好事情结束的评判标准，也就是指定目标，并且制定好目标完成的标准。

对于一件事情的结束，每个人可能有不同的理解，比如一个需求的完成，我觉得是开发完成就算完成了，然而老大看到的完成是上线完成。

所以，一件事情的结束需要在一开始，在事情开始做之前就要制定好，就像是百米赛跑一样，起点和终点一定是事前测量好的，一定是扯上红布条的，哪能终点在哪都不知道，就开始跑呢？

相对来说，一个可衡量的目标也让人在整个事情完成的过程中是清楚的，清楚自己的进度条，这是一件非常棒的事情。（比如，为什么很多男生追女生，追了一段时间就放弃了？女生也许会想，哎呀

你再坚持一下啊，你再坚持两天，我就同意了。   然而，我连终点在哪都不知道，我连自己参加的是1500的赛跑还是马拉松都不知道，心里哪有底）

em。。。 好吧，这个例子不太恰当。

 

很多时候，事情在做之前，想明白为什做，怎么做是非常有必要的，在过去的一年里，我总是不假思索便去实现一个又一个的需求，连需求做出来是干什么呢，给谁用，怎么用都不明白，

您要是问我：这个需求为什么做呢？ 我也许会回答：这个是我导师让我做的。

可能要问，搞清楚为社么做，重要吗？

以现在来看，很重要。

因为使用场景都搞不明白的话，难免需求完成之后依然有很多的意外惊喜，也就是bug，到时候才一拍脑袋，啊，这么回事啊，我怎么当时没考虑到呢。然后再花若干排期之外的时间去填之前的坑。

所以呀，与其开始做之前就想明白要做什么，考虑到使用的场景，也许就能想明白很多预料之中的事情，同时，定义好完成的目标，才能真正的叫做做完一件事情。

 

一些人说，自己靠直觉就能把事情做好，其实这是一种误解，因为那种所谓的直觉，通常是一种洞见（Insight），洞见很大程度上依赖于一个人在一个领域长期的沉淀和积累，而这其实是某种意义上的大数据。— 10x程序员

 

为什么我们的工作都需要用kpi来定义呢？

这其实就是一种用数字来衡量事情的做法，现在大家都讲数据，都讲量化，为什么呢？就因为直观，例如：这件事情我做的差不多了，这就很模糊，差不多的定义没办法衡量，而如果说这件事情完成了80%，

那就很直观了。所以量化自己是一件很值得去做的事情。

 

2、任务分解

 

一个大问题总是可以分解成若干个小任务的，而任务分解的思路也正是承载了以始为终的思想，在动手之前，先将目标考虑清楚是第一步，任务分解正是以始为终的落地执行。

比如说：我现在想要做一份酸辣汤（hhh），em。。。 好像有点难。

而如果换一种说法：番茄切丁、葱花爆香、番茄炒出汁、。。。 出锅～（路子真野啊，菜谱都出来了）

这样是不是就清晰很多了呢？

将目光聚焦在一个大问题上，可能会感觉到无从下手，而将问题聚焦在一个不用思考，随手就能办的原子操作上，是不是就简单清楚很多了？

同样的，写代码也是一样，一个功能的必然是若干小模块组装成的，如果能提前将各个模块分解出来，最后再像搭积木一样，堆起来，就完事了。避免突然想起xxx功能好像缺少了yyy，再去实现yyy

所以有的时候效率低，往往也是因为没考虑清楚就动手。

 

记得大学的时候，费老师给我讲过的一些话，他说， 一个题目的解决，应当是在脑子里，而不是在ide中 。

虽然我很菜，没能达到费老师的期望，但费老师确实交给我很多做事情的道理。

这句话的意思呢，也是在说，想好了，再动手。

 

自己在写代码的时候很墨迹，就算是一个小的功能，有时候也会考虑很多，比如它的可扩展性怎么样，或者是运行的效率，先不说这样是否是一个好的习惯，单从工作的效率来看，这确实不是一个好的做法。

因为很多事情就是非常简单的，就是能够快速完成的，过分的纠结与代码重复度，确实很浪费时间。那这个时候就需要一种取舍了，而此专栏的建议是：

MVP  最小可行产品（Minimum Viable Product，MVP）

是啊，花最小的代价，做简单的事情。

 

 

3、沟通反馈

 

这块应该分成两部分：沟通和反馈，两块都是同等重要的部分。对于大部分程序员来说，当然也包括我自己，沟通都是一件令人苦恼的事情，所以在与产品同学进行沟通的时候一开始就处于下风，已经败了一部分。

事实上无论是与产品同学沟通还是与同行程序员进行沟通，往往都不能正常流畅的表达自己的意思，这里说的不能正常表达自己的意思是说，无法将事情结构化的表述清楚，所以在平常的工作之间，我们经常会遇到这样的事情：一个小时的会议，讨论了三个小时，主题已经偏离了十万八千里。所以我自己来说是特别抗拒开会的，尤其是最近会议特别多，就神游。

会议应该是用来给大家同步一个核心思想的事情，而不是一堆人一起讨论，要讨论的话两个人约个点满满讨论呗，而不是一起浪费大家的事情，所以我建议，会议上不讨论超多两分钟还没结果的事情。

 

作为沟通的另一个方式，复盘，好吧，我个人目前还不能很好的意识到这个事情，所以也没有理解。

 

反馈是说什么呢？是说自己的输出是否有效，是否达到了自己输出的目的。

不仅是指与人沟通的过程中得到的反馈，别人是否正确理解了自己的意思，还有部分是说自身的代码，是否按照自己的意愿执行，怎么得到代码的反馈呢？监控，grfana就是一个很好用的工具。

建议沟通的时候进行三次握手，自身意见输出、对方复述、自身确认。（hhh，我真的是太有才了

 

 

4、自动化

 

说到自动化，可能第一个想到的是测试，是啊，程序员这个工作不就是将事情自动化么？所以自己的工作有没有可以自动化的？我想是一定有的。

提到自动化，自己刚好是吃了一个大亏啊，其实关于数据校对，BA的数据校对，早就感觉重复且没有意义了，但是自己懒，做事情执行力不够，才导致数据校对脚本这件事情始终没有落地。。。

啊 崩溃。

 

简单的事情自动化，重复的工作自动化，这其中不仅包括上线、部署、测试，甚至部分。。。（自行发挥考虑）

我理解Docker就是自动化的一个落地，部署运维都自动化、简单化。今年也要尝试一下～

这里作者还提到了微服务以及DDD，还有SOLID原则，关于DDD，还有待深入了解再更新。

 

这里贴一下

SOLID 原则

设计模式背后的道理。

单一职责原则（Single responsibility principle，SRP）。

开放封闭原则（Open–closed principle，OCP）。

Liskov 替换原则（Liskov substitution principle，LSP）。

接口隔离原则（Interface segregation principle，ISP）。

依赖倒置原则（Dependency inversion principle，DIP）。

用好单一职责原则，前提条件是看待问题颗粒度要小。

 

记得老大一直告诉我的一个思想：编程中的道与术。

设计模式就是术，SOLID原则则是其中的道，以道悟术，（em。。。  很虚的一个东西，但确实是这回事）

 

 

其他的：

 

作者最后还讲到了一些其他的东西，例如T型人才，一专多能。

 

行吧，看到最后发现和老大的谈话差别不大。。。行吧。

 

—————————————分割线 —————————————

 

说点题目之外的话。

 

一个有效率的人，一定是一个极具结构化思维的人。

无论是以始为终还是任务分解，都是一种结构化思维的体现，都是一种理性逻辑思想的落地。

这些提高效率的思想和方法，去年在读关于效率书的时候，也是这么说的。

然而，始终有些抗拒。我想，从前的我，写诗，写故事，应该是一个感性的人呢，怎么就走上了程序员这条不归路了。。。（好吧，我现在也想不明白）

我内心也清楚，这样做能够提高做事情的效率，最大化时间收益，但是就是拒绝，内心拒绝，总感觉这样违背了通往自由的道路。

内心繁华三千世界，应当是自由的光，自由的风。

若是全部方方正正，道是少了许多乐趣。