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

点击上方“小白学视觉”，选择加"星标"或“置顶”

重磅干货，第一时间送达

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

原文：

https://blog.pragmaticengineer.com/advice-to-myself-when-starting-as-a-software-developer/