What's Research?

My thoughts on research and stuff here and there…

又是兩週年 – 工作篇

換新工作滿兩年了. 當年回來MERL是因為我之前作的Computer graphics/Visualization和GPGPU/HPC/Cloud computing, 現在則是一直在學Computer vision/machine learning. 有時候別人問我在作啥, 如果對方不是相關領域的, 我都說: 就是最熱門的AI就是了. 雖然還是有講等於沒講, 但就可以換來崇拜的眼神 XD.

儘管是熱門的題目, 但其實還在思考如何下手, 找到自己能夠發揮的部分. 過往老闆或計畫需要什麼, 我就作什麼. 我比較擅長的是計畫的執行, 包括實驗設計, 實作, 觀察和結果分析. 很少會自己去提一個計畫. 前兩年在公司也是接手已經存在的計畫. 現在公司開始希望我有點自己原創的想法,  完全讓自己去找方向. 說是完全的自由, 但我反而覺得困惑. 我大部份的點子都是計畫作一半時才體會出來的. 現在東試一點, 西讀一點, 其實不是很踏實, 頗有種"拔劍四顧心茫茫"的感覺.

和作工程師比, 作研究的難, 不是"怎麼作" 而是要"作什麼". 這種過程和碩二上找題目的茫然有得比. 讀很多paper卻無從下手. 那半年的研究生活等於是繳了白卷. 不過, 既然要作研究, 大概也得有這樣的心理準備. 作研究當然不是簡單的路, 只是這世界上有什麼有趣的工作是簡單的? 我還是喜歡作研究, 或者說, 會想從一些不同的角度或想法去思考怎麼解決問題, 而不只是寫程式/測試, 這也是為什麼回來MERL啊.

但我不是討厭實作. 事實上我很感謝之前在亞馬遜的工作經驗. 有時和同事一起寫程式, 我還可以教一些軟體開發的觀念, 比如code review, 或是比較進階的工具或Python/Java語法, 很多都是當年在亞馬遜學到的. 當時從資深同事的code review中, 學得最多. 現在除了慶幸自己還能有所貢獻外, 也會擔心自己是否很快就江郎才盡. 我常覺得自己快沒東西可以教人了. 有天如果理論和實作都不行, 就沒有競爭力了.

還好現在同事也會找我去試一些不同的東西. 也總是盡量去試看看. 之前一起試Jenkis (支援自動測試), 還有把Caffe給移植到Windows. 我們是兩年前就開始的, 當時Caffe對Windows的支援還很有限. 因為後者的關係, 也試著要貢獻我們作的bug fix回去Caffe, 雖然最後沒有被採用, 但從別人的review中, 還能學到cmake的新功能. 感謝年輕時學到的"不要隨便說不", 讓自己接觸新東西.

當了兩年的研究員, 心中仍然是充滿惶恐, 希望至少不要忘記一些年輕時學到的功課. 最近聽David Patterson的最後一堂課, 很多想法都很鼓舞, 更慶幸的是年輕時有人教我類似的觀念. 比如要證明一個想法是否可行, 與其爭辨, 其實最好的方法是作實驗, 用實驗證明給人看. 還有如何和人溝通, 很多人以為要讓別人覺得自己的研究很偉大, 就得用術語嚇人. 還好我博班老闆是真正的溝通高手, 能把一個觀念講到深入淺出, 讓每個人都能懂, 但又不會誤以為這觀念很簡單, 這才是真本事. 我在學生時代傻傻地學, 現在才真的覺得受用匪淺. 這點非常感謝我博班老闆.

另外去年托同事的福, 投了好幾篇papers. 雖然也拿了不少rejection, 但我們最後都沒有錯過deadline. 結果不敢說是最好, 但我們努力在deadline前把實驗作的很完整, 並且用不同的角度去分析我們的實驗結果. 不論實驗是證明或反證自己的理論, 我都很感謝年輕時學到的觀念: 你測過了嗎? 因為實驗和分析, 都幫助我們更了解整個問題.

