本文经授权转自公众号“ALFRED阿福”
责编 | 胡巍巍
来自Heap（一家主要为企业提供用户数据分析架构的企业）早期员工Michael Malis，就如何成为一名更加优秀的工程师给出了自己的日常训练方式：
读论文；
学习一种新的工具；
读书；
录屏。
其中第四点比较有趣，大家感兴趣可以直接跳到第四部分，看看他是如何具体实施的。以下为正文。
我的成为更好的工程师的方法是建立一套训练体系。这套体系里有一些固定的练习，我每周都会进行。设计这套训练体系有两个非常明确的目标：
学习解决之前不会解决的问题；
学习如何更快更好的写程序。
训练计划主要是由四个练习组成的，每一个都会帮助我向上面的两个目标前进。这四个练习是：
读论文；
学习新工具；
读书；
写程序的时候录屏。然后回顾一下，看看能不能写得更快。
下面我会详细地介绍一下我是怎么做的。我想分享一些练习的细节，还有我从中获得的收益。
读论文
这项练习的目标是拓展CS相关的知识。在这之中我发现有两方面直接收益。第一是一些论文可以改变我对一些固定问题的思考模式。举个栗子，The Tail at Scale这篇论文验证了反直觉的长尾延迟的本质。
其中我认为比较有趣的是关于在大量机器上运行一个请求是怎样影响延时的问题。作者研究了Google一项服务的实验数据。这项服务将请求拆分，然后分发给不同的服务。
他们用数据评估了一下，将请求分发给100个服务的情况。作者发现，如果你测量从100项服务获得回复的时间，一半以上的时间花费在等待最后五项服务的回复上。
这是因为最慢的5%的请求要比其他请求慢非常多。论文也给出了一些方法来降低长尾延迟。我发现这些方法，在我这边的一些工作上也可以用。
第二个好处是我发现读论文可以让我融会贯通不同系统的知识。举个栗子，Google的分布式数据库Spanner。
Spanner用了很多不同的技术，比如Paxos、two phase commit、MVCC和predicted locks。通过阅读相关论文，我就能建立对于这些不同的技术的理解。这可以让我以一个整体来理解Spanner，并且和其他系统比较Spanner的利弊。
我读的论文主要来自于以前读过的论文的参考文献或者Morning Paper的封面文章。Designing Data Intensive Applications这本书的参考文献里也有很多值得一读的论文。
学习新工具
解决问题最简单办法之一就是用一个解决这种问题的工具。这个练习就是选一个工具，然后学习一下它。
通常我的练习过程就是，安装工具，练几个教程，然后简单看看手册。我这么学过的工具范围从bash指令比如JQ、Sed到分布式系统比如Kafka、Zookeeper。
学习bash指令让我解决日常问题的效率提升了很多。类似的，学习不同的分布式系统可以让我明白如何针对不同的问题运用不同的工具。
读书
我用书来补充从论文里或者学习工具无法获得的知识。我读过的书主题范围比较广。比如最近读过的：
Refactoring – 这本书让我明白好的代码是什么样的，以及如何将不好的代码转化为好的代码。
Getting Things Done – 这本书让我明白如何安排工作的优先级以及如何追踪工作进展。它帮我建立了一套体系来确认优先完成重要的工作。
The First Time Manager – 最近我刚好做了团队管理员，需要协调不同的团队一起工作，还要主持团队会议。这本书有助于我理解管理的基本原理。
录屏
这个训练是我的最爱。这个练习也是对我解决问题改变最大的。运动员经常会看自己的录像来让自己做的更好。
所以我决定也这么搞一下，来提升编程能力。我从自己的录屏里学到的经验包括：
它可以帮助你在写代码的时候就测试代码。这样可以通过快速定位Bug来减少DEBUG方面消耗的时间。如果之前的代码都没有Bug，那Bug肯定是在你新写的代码里。
当DEBUG时，针对要DEBUG的对象专门添加函数是非常有必要的。举个栗子，之前一个玩具的项目，我要写一个LRU缓存。写了个Bug，它不能清除正确的元素。这时我就可以快速地添加一个打印当前缓存状态的函数来看一下是哪里出问题了。之后我就可以看一下缓存的期望状态和现在实际情况的差别。这样就可以让我快速定位Bug。
在开始写代码之前，花五分钟决定一下方向会非常的有效。这么做有两点好处。首先是能够确认方向是正确的。更重要的是，这样可以强迫自己选择单一的方向。因为看了我的录像后，我发现我在选择实现方向上经常犹豫很长的时间，其实两个方向都还OK。
所有这些经验现在回顾的时候都很明显。但是在我看录像，发现我在哪里花费大量时间之前都没有能够系统地将这些经验总结出来。
我做这项练习的步骤是：
记录一些我写程序的录像。可以是工作中的，也可以是在LeetCode这种刷题网站上刷题的时候。
十倍速看一遍录像，并且记录每个时刻我在做什么。
然后统计一下在大的类别上分别花费的时间。比如花了多少时间DEBUG，花了多少时间写功能。
看看花时间最长的类目。然后仔细研究下为啥花费了这么长的时间。
提出一些能够让我节约时间的方法。有一些办法可以让我把代码结构化，然后可以让我少写一些代码或者更快找到Bug。
我强烈推荐写代码的时候录屏。这是一种最简单的不断做一些小的改变来让自己效率更高的方法。
这套训练策略我坚持差不多一年了。感受到自己发生了很大的改变。学到了很多之前没有学过的关于系统和工具的知识。
现在解决问题也要比之前快。希望你能考虑一下这些练习，然后自己也尝试一下。
原文：https://malisper.me/my-approach-to-getting-dramatically-better-as-a-programmer
翻译：阿福
推荐阅读：