從純文科生到軟體工程師之路:離開哈佛後,「再也沒有標準答案」的嶄新旅程

「從純文科背景轉往軟體工程,我面對的,不僅止是換跑道、轉專業的挑戰;更加衝擊的是,被標準答案掛帥教育體制下長期豢養的我,一轉眼間被丟入這個由 0 和 1 建構的學習場域。」
評論
Photo Credit:Shutterstock/達志影像
評論

本篇來自 Alice Yang 投稿,同步刊登於 Medium,INSIDE 編審後刊登。關於作者:從純文科生轉換跑道,誤打誤撞來到矽谷當起軟體工程師,上班寫的是程式碼,骨子裡仍然是無可救藥著迷於 storytelling 的浪漫主義者,不想錯過任何生命中發生的新奇事物,因此決定持續用文字,去紀錄一段段世代的呢喃。

整整兩年沒有下筆寫過一篇文章,現在的我連起個「正常的」中文文章開頭,都略顯激動 — — 因為在這過去 700 多個日子天天陪伴我的,不是我最鍾情的中文字、也不是短篇小說或電視劇,而是一片漆黑的螢幕,運行著上百行的程式碼⋯⋯。

一個又一個漫漫長夜裡,只有解也解不出來的 bug 和一杯杯的咖啡因,在一旁冷眼看著時間流逝,一切都只為了等待螢幕上最終跳出的, “ all tests pass ”。

落入「外星文」的世界 — — 與程式語言的第一次接觸

Source: everyone’s very first Java code
Source:  everyone’s very first Java code everyone’s very first Java code


這是我這輩子第一次接觸的 Java 程式碼,我想我永遠不會忘記當時面對這段「英文字」時,腦海中排山倒海而來的不解 — — 大概是因為人生中第一次遇到「每個英文字都看得懂,但怎麼樣都無法領悟這些字結合起來的意義」的狀況。記得那時還想著:「喔,原來程式還有公開和非公開的隱私啊!」

學到物件導向(object oritened programming)的時候,也總是無法理解「類」(class)的道理,和為什麼要「創建」(new)一個「對象」(object);接觸了資料結構,覺得發明二元搜索樹(binary search tree)的人簡直來自異次元,遑論動態規劃(dynamic programming)、回溯法(backtracking)對我而言更宛如天書⋯⋯種種當時的懞懂,現在回想起來只覺得恍如隔世。

姑且拋開那些流不完的眼淚,和為了抵擋睡意支撐顫抖的深夜,從純文科背景轉往軟體工程,我面對的,不僅止是換跑道、轉專業的挑戰;更加衝擊的是,被標準答案掛帥教育體制下長期豢養的我,一轉眼間被丟入這個由 0 和 1 建構的學習場域:

它既不能容忍任何錯誤、卻又沒有「標準答案」,凡事只能靠不斷地摸索磨練中,追求優化再優化的成果、與自己的能力。

反思台灣教育 — — 保護傘底下,我們究竟學會了什麼

初學程式,我接受的是完全性的震撼。從小在台灣接受教育的我,不管是什麼科目,選擇題、填空題都有「正確答案」,應用題有「標準解法」,甚至連申論題和作文都有「參考範文」,在參考書的最後一頁靜靜地等待著。

這個教育體制的設計,仿佛深怕在學習路上的我們,因為碰到解不開的問題感到挫折,一絲一毫偏離正規軌道都覺得心疼不捨,小心翼翼地,架設從小到大的「學習保護傘」,就像學游泳從不脫掉的救生衣,學騎腳踏車從不拆掉的輔助輪。這導致我們往往覺得自己「學會了、理解了」,從成績單上亮麗的滿分、領不完的獎狀,獲得自我膨脹的滿足感。但其實卻是從未真正準備好,勇於面對沒有標準答案的真實世界。

在被程式問題連番擊倒,開始自我懷疑的同時,我總忍不住回想,當年那個在學習路上一帆風順的自己,究竟是抱持著怎麼樣的學習模式?