發表論文對研究者很重要, 特別是這個博士過剩的時代, 但我總覺得論文是副產品. interesting work, good work, solid work, 才是最該追求的事, 也才是最快樂的事. 保持這樣的想法, 才能無入而不自得吧?

 

FW: How to Be a Bad Professor

David Patterson (RISC, RAID還有SPARK的發明者)去年從大學退休, 他的最後一個lecture title是How to be a bad professor, 我想把professor換成researcher也適用.

原文出處: https://docs.google.com/document/d/1s4pnLF6S5q_r7jv1Vo8d6SiUUwaUY_pYo1001Fgfo3s/edit#heading=h.3npmj9somgol

Abstract: The premise of a last lecture, which is a tradition at some universities, is that if this were the last public lecture you would give, what would you say? In the hope of starting that tradition here—in my actual final Berkeley lecture before I retire in June—I will give the fourth and final edition of my bad advice talks. (The prior three were “How to Give a Bad Talk,” “How to Have a Bad Research Career,” and “How to Build a Bad Research Center.”)

 

The first part of the talk will be a tongue-in-cheek advice at how to be awful at all the responsibilities of professorship: research, classroom teaching, graduate student advising, service to the field, and service to the campus and community.  Guidelines include:

  • (Research) Papers are the Coin of the Academic Realm
  • (Classroom) PowerPoint Replaces Preparation
  • (Grad Students) It’s Quantity, Not Quality
  • (Service to the Field) Serve only if a big Fame Ratio: Name Recognition Increase / Hours Invested
  • (Service to the Campus and Community) Don’t Do It!

The second part of the talk will offer advice on alternatives to being a terrible professor. As I’ve got nothing left to hide, I’ll use tell-all examples from my four decades at Berkeley.

After a question and answer session, I’ll tell my story of how I accidentally became a CS grad student and a Berkeley professor, and life lessons that I wish someone had told me 40 years ago that I’ll pass along now.

 

FW: India’s worst engineers come from the city that sends the most STEM students to the US

這文章一定要存起來 因為我想原文很快就會因為政治正確的理由被和諧掉了 XD

India’s worst engineers come from the city that sends the most STEM students to the US

Hyderabad, the southern Indian city that sends the largest number of STEM students to the US, is home to India’s worst techies, a study has noted.

Software engineers from the city lag much behind those from other Indian cities when it comes to programming skills, a recent Aspiring Minds study of over 36,000 engineering students in India showed. The employability assessment company tested students from IT-related streams at over 500 colleges across India on Automata, a machine learning-based assessment of software development skills.

The study analysed students on their programming skills, practices, and ability to handle runtime complexity—the time taken to run a program. Hyderabad had a total score of just 3.49 on 100 while New Delhi had 23.48 and the Mumbai and Pune regions together had a score of 17.51.

Hyderabad, home to over 6.8 million people, is the common capital of two Indian states, Andhra Pradesh and Telangana. Over the past decade or so, it has turned into a hub for thousands of students aspiring to enter the prestigious Indian Institutes of Technology. Between 2008 and 2012, it sent over 26,000 students to the US, most pursuing science, technology, engineering, or mathematics (STEM) degrees, a Brookings Institution report (pdf) said.

“Hyderabad, India, sent the largest number of STEM students (20,800) to the United States and ranked fourth for the percentage of its students pursuing a STEM degree (80%) during the 2008-2012 period,” the report said. “Notably, 91% of students from Hyderabad are studying for a master’s degree, versus only 4% for a bachelor’s degree.”

In 2015—the year for which the latest data is available—the US government issued around 60,000 visas to Indian students, with a large number being issued by the US consulate general in Hyderabad.

India is believed to be churning out the world’s largest number of engineers every year at over one million, but the graduates’ skill levels have remained poor. “Only 4.77% candidates can write the correct logic for a program, a minimum requirement for any programming job,” the Aspiring Minds study had noted.

