会上有两个话题，1､职场的困惑和不爽；2、成长的选择和原因。

有朋友说，这样的讨论没有意义。不管你愿不愿意，社会总会逼着人成长，大家都需要成长，只是有时候不知道怎么更好地成长而已。

其实，如果积极参与讨论和思考的话，应该能发现Tiny兄谈到了一些自己成长的办法：比如营造圈子，放开自己的思维；比如想做什么事情，就买十几本相关书籍来看；比如把事情按重要性和用时排列出来；比如分解项目，快速迭代。

会上我说，我是必须成长的。因为我依赖于大脑中力量感不断成长的过程来让自己对生存下去有足够的兴奋度。也许，我不会因为自己停下来而自杀，但我真的觉得如果我停下来了，那就跟我现在就死掉了没什么分别。

OK，让我们回到问题：我怎么成长？

腾讯的朋友说，喜欢在工作过后总结自己的方法论，来指导自己下一次的工作，我对方法论的总结有着巨大的热情，然后是整天在总结调整方法论，什么事情都不做。

这是我最新的成长方法论，刚刚今天下午和老婆讨论敲定的：

173 指模书伙

排列改分复简

先说“17､3“。这里是一天24小时的时间管理。17小时工作学习，3小时睡觉。可能你会觉得奇怪，还有4小时呢？早、中、晚餐＋洗澡，共4小时。17小时，我已经提出来很多天，很多人说3小时的睡眠绝对不够，不现实。无所谓，你可以根据自己的需要去调，比如12小时工作学习，8小时睡觉。作为一个方法论，或者说理念，我喜欢清楚明白地表明它的极限。我觉得工作学习17小时，是正常人的极限。我提出以来，只有一天完成过。也许效率并不高，不是最优，但我还是建议大家试试，哪怕只试一天一次。

在漫长的工作学习时间，又可以怎么样加速成长呢？大家最害怕的时候是什么呢？往往把生活的其它方面压缩得尽，挪出一大片时间来，结果还是一无所获，只是让身体越来越差，是不是？我们需要对这个漫长的工作学习进行测量，究竟有没有足够高的效率？我们得追问，一段工作学习时间过后，我们能有什么产出？

于是就轮到“指模“。因为是我自己用的东西，我只从自己的行业来给出回答：我需要在一段时间段内，产出两个东西，编程指南和程序模块。

程序模块，很好理解。程序员，就是写代码。把自己写的代码重构成一个个的模块，方便自己下次重用，或开源互相学习。但为什么要有编程指南，而且还把它放在程序模块之前呢？

过去，我写程序，总是写到哪算哪，很少去思考去设计，反正先写，跑起来，如果出错，再随便改一下，再看看能不能跑正常。这种做法，对于简单的问题，效率有可能会高，但一遇到稍为有一点点复杂度的编程，非常容易掉进“百试不灵“的坑里。我希望自己可以先去学习、理解问题的相关领域背景知识，根据自己的理解进行设计，再去实际写码。从瞎写，到有计划有设计地实现。所以，我希望自己可以先输出编程指南，再写出相应的程序模块，这样也更方便与人交流互动。

巧妇难为无米之炊，知道自己要输出什么之后，事情的另一面是，要知道自己需要输入什么？

输入的主要来源是“书伙“，就是书籍和小伙伴们。我以前都是先自己一通瞎写，实在不行，就问问别人，如果长时间下来还是没能搞掂，才去看书，从头学习。同样的，碰到简单问题，可以非常快，但只要稍为复杂一点点的，就是时间的大片白费。

所以我现在都是要求自己，先看书，再问人，最后才来自行研究。先看书的好处是，书一般都讲得相对系统全面，可以让你有一个更大局的视野。看完书后，对事情本身已经有了基础认识，就可以针对特定小伙伴提出更有意义更接近解决方案的问题。而且在这个时候，你可以在问答中进行更多互动，而不是在什么都不知道的情况，光听别人讲，自己一点都不消化。