時間倒轉,回到高三那年為了準備七月指考的五、六月 — — 教室裡的電風扇孜孜不倦地旋轉,也抵擋不住夏日高漲的炎熱,台上老師口沫橫飛,一切只為了將學生送往好大學。台下的我們,則不知道畫乾了多少螢光筆,粗體、斜體、紅黃綠藍,在各大重點間徘徊。不知道寫滿了多少本參考書和模擬試題 — — 題目對我們而言不重要,而是全心全意要將考點和答案牢牢記住,只為追求那個上榜時那個不可一世的瞬間。高三時期,儼然是我一生中知識水平的巔峰,我們在考試的窄門中用盡全力的求生存,有如豺狼虎豹,飢渴地將書本上的內容全數掠食;我們為了排名爭鬥不休,卻對於獲取的知識往往不明就裡,只對分數的差距錙銖必較。

不諱言,在這樣的學習體制下,我做到了,進入了人人稱羨的名校。但作為表面上成功者的我,內心卻充滿著徬徨和悲哀。我為那些來得快、去得也快的速食知識感到悲哀,也為失去這些知識的自己,感到無盡的徬徨。

如果現在問起,高三的時候學了什麼,我八成支支吾吾的答不上話,說也奇怪,當時可以說是自信滿滿把所有內容背得滾瓜爛熟的自己,為什麼這段記憶就像是從腦袋中某個區塊被狠狠拔除一樣,忘得乾乾淨淨了呢?

我想,這也許是因為我從來沒有,嘗試去驗證考卷上的答案、或思考答案背後的意義,這項能力也未曾在我的學習歷程上,受到過任何重視。

每個人都該學習程式,因為它教我們如何思考

Everybody in this country should learn to program a computer, because it teaches you how to think”

— Steve Jobs, Co-Founder, Apple

這個國家的每個人都該學習編寫電腦程式,因為它能教你如何思考

 — 史蒂夫.賈伯斯,蘋果共同創辦人

學程式給我的課題,首先來自於思考:我開始學著不靠關鍵字做題目,仔細地逐字逐句讀懂問題、釐清各種假設;也體認到「No one knows everything」(沒有人知道全部),和在面對問題時如何「擁抱未知」的心態。

在沒有了標準答案奉為圭臬,你會發現自己「真的開始思考」:思考題目的含義,思考如何設計答案。反觀以往習慣「一張考卷、50 題、60 分鐘」等的作答方式,在時間的壓力下往往不允許思考,更遑論「設計答案」 — — 這也是我認為在傳統體制內學習的學生,最欠缺的能力。

其實,不論面對什麼類型的問題,都需要「思考」和「設計」這兩項能力,不是事事都有標準答案;只要這答案是符合需求(能夠解決問題)的,都有存在的價值。

另外,就是在遇到問題時「找尋答案的能力」程式語言社群奇妙的地方在於,它像是一個集大成的智慧結晶(Collective Intelligence),在遇到程式相關的問題時,你絕對不是世界上唯一有過相同問題的人,另一個有趣的現象是,你也很難搜尋到一模一樣的答案,是可以百分之百複製貼上到你的程式碼裡的。所以,你需要的不僅僅是「找到答案」,更要做到「驗證答案」,最後並能夠「內化答案」。

程式語言的學習曲線,對我來說就像是座標軸上的垂直線,第一眼面對的,就是毫不留情的懸崖峭壁,我曾經狠狠地被撞得頭破血流,數不清在腦海裡萌生過多少次想放棄的念頭 — — 但說也奇怪的是,也許是這種「沒有防護繩索」的學習模式,我一次又一次被前所未有的挫敗感襲擊,卻也體驗到從小大到沒有感受過的成就感。感覺就像是電影《Free Solo》裡,男主角Alex 徒手攀登上優勝美地酋長岩的過程 — — 危險在指尖顫動、生離死別在眼前閃過,那種屏息以待的悸動,直到成功站頂峰上的瞬間,更是一種無法用言語形容的成就和滿足。

一段打破過往框架的學習之旅

Learning to write programs stretches your mind, and helps you think better, creates a way of thinking about things that I think is helpful in all domains.