“Lack of programming skills is adversely impacting the IT and data science ecosystems in India,” Varun Aggarwal, a co-founder at Aspiring Minds said. “The world is moving towards introducing programming to three-years-olds. India needs to catch up.”

 

提醒自己vs抱怨別人?

有人對我說: “你工作好像很容易?"

我一怔: 啊? 怎麼會呢? 我同事都是相關領域研究的資深研究者, 我的論文少 其實很弱的. 而且我才剛轉過來作新題目, 其實還有很多要學.

“可是 看你的波文常常在嫌人家這裡不好那裡不好 應該是你覺得別人很弱".

er…這…好像也沒錯. 最近的基調, 好像真的常常在嫌別人哪裡沒作好就是了. 雖說是提醒自己, 可能也太頻繁了點.

我是常常在嫌不好的實習生(嗯), 而且抱怨的不只是現在的同事 (咦?). 有時看到一些事, 想到以前看到的種種反例 就忍不住會寫下來. 不過寫太多, 似乎對自己也沒啥好處就是了. 嫌別人之餘, 更重要的是自己能否避免同樣的錯誤.

自己還在博班時期寫的 感覺比現在正面多了. 我自問很好運 在職場早期看過很多正面的例子, 也還好以前有寫下來. 不知道還有無機會寫出同樣的感覺?

不然, 就是溫習一些職場日劇(比如“午餐的敦子”“紅鱂魚”), 給自己一些比較正面的想法吧.

 

 

 

不忘初衷?

工作幾年 發現就算你很喜歡那個環境, 也總會遇到不想共事的人, 或是遇到一些莫名其妙的事.

剛好最近遇到一些事, 讓我在想: 如果被迫要和一些不喜歡的人一起工作 該怎麼處理呢?

其實是很想率性地說:

我是來工作 不是來修身養性的.

不過今天早上想: 真正重要的 不是職場上的人怎樣, 或是工作的環境變怎樣, 而是自己會變怎樣, 特別是:

是否能保持從第一份工作時學到的東西?

我在第一份工作中學到很多東西, 比如要寫紀錄, meeting要準備, 不要輕易否決對方的想法, 要作測試, 等等. 很多人一輩子也遇不到好的mentor 我年輕時倒是遇到很多.

特別是: 不輕言說不. 我年輕時老是說不, 什麼都不可能, 不夠好, 有問題, 一直看我經理和同事把我否決的事情給作出來.

我常想, 還好年輕時遇到他們. 所以後來有人找我合作時, 總是願意去試看看. 也因為這樣, 才一直學到新的東西. 從圖學到GPGPU, 再因為老師的計畫開始作HPC, 因為這樣的背景, 才能去亞馬遜接觸雲計算. 又再度因為這些技能的總合, 才回到現在的單位, 也才有機會作電腦視覺 作所謂最熱門的AI. 熱門不是重點, 只是方便和圈外人解釋自己在作什麼. 真正幸運的是過程中一直有新的體會, 看到新的東西.

我可能還是很討厭一些人, 但就是因為討厭他們, 更沒有理由因而喪失了自己好不容易才學到的東西.

因為, 為了這種人而墮落的話, 不是太對不起年輕時遇到的那些人了嗎?

FW: 孤獨

大學+當兵時的學弟寫的 很傳神:

自己一個人,或許是一種溫水煮青蛙般的孤獨,可是當一群人聚在一起,你卻發現你更加孤獨的時候,那才是折磨人的孤獨

本來我以為沒有多少人能了解我這種想法,但是自從看了月薪嬌妻,男主角發現自己無法插入俊男美女快樂的感情話題,所感到的那種孤獨與憤怒,我就相信應該很多人都這樣,所以編劇才編得出來

寧願溫水煮青蛙,也不想要在外受到折磨的感覺,不知道有多少人其實是這樣靜靜地活著的

你測過了嗎?

這週五有個會議的deadline 我們打算把之前一篇被拒的paper 改投到這個會. 之前我們作了幾個實驗,比較我們的兩個方式A和B, 但沒有整合在一起比較, 這次就補個實驗 看A和B如果結合在一起, 效果會怎樣.

