小型项目开发
一个小型项目指的是一个普通SWE能够在合理的时间内（一般不超过两年）完成的项目。一个中型项目指的是一个人无法在合理的时间内完成，但是一个由2～5个SWE组成的小团队可以完成的项目。一个大型项目则需要一个较大的SWE团队（超过5个成员）来完成。
就LOC（Line Of Code）而言，一个小型项目会包含50～100K LOC，一个中型项目会在50～1000K LOC（约100万行代码）范围内，而一个大型项目少则包含500～1000K LOC。
在软件的生命周期（Software Development Life Cycle）中，一个软件通常要经历8个阶段：
- 产品概念：产生了一个软件想法，并且创建了一个业务案例来证明这个想法。
- 需求开发与分析：创建需求文档，并且与客户进行了沟通，以确保对需求的理解是正确的。
- 设计：根据需求文档创建系统设计文档，并且得到了客户的认可。
- 编写代码（实现）：根据系统设计文档编写代码，并且进行单元测试。
- 测试：进行集成测试，并且修复缺陷。
- 部署：将软件部署到生产环境中，交付给客户使用。
- 维护：在生产环境中对软件进行维护。
- 退休：软件已经不再使用，或者被新的软件取代。
对于小型项目，一个SWE会全面负责系统设计、实现、测试、部署和文档编写。
估计小型项目的开发时间
第一步是识别和理解需要完成的所有工作。如果此时项目的某些部分还没有被清晰定义，那么在进度表中就会引入相当大的错误，因为这些未定义的组件，不可避免地要花费比你想象的多得多的时间。
在估计某个项目的完成时间时，设计文档是项目中最重要的部分。如果没有详细的设计，那么就不可能知道项目由哪些子任务组成，以及每个子任务将花费多少时间来完成。一旦你将项目分解成适当大小的子任务（一个合适的大小，就是清楚地知道完成它需要多少时间），你需要做的就是将所有子任务的时间汇总起来，从而产生一个合理的初步估计。
在估计小型项目的进度时最常犯的一个最大的错误是，SWE会把子任务的时间加到进度表中，而忘记了会议、电话、电子邮件和其他管理任务的时间。SWE还容易忘记增加测试时间，以及发现和修复缺陷（和重新测试）的时间。因为很难估计软件中存在多少缺陷，以及解决这些缺陷需要多少时间，所以有经验的SWE会将进度表中第一次估计的值扩大2～4倍。
提高开发效率
1. 合理选择软件开发工具
2. 管理开销
对于任何项目，我们都可以将工作分为两种类型：与项目直接相关的工作（例如，为项目编写代码或者文档）和与项目间接相关的工作。间接的活动包括会议、阅读和回复电子邮件和更新日程安排。这些都是日常开销活动，它们增加了项目的时间和成本，但是并不直接有助于完成工作。
通过遵循Watts S.Humphrey在Personal Software Engineering中介绍的方法，你可以跟踪在项目期间将时间都花费在了何处，并且很容易地看到直接花费在项目上的时间，以及花费在其他活动上的时间。如果你的其他活动时间超过总时间的10%，那么你应当重新考虑日常活动。你应当试着减少或者整合这些活动，来降低它们对你的工作效率的影响。如果你没有跟踪项目之外花费的时间，那么就会错过通过减少管理开销来提高生产力的机会。
3. 设置明确的目标和里程碑
4. 集中注意力，排除干扰
专注于一个任务并消除干扰，是另一种能够显著提高生产力的方法。你应当能够“进入状态”。通过这种方式工作的SWE比那些一心多用的人更有效率。为了提高工作效率，你应尽可能长时间地专注于某一个任务。
在没有任何视觉刺激（除了显示屏）的安静环境中，专注于一个任务是最容易的。有时候，工作环境并不利于让你专注。在这种情况下，戴上耳机，播放背景音乐可能有助于消除干扰。
无论什么时候你在工作中被打断了，你都需要时间恢复状态。事实上，你可能需要半个小时才能完全集中精力工作。当你需要集中精力完成一个任务时，可以贴一个告示说只有紧急的事情才能打断你，或者在你的日历中贴上“Focus time”，即你不希望被打扰的时间。回答同事们自己能想明白的问题，可以节省其10分钟的时间，但是这可能会浪费你半个小时。你必须作为团队的一部分工作，成为一个好队友，然而，同样重要的是，需要确保过度的团队互动不会降低你（和其他人）的生产力。
5. 练习自我激励
6. 如果觉得眼前的工作无聊，就做点别的事情
7. 尽可能自立，但清楚何时需要帮助
经验法则
简单设计指引
- 不要重复自己（Don’t repeat yourself，DRY）。需要重复的代码是复杂的代码。
- 一次且只有一次（Once and only once，OAOO）。所有独特的功能都应该作为方法/过程存在于代码中，并且只在代码中出现一次（最后的观点也是不要重复自己）。
- 你不需要它（You aren’t gonna need it，YAGNI）。在向代码库中添加功能时，请确保它对应着一个用户故事（即需求）。不要因为将来可能的需求而添加代码。
- 限制API和（已发布的）接口。如果你的代码是通过发布一个API与其他系统进行交互的，那么将接口的数量限制到最少，可以让你将来更容易修改代码（而不会破坏外部的代码）。