A Survival Guide to a PhD by Andrej Karpathy

先送上原文鏈接，專心看的話英語全文閱讀時間大概在40分鐘左右。

這篇博客是Stanford博士，現在的Tesla AI Lab Director Andrej Karpathy關於PhD生活的一些體會和經驗，泛泛談了包括了如何選擇導師和相處，如何選課題，如何看paper和寫paper等等學生關心的話題。總體而言寫得比較樂觀但還是很實在，不惜用自己的糗事來舉出反面例子告誡後生。

下面筆者挑選一些自己感興趣的店來作為提要，讓大家在讀這篇博客之前有個初步印象。

• 挑選課題：

一個ambitious的目標可以讓你更有創造性地思考手頭的工作。

phd最好在某個方向有奠基性工作：堅持一個細分方向，做到最好。

cockroach paper: 做"incremental work"的工作，也就是對 方法 沒有大的改進，只是稍微提高了性能。有趣的是這樣的paper容易被錄取，因為審稿人沒理由拒絕。但是並不會有很高地引用率，也不會給你帶來什麼名聲。所以最好不要做那種「順其自然」，「進一步發展」的工作。

作者花了三年才找到自己堅持的方向，前兩年做3D(kinect fusion, 3D meshes, point cloud features)和video.第三年和Richard Socher談話才覺得圖像和語言融合是一個很有趣的事情。

• 如何寫paper:

中心思想應該只有一個。

關於用詞：

in your papers you never 「study」 or 「investigate」(there are boring, passive, bad words); instead you 「develop」 or even better you 「propose」. And you don』t present a 「system」or, shudder, a 「pipeline」; instead, you develop a 「model」. You don』t learn 「features」, you learn 「representations」. And god forbid, you never 「combine」, 「modify」 or 「expand」. These are incremental, gross terms that will certainly get your paper rejected :).

一個好習慣：把投稿deadline訂在實際得兩周前，然後做內部review。

其他關於寫paper的建議：https://cs.stanford.edu/people/widom/paper-writing.html

• RELEASE YOUR CODE

it will force you to adopt better coding habits due to fear of public shaming (which will end up saving you time!), it will force you to learn better engineering practices, it will force you to be more thorough with your code (e.g. writing unit tests to make bugs much less likely), it will make others much more likely to follow up on your work (and hence lead to more citations of your papers) and of course it will be much more useful to everyone as a record of exactly what was done for posterity.

使用docker container來減少別人提出的依賴問題

• Give Talk

A common failure case (as an audience member)

is to see talks where I』m painfully bored during the first half and completely confused during the second half, learning nothing by the end.This can occur in talks that have a very general (too general) overview followed by a technical (too technical) second portion. Try to identify when your talk is in danger of having this property.

推薦閱讀：