初步實驗作完後, 我們只看統計數據, 看不出什麼差別, 但我們不知道怎麼解釋. 後來我們有一個假說, 就是這兩個方法中 其實有個方法已經cover另一個方法.所以就算合在一起, 也看不出顯著的差異.

這假設乍聽之下也沒什麼不對, 但我總是不太comfortable只有假說, 而沒有額外的測試去驗證, 就建議除了最後的統計外 我們應該至少去探討我們從A方法, B方法, 和A+B一起的方法所得到的數據 看有沒有什麼特性可以支持或反證這個看法. 我想如果真的已經被涵蓋了, 這些數據應該有很多重複性吧?

後來幾個小時後, 實習生跑過來, 說其實實驗有問題…

簡單地講, 因為一個程式的錯誤, 所以我們並沒有真的測到A和B共同的效應. 我們只測到其中一個方法, 難怪測出來不分軒誌. 他就是在比較這幾個方法得到的數據時, 發現會得到一模一樣的結果, 而這是too good to be true, 是不可能的. 所以他才回去重新看log, 看程式, 才發現這個問題.

我倒沒生氣. 只要我們沒有報錯的數劇就好. 還有幾天時間, 就重新測A+B. 反正還有原本的實驗作基礎.

後來想: 我當時沒有兇, 絕對不是我脾氣好的關係. 我不是出名的兇嗎?

事實上, 聽到這件事時, 我還蠻高興的. 因為, 如果不是當時我們決定要去重新檢視資料, 我們根本不會找到這個問題. 就算實驗失敗, 如果能夠知道為什麼失敗, 那我們已經又邁進了一步. 總比作了一個看似成功卻不知道為什麼的實驗要來得solid.

而且這不但幫我們找到一個問題, 對我個人來說, 又證明了年輕時學到的一句話是多麼重要:

你測過了嗎?

我以前經理老愛問這一句. 而那時候真的是履試不爽: 不管是現象, 假說, 還是bug, 如果我沒再測過的東西, 不管再怎麼claim, 總會被別人發現漏洞. 大概那時常常出糗, 後來就覺得真的沒有測過, 就不要隨便claim, 因為到最後丟臉的是自己.

但我後來自己拿這句話教學生, 或是問同事, 對方不是不甩我, 就是告訴我: 這已經被證明會work了. 還好我年輕時吃過一些苦頭, 就算遇到這些同事或學生, 我也不會覺得這句話不對, 只是常常想: 要怎樣去表達, 才能把這種自己好不容易體會到的精神, 讓別人也感受到呢?

這次的過程, 不就是個很好的經驗嗎?

後計: 剛好最近看到下面這篇文章, 講法國一個博士後, 好不容易上了篇頂級期刊, 但後來發現太多錯誤而被撤稿. 文章中提到現在找教職的壓力很大, 沒有幾篇好的期刊, 根本沒有機會.

http://retractionwatch.com/2017/03/14/stress-postdocs-negligence-lead-retraction-high-profile-paper-supervisor-says/#more-48658

剛好遇到這次實驗的錯誤 倒也提醒自己: 作研究之所以為了投好的會議/期刊, 真正的重點不是成名, 也不是所謂的career. 而是

  1. 讓自己在一個定點前能夠有把任務給wrap up的能力
  2. 不要輕易放棄.
  3. 投好的會議, 才不會讓自己誤以為做研究很容易.

無所不知? 無畏不知?

從年輕時到現在 總會遇到真的比我知道多很多的人. 比如現在有個同事 雖然是研究員 可是對於各種系統管理的工具和技能都很熟. 還好我以前在台灣當兵也是作網管 有點基本概念. 如果他找我一起測試什麼, 我都很高興, 因為和他一起作事, 都能學到新東西. 這種真的很懂的人, 多半是很謙虛的, 但你和他作過事, 你就知道他的實力.

