引言
我成为技术主管已经超过一年半的时间，在日常工作中，我会持续召开回顾会议来总结学到了什么，以及如何在将来有所提高。我一直都觉得这些事情对我个人和职业生涯都非常有价值。因此我决定大概每周做一次这些相关内容的分享，同时也便于某些读者发现其中可能的价值。另外我也经常致力于自己的专业发展，这是巩固以艰难方式获得的所有知识的一个方法。
经验教训
客户不应该支付您的学费
我想这是一个大多数（如果不是所有）高层和管理人员都知道的商业规则，但依然值得分享。员工不是雇来学习的，而是雇来干活的。
比如以下两种不同的情况：
- 如果日常工作中的某一周事情非常顺利，并且您已经交付了要求的任务，同时还有一些空余时间，那么这就是一个绝佳的时机用来打磨您的手艺。您依然需要把这些小时算到工时里面，然而您可以很聪明的使用这些时间，比如学一些新的技术，新方法论，以及您们公司的产品等等，这能让您获得具有竞争力的优势。
- 在某些特殊时刻，比如截止日期紧迫，或者有一个产品事故，或者任何其他原因，这个时候恰恰也正是您不想发现自己不了解某个工具、某种编程语言、某个服务、或者任何技术相关的东西，等等这些是如何运作的时候。
日常工作中，没有比别人认为您没有竞争力更糟糕的情况了。相反地，更好的情况是公司知道您是不可替代的。所以请打造更好的自己以获得成功。
不提问的代价
我一直认为一个人不提问是因为自尊心太强或者过于自负。但是理解提问是职业生涯成功的基础，这不应该是一种令人羞耻的经历。
我和小组内的一个开发就这个话题进行了一次谈话。如果通过提问能立即解决一个难题，反而自己研究解决则需要三天时间，那么为什么不提问呢？而且个人单独完成所有的事情真的是健康的工作方式吗？
毕竟，大家一起在一个公司工作，公司自然是期望我们一起能让公司业务在市场中盈利。因此如果某件事只花费了原本十分之一的时间，这个时候您要么在给公司省钱，要么是在给公司赚了更多的钱。这两者情况均能对您的职业发展产生正面影响。
本周阅读/学习的内容
实例讲解测试驱动开发 -- Kent Beck
从结对编程这一观点开始，我完全反对很多极限编程里面提到的核心概念。尽管如此，我还是认为 Kent Beck 的写作风格非常有趣。其中虽然充满了各种讽刺，但大多数时间，我的阅读依然轻松有趣。
当读到 TDD 的时候，我认为这真的是一个值得掌握的好工具，特别是对新功能的项目开发而言。这本书到目前为止的内容都很容易理解和消化。拥有理想的测试场景并以这样一种方式构建代码的核心思想，让您确信它无需回头看就能完成它需要做的事情，这本身就很美。书中有一些引文值得强调：
- 关于混淆现象的定义：
假设我有一张支票，我把金额定为 5 美元，当更改第一张支票的价值导致无意中更改了第二张支票的价值时，于是我职业生涯中开始出现了一些最讨厌的错误。这是混淆现象。 * TDD 的真正价值
在 TDD 开发中，我总能看到这样的情况 - 优秀的软件工程师花费 5 到 10 分钟找一个问题的原因，而这个问题计算机可以在 15 秒内给出答案。没有测试，您没有选择，只能寻找原因。但有了测试后，您能很快地决定某个实验是否能更快的回答问题。
除此之外，这本书还包含了巨量的有用技巧、模式和想法。我已经向很多人推荐了这本书，但我认为这本书与 Martin Fowler 的《重构》、Bob Martin 的《代码整洁之道》、关于设计模式的任何书籍相结合时效果最好。
