Jasonmel Online

搜尋「#google」· Search results for "#google"

找到 13 篇文章 · Found 13 posts

NVIDIA 和 Google 文化比較

2025/05/02 (Fri.)

根據自身的經驗,NVIDIA 和 Google 分別存在著兩種很極端的文化。

Google 講求穩紮穩打,凡事圍繞著 design docs 進行:要開始一個專案,先丟出一個比較 high-level 的 design doc,讓跟專案有關的人充分討論之後,再基於這份 doc 丟出一個涵蓋所有細節的 design doc,再充分討論之後,取得所有人的 approvals,等大家都沒意見之後,才實際去執行。這套流程有個很大的優點,就是事情都是經過所有人的詳細討論,幾乎可以肯定設計上沒有任何問題,最後才執行,所以基本上細節都訂好了,實際寫 code 就是無腦把 spec 翻譯成程式碼的過程而已,執行上會超有效率,也幾乎不會有什麼大改。但缺點也很明顯,就是討論過程會超級無敵花時間,對於一個稍有規模的改動,討論拖個半年一年絕對不用感到意外。

NVIDIA 講求 SOL (Speed of Light),凡事回歸第一性原理去想:覺得什麼應該做,就以最快的速度去完成。以個人經手過的幾個專案來說,都是先憑直覺做出一個 prototype 產品,馬上丟出來給大家使用,馬上就會收到四面八方的 feedback,馬上再動態調整,很自然地,產品也會很快收斂到一個對大家很有價值的狀態。這個做法執行上勢必得隨時刪刪改改,有時候甚至會需要砍掉重練,但少了繁瑣的討論流程,也確實讓整體效率快了不少。甚至可以這麼說,我在 Google 花了一年多做的專案,如果以 NVIDIA 的方式去做,大概三個月內就可以完成。

話雖如此,當初剛從 Google 切換到 NVIDIA 時,也還是會有一小段覺得很混亂很沒有制度的時期,不過自從有了這種高效率創造高價值的體驗之後,就覺得這樣野蠻生長的方式也蠻好的。

然而,最近部門似乎也開始要推行 Google 的做法,個人覺得沒有學到精髓。如果大家在思維和文化上,沒有那種把 design docs 當作溝通工具,先充分討論完再執行的認知,反而就只會流於形式。大家被逼著寫 design docs,被逼著 sign off,在寫 design docs 的同時,東西還是照做,做出來的東西還是照樣不停一改再改,design docs 勢必也得跟著一改再改,流程只變成額外的負擔,浪費大家時間。所以,就斗膽把這樣的想法提出來跟老闆討論,老闆也表示會再和上層溝通。後續會如何調整,就讓我們繼續看下去。

大學同學小聚

2025/03/27 (Thu.)

利用 NVIDIA Days 的空檔,到還沒機會參訪的 Google TPKE 找大學同學們聚聚。

謝謝 single 帶路,原本預約 TPKD,後來去 TPKE 似乎沒辦法用同樣的名字登記,只好改個名字試試。謝謝 single 帶路,原本預約 TPKD,後來去 TPKE 似乎沒辦法用同樣的名字登記,只好改個名字試試。

過往在求學階段剛出社會,會覺得 Google 是一間夢想公司,不太敢妄想自己會有機會加入。如今,除了自己曾經待過,包含也已經離職的強者 redjava,同樣在 AI 領域混得很好的 rior,以及今天有出席的 mobo, single, wind77, forsaken,我們班的 Googlers 其實也還不少呢!看到大家都有好的成就,真替大家感到開心!

Cursor

2025/03/20 (Thu.)

最近公司開始導入和評估 Cursor 以及一些 AI 寫程式的軟體或外掛,原本沒抱太大的期望。畢竟這種東西之前在 Google 任職期間,公司內部早就已經有了,那種 tab, tab, tab, ... 自動完成的體驗,的確能加速寫程式效率,但就只是很局部的自動完成,大多數時候,還是得自己對細節流程有清楚的認知和想法。直到最近用了 Cursor,才驚覺原來現在的自動化程度,已經做到給一個相對大的需求的 prompt,AI 會自動去掃描分析整個專案,然後整套需要修改或新增的 functions,需要開新的檔案,都幫我們自動完成了,甚至品質比徒手自幹還要好。

這真的是蠻讓人感到震撼的。一則以喜一則以憂,喜的是工作效率真的是有 10x 以上的加速毫不誇張,但也是第一次開始感受到來自 AI 的威脅,那種非理工背景講人話都能寫程式的年代,似乎就快來了。話雖如此,還是十分慶幸自己曾經經歷過這個軟體工程師高度被需求的年代,能因為資訊工程的專業,吃到這部分的紅利。

AI 年代,勢必會有許多工作陸續被挑戰和取代,人類也只能持續去思考,有什麼價值是 AI 沒辦法提供的,朝那方面去發揮,才能保有自己的一席之地。其中,個人認為,不管是在什麼領域、什麼專業,那種對於美感的追求,那種創新思維,那種想把事情做到極致、並且堅持不放棄的職人精神,那種有崇高理想並且努力去實踐的態度,可能會是 AI 難以跨越的人類的護城河,而這也呼應了「藝」,這個十年前就幫孩子取的好名字,十年前就這麼認為,如今也還是這麼認為。

誠實

2024/08/17 (Sat.)

這兩天 Google 前 CEO Eric Schmidt 在 Standford 的公開訪談當中,譴責了 Google 當下看重在家工作勝過於取得勝利,以及一些和 startup 在文化上的落差,甚至還提了台積電竟然能讓博士在工廠地下室工作,試圖闡述他對 Google 的擔憂。沒想到吃了誠實豆沙包的 Eric 此話一出,立馬遭到炎上。對於這件事,身為 ex-Googler 之一,我自己也在很多面向上也相當有感處。今天先就「誠實」這件事發表一些看法。