倒是也遇過很多人, 老想維持自己"無所不知"的形象, 問他什麼, 他一定會立刻生出一個答案 這個答案一定fancy 並充滿術語. 但不一定合乎真正回答你的問題 因為他的目的不是回答你的問題, 是要讓他自己看起來很強. 他們自己往往也不知道這個答案是在幹嘛用的, 他們只是在某處看過相關的字眼, 就拿來嚇你了.

如果繼續問: 你有測過嗎? 他就說: 別人已經證明過了. 至於別人證明時的假設是什麼? 是否和現在問題的情況相符? 是個漂亮的理論 還是已經實用化? 付之闕如. 有時候我甚至想問更基本的問題是: 你回答的, 和我問你的, 有什麼關係?

還好, 仍然能和很多前者一起共事.  因為看到前者, 才知道知識在真正知道的人上是什麼樣子, 也才知道這種"無所不知"的外在形象, 其實是虛無的. 不然, 面對人家拿個新問題來問你時, 能夠壓制自己想要show off的心態, 甚至承認自己不懂,  其實有點難.

與其把自己表現成"無所不知", 更重要的是保持種"無畏不知"的心情, 或者說, 不會去畏懼未知. 以前李遠哲對他的學生說:

我如果知道答案, 我就不會要你作這個題目了.

不論是R(研究)或是D(開發), 一直在遇到未知的問題, 不才是正常的嗎?

What’s (Vis) Research?

很久沒寫東西了 雖說是寫給自己看的 總覺得荒廢太久不太好. 最近在審paper 就算是這幾年幫vis相關會議審papers的牢騷吧, 只是這個題目很潛越就是了, 因為這種題目通常是給大師級人物用來作keynote speech用的.

常常覺得很多人以為Visualization就是作GUI: 只要寫了一個系統有menu/button/滑鼠操作, 加上一些2D繪圖, 他們就覺得這是Visualization的Research, 然後就拿來投學術會議了. 我不是說這些使用者介面和visualization無關, 但我實在無法找到研究的成份. 有時看到一些本來不是作vis的人  突然submit paper到相關會議時 與其高興 (多數人都希望自己的領域有越來越多人參與) 我倒是好奇: 這些人是真的覺得Visualization很重要? 還是他們誤以為Visualization的研究很好作?

可是話說回來, visualization的研究是什麼呢?

我也不知道答案. 審文章的時候, 我可以判斷它有沒有研究的成份, 但我卻無法很明確地描述怎樣的研究和visualization有關, 大概是這幾年念太少相關的papers了. 我早期的論文都和速度有關, 如何把已知的方法作得更快或更好. 速度是最容易衡量的. 這幾年隨著計算能力的進步, 速度的重要性似乎降低了. 現在要如何找到自己能切入的方向呢?

題外話: 對一般人來說, visualization代表什麼呢? 至少以找工作來說, 會找到怎樣的工作呢?

因為我過去都在IEEE Vis發表paper, 當年要找工作時 一開始也是用visualization當關鍵字來找職缺. 扣除研究單位的研究員工作, 能找到的業界工作主要就是作visualizaiton相關軟體的公司. 2D vis的話有Tableau或Bloomberg. 3D vis的話有Kitware和一些作CFD的公司, 但是地點沒有Tableaus (Seattle, WA) 或 Bloomberg (NYC) 那麼有趣. 對我這種城市小孩來說, 就不是那麼有吸引力.

如果是大IT公司, 很不幸的, 他們的visualization職缺通常是我這種人無法match的, 因為對他們來說, 需要visualization技能的職位是:

  • 設計師: 需要的是設計/藝術相關訓練, 不是CS背景.
  • 資料科學家 (Data scientist): 真正重要的是統計相關的訓練. 這種職缺通常把data visualization放在第三順位. 講白了, 有visualization經驗很好, 但沒有也沒有關係. 可是如果統計不好, 那就不行了.

這也算是種inconvenient truth吧.

冒名顶替综合症

