http://book.douban.com/review/6473544/
P1《引言》
编程不想数学物理一样一大堆理论，它还和设计关系紧密，艺术与逻辑一样重要。
隐身不适合搞编程，我们要和用户打交道
P21《动力》
制作软件的过程中，在不同的时间点，可能有不同的东西促使你前进。保持动力的存在于各行各业
P26《从喜欢入手》
如果你发现自己就是三分钟热度，那么及时停止，损失也不大。
用三天（或者一礼拜）踏踏实实地去写程序，你会对自己在做的东西以及剩下的部分何时能够完成有更多的了解。
有一点灵感并做出了一点点成绩之后，再去制定切合实际的时间表就容易多了。
P27《莫求全》
要在行业中生存下来，你最好不是一个完美主义者。
我们的产品是通过用户存活下来的。用户基数增长，他会嬗变（本质变化）。新功能会不断涌现，新Bug会不断产生，追求完美会让人精疲力尽。
越早接受不完美，就越能保持干劲、坚持到底，最后完成工作就越多。
P27《休止一下》
两个小时的高质量编程胜过八个小时的煎熬，所以，出去走走，享受一下生活吧。
P39《找个争论话题》
网络社区的好处在于，你的发言是简历在内容上的，别人不关心你是谁。
写作让你斟字酌句，让她趋于完美。
你可以自己建一个博客，也可以联系其他有影响力的博客作者，写些客座文章。你会惊讶于这个社区有多么包容。
P42《对消闲项目坚决说不》
Q我每周花几天，每天花多少时间在这个项目上？
Q我什么时候能出demo给人展示
Q哪一天release to public
Q哪一天发第一个main update version
没有deadline就没有生产力
P48《去掉时间表中的细节》
搞开发十二年了，从来没有一个项目是完全按照计划走的。
所以，开始做计划的时候，要少计划些细节。
P55《为良好的工作环境投资》
若想知道某项工作好不好，迅速扫一眼办公室，就知道管理层是不是关注开发团队。
显示器数/员工数：
[1]不关注
(1-2)有一定程度关注
[2-3)非常关注
[3-)走错办公司啦~
P56《列张个人待办事项清单》
好的代办清单的特质：
-一张清单，只有一张
-今天、明天、后天、未来
-不嵌套，易修改
-若干短任务，每个几小时
-*每天清理，超过一周在未来，直接删掉
P62《安排免打扰时间》
那些希望员工发展而不是仅仅关注生存的公司，都需要采取一些方法来将其变成现实，比如google的20%时间做喜欢且与公司相关的项目
每天轮流两小时免打扰时间：不用回邮件、不参加会议、不接电话、不收IM，不说话
别人能帮你
打扰别人是最后选择
P65《采用自治小团队的工作形式》
有些特别大的公司，可以持续招聘，所以一年内把新员工的活力挤榨得一干二净，然后又去市场找人。
大公司“繁文缛节、官僚作风、开会无休、优柔寡断、犹豫不决”，然后高举“人是我们的宝贵资产”
P67《提高生产力，避谈“我们”》
eg:会议上，我们需要加硬件么？=>mike，我们需要加硬件么？
P75《关于“简单”的悖论》
“一个想法足够复杂，所以很有价值”
矛盾就在于此。作为开发者，我们往往把所做软件的价值等同于其复杂性，复杂度越高就等于价值越大。
并非功能讨论了好几个小时，我们就得添加好几个功能。
我们会很自然觉得，功能数要和投入的时间成正比，不管新功能带来什么好处。
一旦你不再天真地任务简单会降低价值，就可以开发出好的软件了。
P115《宽容大度，和蔼可亲》
充满热情的程序猿容易愤怒。
因为不成熟的想法和客人争辩，实在是让人郁闷。
打电话给他们，而不是只发邮件。你会惊讶的发现，一个体贴的声音能给你带来很大的转机。
P124《写代码是不得已而为之》
有些好的答案是在别处发现的。
Q别人做过这件事么？我能不能拿到现成源码？
Q这个功能重要么？是不是已经有了，只是需要不同的用户体验来实现。
Q有没有更简单的实现方式？即使这方式没完全解决问题，是不是也值得做出让步？
Q能自动化么？以后不重复劳动啦
P126《拿来主义文化》
真正伟大的代码别人已经写好了，它们已经发往全世界，帮助我们加快流程。
https://ruby-china.org/topics/8072
不要在卧室工作.在家工作的人应该都深有体会.
为了开心和兴趣工作,不能一直朝钱看,太看重钱只会害了自己.虽然达到这条在国内有点难,但是至少对我们这个浮躁的环境来说,能有这种想法总比没有好.
多面手没啥坏处,保持极度旺盛的求知欲. 对于知识的广度和深度,我觉得深到恰到好处就可以了,再深下去意义不大,不如提升广度带来的收益更多.
http://blog.csdn.net/fxleyu/article/details/8974358
Chapter 2: Metaphor
Follow Metaphors with Care
Plan Enough, Then Build
Launch Is Just the First Release
The “Ivory Tower” Architect Is a Myth
Throw Away Your Old Code
Diversification Over Specialization
Metaphors Hide Better Ways of Working
Chapter 3: Motivation
The Perks Are in the Work
Begin Where You Love to Begin
Be Imperfect
Stop Programming
Test Your Work First Thing in the Morning
Work Outside the Bedroom
First Impressions Are Just That
The Emotional Value of Launch
Find an Argument
Chapter 4: Productivity
Just Say “No” to the Pet Project
Constrain All of Your Parameters
Cut the Detail Out of the Timeline
Improve Your Product in Two Ways Daily
Invest in a Good Work Environment
Keep a Personal To-Do List
Create “Off-Time” with Your Team
Interruption as the Last Resort
Work in Small, Autonomous Teams
Eliminate the “We” in Productivity
Chapter 5: Complexity
Sniff Out Bad Complexity
The Simplicity Paradox
Complexity as a Game of Pickup Sticks
Keep Complexity Under the Surface
“Hard to Code” Might Mean “Hard to Use”
Know When to Refactor
Develop a Programming Cadence
Chapter 6: Teaching
Teaching Is Unlike Coding
Beware the “Curse of Knowledge”
Teach with Obvious Examples
Lie to Simplify
Encourage Autonomous Thought
Chapter 7: Clients
The Tough Client Is Ubiquitous
Demystify the Black Magic of Software
Define the Goals of Your Application
Be Enthusiastic and Opinionated
Be Forgiving and Personable
Value Is Much More Than Time
Respect Your Project Manager
Chapter 8: Code
Write Code As a Last Resort
A Plug-in Happy Culture
Code Is the Ultimate Junior Developer
Separate Robot Work from Human Work
Generating Code at Its Core
The Case for Rolling Your Own
Chapter 9: Pride
We Have a Marketing Problem
Lessons from the Cooking Industry
P1《引言》
编程不想数学物理一样一大堆理论，它还和设计关系紧密，艺术与逻辑一样重要。
隐身不适合搞编程，我们要和用户打交道
P21《动力》
制作软件的过程中，在不同的时间点，可能有不同的东西促使你前进。保持动力的存在于各行各业
P26《从喜欢入手》
如果你发现自己就是三分钟热度，那么及时停止，损失也不大。
用三天（或者一礼拜）踏踏实实地去写程序，你会对自己在做的东西以及剩下的部分何时能够完成有更多的了解。
有一点灵感并做出了一点点成绩之后，再去制定切合实际的时间表就容易多了。
P27《莫求全》
要在行业中生存下来，你最好不是一个完美主义者。
我们的产品是通过用户存活下来的。用户基数增长，他会嬗变（本质变化）。新功能会不断涌现，新Bug会不断产生，追求完美会让人精疲力尽。
越早接受不完美，就越能保持干劲、坚持到底，最后完成工作就越多。
P27《休止一下》
两个小时的高质量编程胜过八个小时的煎熬，所以，出去走走，享受一下生活吧。
P39《找个争论话题》
网络社区的好处在于，你的发言是简历在内容上的，别人不关心你是谁。
写作让你斟字酌句，让她趋于完美。
你可以自己建一个博客，也可以联系其他有影响力的博客作者，写些客座文章。你会惊讶于这个社区有多么包容。
P42《对消闲项目坚决说不》
Q我每周花几天，每天花多少时间在这个项目上？
Q我什么时候能出demo给人展示
Q哪一天release to public
Q哪一天发第一个main update version
没有deadline就没有生产力
P48《去掉时间表中的细节》
搞开发十二年了，从来没有一个项目是完全按照计划走的。
所以，开始做计划的时候，要少计划些细节。
P55《为良好的工作环境投资》
若想知道某项工作好不好，迅速扫一眼办公室，就知道管理层是不是关注开发团队。
显示器数/员工数：
[1]不关注
(1-2)有一定程度关注
[2-3)非常关注
[3-)走错办公司啦~
P56《列张个人待办事项清单》
好的代办清单的特质：
-一张清单，只有一张
-今天、明天、后天、未来
-不嵌套，易修改
-若干短任务，每个几小时
-*每天清理，超过一周在未来，直接删掉
P62《安排免打扰时间》
那些希望员工发展而不是仅仅关注生存的公司，都需要采取一些方法来将其变成现实，比如google的20%时间做喜欢且与公司相关的项目
每天轮流两小时免打扰时间：不用回邮件、不参加会议、不接电话、不收IM，不说话
别人能帮你
打扰别人是最后选择
P65《采用自治小团队的工作形式》
有些特别大的公司，可以持续招聘，所以一年内把新员工的活力挤榨得一干二净，然后又去市场找人。
大公司“繁文缛节、官僚作风、开会无休、优柔寡断、犹豫不决”，然后高举“人是我们的宝贵资产”
P67《提高生产力，避谈“我们”》
eg:会议上，我们需要加硬件么？=>mike，我们需要加硬件么？
P75《关于“简单”的悖论》
“一个想法足够复杂，所以很有价值”
矛盾就在于此。作为开发者，我们往往把所做软件的价值等同于其复杂性，复杂度越高就等于价值越大。
并非功能讨论了好几个小时，我们就得添加好几个功能。
我们会很自然觉得，功能数要和投入的时间成正比，不管新功能带来什么好处。
一旦你不再天真地任务简单会降低价值，就可以开发出好的软件了。
P115《宽容大度，和蔼可亲》
充满热情的程序猿容易愤怒。
因为不成熟的想法和客人争辩，实在是让人郁闷。
打电话给他们，而不是只发邮件。你会惊讶的发现，一个体贴的声音能给你带来很大的转机。
P124《写代码是不得已而为之》
有些好的答案是在别处发现的。
Q别人做过这件事么？我能不能拿到现成源码？
Q这个功能重要么？是不是已经有了，只是需要不同的用户体验来实现。
Q有没有更简单的实现方式？即使这方式没完全解决问题，是不是也值得做出让步？
Q能自动化么？以后不重复劳动啦
P126《拿来主义文化》
真正伟大的代码别人已经写好了，它们已经发往全世界，帮助我们加快流程。
https://ruby-china.org/topics/8072
不要在卧室工作.在家工作的人应该都深有体会.
为了开心和兴趣工作,不能一直朝钱看,太看重钱只会害了自己.虽然达到这条在国内有点难,但是至少对我们这个浮躁的环境来说,能有这种想法总比没有好.
多面手没啥坏处,保持极度旺盛的求知欲. 对于知识的广度和深度,我觉得深到恰到好处就可以了,再深下去意义不大,不如提升广度带来的收益更多.
http://blog.csdn.net/fxleyu/article/details/8974358
Chapter 2: Metaphor
Follow Metaphors with Care
Plan Enough, Then Build
Launch Is Just the First Release
The “Ivory Tower” Architect Is a Myth
Throw Away Your Old Code
Diversification Over Specialization
Metaphors Hide Better Ways of Working
Chapter 3: Motivation
The Perks Are in the Work
Begin Where You Love to Begin
Be Imperfect
Stop Programming
Test Your Work First Thing in the Morning
Work Outside the Bedroom
First Impressions Are Just That
The Emotional Value of Launch
Find an Argument
Chapter 4: Productivity
Just Say “No” to the Pet Project
Constrain All of Your Parameters
Cut the Detail Out of the Timeline
Improve Your Product in Two Ways Daily
Invest in a Good Work Environment
Keep a Personal To-Do List
Create “Off-Time” with Your Team
Interruption as the Last Resort
Work in Small, Autonomous Teams
Eliminate the “We” in Productivity
Chapter 5: Complexity
Sniff Out Bad Complexity
The Simplicity Paradox
Complexity as a Game of Pickup Sticks
Keep Complexity Under the Surface
“Hard to Code” Might Mean “Hard to Use”
Know When to Refactor
Develop a Programming Cadence
Chapter 6: Teaching
Teaching Is Unlike Coding
Beware the “Curse of Knowledge”
Teach with Obvious Examples
Lie to Simplify
Encourage Autonomous Thought
Chapter 7: Clients
The Tough Client Is Ubiquitous
Demystify the Black Magic of Software
Define the Goals of Your Application
Be Enthusiastic and Opinionated
Be Forgiving and Personable
Value Is Much More Than Time
Respect Your Project Manager
Chapter 8: Code
Write Code As a Last Resort
A Plug-in Happy Culture
Code Is the Ultimate Junior Developer
Separate Robot Work from Human Work
Generating Code at Its Core
The Case for Rolling Your Own
Chapter 9: Pride
We Have a Marketing Problem
Lessons from the Cooking Industry
