1. 每年花时间读两本关于软件工程的书

我每次花时间缓慢而认真地阅读别人推荐的软件工程书籍时，自身都会得到提升。所谓认真阅读，我的意思是要做笔记、与他人交谈、写写画画、动手尝试、回过头来重新阅读。

我希望我在成为开发人员的头几年就阅读与软件相关的书籍。 但我是在从业第 5 年左右才开始这样做的。诸如《C＃深入》，《简洁代码》和《Javascript：The Good Parts》之类的书都帮助我提升了技术水平。我并不是在推荐具体的书名——不管怎么说，其中有些都已经过时了。我的建议是寻找比你现有知识更深入的书籍，可以是关于特定技术或关于软件工程实践的著作。

看这些书时我不会一目十行。实际上，我看得很慢。我通常每次坐下来只读一两章。看的时候，我会做笔记或把重点划出来；看完后，我会回顾并经常与他人讨论。我也开始写一些书评放在自己的个人博客。

主要是反思我学到的东西。过去几年，我养成了这些习惯。这些习惯帮助我以技术经理的身份迅速成长：它们对工程师来说也非常有益。想找推荐书单吗？这里是我已经看过的和正在看的书籍清单。

为什么书籍要好过博文、视频或演讲？其实我认为书籍比其他加起来都要好。无论什么样的主题内容，与书籍相比，其他的格式都会流于表面。书籍里的知识更深入，而且组织良好。像本文这样的帖子，我只需要花费几个小时来写，但是我花费在我写的这本关于软件工程师成长的书籍上已经将近一年。我认为读书可以更缓慢但深入地消化知识。

不要太贪心：每六个月读完一本书已经很棒了。挑选一本好书，多花一些时间好好阅读。在读了一两本书之后，我还建议你阅读《如何读一本书：智能阅读的经典指南》一书，强烈推荐。

2. 精研你工作中主打的编程语言，学到底层

我刚开始时主要用 PHP，兼写一点初级 JavaScript。我在大学里学过 C 和 C ++，都不喜欢。我的第一份全职工作用的是 C＃。我了解很多种语言，但是没有一种语言学得非常好。

两年后，我开始遇到一些麻烦，在调试 C＃代码时不得不找高级开发人员帮忙。其中一个总是帮我调试程序的高级工程师，他似乎非常了解这种语言，他向我推荐了一本书《C＃深度学习》让我去看。然后我看了。我一路学到线程、垃圾回收和泛型的工作方式，这些都是底层知识。我花了数不清的时间去了解协方差（covariance）、逆方差（contravariance）和其他艰深的主题。

精研我工作中主打的语言是我做出的最佳决定之一。 在我的第一份工作中，这种研究只是无意为之的，并且还得靠那位高级工程师指点；但是，这些知识在工作中，以及面试其他工作时都成了一种优势。在我职业生涯的后期，我有意深入研究新的语言和框架。我是作为 C # 程序员加入 Skype 的，但是，我们需要改用 JavaScript 和 WinJS。因此，我又深入学习了 JS，并掌握了 WinJS，以至于我可以在 Pluralsight 上开课。

你懂的语言越多，就越了解它们各自的长处和短处。 当我转移到 iOS 时，我已经精通好几种语言。Swift 出现时，我简单关注并参与了语言讨论，并建议添加读写反射这项能力到 swift 的未来规划中。了解了该语言的特性后，就可以更容易地找出让我的团队从 Objective-C 迁移到 Swift 的最佳策略。而且，你知道的语言越多，就越容易掌握新的语言——并且在需要时更轻松地深入学习。

3. 多与他人结对编程

我觉得最近结对编程已经过时了。当年我们开始时，长期结对的极限编程、测试驱动开发和 mob 编程都很受欢迎。与人结对之后，我获得了职业生涯中一些最大的跃升。这些跃升比读书更重要。

我曾与一位开发人员有过一次难忘的结对编程经历。他对包括我在内的所有人都进行了严格的代码审查。有一天我受够了代码审查工具上的评论，决定不再在上面答复，而是坐在这些评论者旁边，要求他们当面向我说明他们的评论。我最终学到了很多东西——同时还告诉他们，我认为他们的评论不公平。他们注意到了这点，建议我每当有这种情况时就结对编程。然后我就去做了。这位开发人员对性能有所了解，我通过跟他结对编程，了解到了潜在的性能瓶颈的来龙去脉——然后我教给他们有关可维护性方面的知识作为回报。

与另一位工程师进行测试驱动开发经历，是我在结对编程中的另一个美好回忆。我们轮流编写代码和测试代码。我们做了两天，实现了系统中一个棘手的部分。那次经历实在令我大开眼界。我们在验证所有边界值的过程中，甚至反过来完全改变了实现方法。我们还与该开发商建立了牢固的纽带并持续了数月之久。

4. 编写单元测试用例，并在持续集成中运行

高级工程师们经常谈论单元测试的重要性。但是单元测试似乎太违反直觉了：为什么要花更多的时间编写看起来很简单的测试？这是我在某段时间里对单元测试的看法。

