亲爱的儿子：
当你打开这封信的时候，我已经离开波士顿回到加州了，你也已经结束自己最后一个暑假，去往自己非常喜欢的公司。
虽然你我都是程序员，但是你却很少向我咨询过技术相关的问题，咱们上一次一起写代码，也是你高考结束那个暑假了。不过前几天你问了我一个问题，你说，如果让你写一封信，跟当初刚刚成为程序员的自己说一些话，你会说什么呢？
我在想，我会说些什么呢？我想说的太多了，可是如果说了，他能听进去多少呢，就算听进去了，他又会用到多少呢？我想起了瑞·达利欧的《原则》，如果我把我这几年的经历、收获，总结成几条原则，是不是会好一些。
以下，是我总结的几条原则。
1.权威精神
对于某一项具体技术来说：
官方文档、白皮书、论文，比博客更权威；
由此引申出：
谷歌比百度更权威，因为谷歌的搜索结果，权威的资料靠前，而百度，靠前的多是博客；
大多数时候，英文文档比中文文档更权威，因为官方文档、白皮书、论文，大多数是英文的；
如果你想向别人解释一项技术，那么请向他们展示权威的资料，而非一些网络上的博客；
为什么这么强调权威精神？
《禅与摩托车维修艺术》里，作者和朋友骑摩托车去沙漠，车坏了，朋友依靠直觉和经验，尝试了各种办法，就是修不好，而作者找到了他购买摩托车时配套的指导手册，照着上面的步骤排查，很快找到了导致车子故障的原因，换了个零部件，车子就好了。
数学、物理的很多研究，都是基于定理之上，谁也不会基于一条未经检验、未被公认的理论去研究自己的工程，就好比一位军事科学家，是不可能用一位民间科学家的一篇文章里的理论，去设计自己的军事系统的，稍不留神，一个计算错误，就会把导弹射向自己。
而软件工程，其实和数学、物理一样，也是一门科学，这一点很多人都忘了。
为什么他们会忘了，因为在软件领域，破坏的成本几乎是零。
你可以在计算机这个狭小的空间内，制造各种爆炸：内存溢出、栈溢出、空指针等等各种系统异常乃至奔溃，都不会对你造成伤害，计算机默默承受了这一切，CPU 帮你执行了一次又一次的任务，最多就是浪费电，不太环保而已。
事实上很多程序员就是在不断的试错中完成需求的，我喜欢称他们为“试错型程序员”，他们在网上随便找代码抄过去，自己跑了一下，有点问题，改了几个 bug，看起来没问题了，提测，测试同学又发现了几个 bug，改 bug，bug 改完了，上线，上线后有点小紧张，怕会出现什么“意外”，观察了好一阵子，没有“意外”，呼，长叹一声：运气真好。
而一个具有权威精神的程序员，是不相信运气的，他的学习、工作效率是极高的。
他从官方文档、白皮书、论文里看到的资料，就是软件工程的定理，他可以放心的认为它们就是正确的，而那些从非权威资料，从网络零零碎碎博客学习的程序员，他们会心虚，他们也许得看好几篇博客，才能觉得这就是正确的结论（而这时候有可能这些博客都是错误的、过时的，因此他所认为的正确，其实还是错误的）。
也许你也尝试过阅读英文文档，但由于母语环境的原因，阅读英文，肯定没中文快，没关系，我并不是说你就不能从中文博客里学习：
如果你现在还需要依赖中文博客，那么业界大牛的博客、参考了权威文档的博客，要比那些毫无依据的博客更权威；
在博客里获得的知识，请尝试到权威文档，找到对应的描述和依据。方法：把知识点关键词，翻译成英文，在谷歌里搜索，能够在官网站内搜索更好（当然谷歌也支持指定站内搜索，site:${官网} 关键词）
请多阅读英文文档，努力提升你阅读英文文档的能力；
2.底层精神
你很可能会焦虑，焦虑自己到底要做什么，学什么，才能让自己区别于他们口中的“CRUD 程序员” ？
有人说，程序员门槛很低，确实，如果把能够写出可运行代码的人，称为程序员的话，那人人都有成为程序员的潜质。
会写 CRUD 的程序员，很多，但是懂 CRUD 背后原理的程序员，则很少：
你会用 Java 在内存里给 i 做加一的操作，但不代表你知道 JVM 是怎么给 i 加一的；
你会往 MySQL 里插入一条记录，但不代表你知道 MySQL 是怎么插入的；
你会用 Kafka 做消息队列，生产消费消息，但不代表你知道 Kafka 是怎么处理消息的；
似乎一切的动作，都可以归纳为 CRUD，但如果你知道 CRUD 底层的原理，那就和那些只会写 CRUD 的程序员不一样了，代码上线后：
某一段代码性能极慢，他们不知道为什么慢，你知道；
MySQL 死锁了，他们不知道为什么死锁，你知道；
Kafka 处理消息效率很低，他们不知道为什么低，你知道；
而且你很自信，如果是你来写CRUD，是不会让这样的问题上线的。
这，就是你作为一个程序员的竞争力所在。
有一张后端程序员的学习路线图（Back-end Roadmap）：
当然，不是这里面的东西都要学，如果都学，你可能就会和其他程序员一样，只懂得怎么用，而不知道技术底层是怎么实现的。
挑其中你最常用的几项，比如 Java、Spring、Dubbo、MySQL、Kafka、Apollo，深入研究他们，阅读他们的官方文档，看源码，知其然知其所以然。
检验的标准很简单：梳理出自己的一套调优方法/最佳实践，并能解释为什么这样做是最优的，这就要求你弄懂它们底层的原理。
3.不只是技术
技术是用来解决问题的，但是当你工作后，你也许会发现，只靠技术，是不能解决所有问题的。
你需要熟悉公司的业务，理解需求的价值和目标，再用合适的技术去实现它，能解决问题的程序员才是牛逼的程序员；
你想用的技术，公司不支持，也许是因为需要更多的机器，你需要学会怎么在技术和成本之间做平衡；
技术是你的一把锤子，但不要有了锤子，就认为万物都是钉子，什么都想用技术去解决，也许换个需求的实现方式，也能解决用户的痛点，而且实现起来还更简单，那何乐而不为？
只会用技术解决问题，那不是你掌握了技术，而是技术控制了你；
知道什么时候要用技术解决问题，用什么技术，这才是你掌握了技术。
你要学习的，不只是技术，也许还有沟通、管理、写作、思考等等能力，也许你需要阅读很多非技术类的书籍，我也会在后面的来信中和你分享一些书单。
4.保持技术热情
你是不是觉得我很矛盾，刚说不要只懂技术，现在又让保持技术热情。
可是这两者并不冲突呀，只懂技术是一个极端，丧失了对技术的热情又是另一个极端，最好的状态就是，保持对技术的热情，又清醒的知道不必什么都用技术去解决。
为什么会失去对技术的热情呢？也许就是因为上面所说的，你发现了太多太多的事情，不是用技术就能解决的，现实并非你以前认为的那么纯粹，现实世界并不像计算机世界那样，特定的输入就有特定的输出。
但是，想一想你为什么选择了做软件、做科学，也许当初你爱上编程，就是因为你喜欢创造，你享受自己写下的代码，创作的的作品，运行起来时的那种美妙的感受，哪怕只是打出一行“Hello World”，都让你开心半天，更何况是你写的代码，做的轮子，被成千上万的用户使用了呢？
总而言之，不忘初心，不要被工作、生活的其他杂七杂八的因素，毁灭了你的技术热情。
你想问我是怎么保持技术热情的？
我的方法很简单，那就是在工作之外，自己写些代码解决问题，如果实在没有问题可以解决，我就写编程题、写算法题，我还喜欢用非工作语言的编程语言来写，比如我工作用的 Java，那业余时间我就用 Python。
写代码有时就像写作，写着写着，你就会不由自主的回忆和思考，拾回一些丢失的东西。
5.马上就干
很多人懂得很多道理，但就是过不好这一生，每年年初都制定了一堆计划，但是最后发现都没坚持去做。
也许你看了我上面的信，有很多感触，但是如果没有行动，这些收获就不能转化为实实在在的东西。
我相信你不想成为这样的人，怎么办？四个字：马上就干。
通常当我听到一些很有用的话时，我不会就此打住，我会继续追问，然后呢？然后我可以做什么呢？有什么事是我马上就能做的呢？
陈皓老师（左耳朵耗子）发起的一个叫 ARTS 的打卡计划启发了我，如果我们可以针对我们的目标，列出对应的行动，并且给自己布置作业：每周/每月完成多少次，甚至是跟一群人一起打卡，互相鼓励和分享，这样一些看似很难实现的大目标，就被我们拆分成每周/每月去完成的小目标，这样也就变得很容易实现。这也是陈海贤老师在他的书《了不起的我》里头提到的 —— 小步子原理。
如果你的目标跟我一样是：
提高阅读官方文档、白皮书、论文等英文权威资料的能力；
深入学习常用的技术，打造自己的竞争力；
提升沟通、管理、思考、写作等综合能力；
保持技术热情；
那么你可以这样制定自己的每周打卡计划：
每周至少做一个 Leetcode 算法题。主要是为了保持技术热情，不忘初心。
阅读并点评至少一篇英文技术文章。主要是为了提高英文阅读能力，让你能阅读更多的权威资料。
分享一个技术知识。主要是为了归纳总结你的技术学习，最好是在某个你常用的领域，不断深入学习，提升竞争力。
分享一个你在非技术领域获得的感受。主要是为了在其他方面也能够得到成长。
每周完成这四个目标后，把四个目标对应的输出合并在一起，发布出来，完成打卡。
如果你的目标跟我不同，想在其他方面有所发展，也可以制定自己的目标和打卡计划。但有一点，我希望你的成果，是能够输出出来，给其他人去看的。
如果你仔细看我的目标，你会发现，我的结果都是对外可见的。不管是代码，还是点评文章、还是分享，以及最后的汇总发布，因为只有你的成果，是你愿意去对外分享的，你才真的收获到了东西。
如果你只是在心里跟自己说，我这周学习了，很努力了，但其实你并没有收获到什么，那你只是在自欺欺人，假装很努力。
但是一个人的自控力是有限的，不可能要求自己每次都能管住自己，每次都能约束住自己，这时候，就需要借助外界的力量。这时候，找一群志同道合的人，一起学习，一起打卡，就变得特别有意义。
转自：公众号-柳树的絮叨叨