书摘: How to be a programmer: A short, comprehensive and personal summary

看得是初学者进阶阶段,因为工作经验还是比较少,理解的并不深。先暂且摘录几个要点,以供时时反省和检查。

  1. learn to debug: be able to examine the code and understand what’s wrong

至少从我现在写的小模块来看,这点还是不难。但是如果新接触一个复杂的系统,要入手实现某些功能或者应用,还是有点难,特别是涉及到很多引用类,或者没有文档的情况下。

2. remove an error and fix the bug

作者建议是一次只改一样东西。

3. how to effectively use a log

我很少会去写log,可以去思考下公司的项目,都是如何写LOG的,怎么通过看LOG去找有意义的信息,发现可能的错误,或者发现performance的瓶颈。这是要去学习的的地方。

4. how to understand performance problems

如果一个系统的latency高,那么如何去发现可能的performance bottleneck。这个也是现在工作里比较少涉及的,因为我们更多去关注了搜索产品的相关性。作者提到I/O expense(也就是从hardware去存,或者取),这个是很多系统的通病。作者也提到一些技巧,来减少performance issue。

5. how to learn design skills

design方面更是没有涉及到过。我觉得这个应该从自己的小项目开始练习,并且去读那些设计优秀的系统或者软件的源代码。

除了技术能力之外,作者也谈到了一些软实力。

  1. estimate how much time you will spend on programming

这里讲的就是要估计到所有的不确定性,也许可以通过一个统计模型来大致估计要花多少时间。并且要让团队的人都能对你的估计,表示一致。

2. how to find information

我觉得这个是非常重要的部分。因为工作中时常有问题,知道什么类型的问题该用何种渠道去解决,将使工作变得更加高效。

a. 如果只是general knowledge, 比如你想更进一步的了解深度学习,这个当然是自己去找书看。如果是non-trivial issues, 比如当时我在建模型的时候,想明白为什么sampling可以有规律的改变GBDT模型的precision/recall。 我就去阅读GBDT模型的数学基础。

b. 如果你是一个比较明确的问题,你想获得别人这个方法可以不可以,这个library用合适不合适的问题。那么找到相关的人,或者求助网络,总没错。

c. 如果没人知道答案,而你却又可以通过实验来解决,那么自己来实验是最好的方法。但记住,每次实验的时候,都记住你的假设。并且去思考为何实验的结果和假设相符了,为什么不符。

3. how to utilize people as information sources

这章节也是我需要反思的。我现在还处于,哎,我今天问了你一个问题,我在你面前混了脸熟。我没有去思考,在别人给我benefit的同时,我是不是也可以帮到他们什么,给他们一些benefit,做到互惠互利。

4. how to write documentation wisely

不是为了写文档而写文档。真正牛逼的程序员,是能做到以下两点: 1. write self-explanatory code 2. only document code that you cannot make it clear by writing the code itself

我记得当时我去读Yoni大神的代码。他的documentation非常清楚,让我知道了他的设计思路,通过例子告诉我,每一个重要的类都是做什么的。