为了领略单元测试的价值，你需要拥有“啊哈！”时刻——当你编写的单元测试为你节省了一天的时间，那就是“啊哈！”时刻。在到达这一步之前，你需要脚踏实地，好好编写这些测试，并使它们在持续集成中运行。而且，你可能需要持续做上几个月，才会得到一个“啊哈！”时刻。

我有两个这样的时刻。第一个发生在我为一个小型在线赌场构建后端引擎（作为辅助项目）时。该 API 正在管理真金白银，我因为害怕犯错误，所以用单元测试覆盖了所有代码。该项目交付比我预想要晚——部分原因归咎于测试，它们耗费了很多时间。但是这样做是正确的。我在合同结束时将项目移交给了客户，两年后，他们告诉我，这些测试多次挽救了团队——如果不是因为测试失败，代码漏洞将会扩散到生产环境中。

我的另一个“啊哈”时刻是在 Web 上构建 Skype。我们在 web.skype.com 上给 Google Hangouts 创造了一个新的竞争对手。我们团队是一支强大的团队，拥有完整的单元覆盖范围和严格的集成测试。进入项目三个月后，工程师决定重构整个项目的结构。这是非常冒险的重构，我们所有人都投票反对这样做。

那位工程师指出，基于现有的测试覆盖率，这次重构应该是小菜一碟，只要测试通过，重构就没问题。我对此表示怀疑。但这正是测试用例的用处。经过为期一周的重构，他推动了一次巨大的变革……一切都没有中断，当时没有，之后也没有。所有测试均通过。就在那刻，我意识到了一套强大的测试用例所能提供的安全保障，以及它能够让我们不害怕重构的事实。

5. 养成重构习惯并掌握重构工具

多年来，当我与团队合作时，我倾向于在代码库中进行尽可能小的更改。对于我自己的个人项目，我进行了大量的重构——但是我从来不在我不完全掌控的代码库上做这种事情。

然后，我在 Skype 遇到了一位工程师，他会不断进行小型或大型重构。他们都有道理，并且代码总是变得更好。而且他们从不搞乱事情。他们是如何做到的呢？

当我与他们结对编程时，发现他们非常了解自己的 IDE，并添加了用于重构的插件。提取方法、改变量名、提取成常量………他们只需要花一秒钟。

我意识到，我害怕重构，既错过了实践，又错过了能帮助我重构的工具。 于是当我开始养成每周重构一次的习惯时，我在这两个方面都提升了。这个习惯后来对我很有帮助——我多么希望自己在很多年前就开始这么做啊。

6. 学习良好的软件工程经验，这使我获益良多

在我刚开始做软件工程师的时候，我曾经被高级工程师唬到了。他们看出了我没看出来的错误，他们知道我不知道的答案。我当时以为他们比我更聪明，并且接受了这一切。

现在，我已经与许多著名的软件工程师紧密合作过，并担任了另外几位的导师，我发现没有那么唬人。最好的软件工程师会把学到的知识和实际经验结合在一起——知识，你可以去学；经验，你需要去实践。

找机会在不同的技术栈、不同的领域和具有挑战性的项目里工作。 我花了七八年的时间才达到我认为的“高级”水平。我看到有些人加入了像 Uber 这种高成长性的公司，三四年就达到了。这中间的区别是什么？这些人从事具有挑战性的项目，力求跟上周围其他人的步伐，并经常在中途更换团队，重新开始。他们自愿参与新项目，并在团队中率先尝试新技术。虽然我最终还是成为了这样的人，但那是后来的事，不是在最初的几年中。

7. 把所学教给他人

学习某些东西，最好的方法是把它们教给别人。我是很偶然发现这一点的。在 2010 年，我开始在.NET 和 Windows Phone 用户组中做演示。我的演讲效果不佳，但是我仅在准备阶段就学到了很多东西。

现在，当我想学好东西时，就会报名参加了一次公开讨论。 加入 Uber 一年后，我提出做一个演讲，介绍在 2017 年 Uber 如何大规模推出后端更改。当时，我还不完全了解我们是如何做到的——在那之前，我主要从事移动开发，并管理一个移动团队。通过演讲，我别无选择，只能学习所有细节。我这样做的压力很大：大约有 100 个本地开发人员报名要来听我的演讲。

许多其他人也说这种方法很有效——Shawn“Swyx” Wang 是 #LearnInPublic approach 的杰出代表。他的成长故事远比我的经历令人印象深刻：改行后在四年里做到 Netlify 和 AWS 的高级工程师职位，并撰写了一本关于他学习经历的书。教别人你只会得到好处。你不仅可以通过教学来学到东西，而且还可以帮助和启发他人。

而且我认识的所有经验丰富的模范开发人员，都是合格的老师和导师。越早开始回馈和教导，就会越自然而然地成为这样的开发人员。

英文原文

Advice to myself when starting as a software developer

创作场景

一些建议：给当年刚做程序员的我