— Bill Gates, Co-Chairman, Bill & Melinda Gates Foundation, Co-Founder, Microsoft

「學習如何寫程式,可以延展思路,讓你學習如何更好的思考,創造另一種思考事情的角度。我覺得這種思考能力在任何領域上都很有幫助。」

— 比爾蓋茲,比爾及梅琳達.蓋茲基金會聯合主席、微軟聯合創辦人

對我來說,學程式這兩年來所學到最重要的事情,不在於程式語言本身,而是在改變了一生的學習態度。而我也深信,這樣的學習態度,是任何專業領域都可以受用無窮的寶貴資產,因此希望能將這些體會分享給讀這篇文章的你:

1. 「萬事起頭難」但「貴在堅持」:在這個學程式儼然變成全民運動的時代,多少人前仆後繼,但到最後能夠堅持下來的卻寥寥可數,我也記不清自己曾經註冊了多少從來沒上完的網課,Introduction to Python, Programming Language for Everyone, Web Development Fundanmental,買了多少本「第一次學XXX程式語言就上手」,有如磚頭般厚重的工具書,經歷仿佛科技文盲的撞牆期⋯⋯但在初期階段,我發現,與其貪心地想要上完所有的課,不如先專精地選擇一門自己真正感興趣的領域,等你從頭到尾學完一門課的時候,想學下一門的恐懼和困難也必然大大減少。

2. 不追求「囫圇吞棗」和「一夜速成」:學程式好比學武功,達到高峰絕非一夜練成,體會其中的精妙之處也不是一蹴可幾,有別於以往考試前可能還可以「臨時抱佛腳」,學習程式更加看重的是點點滴滴的積累和反覆思辨。同時很重要的是,學習如何在「精疲力盡」和「苦無進展」之中取得平衡點 — — 學程式的過程並非平穩上升的直線,更會經歷許多百思不得其解的問題點,與其正面對決,你更應該做的是適時暫停,放下手邊的問題,過一段時間後,也許你會驚訝的發現尋覓已久的答案往往近在眼前。

3. 「永不止息的熱情」:學無止境,是從事軟體工程師必須恪守的志業,要如何能夠時時刻刻保有信念呢?我想,唯有無可抹滅的熱情 — — 那是一種不需要靠別人認可,由內部而生的動力,才能帶給你誰也偷不走的滿足感。

持續不斷的「書寫」

有人說,程式語言像一面鏡子:即便是同樣的運行結果,卻可以反映出書寫者最真實的心境,苟且、急躁、縝密、多疑,都可以從程式碼的樣態中一覽無遺。

又有人說,程式語言是世界上最誠實的語言:不存在任何僥倖和模糊空間,不心軟、也不刁難,老老實實一行一行地運行著;也有人說,程式語是唯一只能透過書寫(而非口語)詮釋的語言⋯⋯。

或許正是上述種種原因,造就了程式語言的「高冷」,彷彿兀自處在只屬於「自己人」的小宇宙內,彼此無聲而熱切地交談著。

但在曾為人文學科的我看來,程式語言的字裡行間,更潛藏了一種「病態的美」:那種「病態美」正來自於書寫者的投入與狂熱,像是畢卡索作畫時的轟轟烈烈,張牙舞爪卻只改動了畫布的冰山一角;又像是達文西雕刻時的百般斟酌,反覆推敲只為了那寥寥數行文字。
現在的我,對於這種狂熱美感,也許還有那麼一點似懂非懂的迷惘,但現在我清楚知道的是,程式語言也好、中文字也罷,我只希望自己能夠用這些語言持續書寫,留下點什麼。

Write once, build everywhere,simple, yet beautiful. 

後記:寫這篇文章的出發點,並不在於教導人如何「從零開始、學程式一學就上手」,但若大家想知道更多關於學程式的實戰面心得或學習資源,歡迎留言給我。希望這篇文章對你有幫助,想看更多文章或分享歡迎來我的專頁/IG 逛逛。

責任編輯:Anny
核稿編輯:Chris

