從工程師轉行數據科學家後需要做什麼?前輩建議:趕快把 SQL 練熟吧

【為什麼我們要挑選這篇文章】從軟體工程師轉行數據科學家後,該學習哪些技能?這兩個領域的差異,是軟體工程師的工作較好定義,時程相對容易規劃,而數據科學家必須常常面對「未知」,除了硬實力(Python、SQL)之外,軟體工程師還需要怎樣的 mindset?(責任編輯:郭家宏)

萬事開頭難,從一個軟體開發工程師轉型為數據科學家,第一年該怎麼做?

一位博主就記錄了自己從全端工程師轉行數據科學家第一年的心路歷程,包括好的方面和不好的方面,希望能幫助到同樣處境的人。

以下是作者第一人稱敘述。

從全端軟體開發人員轉行數據科學家

我覺得自己非常幸運僱主給了我一個機會,讓我從一個全端軟體開發人員轉型變成數據科學家,和內部數據團隊一起工作。

入職一年,我很享受這份工作給我帶來的全新挑戰,完全不同於以前做開發。我想寫這篇文章,首先是為了回顧過去一年所做的事情:我經歷的改變,我做得好的地方,我可以改進的地方。第二,通過記錄我曾經遇到過的問題和挑戰,我希望能幫助到和我處境相似的人。

在開始之前,我先介紹一下我的背景:我之前不是做軟體開發的,我擁有計算機科學的碩士學位和博士學位。因此,我不算新手,我有工具、模型和分析方法方面的相關經驗。我從事開發工作將近 8 年。自從我的論文發表以後,我經歷了很多變動。

本文將分為兩部分。進展順利的部分和進展不佳的部分。對於那些只對結果感興趣的人,也可以拉到底直接看最後的結論。

進展順利的心得:程式語言選擇 Python,並確實記錄文檔

Python vs. R:Python 更好上手

剛開始,我不確定在專案中該使用 Python 或 R。所以一開始我對這兩種語言均作了研究學習,並在專案中結合使用了這兩種語言。

R 經常讓我想起 Matlab,兩者在用來編寫和執行程式碼的界面非常像(我嘗試了 R Studio 和 Visual Studio 的 R 外掛),同時寫程式碼和處理數據的方法也很像。