個人認為,充分溝通,是大到人類文明、小到人與人的關係互動,想要往前推進的必要條件。然而,人類天生一個很大的缺點,就是溝通超沒效率。當一個人想以說話的方式,把一個想法傳達給另一個人,需要把想法先轉換成某種語言,控制肺部的肌肉把空氣從胸腔快速擠出去,控制鼻腔的肌肉讓空氣不要從鼻子洩漏出去,控制嘴巴的肌肉去影響空氣經過喉嚨的聲音,然後聲音透過空氣的振動以音速向四面八方傳遞出去,震動了接收者的耳膜,耳膜訊號傳遞到大腦解讀為語言之後,再轉譯為想法。這就像超級比一比,一件事情經過層層的轉換之後,要維持原樣已經很不容易。

如今,在社會化的過程當中,我們還不被允許誠實地表達內心真實的想法,又進一步讓溝通更加沒有效率,這又是為什麼呢?追根究底,就是講實話會受到懲罰,會讓自己陷於不利的狀態。例如任何的炎上事件之後,我想主事者之後都不敢再任意發表自己內心的真實想法了。職場上,忠言逆耳,有時候說實話也會影響到自己的職涯發展。而任何不健康的人際互動關係當中,也都會因為某方或雙方對彼此的實話採取負面回應甚至進行攻擊,而導致無法溝通進而關係破裂。零零總總現實中有太多不被允許說實話的情況,繁族不及備載。

但實際上,不說實話是有負面效果的,不但問題並沒有解決,反而會因為不去面對而使問題擴大到無法收拾,最終形成遺憾。那麼,要如何在說實話和避免自己因為說實話而受傷害之間取捨呢?我覺得對於說話的人來說是無解,關鍵比較在於接收者面對實話時的態度。如果接收者能接納包容實話,那說話的人就會更願意說實話,創造良好的正向溝通循環,反之亦然。

關於這點,在和孩子的互動當中也特別容易感受得到。孩子是一張白紙,沒有經歷過社會的摧殘,往往比較直來直往。想牽手就直接牽上來,想抱抱就直接抱上來,用全身的重量壓在自己身上,想哭就哭,想笑就笑。然而有時候,還是會不經意說出自己覺得不太好或不太能接受的話。這時我就會去權衡,相較於去指責孩子或許能獲得更立竿見影的效果,我更想保有和孩子之間能互相說實話的連結,而試著花更多的時間和耐心,去和孩子溝通一些我背後的想法和考量點,供孩子自己去做判斷和選擇。不知道孩子還願意和自己說實話到什麼時候,就只能盡力讓自己成為接納包容實話的接收者,去延長這樣的關係了。

個人網站砍掉重練

2024/02/09 (Fri.)

睽違十年,終於再度下定決心,把個人網站做了一次大重寫,也把底層架構整個全部翻新。

讓人感到興奮的新版個人網站架構。讓人感到興奮的新版個人網站架構。

在 Yahoo 工作期間,第一次接觸到 Node.js 搭配 CI/CD 的開發流程,就深深被這套模式給吸引。那時就覺得,這才是網站開發應該有的樣子:網站可以在本機端運行起來,只要檔案一變動,馬上就反應在瀏覽器上,開發完成把程式碼推上 repo 之後,CI/CD 流程自動進行測試,然後自動部署到 staging 機器上,由 QA 進行最後的把關,最後再一鍵自動部署到 production 機器上。當時的個人網站還是以 Apache/PHP 運行的,光是要在本機端開發就不那麼直覺了。同時,當時公司的 CI/CD 是使用 Jenkins 的內部版本,如果要自己去架設維護這套系統,是還蠻殺雞用牛刀的。因此也就只能在公司裡好好享受這樣的開發環境了。

後來到了微軟,網站開發清一色都是圍繞在 .NET, C#, Visual Studio, Windows Server 等等的微軟方案,大概也只能在公司跟著用,難以套用在個人網站上。

再來到了 Google,雖然網站開發表面上用的是 Angular,是個蠻開源的東西,但底層還是奠基於許多很強大的公司內部的生態系統,也是個只能在工作當中好好享受的開發環境。

終於,到了 NVIDIA,第一個被指派的任務,就是把某個重要的內部工具網站整個翻修改寫。由於某個專門在搞網頁的部門推薦使用 Next.js,就硬著頭皮去接觸這個當初並不熟悉的 Node.js + React.js 的框架。而在開發完成後,也順帶把 GitLab 的 CI/CD 給串起來。配合 Ansible 和 Docker,使得運行環境的設定得以自動化和模組化,又讓整件事更加單純和可靠,不用再像以往,重新設定一台新機器都要手動安裝一堆有的沒的,還要擔心在機器裡面操作,一不小心就會把東西搞壞。如今機器壞了也沒差,再開一台,Ansible 一跑,Docker 一上,就都設定好了。甚至,因為有了 Docker 的關係,使得一台機器上同時跑 Apache/PHP 和 Next.js 成為可能,只要前面以 Nginx 來做分流,就有機會讓新舊網站同時並存。這才發現,這一整套唾手可得的方案,不就是自己夢想中網站開發應該有的樣子嗎?沒想到這是有可能以如此廉價、如此優雅的方式辦到的!既然如此,心動不如馬上行動,終於讓個人網站又更接近自己喜歡的樣子一步了!

這時候,再回頭看看 1997 年做的現在看起來很智障的第一代個人網站,有種說不出的感動。沒想到寫網頁可以一路寫到現在,還能靠著這門技術在各大公司之間走跳,一路體驗著各種不同的 web 技術,隨著 web 的技術演進學習成長,應該算是很幸運的人了吧。