延伸閱讀:



開發者享受 CI/CD 價值!運用 Amazon EKS 整合 GitLab 創建自動化部署

企業如何在 Amazon EKS(Elastic Kubernetes Services)上使用 GitLab 創建自動化部署,減輕人力負擔,提升專案服務運作效率?
評論
評論

所謂現代化智慧 IT,所有工程師最希望的境界,莫過於只要輕鬆點幾下設定,系統就會自動跑起來,管理者再也不用隨時待命在機台旁邊,從此工作悠哉又快樂!儘管這樣情境還沒到來,但隨著敏捷式開發的流行,除了 DevOps 人員,有越來越多開發者將 CI/CD 概念融入到工作流程當中,例如從 build code、執行 unit test、到部署應用程式。

打造第一個在 AWS 上的應用程式

上述種種反覆步驟自動化執行,也就能提昇服務品質、主動通知開發人員以減輕人力負擔,讓專案服務能持續運作。

其中,GitLab 是執行 CI/CD 常用的工具之一,也是開發者使用程式碼儲存庫的地方。為了讓 GitLab Runner 在雲端快速實踐 CI/CD,《AWS 開發者系列》透過影片分享,如何在 Amazon EKS(Elastic Kubernetes Services)上使用 GitLab 創建自動化部署。

以下節錄工作坊影音內容,幫助開發者快速理解如何運用 Amazon EKS 的高可用性且安全的叢集,將修補、部署節點、更新等關鍵任務,全部做到自動化設定。同時影片也會示範 Amazon EKS 搭配 GitLab 如何展開自動部署,幫助工程團隊實踐 CI/CD 價值。

Amazon EKS 對容器管理輕鬆簡單、維運省時省力

容器化服務越來越興盛,當容器(Container)越來越多,在複雜的微服務(Microservice)系統環境之下,運維團隊的管理成本可能相對會增加不少,為了有效調度容器部署, 導入Kubernetes 無疑是近年企業熱門的話題之一。

建構 Kubernetes Cluster 流主要可區分兩大塊,一是安排容器調度的Control Plane、另一則是容器運行時需要用到的 Worker Node。

Control Plane 裡面涵蓋有儲存狀態的 ETCD、CoController manager 、Scheduler 的調度管理、甚至是操作時進行互動的 APIServer,若是自己創建 的 Kubernetes Cluster ,需要自己安裝這些元件,後續仍需要對 Control Plane 進行相關管理、維護、升級工作。為了減少上述 Components 的繁複維護,在透過 AWS EKS 代管的 Kubernete Control Plane 部可以獲得以下三大好處。

透過 AWS 增加雲端技能 在組織發揮影響力

Amazon EKS 一鍵式部署,展現三大優勢

第一,Amazon EKS代管的 Control Plane實踐了跨AZ的高可用部署,使用者不需要擔心單一節點故障的風險。

第二,Amazon EKS 支持至少四個 Kubernetes版本,持續跟進每季 CNCF 的發佈,同時 EKS 也完全符合上游 CNCF 規範。

第三,部署 Amazon EKS 之後,可直接使用 AWS 平台上現成的服務工具,在安全性管理、網路設定方面,可以做到無縫整合。

最後 AWS 台灣解決方案架構師也提到,若想在容器環境進行 CI/CD 及應用程式的管理,可以進一步透過 IaC 整合部署 Amazon EKS 叢集,透過使用 Console、把 EKS 變成 Cloudformation 的模板、使用 AWS 所開發出來的 eksctl.io、或指令是採用 AWS CDK 可以讓開發者用自身熟悉的語言,在 AWS 平台整合 CI/CD 工具進行維運及部署 EKS。

了解 Amazon EKS 整合 GitLab ,獲得三面向價值

對開發者而言,想把 Amazon EKS 整合到 CI/CD 工具之一的 GitLab 平台上,可以看到那些實際的優勢?

在 DevOps 開發者示範工作坊當中,GitLab 資深解決方案架構師指出,GitLab 使用到 Kubernetes 技術,主要有三種搭配方法,包含 GitLab Server、GitLab Runner、以及創建 Deployment Environment。

