我希望我在成为开拓职员的头几年就阅读与软件干系的书本。 但我是在从业第 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
关注我并转发此篇文章，私信我“领取资料”，即可免费得到InfoQ代价4999元迷你书！
