http://www.lxway.com/48066412.htm
程序员最重要的是学习能力和聪明，所以特别要求某项技能的公司一般是很low的。一个勤奋聪明的程序员，三个月工作的知识和经验，已经足够胜任这一领域普通的任务，能比得上很多在这里呆了很多年的碌碌无为的人。但是一些领域还是需要投入几千小时的专家人物。换到面试官的角度，考算法题是非常必要也是最合理的，因为它就能看出学习能力和是否聪明。
程序员需要双显示器，好的靠椅，安静的环境，以及良好的环境光，工具就像你的宝剑，怎么奢侈都不过分。一个公司就该为他的员工投资这些，这是程序员的基本要求。
尽量避免开会，开会是浪费时间的最佳手段，如果一定要开，请保证在一小时内完成，同时提前通知大家内容并做好准备，结束时让大家每个人都宣讲一下自己要做的内容。
编程只是实现任务的一种手段，只是知识和经验的一种表现形式，越多代码就意味着越多的责任和bug。千万不要以代码量来衡量工作量，要么不出手，要出手就一击致命，足够sharp，足够稳健。
与人沟通很重要，有好的同事也很重要。
一个不好的同事会让整个团队沉沦。不要总是向其他人夸夸其谈所谓的最佳实践。比如在团队里强硬地推广版本控制和某本大作，你当前的口头之快虽然似乎“证明”了自己的远见卓识，但这潜在地要求别人以更多的工作量来实现它，这往往是吃力不讨好的。“好为人师”反而会引起反弹。最好的方式是“以身作则”。
远程工作是现代常用的工作方式，不过这需要热爱写代码的专业人士，否则自控能力不强的人很容易走偏，邮件列表，skype都是良好沟通的基础。结对编程，互相review代码，都是很好交流手段。
用户界面要够好，对使用者来说，界面实际上是软件的全部， 用户才不关心你内部用了怎样牛逼的架构和算法。程序要快，越快越好，一丝性能的提升就可能吸引更多的用户。即使很烂的web程序，也要比桌面程序强，未来是web的时代。用户是瞎子，他会直接忽略他能忽略的所有内容。所以，要把最重要的放到最好的位置上去。不要让用户去想！
完美是不可能的，所以要尽快发布第一版，客户的意见是最好的指导，让你把资源花在最重要的资源上。
测试很重要，单元测试能解决很多不容易发现的问题，但可用性测试更重要，软件好用吗，用户到底在怎么用它？请一些人过来用一下，你就会收到大量的反馈。
http://www.cnblogs.com/xujanus/p/4522628.html
第2章：把一堆烂事搞定的艺术
4.如果你想造一艘船，就不要催着工人们去收集木头、分派工作，发号施令。你应该教会他们的是对无边无际大海的渴望。
5.磨刀不误砍柴工。（程序员应该多阅读编程相关的博客或者书籍）
6.对磨锯子有些痴迷是没有问题的，但前提是，你的痴迷是在“技术”相关的事物上。
7.只有又快又好的决定，而在反应迟缓的情况下不可能做出好的决定来。
第3章：高效编程之原则
9.在所有报告的错误中，大约有95%是有程序员造成的，2%是有系统软件造成的，2%是由其他软件造成的，1%是由硬件造成的。
10.作为程序员，我们的任务是要意识到，我们所做的每个决定都是一个折中。（我们的任务是选择最合适的方式来解决实际问题，而不是一味的追求所谓最高效或者最美观的代码）
11.不要把太多精力放在注释上，而应该关注代码本身的优美
12.学会读源代码
13.向橡皮鸭求助（遇到困难先理清思路，换个角度）
14.执行力比创意更重要。在软件开发领域，执行力意味着专注于构成你的应用程序的所有微小细节。（敏捷开发？）
15.你团队里的米个人都应该能通过由陌生人主持的额“电梯测试”——在60秒内，清晰的解释他们在做什么以及为什么人们会在意他们正在做的事情
16.性能致胜：
1）.虔诚的遵循雅虎的指导原则（进行优化）
2）.善待匿名用户和注册用户（并且为他们进行定制优化，根据他们不同的目的）
3）.使性能成为一种（公开的）骄傲
第4章：招聘程序员须得其法
17.软件开发者最擅长的就是学习（雇主应该找有能力有热情的人而不只是有经验的人）
18.工作经验年数与编程技能之间是没有必然联系的
第5章：促使团队紧密协作
http://www.lxway.com/89940954.htm
沟通
正如前面所说，当今我们已经不可能单靠一个人来完成一个项目了。我们依赖的是一个团队。团队就是由人组成的。人就是需要沟通和交流的。而那些人，正是“程序员”。如果我们无法准确快速的让别人知道自己在想什么，知道自己要什么的话，事情往往就会因此受阻。效率会因此降低，成本则会上升。
拥有良好的沟通能力，就是程序员迈向“高效能”的第一步。
分析
这里说的分析，包括对需求的分析、对市场的分析、对优先级的分析以及对自己的分析。
想要开发出一款软件，并且希望它能被大众接受（甚至喜欢），需要精确的知道它应该具有什么样的功能，使用怎样的交互，面对的客户群是谁，以及何时发布最为妥当。这些都需要有着出色的分析能力来给出答案。不可否认，在当前这个“术业有专攻”的时代，这些事情会被不同的人（产品经理，市场人员，项目经理等）去完成，而程序员只被要求做具体的功能实现。但这并不代表程序员只能守着自己那一亩三分地。程序员需要用他独特的敏锐的嗅觉去帮助其他人来完成他们的工作，确保产品万无一失的成功发布。
程序员很忙的。一天要写好多好多代码，还要做各种各样的分析。还时不时的有些有关无关的会议要参加，有些有关无关的人要伺候。先做哪个，后做哪个，哪个是要自己做的，哪个不适合自己做的，都需要想清楚，安排好。一股脑的来者不拒，笑脸相迎只会给自己带来很多麻烦。
拥有出色的分析能力，是程序员迈向“高效能”的第二步。
http://www.lxway.com/89940512.htm
对于产品开发到发布，应该讲究快速迭代，搜集用户需求、然后再迭代开发和发布…以占得市场先机，而不是纠结于面面俱到而贻误最佳的发布时机。
http://stanzhai.github.io/ReadingShare/Effective-Programming.html
成为杰出的程序员的关键
把想法表达清楚（沟通）
清晰的注释和技术文档，让他人能够复用代码，不必重写
选择了开发行业，还是想想如何提升沟通吧！
培养写作习惯（沟通）
书面沟通有助于我们理清我们的思路
有效写作是推进你职业生涯发展的一种基础技能，必须加以重视
写博客是个好方法。
高效编程
同时记住的东西越多，编程效率越高。
永远都是你的错
在怨天有人之前，应该先自我反省，努力把自身的问题解决了。
碰到问题的时候，应该很淡定的说：“嘿，这是我的错，让我把它查个水落石出。”
作为一名开发者，你自己就是最大的敌人。越早认识到这一点，你的境况就会越好。
大道至简——代码不是什么好东西
随时间推移会腐烂，需要周期性的维护
藏有Bug，代码越多Bug越多
写更多的代码需要更多的工程师，沟通成本->n*n
以用户为中心去考虑产品的设计，我觉得这点非常有道理，一个软件产品最终是给用户使用的，所以软件的视觉、用户体验、界面的友好度等等，决定了一个产品的成败，所谓细节决定成败，书中通过详细的UI界面和控件元素的不同设计比较了产品设计的优劣
我们是天生的模仿者。和优秀的人呆在一起，大脑自然而然的会变优秀。
注意力是最需要管理的资源。如今的人不缺乏信息和知识，却缺乏对重要事物最起码的关注。不停地切换情境，会严重降低效率。如果一个人能很好地管理注意力，那么他可能早就成功了一大半。
克服外界的干扰，也是保护自己注意力的重要一环
http://www.jianshu.com/p/33933a3ba977
像这种用意识层面的语言来表达潜意识的思考的能力确实是值得锻炼的。试想一下，如果我们能把自己潜意识层面的思考准确地再现于意识层面，那么这显然会有助于帮助我们检查思维的缜密性和正确性，而且也会锻炼我们的逻辑思维，从而能更好地去思考，形成良性循环。
关于请教问题
对于第一条，笔者深有体验:笔者做了一个类似新手引导的教程，因为队友修改了页面加载的逻辑，导致了用户只能通过，点击，滑动，手动加载后才能出现看到教程的情况，而刚看到页面时，教程是不会自动出来的，其实这个体验是很差的，因为用户需要自己动手。但是当时由于已经处于测试末尾阶段，我个人也没有在意。
在跟产品经理交流后，产品经理人很好，只是说了最好要加上。我想了想还是加了，添加的方法很简单，只是在
程序员最重要的是学习能力和聪明，所以特别要求某项技能的公司一般是很low的。一个勤奋聪明的程序员，三个月工作的知识和经验，已经足够胜任这一领域普通的任务，能比得上很多在这里呆了很多年的碌碌无为的人。但是一些领域还是需要投入几千小时的专家人物。换到面试官的角度，考算法题是非常必要也是最合理的，因为它就能看出学习能力和是否聪明。
程序员需要双显示器，好的靠椅，安静的环境，以及良好的环境光，工具就像你的宝剑，怎么奢侈都不过分。一个公司就该为他的员工投资这些，这是程序员的基本要求。
尽量避免开会，开会是浪费时间的最佳手段，如果一定要开，请保证在一小时内完成，同时提前通知大家内容并做好准备，结束时让大家每个人都宣讲一下自己要做的内容。
编程只是实现任务的一种手段，只是知识和经验的一种表现形式，越多代码就意味着越多的责任和bug。千万不要以代码量来衡量工作量，要么不出手，要出手就一击致命，足够sharp，足够稳健。
与人沟通很重要，有好的同事也很重要。
一个不好的同事会让整个团队沉沦。不要总是向其他人夸夸其谈所谓的最佳实践。比如在团队里强硬地推广版本控制和某本大作，你当前的口头之快虽然似乎“证明”了自己的远见卓识，但这潜在地要求别人以更多的工作量来实现它，这往往是吃力不讨好的。“好为人师”反而会引起反弹。最好的方式是“以身作则”。
远程工作是现代常用的工作方式，不过这需要热爱写代码的专业人士，否则自控能力不强的人很容易走偏，邮件列表，skype都是良好沟通的基础。结对编程，互相review代码，都是很好交流手段。
用户界面要够好，对使用者来说，界面实际上是软件的全部， 用户才不关心你内部用了怎样牛逼的架构和算法。程序要快，越快越好，一丝性能的提升就可能吸引更多的用户。即使很烂的web程序，也要比桌面程序强，未来是web的时代。用户是瞎子，他会直接忽略他能忽略的所有内容。所以，要把最重要的放到最好的位置上去。不要让用户去想！
完美是不可能的，所以要尽快发布第一版，客户的意见是最好的指导，让你把资源花在最重要的资源上。
测试很重要，单元测试能解决很多不容易发现的问题，但可用性测试更重要，软件好用吗，用户到底在怎么用它？请一些人过来用一下，你就会收到大量的反馈。
http://www.cnblogs.com/xujanus/p/4522628.html
第2章：把一堆烂事搞定的艺术
4.如果你想造一艘船，就不要催着工人们去收集木头、分派工作，发号施令。你应该教会他们的是对无边无际大海的渴望。
5.磨刀不误砍柴工。（程序员应该多阅读编程相关的博客或者书籍）
6.对磨锯子有些痴迷是没有问题的，但前提是，你的痴迷是在“技术”相关的事物上。
7.只有又快又好的决定，而在反应迟缓的情况下不可能做出好的决定来。
第3章：高效编程之原则
9.在所有报告的错误中，大约有95%是有程序员造成的，2%是有系统软件造成的，2%是由其他软件造成的，1%是由硬件造成的。
10.作为程序员，我们的任务是要意识到，我们所做的每个决定都是一个折中。（我们的任务是选择最合适的方式来解决实际问题，而不是一味的追求所谓最高效或者最美观的代码）
11.不要把太多精力放在注释上，而应该关注代码本身的优美
12.学会读源代码
13.向橡皮鸭求助（遇到困难先理清思路，换个角度）
14.执行力比创意更重要。在软件开发领域，执行力意味着专注于构成你的应用程序的所有微小细节。（敏捷开发？）
15.你团队里的米个人都应该能通过由陌生人主持的额“电梯测试”——在60秒内，清晰的解释他们在做什么以及为什么人们会在意他们正在做的事情
16.性能致胜：
1）.虔诚的遵循雅虎的指导原则（进行优化）
2）.善待匿名用户和注册用户（并且为他们进行定制优化，根据他们不同的目的）
3）.使性能成为一种（公开的）骄傲
第4章：招聘程序员须得其法
17.软件开发者最擅长的就是学习（雇主应该找有能力有热情的人而不只是有经验的人）
18.工作经验年数与编程技能之间是没有必然联系的
第5章：促使团队紧密协作
http://www.lxway.com/89940954.htm
沟通
正如前面所说，当今我们已经不可能单靠一个人来完成一个项目了。我们依赖的是一个团队。团队就是由人组成的。人就是需要沟通和交流的。而那些人，正是“程序员”。如果我们无法准确快速的让别人知道自己在想什么，知道自己要什么的话，事情往往就会因此受阻。效率会因此降低，成本则会上升。
拥有良好的沟通能力，就是程序员迈向“高效能”的第一步。
分析
这里说的分析，包括对需求的分析、对市场的分析、对优先级的分析以及对自己的分析。
想要开发出一款软件，并且希望它能被大众接受（甚至喜欢），需要精确的知道它应该具有什么样的功能，使用怎样的交互，面对的客户群是谁，以及何时发布最为妥当。这些都需要有着出色的分析能力来给出答案。不可否认，在当前这个“术业有专攻”的时代，这些事情会被不同的人（产品经理，市场人员，项目经理等）去完成，而程序员只被要求做具体的功能实现。但这并不代表程序员只能守着自己那一亩三分地。程序员需要用他独特的敏锐的嗅觉去帮助其他人来完成他们的工作，确保产品万无一失的成功发布。
程序员很忙的。一天要写好多好多代码，还要做各种各样的分析。还时不时的有些有关无关的会议要参加，有些有关无关的人要伺候。先做哪个，后做哪个，哪个是要自己做的，哪个不适合自己做的，都需要想清楚，安排好。一股脑的来者不拒，笑脸相迎只会给自己带来很多麻烦。
拥有出色的分析能力，是程序员迈向“高效能”的第二步。
http://www.lxway.com/89940512.htm
对于产品开发到发布，应该讲究快速迭代，搜集用户需求、然后再迭代开发和发布…以占得市场先机，而不是纠结于面面俱到而贻误最佳的发布时机。
http://stanzhai.github.io/ReadingShare/Effective-Programming.html
成为杰出的程序员的关键
把想法表达清楚（沟通）
清晰的注释和技术文档，让他人能够复用代码，不必重写
选择了开发行业，还是想想如何提升沟通吧！
培养写作习惯（沟通）
书面沟通有助于我们理清我们的思路
有效写作是推进你职业生涯发展的一种基础技能，必须加以重视
写博客是个好方法。
高效编程
同时记住的东西越多，编程效率越高。
永远都是你的错
在怨天有人之前，应该先自我反省，努力把自身的问题解决了。
碰到问题的时候，应该很淡定的说：“嘿，这是我的错，让我把它查个水落石出。”
作为一名开发者，你自己就是最大的敌人。越早认识到这一点，你的境况就会越好。
大道至简——代码不是什么好东西
随时间推移会腐烂，需要周期性的维护
藏有Bug，代码越多Bug越多
写更多的代码需要更多的工程师，沟通成本->n*n
我们是天生的模仿者。和优秀的人呆在一起，大脑自然而然的会变优秀。
注意力是最需要管理的资源。如今的人不缺乏信息和知识，却缺乏对重要事物最起码的关注。不停地切换情境，会严重降低效率。如果一个人能很好地管理注意力，那么他可能早就成功了一大半。
克服外界的干扰，也是保护自己注意力的重要一环
http://www.jianshu.com/p/33933a3ba977
俗话说：程序员不能只想着写代码。在编程以外的闲暇时间，读一点这种有助于程序员扩展视野和提高素养的书籍是很好的。
关于程序员的表达能力
关于程序员的表达能力
杰出的程序员和勉强过得去的程序员之间的差别是他们能不能把他们的想法表达清楚。大家应该不会怀疑程序员的平均智商，但是程序员中每个人的表达能力却参差不齐，差别极大。其实有些时候头脑中想到的方法可能是在潜意识下想到的，如果这时候需要我们有条理地说出来，确实不是一件容易的事。
像这种用意识层面的语言来表达潜意识的思考的能力确实是值得锻炼的。试想一下，如果我们能把自己潜意识层面的思考准确地再现于意识层面，那么这显然会有助于帮助我们检查思维的缜密性和正确性，而且也会锻炼我们的逻辑思维，从而能更好地去思考，形成良性循环。
关于程序员的学习：
勤加练习固然重要，但是只顾着买头写代码，没有讨论和反思的时间，那么是无法得到真正的进步的。在阅读博客和相关书籍的过程中，从自身利益出发去考虑，如果我们能从中找到哪怕一点对我们有用的东西，其实就已经很赚了。复习和反思是学习过程中很重要的环节，如果没有及时的复习与反思，那么往往事倍公半：忘记知识，而且就算不忘，也无法高效地将知识提取出来。作为程序员，应该适当脱离键盘反复思考，将学到的知识高效地整合到自己的知识结构中，有助于知识的提取和运用。
读到这里的时候笔者很是惭愧。因为笔者在写代码的时候，是将代码和注释一起写的。所以应该将这个习惯改过来：写代码的时候忘记注释，应该尽全力用代码自己解释逻辑。到最后逻辑达到很清晰的程度后，再加上必要的注释：为什么用的是这个逻辑。
- 注释需要说：程序为什么这样工作。
- 你应该总是专注于编写代码，而忘了还有注释这种东西的存在。
- 当我脑子里了一个明确的目标，并且有一段复杂的代码要写时，我会把时间花在时间代码上面，而不是写下他的故事，讲给我自己听。
- 如果你的代码在没有注释的情况下显得过于复杂，很难被人理解，那只能说明你的代码写得太早了，重写代码，直到它不再需要任何注释。
关于请教问题
笔者在工作中也会请教同事问题，前几次问的时候发现自己将问题说出来之后，自己头脑里已经有了解决的办法，而且觉得很简单。所以后来想问问题的时候，保证自己先解决一般问题，将问题深入，然后尽可能问出高质量的问题来。
- 向别人请教问题：
- 提供足够多的细节描述发生的状况
- 说明你为什么需要这个答案
- 表述你所做的研究和发现
- 如果你想让别人花上宝贵的时间来帮助你，你也要花了宝贵的时间酝酿出一个合格的问题才算公平。
关于提出问题
笔者认为如果是对一个无生命体，大脑中负责情感的部分会被抑制，会更加促进理性分析，更加清晰地表述问题(因为你的潜意识知道小黄鸭*是不会“理解”你的话里半点遗漏的点)。
- 提出正确的问题差不多已经把问题解决了一半。
- 完全投入地向一个假想中的人或者是没有生命的物体问一个透彻而相近的问题。
关于创意和执行
- 如果你想要赚钱，你必须把这两者相乘，除非创意被执行，否则它一文不值，执行是创意的倍增器，真正价值巨大的是执行。
- 与其担心你全心投入等下一个创意是否足够出色，不如担心你能执行的多好。
- 在软件开发领域，执行意味着专注于构成你的应用程序的所有微小细节，如果你不是始终沉迷于你的应用程序的每个方面，不去优化和赶紧它的每一处细节，那么你就不是在执行，至少，不是在很好地执行。
关于团队
- 如果你把一个好的创意给一个普通的团队，他们会把它搞砸。如果你把一个普通的创意给一个好的团队，他们会对它加以完善，或者他们会把那个创意丢掉，然后相处一些更棒的 - Catmull"
- 如果你想取得成功，不要担心没有伟大的创意，转而去专注于培养卓越的团队。
关于会议：
会议绝不应该超过一个小时。其实会议确实比较耗费时间，所以就要为了提升会议的效率和价值：
每个会议都要有一个清晰的目标声明。
在开户之前做好功课：提前知道将要讨论和分享的内容。
把会议变成可选的：每一个人都因为他们想要在那里，或者需要在那里。
会议结束后，概括一下待办事项。
- 在会议开始前：熟悉会议内容并提前思考。
- 在会议结束前：整理会议结果，列个待办事项。
- 在会议结束后：执行！执行！执行！
关于用户和产品
这两条分别告诉我们：
- 用户不会阅读你屏幕上的任何东西。用户只会读取屏幕上足以让他们完成任务的，最少量的文字。
- 与世隔绝在实验室花上三个月的时间修复第一版里的问题，不如把这3个月的时间用于倾听来自真实世界里使用你的软件的用户提出的反馈。
- 我们在做产品的时候，应该把用户当成“弱视不会思考”的人。
- 用户可以“为我们所用”。
对于第一条，笔者深有体验:笔者做了一个类似新手引导的教程，因为队友修改了页面加载的逻辑，导致了用户只能通过，点击，滑动，手动加载后才能出现看到教程的情况，而刚看到页面时，教程是不会自动出来的，其实这个体验是很差的，因为用户需要自己动手。但是当时由于已经处于测试末尾阶段，我个人也没有在意。
在跟产品经理交流后，产品经理人很好，只是说了最好要加上。我想了想还是加了，添加的方法很简单，只是在
viewWillAppear方法里加了触发的逻辑，但却发现体验直线上升。这件事对我感触很大，只是一两行代码就能明显改善用户体验，那么为什么不去做呢？为什么一定要去麻烦用户去动脑，去动手呢？