本次示範教學會主要聚焦在 GitLab Runner 如何採取 Auto-scaled 方式進行 Build、Test、Package Apps;以及在 Deployment Environment 運用 Kubernetes 技術,做到 Auto Deploy、Review App。

正因為 Amazon EKS 能夠在 DevOps 過程提供所需要的彈性計算資源,幫助開發者在 GitLab 平台上面獲得以下三個層次的優勢:

  • 在 GitLab 內建的部署工作流程當中,自動生成整套 CI/CD 最佳實踐腳本。
  • Review App 過程,從 Merge Request 中可直接訪問應用程式 /App 的 UI 介面,並且根據 Git branch 名稱、專案名稱,自動生成 Review App 的 URL,以及在 Merge 前的最後防線進行 Approval 檢查。
  • 加速 CI/CD 流水線,GitLab Runner 運行時候還可藉由 Amazon EKS Cluster 進行 Auto-scaled 的支援。

Amazon EKS 整合 GitLab ,需要兩大流程

影片最後,GitLab 資深解決方案架構師示範如何把 Amazon EKS 整合至 GitLab 執行 Auto Deploy,主要可分為兩大區塊流程,第一部分聚焦在 Amazon EKS cluster 的設置,第二部分則執行 Auto Deploy 設置。

第一塊可拆分為四個階段,首先教學怎麼創建 EC2 節點的 EKS cluster,第二階段示範把 EKS Cluster 連接到開發者的 GitLab Instance、Group 或 Project,下一步則使用 Cluster Management Project Template 創建一個 Cluster Management Project,以及最後一階段透過 Cluster Management Project 自帶的 Helm Chart,安裝在 Cluster 所需要的內建 App。

第二塊執行 Auto Deploy 設置,針對需要部署的 App 創建一個 GitLab Project,接著再把 gitlab-ci.yml 添加到 Project,並從 Web IDE 選擇及導入 Auto Deploy 的 CI 模版,讓 GitLab 自動生成最佳實踐的整套流水線。

幫助開發者更了解 Amazon EKS 整合 GitLab 的 QA 系列

Q:使用 Amazon EKS 之後,如何更有效率或優化資源去配置 Worker Node 的機器數量,以及如何有效空管開發維運的成本?

A:Kubernetes 除了本身有 HPA(Horizontal Pod Autoscaling)可根據使用程度自動調整資源流量,另外也能延伸使用 AWS Auto Scaling 方案,針對可擴展資源去設定自動擴展管理。另外在成本管控,雖然 Amazon EKS 會收取額外管理費用,但可透過 AWS 平台的 Calculato r計算每個 EKS 的價格,你會發現自動化部署及管理的費用,相對工程師人力的成本更加便宜。

Q:越來越多客戶考慮把現有 Application 變成容器部署,大多是爲了加快部署的效率,那麼變成容器模式之後,對 CI/CD 的工作流程有什麽影響嗎?

A:運用容器技術最直接的效果,可以讓應用程式的環境更一致化,例如 testing 環節、stage production,讓容器避開一些差異問題。至於 CD 部分要 delivery 一些 usage 不太一樣的時候,容器會幫忙做配置,所以 CI/CD 對容器的效益是相輔相成的。

Q: 客戶在開發流程漸漸會把 Infrastructure 變成代碼或文檔,是不是可以把程式碼跟現有的應用程式的 CI/CD 流水線整合在一起,達到一套完整的 CI/CD 部署流程?

A:觀察目前市場作法,主要分成兩個階段去做整體部署。如果規模比較小的團隊,會把 Infrastructure 代碼跟 App 代碼分開,在管理上會比較靈活;如果企業規模比較大,會有另外一個 Infrastructure 團隊來控制部署事情,這種情况之下,APP 的項目會生成一個 APP package,主要做到 delivery 這個階段爲止。而 Infrastructure 的項目會指定把需要版本的文檔,部署到他們的 Kubernetes Cluster。

填寫表單 找到適合的快速上雲服務與工具!