但我只在碩士論文中用了 R,還在博士學位論文中用了一些。除此之外,R 和其他程式語言相比(這些年來,我在軟體開發中經常使用 C#)就沒什麼共性了。R 這個工具極度以數據為中心,與數據進行交互的方法也很不一樣。

在 R 裡有:列表、矩陣、向量、陣列和資料框。每個都有不同的使用場景,你需要學會什麼時候使用。R 與 C# 的語法很不一樣,所以剛開始學 R 我遇到了不小的困難。我並不是說 R 不好,只是我使用 Matlab 10 年,並且作為開發我的腦子已經習慣了某種思維方式,所以比較難轉變。所以我剛開始的時候覺得 R 很難上手。

作為一名有 8 年 C# 開發經驗的工程師,我覺得 Python 比 R 更容易起步。很可能是因為我的大腦已經習慣了 C# 的思維方式。python 比 R 更接近於 C#,所以我學 Python 比 R 快很多。

在使用這兩個語言時,我沒覺得兩者有明顯區別,尤其是對於可用的庫,兩者在我想做的工作的實現方面有差不多的處理能力,我也會得到相同的結果。但在摸索過程中,我對兩個工具分別都有些困惑。

總的來說,寫程式久了, Python 對於我的工程師思維更友好。

所以我很快放棄了學習 R,轉而專注 Python。這有助於我更快地進步,不必再花時間閲讀新語法,事情變得簡單許多,我一直覺得簡單才是王道。這對我應對角色的許多其他變化也是有幫助的,因此,這樣做可以最大程度地減少更改。

關於使用哪種以及何時使用,我敢肯大家定對此有很多意見,但是對我來說,從開發人員過渡到數據科學家後,我發現 Python 變得更容易掌握和使用,尤其是在我擔任新職位後想快速發展並取得成果的初期。

所以與 R 相比,使用 Python 讓我更快進入狀態,在輸出方面,我沒有發現兩者有任何明顯區別。所以我把這個歸類為進展順利,因為我很早做出了決定,且至今沒有遇到任何情況讓我覺得自己選錯了 Python,相反我節省了不少時間,所以我能更快地開始工作。

文檔記錄:完整文檔可提升專案效率

記錄一切,我定義的一切是從模型超參數到從何處以及如何獲得訓練數據,到在整個專案中做出選擇的理由。另外,以有序的邏輯方式編寫文檔,實現這一目標的一個秘訣是, 哪怕你只是寫給自己看(例如,在我的情況下,我是唯一的數據科學家),你應該想像有人會讀這份文檔。

此外,記錄時要對自己有一定的約束,不要拖拉,不要走捷徑。不然等你開始寫的時候,你可能已經忘記一些需要注意的細節。因此一定要及時寫下來。在完成文檔之前,我覺得工作就還沒做完。我從一開始就遵循這種方法,我覺得至關重要。

我發現一件事是,即使在一個中型企業,等到一個專案的研究成果在公司開始推廣已經是一段時間以後了,利益相關方因為有其他事要忙,所以不會立刻作出回應。

有時候在我完成一個專案幾個月後,有人跑來問我問題,我一時想不起來,但如果我翻看我之前做的文檔記錄就能馬上提供詳盡答案。例如,有一次我與另一位經理聊起幾個月前做的一個專案,我向他展示了我已經完成的工作,他問我訓練集的大小是多少,以及我用來獲取數據的日期區間。我並記不得那些數據,但我記得自己已經寫下過,而且我也記得寫在了哪裡。所以我能馬上把文檔拿給他們看。

我發現自己遇到的另一種情況是當業務優先級發生變化,你可能會需要停下手頭還沒完成的專案去做另一個專案。當你再回到之前開始的專案時,完整的文檔可以讓你從之前停下的地方繼續進行下去。

不順利中的學習:數據處理要用 SQL,並根據受眾調整溝通模式

數據處理:SQL 是良好的解藥

回顧前一年,進展不順利的一個原因是我處理數據的方式(對於數據科學家而言這非常關鍵)。

當我沒有使用數據庫的經驗時,我基本上復用了在博士期間使用數據的方式。使用平面文件(特別是 CSV)來儲存數據。我把從生產環境中提取的初始數據,清洗後的中間過程數據,分析後的數據和結果都存在了 CSV 裡。我工作流程中的每一步驟都需要透過 Python 腳本讀取上一步建立的文件,並建立新的文件。

這種把內容儲存在硬碟上,並透過 Python 腳本與數據交互的原始辦法,很快就出現了一些問題:

▌有時很難在大量文件中找到我要找的那個文件。即使我記錄了文件的內容和位置,但有時還是很難找到我想要的確切文件,因為文件實在太多了。
▌我似乎總是在忙著用 Python 把從文件中讀取數據或者將數據寫入文件。我寫了很多文件訪問的命令,但其實是在做重複勞動,寫這些程式碼對我要做的工作並沒什麼幫助。
▌想快速地將數據總結一下似乎都有點費力:讀取數據、彙總統計、輸出統計、查看統計結果。
▌有些文件很大,用起來很困難(在 notepad 中打開 10 GB 以上的文件很麻煩)。

第一年,我花了很長時間才意識到 SQL 是我的解藥。

在從事數據科學家工作之前我使用過 SQL,但是我一開始沒有意識到它對我的價值。當我意識到 SQL 就是我的解決方案後,我花了很多時間來學習更多有關 SQL 的知識,因為我在做工程師的時候稍微學了一點 SQL。

具體來說,我學習了如何查詢數據(特別是我以前沒接觸過的高級語句)以及搭建和維護數據庫的基礎知識。我甚至通過了兩個 Microsoft SQL 的考試。我現在主張儘可能用 SQL。我把所有專案的數據都存在了 SQL 數據庫中,儘量在 SQL 中做數據查詢和操作。

我的原則是:能在 SQL 中完成的處理,就在 SQL 中做。SQL 處理不了的任務再用 Python(例如模型訓練和執行)這裡延伸出一個問題:你需要學會使用 Python 庫,例如 SQL Alchemy,從 SQL 讀取數據到 Python 裡。

現在我的後 SQL 生活變得容易很多:

▌所有專案數據存儲在一個容易找到的地方。
▌沒有重複程式碼用於讀寫文件。
▌我能快速查詢數據並從數據中輕鬆得到統計結果。
▌我能夠很容易地查看大量數據,特別是前幾行的數據。
▌額外的好處是,現在很容易把不同的數據聯繫起來,因為數據都已經在關係數據庫中了,現在安全性也提高了:把數據存在本地磁碟上有潛在的風險。數據都在伺服器裡,安全很多。

因此,我強烈推薦學好 SQL 並用起來。

成果展示:根據受眾調整溝通模式

還有一個進展不順利的地方是我做的一些展示。從開發人員到數據科學家的一個變化是,我做演示的場合變多。展示的內容各種各樣,有面向技術人員的 demo 演示,有面向業務相關人員的專案報告,再到與公司內部其他部門討論專案工作,甚至向公司外部的第三方合作方展示工作。

對於這些人,我覺得我沒有做好的一點是,我沒有根據受眾來調整自己的展示方法。有些展示我做得還不錯,比如對開發人員的技術演示我覺得我做得還不錯。因為我跟技術人員擁有差不多的背景,所以說技術的內容彼此也聽得懂,交流起來會更容易一些。其他類型的演示更難一些,不幸地是,很多時候,我在展示的時候才意識聽眾對我講的內容不是很在意。

我的受眾分為四類,從展示的難易程度來分如下:從最簡單的(最左邊)開始,到最難的(最右邊):開發人員、業務、其他部門以及外部人員。

我還可以將最左邊的那些受眾標記為最技術性的,將右邊的那些受眾標記為更「銷售型」的,當從左向右移動時,兩者之間會有一個過渡。我發現針對左邊受眾的展示是最容易準備的:他們對我正在使用的技術或所從事的業務領域有深刻的瞭解。

針對外部人員的演示是最難的,因為他們往往相關知識最少。過去,我與這些聽眾進行交流的時候會直接進入到技術細節,就像我和左邊聽眾交流時一樣,但是結果很不好,因為他們不一定具有任何數據科學或機器學習的背景,所以我談論許多概念對他們沒有多大意義,他們不知道我在說什麼。對這些受眾來說,如果我花點時間介紹一下我正在做的工作以及更多的背景知識,效果會更好。甚至對某些受眾來說,向他們介紹機器學習的概念,為什麼我們要使用它以及它的好處。有時候,對我來說,不過多討論技術細節反而是好事,給他們一些大概的框架概念就好。

在反思了這一點之後,我現在在準備演示材料時,會更多地考慮我的目標受眾。具體來說,我會考慮聽眾可能知道或不知道的內容,以及需要向他們呈現的內容,以幫助我準備需要討論的內容和專業程度。這樣他們就可以更好地理解我正在談論什麼,並從演示中得到一些收穫。為此,在準備演示文稿時我為自己準備了一些有用的問題,如下:

▌聽眾對於數據科學領域瞭解多少?
▌聽眾對於我試圖解決的問題瞭解多少?
▌聽眾知道我在使用的技術嗎?
▌聽眾對於我採用的技術細節或者結果感興趣嗎?

計劃:數據科學家必須接受「未知」

與工程師時相比,做數據數據家的工作計劃更有挑戰。作為開發人員,工作相對比較直接,所以也更好估算和規劃時程。你通常知道你要實現的目標以及如何實現。當我還是一名開發人員的時候,我使用敏捷開發工具。

因此,工作內容可以先評估、計劃,然後排好優先級就開始做。在敏捷的方法論指導下,如果工作沒什麼意義,或者你不清楚如何做,你就不會把它排進工作計劃。因為無法評估,因為未知,你要等到所有不明確的地方明確後才開展工作。

數據科學的工作並不像這樣簡單,對於給定的問題,你不會總是提前知道什麼會起作用,也不會總是知道哪種類型的模型最準確。類似這樣的情況與剛才提出的觀點出現矛盾,當你是開發人員時,只有問題明確後,你才會把他們放入你的工作列表中。作為數據科學家,未知是你工作的一部分,因為你的工作就是要回答這些問題。或者你正在處理的問題可能會隨著專案進展而改變。因此,有時候你提前做的幾週計劃可能很快要重新考慮。

在計劃方面,我喜歡將開發工作視為線性的:你知道自己在做什麼以及如何做。數據科學工作我覺得是分叉樹,可能需要試不同的道路,可能會碰到死胡同。

數據科學家做短期工作計劃還是可行的,比如你正在訓練和測試的模型之類的,接下來一兩週的工作,但是長期計劃很難做。你不可能總是提前知道什麼會起作用,什麼不會。所以我們才要進行實驗和測試,這是數據科學家工作的核心價值。

最後,花點時間去做不一定會有成果的工作,即使不起作用,也沒什麼大不了的。

回答正確的問題:先從業務蒐集初始需求與資訊

在過去一年中(這讓我跌過很多次),我發現數據科學工作的關鍵部分是回答問題,但更重要的是回答正確的問題。

正如我所說,我跌過很多次,當時我正在回答一個問題,但並沒有回答業務方實際想要回答的問題,之所以發生這種情況,是因為業務方使用的業務語言跟我用的的技術語言有差異,有時候我們用一樣的詞,但要表達的意思卻不同。

針對這問題,我的解決方法是在做專案的實際工作(現在稱為「專案前」工作)之前先做準備性工作,在這個階段,我會從業務方那裡收集初始需求和資訊,做一些初步分析,然後給業務方展示。

運用敏捷的工作思路,我希望在每個 sprint 實現一個可交付的成功,並向業務方展示該成果。這樣,我與業務方建立了一個有效的循環反饋機制,向他們展示一些東西並詢問他們的意見,這可以建立一個有效對話,從而更清晰地定義真正要解決的問題。這個方法在專案各個階段都有效,不僅僅是初始階段。當你向業務方展示你的工作結果時,可能會激發他們不同的想法以及他們之前沒有考慮過的思路。從而你能找到他們真正的痛點。

所以過去一年來我發展的一項關鍵技能是與業務方的互動交流,深入挖掘他們真正想要的東西。

總結:用 Python 吧!再練個 SQL

Python 比 R 更容易學習,因為對於工程師來說,Python 與其他程式語言更接近。

▌邊執行邊做文檔
▌學習如何使用關係數據庫,比如 SQL,用數據庫來查詢、操縱和儲存數據。
▌你需要準備很多展示,不僅是向專案業務方的報告,還要向公司其他同事報告,甚至是公司外面的人。
▌你需要提高演講能力以滿足不同受眾(技術或非技術)的需求。

工作計劃不是一帆風順的,因為你無法預知什麼起作用什麼無效,要有心理準備有時候花了時間不一定取得預想的結果。

花時間找你真正要解決的問題,不要不加思考就埋頭開始做,與業務方建立反饋閉環是很有必要的。

原文 傳送門

(本文經合作夥伴 大數據文摘 授權轉載,並同意 TechOrange 編寫導讀與修訂標題,原文標題為 〈从全栈工程师到数据科学家,入职第一年我都做了些什么?〉。首圖來源:Pxfuel CC Licensed

更多數據科學家的工作心法

數據科學家技能趨勢解析:PyTorch 職缺大漲 108%,SQL 將成為需求第二大的程式語言
【內附免費工具】給工程師的學習路徑與訓練開源碼,手把手帶你升級數據科學家!
傑出的數據科學家不會用一般人的方式學習,他會掌握這 5 個訣竅!

點關鍵字看更多相關文章: