原文·Why I gave your paper a Strong Reject [1]
作者·Matt Welsh [2]
剛剛完成了對另外一個會議投稿論文的復(fù)審，所以說，現(xiàn)在該是我寫博客的時間了。
我慢慢的開始意識到，利用風趣的語言去教育每一個論文作者們，或者使用刻薄的語言給予一篇論文反饋意見已經(jīng)不是我所期冀的事。真希望有人能夠開一門“如何寫一篇精妙的科學(xué)論文”的課程，并且把我的這篇文章作為課上的必讀材料。但是如此的話，哎，我就要和這些被要求來讀我這篇博文的可憐的人們糾纏在一起?；蛟S從現(xiàn)在開始，我應(yīng)該先將這篇博文附在我的所有論文反饋意見上。
今天我將說的所有內(nèi)容其實早就被提及過（強烈反對）[3]，而且很有可能是我說的（勉強接受？），但我還是想分享一下幾個最重要的，會使我恨不得撕碎一篇論文的原因。
（必要聲明：這篇文章僅代表個人觀點，不涉及公司或其他相關(guān)個人。）
差勁的摘要和前言。在讀完一篇論文的摘要和前言后，我基本就可以確定將懷著怎樣一種心情去繼續(xù)閱讀論文剩下的部分，當然我也一定不會去讀一篇已經(jīng)被我打上“強反對”標簽的論文的剩余部分。記著我的話，我每天要讀一打20到30篇的論文，所以不要期待我會在讀了你糟糕的前言后，還會有心情去幫你挑論點或者數(shù)據(jù)的小錯。
許多問題會出現(xiàn)在你的前言部分，比如到處可見的拼寫錯誤和語法問題。（當然，在某些情況下這是可以忍受的，比如作者是非英母語地區(qū)的人。但如果這種情況下，他的文法仍然很差的話，我依然會強烈反對這篇論文，哪怕他的技術(shù)部分無懈可擊。）還有一小種問題就是，缺少在摘要和前言中概括自己方法和成果的能力。別讓我在深入地去讀完你的文字后才可以理解你的工作內(nèi)容和你的論文結(jié)果，這又不是丹布朗的小說，我不需要期待一個大反轉(zhuǎn)結(jié)局。
我認為的好的論文需要一個如雄辯闡述式的前言。我在寫論文的時候，往往會花費更多的時間在前兩頁，因為這才是一篇文章的重中之重。剩余的部分只不過是對前兩頁的支持罷了。
還沒有定義清楚問題就闡述解決方案。 這是我個人的一大忌諱。許多論文在沒有闡述清楚自己要解決什么問題的時候，就開始急于表達解決方案或者系統(tǒng)設(shè)計。最起碼要做到的是，你要說一下自己的論文目標和受限條件。更好的改正方法就是提出一個真實的、具體的場景，并告訴我為什么現(xiàn)有的技術(shù)不能解決這個問題。簡而言之，就是讓我感受到你論文的強烈動機。
贅言實現(xiàn)細節(jié)，不說解決想法。許多系統(tǒng)領(lǐng)域的論文都有這個問題，浪費四到五頁紙去說該系統(tǒng)如何實現(xiàn)中最無聊的部分——充盈著箭頭和盒子的圖，詳細的API定義，該用哪個版本的python以及研究生桌子下的實驗機的內(nèi)存有多大。
對這種問題，我只能說：我根本就不在乎你的實現(xiàn)。我在乎的是你的想法是怎樣的，以及這個想法是如何轉(zhuǎn)化成為一個，遠比你之前寫的還抽象和高度概括的多的實現(xiàn)綜述。許多人根本搞不清什么是想法，什么是作品—— 詳見我之前發(fā)布過的內(nèi)容. 有許多論文需要著墨于實現(xiàn)細節(jié)，例如一個很難的技術(shù)問題是如何被他們克服的。 但絕大多數(shù)的其他論文，實現(xiàn)是根本無足輕重的。所以千萬別讓你的論文充滿這些垃圾，雖然這些內(nèi)容會讓你的論文看起來科技感十足。而我也知道，這幾頁是非常好寫的，因此寫多寫少都不會讓我對你另眼相看。
寫一堆從毫無用處的文法意義上的廢話。 相信我，你絕對不會讓學(xué)術(shù)委員會成員們吃驚于你的：基于內(nèi)容的動態(tài)可擴展帕累托最優(yōu)中間層在基于云實現(xiàn)的傳感敏感的分布式車輛中的應(yīng)用。 如果你寫的論文像自動生成的論文模板 ("在理論的理論大挑戰(zhàn)是虛擬機和實時理論的重要統(tǒng)一。為了能網(wǎng)頁瀏覽器構(gòu)建何種程度上實現(xiàn)這一目的？"[4]), 或許你需要重新想一想該怎么去寫論文了。 簡練而準確得正確描述自己的想法。一個壞的想法不會因為你寫得很花哨而被接受。
著眼一過于復(fù)雜的問題而創(chuàng)造出的工作。 許多計算機領(lǐng)域的研究都是先有解決方案而在之后才為它思考應(yīng)用場景的。 (我也曾這樣做過) 常見的情況是，當一位作者真正要開始寫論文了，他才會開始為他設(shè)計的杰出解決方案想一個令人信服又十分具體的應(yīng)用場景。然而審稿的人并不會被輕易愚弄。 如果把你所面對的問題稍稍簡化一點，就讓你的解決方案失去效果，那么你也應(yīng)該去重新找一個問題來解決了。
沒有描述文字的圖表。 這是一個很小的問題，但往往會讓我崩潰。你明白我的意思，在一個擁有多個坐標系和許多數(shù)據(jù)的圖下面，圖表名卻只有兩個字“圖 3” 。審稿人需要花費很多時間去理解你畫了些什么，然后才能明白哪些是這個表所提出的事實。 理想的說明文字應(yīng)該是高度概況圖表內(nèi)容以及圖中數(shù)據(jù)代表的含義的。這里的一張圖來自于 我之前的某篇論文:
是不是很漂亮？即使某些粗讀論文的人，他們或許并不會深入了解我的方法，但仍然可以清楚地明白這幅圖表達的含義。
草率而幼稚地寫相關(guān)工作部分** 相關(guān)工作部分絕對不是一個音樂單曲搶答游戲。 ("This one goes out to my main man, the one and only Docta Patterson up in Bezerkeley, what up G!")[5]。相關(guān)工作絕不單單是一串論文名，借此證明你知道這些文章。你應(yīng)該詳細描述他們的工作內(nèi)容，并且將自己的方法與之進行對比。你絕對不能說： “文[1-36]同樣與該問題相關(guān)。” 請尊重相關(guān)工作。如果你覺得他們的觀點不對，說出來并解釋原因。如果你贊成他們的觀點，也記得向他們表達謝意和贊成。正如我博導(dǎo)告訴我的，站在巨人的頭上，而不是腳趾頭上。
[1] 文章簡介：該文章來自于博客Volatile and Decentralized，刊載日：2016年4月20日。
[2] 作者簡介：馬特威爾士(Matt Welsh)是Google一名軟件工程師，現(xiàn)致力于發(fā)展移動端網(wǎng)絡(luò)性能。 他曾任哈佛大學(xué)教授。研究主要包括 分布式系統(tǒng)與網(wǎng)絡(luò).
[3] 翻譯小注：由于譯者初次翻譯，又受困于時間?？赡芊g效果差強人意，比如此處，就沒辦法還原作者原意，希望大家可以去看看原文，感受下作者巧思。
[4] 這一段原本就不存在意思，于是我就將原文機翻并復(fù)制過來。
[5] 我保留了這一段沒有翻譯，因為并沒有查找到Dr. G,Patterson的相關(guān)信息，特此聲明，他日如果找到一定回來補充。