過去一年破天荒的參加教會團契,所以也會和人分享一些想法。認識的人以學生居多,所以多數也都會面臨人生的十字路口: 是要繼續念書呢? 還是回台灣呢? 或是要在美國找工作呢? 因為自己也經歷過這些事,所以也會分享自己的經驗,包含以前申請學校,念博班/作研究,求職,在台灣/美國工作等等。

經驗之餘,也會分享當時的心情。說起來,碩士畢業前是最不安的,因為那時真的不知道以後會走到哪去。直到經歷各種轉折後,發現不論去哪,都有神的安排,因為總是能學到東西,只是很多東西當下以為用不到而已。大概是常常在面臨人生的十字路口吧,這幾年在是沒有念碩士時那麼惶恐。看到別人不安時,也會試著去鼓勵人

可是呢,分享到後來,有時卻開始懷疑自己了。為什麼呢?

一種情況是: 你很高興的和人分享,結果對方完全聽不進去,甚至講一些反例,講一講反倒是開始懷疑起自己講的東西了。這個在帶學生時特別容易遇到。

另一種情況,是懷疑自己自己是否能一直保持這樣的心情。並不是說我過去的經驗與心情是假的,只是現在雖然試著去鼓勵人,可是以後如果再遇到人生的十字路口時,自己是否也能保持平靜? 如果作不到,我現在講的話,豈不是對人就很空洞? 更擔心的是: 別人如果真的試了,會不會害到對方呢?

最近看到一個字眼冒名頂替症候群,倒是很能解釋這個現象。根據維基百科:

冒名頂替症候群,亦稱為冒名頂替現像、騙子症候群。這個名稱是在1978年由臨床心理學家克蘭斯博士(Pauline R. Clance)與因墨斯(Suzanne A. Imes)所提出,用以指稱出現在成功人士身上的一種現像。患有冒名頂替症候群的人無法將自己的成功歸因於自己的能力,並總是擔心有朝一日會被他人識破自 己其實是騙子這件事。他們堅信自己的成功並非源於自己的努力或能力,而是憑藉著運氣、良好的時機,或別人誤以為他們能力很強、很聰明,才導致他們的成功[1] 。即使現實環境中的證據指明,他們確實具備優秀才能,他們還是認為自己只是騙子,不值得獲得成功。

不只是在和人分享的事上,在工作和研究上,也常有這樣的感覺: 常覺得如果以前作了一些有趣的計畫,其實都是運氣不錯,能找到一些沒有人想過的點能切入,然後作出一些新東西。比如博班畢業前的最後一篇paper 其實是聽完同學的報告後,突然想到也許可以利用某個數學工具來解。我也會想: 我這樣的好運,會不會那天用完呢?

冒名頂替症候群好像可以視為一種病? 我是不知道怎麼治。也許少和人分享過去的經驗,也是一個方法? 不要和人分享,就不會擔心我的建議是不是不適合別人,也不用擔心別人聽了我的建議後,下場反而會更慘。但是這招不能用在工作和研究上啊!

這幾天有些困惑,突然覺得該寫下一些事,好提醒自己:

  1. 工作/研究免不了會遇到失敗,只是因為害怕失敗而不去試,那就失去自己作為一個員工的價值。既然計畫的結果有可能失敗,那就只好多紀錄那個過程,要求自己在過程中,做好自己該作的,並試著多學一點。
  2. 和人分享自己的經驗時,就真的的只是分享,而不是扮演一個告告在上的先知。要考慮對方和自己的差異,對方的心情,用對方能懂的話語描述。
  3. 更重要的,可能是提醒自己: 在第一次決定人生道路時,自己是如何惶恐,而後來又怎樣被神帶領,讓每次意外的人生轉彎中,都學到一些事。

利用分享來提醒自己這些過去得到的恩典,是更重要的。雖然不知道自己以後會怎樣,但是能夠有過去的恩典,就值得感謝了。

寫到這裡,突然想,大概就是因為我不太虔誠,但又自問虧欠上帝,所以才覺得自己是冒名頂替吧?