时间、输出、输入，都有了。我们还需要处理中间环节：输入之后，通过什么样的处理过程，才能更好地保证我们的输出质量？

首先，根据输入资源，把事情的各个部分按重要性和用时，一一“排列“清楚。长久以来，我拒绝把事情排列清楚。原因简单，我担心这个行为会让我觉得事情太难，影响我下手的决心和速度。但事实上，因为没有把事情排列清楚，我下手虽快，但没盲目。经常的情况是，早早下手，却一直不上手。因为，往往我会不自觉地去做一些，耗时很长，却不怎么重要的事情。

我曾经忽悠自己，所有事情都重要，任何事情只要没解决好都会影响结局。而事实是，如果我不尽快拿出一些成果来，我会没有了继续下去的激情，也很难获得帮助。

所以，“排列“清楚，不只是为了获得事情的全貌，更重要的是“排列“之后 ，它可以让你开始安心地专注于其中一个部分，调用所有脑力来解决眼下的小问题。这样会使得问题被解决的可能高非常多。一个小问题一个小问题解决下来，剩下的问题，会随着你经验的增长而变得越来越容易。同时，任何其他人，也只有看到你产出的东西，才有途径给适当的反馈和帮助。而不会停留“加油，好好干，你一定行“这样范范应付之词。

我把这一步称为“改分“。从排列得出的全貌中，根据当时的情况和限制，选择部分进行首先改善，然后持续快速迭代。

当我们说改善部分，快速迭代时，其实这里面有一个坑：如果你一个小问题都解决不了，还快速个屁。因此，我们需要进一步回答，什么样的行为可以使具体问题变得更容易解决？

我自己主要用两个招：1､不停地变换角度；2､把所有体会进行精简整合。

我尽量不让自己陷进“A好还是B好“这样的无聊痛苦抉择里。而是，先从A的角度出来，不关注任何B的信息，把A好好的实现一遍。然后再返回来，不关注A，好好把B实再一遍。两遍下来，我依靠本能都知道自己应该选什么。而且因为两个角度都走过，我可以比一般的人有更多的体会和经验。

即便是先只从一个角度出发，要查找资料或寻求建议的时候，我们往往会碰到“大长长串信息“，什么“高效人士的七个行为习惯“、“提高效率的35个办法“，这些东西的困难在于，当你要用的时候，你得回去翻书。太过庞大，以至于它们没有办法常驻大脑。大脑不是特别适合拿来存储的设备。它最多就放些指针，放些索引，放些目录。甚至于这些提示信息，如果没有一个特别好的系统关系，大脑在把它们重新联系的时候，也会花费大量的时间，而且容易出错。所以，我经常对我想到的东西进行精简。

不停精简，有两个显注的好处：1､你要记的东西变少；2､精简之后，更容易看到事物的联系。精简过后，你可以非常轻易地从大局出来，观察所有部分的变化，你会更容易从精简信息中，体会它们之间的互相影响。把一个细节，放回到整个系统；把一个行为，放回到整个事件。我们的理解能力可以大幅提升。

我把这两招简称为“复简“。

去过广州乱谈会的朋友，或是看我的乱谈会感受的朋友，不难发现，在乱谈会上，Tiny兄讲过这里面的好几个技巧：书伙、排列、改分。这也是为什么在没有做笔记的前提下，我能记住Tiny兄那么多观点的原因，因为我一直在想这些问题，有了一些自己的总结，所以听Tiny兄聊的时候，巨有共鸣：）

就像Tiny兄在会上强调的，也许你光是听别人讲，也能有一点点收获。但是，这样的收获注定是比较肤浅，除非你也开始试着去讲讲自己的想法，即使这些想法是大牛们已经讲过无数遍的。自己讲一遍，就可以加深对牛人观点的理解，这么划算的事情，何乐而不为呢？用你自己的语言和声音，把你听到的想到的体会到的任何观点、理念、想法再讲一遍，对你对别人都会是一件非常有益的事情。加油：）