分享 通过「刻意练习」，你才能成为顶尖的程序员
作家格拉德威尔在《异类》一书中指出：
人们眼中的天才之所以卓越非凡，并非天资超人一等，而是付出了持续不断的努力。1 万小时的锤炼是任何人从平凡变成超凡的必要条件。
他将此称为「一万小时定律」。
要成为某个领域的专家，需要 10000 小时，按比例计算就是：如果每天工作八个小时，一周工作五天，那么成为一个领域的专家至少需要五年。这就是一万小时定律。
如何打破无休止的加班？
在中国，IT 行业普遍加班严重，先不说行业特征与企业文化。 就我最近面试的经验来看，很多程序员的开发效率实在是低到不忍直视。
所以「效率」是一个导致加班的重要因素。 如果你效率高，但迫于企业有加班的文化，你完全可以用加班的时间来学习一些新的技术，进一步提高自己的效率。
效率低会引起下图的怪圈：
效率低 -> 无法按时完成工作 -> 加班 -> 没有时间练习 -> 效率越来越低。
要打破怪圈，有效的办法就是「刻意练习」，从此进入一个正向循环：
效率高 -> 提前完成工作 -> 练习提升 -> 效率越来越高。
别把工作当练习
演员在台上的表演算是练习吗？球员在比赛场上算练习吗？不算。 那么对程序员而言，工作上做项目算刻意练习吗？
我以前以「能边学边做」为荣，API、语法之类的没必要看，反正我们有 Google 和 Stack Overflow 嘛。 直到我参加了 Hackthon 之后改变了这个观点。在极短的时间内，要把一个创新的想法，用技术手段实现出来。 这个时候如果你还在查某个接口应该怎么用，某个语法应该怎么写，能竞争得过别人吗？
现实工作中何尝不是如此？商业竞争如此激烈，假设你要做个推荐系统，你是找做过的来做，还是边学边做？
所以我认为练习应当发生在工作之外，一旦上了战场，不是你死就是我活。
怎样练习才有效？
并不是所有的练习都是有效的，没找准地方，只是在浪费时间。
比如，我用吉他弹一首曲子时，某个小节老是弹不好，我就会单独把这一个小节拿出来重复练习，而不是把整首曲子一遍一遍地重复练。
专家研究表明，只有在「学习区」练习才最有成效。 我们应当走出舒适区，多在学习区练习，将其变成舒适区； 接触恐慌区，将其慢慢变成学习区。
这样才能避免原地踏步，持续提高。
程序员怎么练习
走出自己的舒适区
首先要走出自己的舒适区，接触一些不熟悉的技术领域。比如后端很熟悉了，去写写前端试试。Web 很熟悉了，去写移动端试试。 业务开发很熟悉了，去研究一下搜索，推荐系统，大数据试试。OO 很熟悉了，玩 FP 试试。 老守着自己会的那点儿东西，总有一天会坐吃山空。
发现自己的不足
有以下方式：
- 录视频
- Code Review
- 结对编程
- 参加编程道场
没有对比，很难发现自己的不足，所以把自己的代码和编码过程展示出来，一定会发现许多可以改进的地方。
只有菜鸟才会觉得自己特别牛，因为物以类聚，他的圈子里全是菜鸟。 你越牛，接触的圈子也越牛，你越会觉得自己渺小。
程序员练什么？
程序员要练习东西很多，一些基本功如下：
- 打字
- 编程语言
- 编程范式
- 编辑器
- 快捷键
- TDD
- Clean Code
- 重构
- ...
没时间不是借口
我第一次组织 Code Retreat 的时候，到 QQ 群里宣传活动，结果得到的是嘲讽：
周末还在写代码，肯定是屌丝。
很多人没有时间练习，却有大把的时间打 LOL，大把时间在群里吹水，大把时间讨论楼市股市。 当然，人都有选择自己生活方式的权利，并没有谁对谁错。
说这么多，只是希望真正热爱编程的同学们知道，只有通过刻意练习，才有可能成为顶尖的程序员！ 在 CodingStyle.cn 这个社区里，我们会组织 Code Review，Code Retreat，Coding Dojo。 希望我们一起成长，成为顶尖的程序员！
非常认同这套方法学。
好文！
我以前也总是这么认为：
我以前以「能边学边做」为荣，API、语法之类的没必要看，反正我们有 Google 和 Stack Overflow 嘛。
但等到类似Hackthon这种情境的时候就完全萎了..萎了...萎了...好嘛.....
而且我觉得不光是作为程序猿，不论是做什么都是这个道理。勤练，多学，不要老加班、加班、加班 。
说实话，我第一遍看这篇文章也是觉得非常赞同的，但是静下心来想一想却又觉得有些不妥，不妥不是因为论点——一万小时定律这个说法是没有问题的，让我觉得不妥的是论述的依据和背后的驱动因素。
一万小时、走出舒适区、不断练习、程序员需要练习的东西……这些都很好，但我始终觉得加班和 Hackthon 这两件事情不太适合用来驱动自己去达成上述的论点或是目标。
先说加班的事情，加班是一种现象，在国内特别是初创型企业和那些把加班当成是“企业文化”的公司里屡见不鲜。但是【效率是导致加班的重要因素】这个观点有待商榷。我不否认有一部分非受迫性加班是由于自己的效率不够高的缘故，但我觉得这是非常小的一部分。
我仔细回忆了一起共事过的同事们，只要大家不是太陌生（比如新来的），那么各自的水平有几斤几两彼此之间应该是心知肚明的，所以在单位时间内各自能做完多少事情能做到什么程度也是可以估计出来的。于是问题就来了：如果这个是可以度量的（哪怕不够精确，但大致有数），那为什么还要把工作安排成非加班不可？
这就好像你做一个老师，却不是因材施教；做一个厨子，却不会看菜下饭；做一个领导，却不会因势利导……你不看生产力现状如何却总是一味的以主观倾向来调配资源和安排计划，怎么可能不加班？因为这种情形而加班的，本来人的心情就很不愉快，能够调整自己积极应对固然是好事，可这种事情却只能期待而不能指望。
如果因为不能正确评估生产力水平而错误的安排计划和调度资源从而产生了无休止加班赶工的恶性循环，这是项目/工程管理的问题，而不应该简单的归咎于从业者效率不够高，更不应该以此为驱动因素去要求从业者主动地忘记加班带来的身心负面影响并且还要发挥主观能动性去提高自己的效率。
反之，如果能够正确的评估和安排计划，在现有生产力的基础上实现不加班并且合理有效的完成计划，那样就可以先杜绝加班或是少量的加班。在此基础上通过激发员工的成就感等方法来唤醒他们希望自我提升的意识并且给予合适的培训和学习环境，那么才真正有希望做到自主自发的去提高每一个人的效率，进而提高团队的生产力……这才是良性循环。
对此我只能说：意图是好的，但是用错了激励方式或引导方式。我想这大概是不同的人对“以人为本”的不同理解吧。
Hackthon 这种活动我没有亲身参与过，其实并没有什么有分量的发言权，不过这种活动形式倒是让我联想到了自己所熟悉的音乐创作。音乐创作在很多地方都和编程开发有相似之处，你看大部分的产品都需要时间精心打磨，本质上这和一万小时定律是一样的，但是由于产品的特殊性（需要市场考验），所以它也有 MVP 这样的快速迭代的创造形式。音乐也是如此，一首名作必然是经历反复推敲打磨才成型的，但由于音乐本身也具有特殊性（比方说舞台上会需要即兴演奏），所以你也得学会和练习一些“套路”……我不知道这种对比是否能让大家 make sense，组过乐队写过歌的人应该能有所体会。
但我真正想说的是，那些历经一万小时锤炼而成的大神们，他们的初始动机绝非是为了在 Hackthon 上能够游刃有余；正如同那些音乐领域里的大师们，他们磨练自己的技艺也并非只是为了应付舞台上的即兴表演。
当然了，因为经历了 Hackthon 或是即兴表演从而认识到自己的不足，进而知道需要刻苦练习，这本身是一件好事。然而有些事情不能因果倒置，迷失了初心的话倒有可能又走一些弯路也说不定的。
另外，一万小时究竟应该练什么我觉得是要因人而异的，好的老师都会因材施教，所以不是一套方法总是适合所有的人。我自己经常看大神们的视频，实际上大神们也总是会去查 API 文档的，我无数次在各种视频里见证过这些东西，所以……
总之，观点没问题，论述的依据和方法个人还是觉得没走到点子上。
很喜欢你这样深入的思考，赞！ 我认为加班主要有几种：
- 企业文化 - 加给老板看
- 项目管理计划能力不足
- 产能跟不上
前两种可以单独写一篇。 我这篇文章主要说最后一种情况：产能跟不上，除了优化工作流程，比如引入自动化减少手工重复操作等。另一个就是提高每一个个体的生产力。
后边 Hackthon 的部分是这样理解的：创业就像是一场时间长一些的 Hackthon，在工作中应该用自己熟悉的技术，才能把精力都花在业务上。 如果用新技术，应该用业余时间去练习。 所以不再以自己能边学边做感到自豪，反而上班时间应该尽量做在自己舒适区的事。
说一个实例，去年我在一家客户那里做顾问时，他们的团队周六加班，我们加了两次后就给他邮件说：「我们要用周末时间来学习，来保证上班的时间最高效」。印度的 CTO 表示很理解。
比如写个纸牌类游戏，我往往喜欢在写好既定的规则后自己再凭空想几个规则（给自己找坑，不符合常理的那种），然后再去思考，试着去完成，这算是么？可事后我想想，感觉有点变态啊 /(ㄒo ㄒ)/~~
楼主所写我都同意，我补充一点儿楼主忽略的。
其实任何行业，首先刻意练习，然后再去工作，都比边学边练效率要高很多。我是程序员，平常真正能刻意练习的机会其实并不多。我们大多数都是在自学，而且还对自学引以为傲。也有观点认为优秀的程序员都是自学出来的，教是教不出来的。我以前也是这么认为，虽然看过《异类》，但还是没有直观的体验，直到我开始跑步，健身，后来加入健身工作室（有专业教练一对一指导）。我才明白什么才是真正的刻意练习。很多动作，你以为自己做得好完美，其实全错了，而正确和错误的差别只是一点点。你自己练，可能练一段时间可以感觉的到不太对，也可能一辈子都不知道。而专业教练，一进屋看你第一眼就知道你哪里做错了。
书里说的很清楚了。
首先，要有针对性，就是说你哪里弱，哪里需要提高，就练什么，而不是我高兴练什么，对什么有兴趣我就练什么。比如你热爱篮球，那就要练弹跳，你不能说我只喜欢打篮球，不喜欢练弹跳，所以就不练了。
其次要有人提示你哪里不好，哪里需要纠正，这个恰恰是程序员缺乏刻意练习的原因。其他行业可以聘请教练，或者有师傅带你入门，程序员就很难，大多都是自学。结对编程也是极少数。而且结对编程也还是需要你主动向别人学习，跟教练会主动纠正你还是不一样。个别公司可能有师傅带领徒弟的制度，但是也只是指导，真正善于纠正的也很少，毕竟人家是程序员，不是程序员教师。
最后就是大量的重复，这个是程序员最不缺的。可是没有前面两条作为前提，最后这一条大量重复，其实只是低效的甚至无效的机械重复而已。就好比，我爸给我家做饭，做了 20 年也还是不如专业厨师去新东方学 4 年的水平。就好比我们几个每周打羽毛球 3 次，打了 2 年，我弟弟暑假去羽毛球班学 3 个月就秒杀我们了。
总结下，要想大规模提高程序员的水平，需要有专业的程序员教育人员。这个全世界目前还是没有。国外比我们情况好的原因只是国外的初高中及大学教育比我们情况好些，毕竟大学的教育从某种程度起到了程序员教育人员的部分作用，但是还远远不够。
我还没有看《异类》这本书，准备看看。
我们经常讲关注点分离，其实写代码的时候应该在技术和业务之间只选择一样。 写业务的时候就不要被技术影响，某个 API 不熟悉了，开发工具配置不健全了等等。 写业务的时候专注业务，开发效率才高，质量才好。
非常同意关于健身和羽毛球的论述，自己是很难发现自己不对的，而教练一眼就能看出来。
其实我们去游泳班，羽毛球班学习，一次课 2 小时，10 次课肯定把重要的东西都学完了，然后就靠自己练习了。 但人往往不愿意练习，比如我觉得篮球好玩，你让我去练习弹跳，我就觉得没意思了。
但我们没有那么多时间精力，成为所有领域的「专家」。 所以我认为要折中一下，花 20 小时刻意练习，学完最重要的东西，就能成为「业余」玩家，比许多「玩」了多年的玩家都要厉害。 我准备在 2016 年尝试学习多个陌生的领域，在 20 小时的时间内看能学到什么程度。 我希望能总结出「快速学习一项技能」的方法和工具。
我想从另一个方面说说，虽然各行业领域都需不断学习攀登，却也未见如程序员这一行，技能淘汰的如此之快，新技术又如潮水般一波波袭来。学习，对于天性好奇又好学的程序员，也仿佛渐渐地成了种压力。 我觉得刻苦一词是对一段经历的总结和评价，不该是一个方向和目的。因为以刻苦作为方向和目的，对于凡体肉胎的人类来说，实在是很难做到的。论坛里的各位，当年写下第一个 basic 程序，艳惊四座的时候，我想当时并没有觉得有多刻苦，尽管你已坐在那台 386 前已足足好几个小时. 对于周而复始一波波袭来的浪潮，只有一种人是毫不恐惧和绝望的，那就是冲浪者。 不忘初衷，保护那宝贵的兴趣，我觉得实在很重要。比刻苦更重要。
这篇文章真的很赞！不过程序员要练习东西我觉得除了 MASTER 一门语言、掌握算法和工具、系统架构外，文档也很重要。因为一个程序员无论再 NB 也无法一人扛下所有的事情，而且现在随着 GITHUB 的火热，让别人能看懂自己的代码、明确而清晰的表达，文笔功底也非常重要。因为人在用程序语言和机器交流的时候也需要和人交流嘛。正如 RUBY 之父那样，他不但写代码而且还发表文章（《代码的未来》一书真的值得一看）。Hackthon 的目的是让你在有限的时间内完成你的项目，怎么说也是团队活动嘛，所以沟通、交流顺畅了，很多问题问题自然会达成一致，任务自然会非常顺利。不仅仅是 Hackthon，大型项目也是一样哦。 以上只是我个人的一点浅见，如有啥错还请多多包涵！
#29 楼 @chenjau 是啊，多少人因为兴趣而开始写代码，却因为工作压力大而慢慢失去了创造的乐趣，编程技能变成了一个混口饭吃的工具。我正在做一个小众社区，正是想帮助程序员能持续保有初心，享受编程的乐趣。https://codingstyle.cn/topics/10
#30 楼 @harold_crane 认同「对程序员而言写作能力很重要」，我认为写文章与写程序员是非常相似，写一本书就像做一个产品。要考虑用户是谁，用户有什么问题，你的书能提供什么价值，用户是否会选择你的书，是否愿意付费。也需要考虑书的架构，也有耦合，依赖的关系。我认为文笔不好，代码也不会很好。逻辑清晰，排版整洁的人代码也会清晰整洁，这是一种习惯。
不过我们更倾向于写自表达的代码（不需要用额外文字来解释），用测试用例来沟通。
图解的那个关于舒适区和学习区，给我蛮大的启发和刺激，现在的自己就有点在舒适区待着的的感觉，因为公司业务驱动最近才开始学习接触 react，但是心里还是有些许的不满。看到这篇文章后，倒是重新提醒自己，不在能学习的年纪就去偷懒了
成为优秀程序员的前提是自己拥有良好的兴趣爱好，所谓的“刻苦”和“练习”，不过是一个在不然不过的过程了，完全像一场心灵之旅，何苦用这么贬义的词语来概括这么一个快乐的过程？
文中一个观点不是很同意。
首先要走出自己的舒适区，接触一些不熟悉的技术领域。比如后端很熟悉了，去写写前端试试。Web 很熟悉了，去写移动端试试。
业务开发很熟悉了，去研究一下搜索，推荐系统，大数据试试。OO 很熟悉了，玩 FP 试试。
老守着自己会的那点儿东西，总有一天会坐吃山空。
程序员现在总体水平低下，主要是因为技术深度不够，而不是知识面不够宽。程序员中能说出各种框架、各种数据库的大有人在，也都能简单用 API 实现功能，但这样的程序员有什么用？不够精通和熟练，如何能够保证软件的稳定性。
而精通和熟练不是通过结对编程或者看《设计模式》这种没有营养价值的书所能提升的。要提升程序员的能力，必须要熟练计算机科学中那些基础的东西，而这些东西就是我们在学校里所学的数据结构、算法、操作系统、编译原理等，而这些东西是大多数程序员最不愿意看的，因为这些知识，需要通过长时间的阅读、思考和练习才能获得。
严重同意楼主的说法，对程序员来说练习是必须的，所以我和小伙伴们一起做了一个创业项目，在这里： http://www.hubwiz.com/course/?ch=rubyc
@nightire 很喜欢看你的评论，属于心直口快的那种。个人认为这就是最有效的交流方式，客观，直接。 不过对于下面这句话表示不能完全赞同：
但我始终觉得加班和 Hackthon 这两件事情不太适合用来驱动自己去达成上述的论点或是目标。
首先这句话表达得比较笼统，没有表明中间的一些关系。其次博主并没说加班和Hackthon就是驱动。
先来理下各种关系，加班和低效率的关系
在中国，IT 行业普遍加班严重，先不说行业特征与企业文化。 就我最近面试的经验来看，很多程序员的开发效率实在是低到不忍直视。
所以「效率」是一个导致加班的重要因素。 如果你效率高，但迫于企业有加班的文化，你完全可以用加班的时间来学习一些新的技术，进一步提高自己的效率。
这是博主的原文，这里其实说明了导致加班的因素有两点，一是企业文化，而是低效率。所以说低效率并不代表绝对会加班。那么接下来博主这句话：
效率低会引起下图的怪圈：（配图参考原文）
就是一个不合理的陈述！ @seabornlee
说到这里，怪圈出来了。接下来博主开始论述他破解怪圈的方法，这个方法就是刻意学习。但是博主提出这个方法的时候并没有说我要在什么时间去刻意学习。接下来博主开始根据自己Hackthon的经历来告诉读者，最好不要在工作时间来刻意学习，因为他认为这是战场，是需要高效工作的地方。那么言下之意就是你需要通过刻意学习来破解怪圈，但是你最好不要在工作时间来这样做。
所以，博主的论点或是目标或是刻意学习的方法针对的是怪圈，而不是加班或Hackthon。 而怪圈的产生需要满足的条件就是你工作效率太低导致了你经常加班，进而导致占用了你的学习时间，跟Hackthon没任何关系，而加班也仅仅是怪圈中的一环。
其实我看不太清楚你的意思——不是说你说的不清楚，我只是不知道你想表达的观念是什么。
我索性把我的观念说的简单明确一点吧（当然只能代表我自己，并没有对错之分）：我学习（我认为练习就是学习的一个组成部分），既不是为了提高效率以避免或减少加班，也不是为了应对类似 Hackthon 这样的特殊场景，我学习就是学习，如果说为了什么，那就是为了满足好奇心和求知的欲望，我是一个纯粹主义者。然而话说回来，我认为像我这样去学习也足以满足避免或减少加班以及应对类似 Hackthon 等特殊场景的需求，只不过它们不是最原始的动机（就是我说的驱动因素），它们只是学习带来的增益效果。
可能对于一些人来说，减少加班或应对 Hackthon 会是非常好的驱动因素（这是很正常的事情，我不觉得是错误），我读第一遍的时候甚至都不觉得哪里有不妥（这种不妥不是针对所有人的），只是当我开始回顾自己的学习历程时才意识到：对于其他一部分人来说（比如我），学习可能是另外一种感受，用来驱动的因素可能会更抽象一些（而不是像加班或 Hackthon 这么具体的东西）。
所以请原谅我之前表述不够清晰，我认为的不适合仅仅是从我的角度来说罢了，不具有普遍性。其实我都不打算去解释这一点，因为我向来都觉得理解的人自然理解（因为是一类人），不理解也没有关系，因为学习本身就是蛮自我的一件事情。就是这样。
#46 楼 @seabornlee 很想知道有没有 ruby 或 rails 相关的，可以自我练习的网站。topcoder 之类，感觉难度非常大，都是些复杂度很高的算法。
#44 楼 @nightire 我只是说学习可以打破因效率低而导致加班的怪圈，并没有说学习「只是」为了打破加班的怪圈哈。
另外，我所说的学习和刻意练习还不一样，举个栗子： Rails 5 刚出来，恰逢周末，leader 说小王你周末研究一下，下周我们把系统升级了吧。
小王有两种做法： 一、周六研究了一下新 feature，知道个大概，然后就开心地打 LoL 去了；周一去公司，一边做一边查，搞到半夜，搞定了； 二、在周末把每一个用到的新 feature 练到烂熟，在本地尝试升级，直到熟练；周一去公司一遍搞定，早早收工回家休息。
第一种情况下 Leader 和同事们会觉得小王工作真努力，第二种情况下 Leader 和同事们可能会觉得小王真靠谱，真牛 B。
不知道这样说有没有表达清楚？
#51 楼 @seabornlee 多谢鼓励，其实 30 多岁，乃至 40 多岁的人，和二十多岁的人比，是存在很多想法的，或者更渴望向着自己的奋斗目标前进，而不是当一个码农。然而，这也取决于个人兴趣，估计老外有很多一大把年纪，还在专注编码的人，老龄化，或许也是国内程序员们的现状。
