提纲：
1. 没有遵从适合自己的最佳产能曲线来进行工作和作息， 是第一个需要反思的事情；
2. 不重视方法， 只顾蛮干， 是第二个需要反思的事情；
3. 没有做好有效的记录、备份工作， 低水平重复劳动， 是第三个需要反思的事情；
4. 开发程序时不能知其所以然， 满足于 “It works”， 是第四个需要反思的事情；
5. 没有建立一套行之有效的机制，来应对工作中的各种中断和异常， 是第五个需要反思的事情；
6. 没有明确的职业/技术方向， 精力分散容易导致样样会一点却无所精通， 是第六个需要反思的事情；
7. 因为过去的疏忽、偷懒、 折中及各种原因而作出不明智决定， 导致现在付出更大的代价， 是第七个需要反思的事情；
8. 因为纵容小问题，导致未来付出更惨重的代价， 是第八个需要反思的事情；
9. 开发程序未能充分考虑线上复杂的环境， 是第九个需要反思的事情；
0. 不作充分规划，过早着手， 导致返工， 是第十个需要反思的事情；
1. 对工作没有规划和记录， 无故“被加班”；
2. 缺乏有效的软件测试， 对代码缺乏信心。
一个程序员的产能曲线应该类似正态曲线， 先逐渐上升到某个巅峰， 持续一段时间， 然后下滑。 中间可能有一两个小高峰。 因此， 正确的作法不是持续长时间作战， 而是充分利用自己最巅峰的产能时段， 完成一天的工作， 其它的时间留给休息；
另一种说法是， 人的注意力持续时间最长为2小时， 因此， 可以2.5 小时作为单元； 工作2小时， 停顿一下， 恢复精力， 然后再继续。 反复如此。
编程开发是智力密集型活动（即使是交流沟通也是非常有技巧性的）， 努力创造性地解决问题， 切忌体力活， 切忌像机器人一样不知疲倦地工作。
警示录： 没有遵从最佳产能曲线来进行工作和作息， 工作效率不高， 是第一个需要反思的事情。
解决方案： 用心去发现适合自己的最佳产能曲线， 遵循适合自己的生理规律安排好工作与休息， 切忌被“朝九晚五”的习惯所束缚， 善待身体， 努力做到工作与健康的双赢。
成功 （100%） = 勤奋 （60%） + 方法 （60%） + 机遇 （40%）。 绝大多数人的资质其实是处于同一水平线的， 为什么在特定领域内人与人之间存在很大的差距？ 除了天赋和努力的因素， 很可能是因为那些表现优秀的人掌握了非常有效的方法和策略来做事。 这种方法将滚雪球似的拉开彼此的距离。 必要的勤奋是不可或缺的， 在勤奋之外， 强有力的方法和策略成为致胜的关键。
如果花费了比别人多得多的时间， 却依然感到捉襟见肘， 就很有必要质疑自己所采用的方法了。 为什么花费了大量时间，收效微小？ 我是否适合做这个事情？ 为什么学习新技术的进度很慢， 是因为基础薄弱， 记忆能力平凡，还是方法有问题？ 过于贪急求快？ 时间安排有问题？ 规划定位不明确？ 不善于利用现有环境和周边资源？
警示录： 不重视方法， 只顾蛮干， 是第二个需要反思的事情。
解决方案： 定期地停下来， 反思现状， 质疑现有方式， 思考更好的方法。
创新式开发探索第四篇 —— 反思自己的开发活动。
为什么开发效率这么低？ 为什么要加班熬夜？ 为什么在上班的时间不能完成该完成的任务， 学到该学到的东西？ 是什么， 隐隐地谋杀着程序员原本短暂的时间和生命？
没有有效地备份， 低水平重复做过的事情。
最近， 接连重装了几次系统， 每次重装系统后， 都要重新搭建开发环境。 比如配置Flex开发调试环境以及各种开发工具、包、Web容器； 还有各种常用软件安装有木有？ 虽然不是什么难事， 却也无情地消耗人的时间和生命， 一次次重做也令人厌烦。
此外， 由于没有有效地备份， 以前做的项目、数据、资源、记录等丢失， 难以找回； 尤其是一些重要的工作记录， 问过了同事却没有备份， 是不是要再问一次？
重复的问题重复求解
做开发免不了要上谷歌百度搜索解答。 有时候，一些临时性问题解决了没有做有效记录， 结果下一次遇到了， 记不清楚了， 又要重新上网搜有木有？ 有木有？ 一定确定以及肯定是有的。
警示录：
重复， 消耗了不知多少人的青春， 人类 60% 的时间恐怕都耗费在重复的事情上了；
没有做好有效的记录、备份工作， 低水平重复劳动， 是第三个需要反思的事情。
解决方案：
使用知识管理软件， 事毕记录， 事必记录， 简要记录， 定期整理。 在遇到同样问题时， 不必重新在网络上痛苦地搜索。
充分重视备份工作， 理清楚有哪些必要的软件、工具和重要文件数据（专门放置在一个命名为 BackupImportant 的文件夹或目录）， 定时备份。 网络， 移动硬盘。 至于软件安装， 尽量写个执行脚本， 一次性自动化搞定。 第一次花费 100% 的精力， 第二次及以后只花费5%不到的精力。
贪急求快， 不求甚解
人都有贪急求快的本性， 在遇到问题并且有项目进度在头上敲钟的时候， 很可能会直接将网上的答案 Ctrl+C/V， 修改， 直至“看上去能够正常工作”， 而不知其所以然。 不求甚解导致的问题就是， 虽然“解决了眼前的问题”， 但是对问题依然缺乏深入的理解和探究， 在遇到问题的变种时可能无法获得解决。
此外， 当使用 Ajax 技术开发前端应用时，是否了解过 Ajax 的内部实现原理？当把应用部署到 tomcat 或 jetty 中时， 是不是期望一切正常？ 当使用框架组件的时候， 是不是期望一切OK？ 这一切看上去很神奇， 对框架、组件内部了解甚少， 却还能正常出结果， 实在令人惊奇； 不过， 当出问题时， 一切就不那么神奇了。
警示录： 开发程序时不能知其所以然， 满足于 “It works”， 是第四个需要反思的事情。
解决方案： 保持好奇心和热情， 对出现的问题要深入探究分析， 知其所以然； 即使当时没有时间， 也要记录下来， 有时间的时候好好钻研下其内部机制和实现。 知其所以然， 也是提高编程开发能力的有效途径。
工作被打断， 干扰管理
同事呼唤有事要探讨一下， 正巧有个临时会要开， 肚子开始抗议了， 而自己正沉浸在程序的构思实现中； 工作伙伴打电话过来， 交代事情需要去处理。 这都是避免不了的工作场景。 大多数时候， 我们可能是基于本能反应去应对各种的被打断， 或者不情愿被打断。 如果打断次数有点多得话， 就会造成较大的干扰和影响， 需要仔细管理了。
警示录： 没有建立一套行之有效的机制，来应对工作中的各种中断和异常， 是第五个需要反思的事情。
解决方案： “保存现场”， 快速切换。 放下自己的事情， 专注与他人的沟通， 这未尝不是一种磨炼。每一件事都隐藏着机遇。 少了几分钟敲代码而已， 但多出了时间去自由思考和交流。 确保一切都在掌控之中。 Everything is in control。同事交代事情， 做一个列表， 尽量给予准确的答复， 并安排时间去完成， 培养自己的职业化素养和良好信誉。
斗志低落，无所适从
人总是有斗志低落的时候。 一种可能是， 不知道干什么， 这是目标不明确所导致； 一种可能是， 遇到问题不知道如何求解， 这说明该向有关人士请教了； 还有一种可能是， 持续工作一段时间， 精力不足了， 这时候， 需要休息停顿一下， 恢复精力。
解决方案： TODO List， 保证总有事情可做； 善于求教，而不是埋头苦干； 适当停顿， 停下来才能更好地前进。
对自己做的事情失去兴趣
有木有这样的感觉： 做了两三年开发， 觉得有些事情， 交给一个花 3-4K 的本科生来做比自己来做更有价值， 甚至做得更好。 做重复的功能？ 花费自己最宝贵的生命力量去做没有太大影响力的事情和系统， 真的想这么得过且过么？
警示录： 没有明确的职业/技术方向， 精力分散容易导致样样会一点却无所精通， 是第六个需要反思的事情。
解决方案： 不要沉迷于纯功能性的开发； 转向“解决方案” 开发； 尽早确立一个值得探索和探究的领域， 在其中深耕细作， 做出前人没有做出的东西来， 哪怕再小； 或者投入到一款新产品开发中， 这种产品能够给人们的生活带来有益的影响。
现在的80%是在为过去买单
历史遗留问题总是令人头疼。 因为疏忽导致的程序错误， 在当时多花一点点精力就能做好， 过一段时间之后， 尤其是在一个很忙的时候突然插上一脚， 需要重新修正， 重新部署， 会导致非常高的维护成本； 大学时不好好努力， 总想早点飞出去， 结果出来后四处碰壁。
警示录： 因为过去的疏忽、偷懒、 折中及各种原因而作出不明智决定， 导致现在付出更大的代价， 是第七个需要反思的事情。
解决方案： 为了不让未来为现在买单， 请慎重仔细做出现在的决定， 多花些精力做得更好一些， 不要因为偷懒而做出折中妥协的方案。必须敢于承担一些风险， 甚至力排众议， 坚持不懈地推动事情发展和完成， 才能获得生活的馈赠。
过去的小问题会在未来的特定情境下放大成大故障
有些问题， 在过去修复代价非常小， 但时隔多时， 在未来的某个时刻修复可能会付出很大的代价。 有个真实的故事。 有一个API调用少传了一个参数（在大多数调用中该参数是可选的，但在少数情况下是必选的）。 如果在当时修复，几乎不是什么事； 然而， 修复发生在系统重构期间对原系统的维护，线上发布的权限控制发生了变化， 发布演变成了一场故障， 导致线上服务中断了30分钟。
警示录： 因为纵容小问题，导致未来付出更惨重的代价， 是第八个需要反思的事情。
解决方案： 不要放过小问题， 尽早修复； 尽量一次性做到完善。
未能充分考虑线上复杂的环境
一条普通的子查询语句， 在 1000 条记录的表中几乎不是问题； 但在百万级以上的表中， 性能问题就很突出了。 详见《第一次项目发布的教训》。同样的程序， 在 2G 内存的机器中运行没有问题， 在 512M 内存的机器中运行就可能出问题。 开发程序不充分考虑线上复杂的环境， 就会出现各种不曾预料的问题。
警示录： 开发程序未能充分考虑线上复杂的环境， 是第九个需要反思的事情。
解决方案： 抽时间专门对线上环境做深入调查， 弄清楚哪些因素可能对程序造成影响，并做些预防措施。
未作充分规划， 过早着手，导致返工
程序员总有点急性子， 希望尽早做出效果。 于是， 容易不作充分规划和设计就匆忙下手。 一个功能实现， 想出一个方案分三个步骤。 急急忙忙做出了第一个步骤，发现这个方案在第二个步骤有瓶颈， 或许需要付出很大代价， 或者有缺陷， 结果不得不放弃， 于是， 在第一个步骤所花费的精力和时间就这样浪费了。
警示录： 不作充分规划，过早着手， 导致返工， 是第十个需要反思的事情。
解决方案： 凡事先做规划设计， 攻克可能存在的问题、困难后再动手。 不作过度设计， 但也不能不作充分的预先设计。
项目人少， 加班必不可免
有时， 项目人少， 那么， 现有的人员就不得不在进度下像螺旋一样了。 但是， 也不应超出限度。 较好的一种方案是， 规划并记录每天所做的事情， 保证这些事情确实在有力地推动项目进展， 并且是一个人可以承担的工作量（正常工作量+合理超出部分）。 有凭有据， 就不必莫名其妙地被加班了。 从另一个角度来说，程序员要学会规划自己的工作， 而不仅仅是执行上级派发的指令。
警示录： 对工作没有规划和记录， 无故“被加班”。
解决方案： 仔细规划和记录每天的工作内容及收获， 确保工作量在可接受的范围内。
不相信自己写出的代码
软件越复杂， 越不相信自己写出的代码。 很可能是看上去能正常工作， 却不知道隐藏了多少BUG。 学习软件测试的技能，同时， 尽量建立规范有效的开发方法和流程， 一次投资， 多次使用， 终生受益。
警示录： 缺乏有效的软件测试， 对代码缺乏信心。
解决方案： 尽早建立有效的测试框架， 增加完善的单元测试， 适度的集成测试， 以及少量合理的端到端的测试。
还有什么？
先解决以上问题吧！