在 LINE 福岡（現 LY Corporation）工作五年的感想

前言

2024 年的 12 月底是我在 LINE 的最後出社日，有休消化到 2025 年的一月底。**文章皆以我現在的感受與體驗為主，與現況可能有不同之處。**所有觀點都是由我的位置、我的經歷出發，可能與實際情況有所不同。

為什麼是日本？

我在另外一個部落格曾經提到我學習日文的動機，以及一路如何走過來的，有興趣的話可以參考：

大學萌生了去日本生活的想法，然而當時經濟狀況不佳，沒有足夠存款負擔打工度假，在學成績也沒有優秀到可以交換留學。

由於延畢加上需要服兵役，讓我無法輕易出國。2018 年的 9 月收到兵單後，我被抓去當四個月的兵。

當時我並沒有想過去日本工作甚至在日本做軟體工程師，是 Denny 跟我說與其用打工度假來日本，不如找一份正職，有固定週休二日與有休可以用。這麼一講的確有道理，於是我便決定當完兵之後就開始找日本工作。

另外選擇 LINE 的原因有幾點：

可以與來自世界各國的開發者一起共事
想要挑戰在規模較大的組織下工作
沒有固定上下班時間
沒有傳統日商（JTC）的氛圍

日本面試準備

因為我很喜歡日文，在來日本之前，我經營了一個名為「日語八百屋」的電子報，大約寫了五、六十期，現在已經停刊了。這段期間也順便報考了 N3 和 N2，當兵時考過了 N1。跟很多人來日本後才開始學日文比起來，這樣的順序感受蠻不一樣的。

我在來日本之前就累積了數年的開發經驗，平時也有在寫技術文章。以當時的條件來看，這或多或少有讓我拿到來 LINE 面試的門票。大約在 2018 ~ 2019 年，LINE 福岡在台灣大舉招才，剛好 Denny 在裡頭工作，結束我四個月的兵役後便請他內推。

日本軟體工程師求職心得之前就很喜歡日本文化，所以在大學時就逐漸萌生要到日本工作的想法。不過礙於兵役跟經濟的關係，所以一直沒有實行。在這之前我當服完兵役，在服兵役之前則是在公司裡頭擔任前端工程師。最近當完兵回來，總算可以毫無後顧之憂找日本工作了。剛好現在也是個蠻不錯的時期，日本因為高齡少子化的緣故正在大幅招攬 IT… random

這邊岔題一下，我認為 AI 的發展已經在改寫軟體開發的面試規則，所以當時的面試經驗可能跟現在完全不符，在閱讀文章時可以當作參考就好。

至於薪資水平，表定的最低年薪是 600 萬日幣（當時的匯率還在 0.3！所以是 180 萬台幣）。以當時的條件來說算挺不錯的。另外如果是應徵 Backend 相關的職缺，有機會談到 1000 萬日幣以上。

為什麼是福岡？

我第一次認識九州是因為《坂道のアポロ》這部動畫。後來在 2018 年來福岡旅行兩次，覺得很喜歡這邊的氣氛，再加上 LINE 福岡就在福岡。

更多心得可以參考我當時來福岡一年的心得。

軟體工程師在日本工作一年的心得在日本就職不知不覺也已經滿一年了，在這邊跟大家分享一些想法與心得，希望可以拋磚引玉，消除一些在日本求職、就職的迷思。 year-in-review

過了五年後，我已經在福岡買房了，可以更負責任地說，福岡真的很棒。幾乎每個我遇過、以前住在東京的日本同事，對福岡都讚不絕口。東京有更多資源，更多工作機會，~~更多人，更貴~~，交通更方便，這也是真的。

短暫的通勤生活

我在 2019 年七月到福岡，剛好是疫情爆發的前一年，所以大約有半年都是搭地鐵通勤去辦公室，在這裡工作的好處之一是沒有固定上下班打卡。

我還記得 2020 年二月左右疫情爆發，公司宣布無限期遠端工作，日本等於是鎖國了兩三年才開放觀光客。所以在這個時期到日本，也算是蠻幸運的。

（附上一張 2021 年年底回台灣時飛機上不到十人的風景）

我在 LINE 做了什麼

這邊總結一下我自己在 LINE 做的一些比較有趣的事情，當然當中也包含很多 day to day 的工作（開票、解 Bug、做 Feature 等等），挑幾件比較有意思的講。

LINE 的基礎建設使用私有雲，叫做 Verda。可以把它想成 AWS，功能上沒有 AWS 那麼豐富，但基本上裡頭的元件足夠搭建完整的網頁服務。例如：

Computing
Load Balancer
Lambda function
K8S
Storage 與 CDN
Database

我特別喜歡的服務有兩個，這邊簡單提一下：

類似 Cloudflare Images 的解決方案：以網頁與 App 為主的服務免不了多媒體操作，常見的操作像是 crop、resize、將檔案轉成 .webp、blur 等等，這些如果直接在 application 做，只要規模一大往往會遇到瓶頸，而 LINE 剛好就是一個規模很大的平台。這個工具真的很棒，直接省下後端工程師。
Central Dogma：這是一個分佈式的設定檔解決方案。主要是想解決設定檔更新後不想要重開機器或重新部署，以及具備高可用性。Central Dogma 的後台有類似 git 的操作方式可以做版本管理，這個變更也可以用 pub/sub 的方式讓 server 知道。看似純樸但非常好用。

一些 LINE 的技術選型就不多提了，大致上就是 Apache 全家桶套餐。Kafka、HBase、Cassandra、Airflow，會按照每個服務的特性出現不同的技術選型。

Slackbot

在我的第一個專案中，由於我們的部署機制是後端更新 tag，當時社內還有提供類似 PaaS 的工具，可以直接串接內部 GitHub 做到一鍵部署，所以我寫了一個 Slackbot 做 Release 管理，透過 Slack 可以直接觸發部署，將原本部署的步驟簡化到 Slack 一個指令。

當時還是 Hubot 的年代，但由於某些原因（具體是什麼我忘記了）導致 Hubot 無法使用，於是我便自己寫了一套支援 TypeScript 的 Slackbot，Slack 的訊息組裝是一組 JSON，所以用類似 jsx 的語法描述其實非常直觀，這部分我參考了前同事 Kai 的 slack-blockx。

基本上他做的事情，就是把原本要跳好幾個系統的 release 流程收斂成一句 Slack 指令：

@hubot release beta my-org my-repo main v1.2.0

背後它會幫你驗證版號、建 tag、開 release，最後把這次的 commit diff 當成 changelog 貼回頻道。另外一點是指令本身則是外掛式的設計，每個指令就是一個物件，連「誰能用、哪個頻道能用」都拉成宣告式的物件，dispatch 前統一擋掉：

const deploy: Command = {
  name: 'deploy',
  command: /deploy (alpha|beta) ([^ ]+) ([^ ]+) ([^ ]+)/,
  isAuthedUser: isMember,          // 只有 member 能觸發
  enableChannels: channelIsValid,  // 只在特定頻道生效
  action: async (matches, message, client) => { /* ... */ },
};

這個框架也刻意做了模組化，把每個指令拆成獨立檔案，而不是一大坨函數包 if else。另外我蠻堅持 testability——Slackbot 最麻煩的就是每測一次都要真的連上 Slack 發訊息，回饋很慢。所以我把跟 Slack 溝通的部分收斂成一層 class，指令邏輯完全不碰 Slack SDK，甚至做了一個 terminal adapter，本地端直接在 terminal 打指令測試，開發時完全不用開 Slack。

現在回想起來還挺懷念的，因為同樣的架構、程式碼，交給 AI 大概一天就能搞定了吧，甚至不應該用程式約束 AI Agent，而是直接告訴它要做什麼。

部署環境改善

當時我們一個服務有好幾個功能同時在開發，團員按專案分配，但因為共用同一個 codebase，同一時間 QA 測試很容易互相衝突。我們手上又只有固定數量的環境，所以我跟另一位同事用 nginx cookie 判斷該走哪個 branch，導到對應的環境。那陣子我從一起合作的台灣同事身上學到很多 Ansible，很感謝他不厭其煩地手把手教。

不過 Cookie 切換手續繁瑣又不直覺，後來另一位同事直接大刀闊斧，用 Envoy 搭配 Docker 整合 GitHub，做到 push 就自動更新 deployment、動態指派 domain。這對 Vercel 這類 PaaS 很自然，但在 Private Cloud 裡要整合其實很不容易。

Landing Page SSR

某個金融服務要上線客製化的 Landing Page，但當時內部工具幾乎只能放圖片（日本很多服務就是整頁圖片、專給手機看的網頁）。同專案其他團隊已經導入 Next.js，我們卻還是純 SPA 加 Node.js server，受限於架構只能放靜態檔案、沒辦法當伺服器跑，於是我開始推動導入 SSR。

現在想想，在沒有 Vercel、又是有規模的組織裡推 SSR 簡直要人命。光是要機器就得跟 SRE 要資源，當時我推專案的能力還不夠，前主管（Engineering Manager）幫了我非常多。我把架構圖、計劃跟目的寫清楚去跟 SRE 溝通，才順利要到正式環境的機器；開發與 QA 環境則是自己想辦法搞定，包含硬啃 Ansible。

那是我最忙、也是學最多的一年。這套 SSR 機制後來沿用到其他功能上——剛開始開發同樣費工，但隨著元件越來越多，省下的時間也越來越多，對企劃端一直強調的 SEO 曝光也是實打實的收穫。

Sentry 自動化

這個產品是 FinTech，也因為資源充足的關係，所以花了很多時間在效能調校。剛好當時 Sentry 有推出了 Core Web Vitals，在後台可以看到目前網頁的幾個效能評估指標。於是我便整合了 Sentry 的 API 做了自動通知功能，每天會將結果分享至 Slack。

將 Sentry 的 Web Vitals 整合到 slack 現在許多網站都會導入測量 Web Vitals 的流程，透過量化指標找到可以改善的地方。不過比較少人知道的是其實 sentry 在之前也推出了 Web Vitals 的統計功能，能夠統計 Web Vitals 的各個指標如 LCP、FP、CLS，讓開發者可以在後台看到相關的圖表，甚至把平均值都標好了，相當貼心。 frontend

內部工具 K8S

在我們的開發中有各種想要自動化的流程族繁不及備載，雖然 LINE 有一套標準開發流程，但仍然會根據服務與團隊的性質而有所變化。舉例來說：

這週輪到誰主持 Daily 會議
PR Merged 之後，自動更新 JIRA 的狀態
Slackbot

這會遇到的問題是每次部署內部工具，就要依賴那位開發者，真的要幫忙做改進也很難下手。當時內部平台已經可以開 K8S 的 Cluster，所以有位同事就率先幫大家做了一個平台，只要是內部工具都可以整合到 K8S 裡，開發者只要負責 commit，部署的部分都交由 CI 搞定。

LINE 證券

我主要擔任つみたて NISA 的前端 Tech Lead，以及信用卡投資（クレカ投資）串接 NISA 的部分。前端團隊出現了人員調動，加入了兩位日本人以及一位法國人，都是實力堅強的成員，幫助我很多。那位法國同事的個性相當鮮明，喜歡打遊戲跟日本動畫，每次都有很多話題可以聊。

剛加入時團隊幾乎都是比我年輕很多的新卒，但實力堅強得嚇人，也有很多參與開源貢獻的高手。每個禮拜還會固定彼此交流技術。

明明是金融服務，卻積極採用新技術，如 React、Kotlin（後端）。看得出來大家是真的熱愛技術，而不是把它當一份金融業的工作在做。

只是這款服務沒能走到最後，LINE 証券的證券業務也在 2024 年 8 月整批移管給野村證券，等於畫下句點。看到自己參與過的東西被收掉，心情還是複雜的。

Impression based 的 feed 排序機制

在 LINE 後期我有機會轉到後端，接手一個 feed 的曝光排序機制，要記錄使用者在 feed 裡實際看到了哪幾則內容。聽起來單純，但那個服務 MAU 有數千萬，量級一放大，每個天真的作法都會變成壓垮後端的地雷。這個 feed 是 server-driven UI，畫面不是寫死在 App 裡，而是後端吐一份 JSON contract 讓 client 照著渲染，代價是每次曝光都得回流到後端。

最直覺的作法是「使用者每看到一則就打一次 API」，但在這個量級下，光是曝光就足以把後端打爛。所以我們改成 client 端直接發 Kafka event，把寫入路徑跟服務路徑徹底拆開；去重跟排序則交給 Redis 的 Sorted Set，score 用時間新舊、掛 24 小時 TTL，過期資料會自己掉。只可惜這套設計最後沒能上線——我離職時它還在測試階段。

黑客松

公司幾乎每年都會舉辦黑客松，我參加了幾屆，跟大家分享一下。

二氧化碳監測

詳細可以參考，這是我與當時在同一個專案的荷蘭同事一起做的項目。

LINE Fukuoka開発室エンジニアによるリモートハッカソンを実施しました LINE Fukuoka開発室では、2週間に渡って80人のエンジニアがリモートでアイディアソンとハッカソンを実施しました。その開催の準備から発表された成果物をご紹介します。 LINE Fukuokaでは去年は実施できなかったですが、基本的に毎年ハッカソンを開催しています。今年も開催を予定していたので... LINE ENGINEERING

主要是用二氧化碳的感測器來感測二氧化碳濃度，透過 ESP32 去跟 Wi-Fi 的方式串接到 MQTT，由 server 端去接收資料然後再搭配 Grafana 把它顯示出來。

詳細的原理可以看這篇文章：

用 Arduino 與 ESP32 實作空氣品質監測應用（1）- 感測器介紹用 arduino、esp32、感測器打造空氣品質監測應用！雖說是空氣品質，不過實作出來後也只有二氧化碳濃度跟溫濕度監測，如果有感測器的話要另外加上也不是太大的問題就是了。 devnote

IoT 蕃茄鐘

就…，也是 IoT。我發現 Swift 的 BLE API 還蠻好用的，所以做一個 Prototype 嘗試做了一個物理蕃茄鐘，但是連接藍牙，從電腦上操控開始與暫停，並且做統計功能。我認為這個功能很棒（自己講），只是畢竟只有一天半的業務時間，所以就沒有繼續往下做了。

GitHub - kjj6198/pomodoro: A simple pomodoro implementation using arduino timer interrupt A simple pomodoro implementation using arduino timer interrupt - kjj6198/pomodoro GitHub

藍牙會議顯示器

我發現在 MacOS 當中，內建的行事曆事件是可以被監聽的，像我有一個很喜歡用的小工具 MeetingBar 就是這個概念。（趕快下載，就不會專心開發忘記開會了）

這代表說我也可以寫一個 App，將這個事件透過藍牙推播出去，再由顯示器顯示。同樣的概念可以無限延伸，只要你有辦法把想要監控的東西推播出去就可以。

GitHub - kjj6198/meeto-iot: A PoC for displaying next calendar event on oLED from your macOS calendar through BLE A PoC for displaying next calendar event on oLED from your macOS calendar through BLE - kjj6198/meeto-iot GitHub

主管A 與主管 B

這邊想花一些篇幅說說我遇到兩位對我成長幫助很大的主管。

我在 LINE 遇到主管 A 是位日本人，整個前端部門的主管。我覺得他非常會溝通、帶領團隊，而且擅長跟不同類型的開發者打交道。儘管他很謙虛常說技術上比不過大家，但其實一直有在掌握各種技術發展，也有不斷在看大家的開發進度。

聊得比較深入之後發現主管已經沒什麼後顧之憂了😂，已經是兩個孩子的爸爸，妻子開一間咖啡廳，存款深不見底，工作是來交朋友的。

主管 A 幫助我的職涯成長很多。我們會彼此追蹤推特，主管也會主動關心我的動態（用蠻含蓄的方式）。關於要不要讓同事知道社群帳號這點見仁見智，我自己判斷如果交情不錯的話都會問，畢竟能在同間公司共事都是有緣。

剛入職時，這裡的環境和我過往的工作經驗有很大差異，我在團隊裡相對在意技術上的細節，但當時我的表達方式不佳，對於同事的提案挑三揀四，常常讓人覺得我非常強勢且難以合作。

後來同事給了我非常重的負面評價，認為我這樣會嚴重影響團隊士氣，他直接寫我的行為讓他 pissed off。主管 A 也鄭重提醒我，在職場上更重要的是發揮影響力，你的做法對於推進專案並沒有用，甚至會阻礙專案進行。

改變人生觀的一句話費曼、卓別林與電影百米，從自卑少年到有能力幫助他人，分享影響我最深的思考與人生態度。 random

一開始聽到這個意見我很不以為然，常常覺得為什麼大家好像都不太注重程式碼品質，還拿到負面評價。

後來主管 A 一步步循循善誘才有現在的我。主管 A 本身也看蠻多書的，他推薦我看《人を動かす》，中文翻做《卡內基溝通與人際關係》。可以說我當時的心態轉變都是因為這本書，那是我第一次認知到技術以外的事。也因如此，我在在職期間除了技術書籍之外，也看了很多管理相關的書。

另外一位主管 B 是 Engineering Manager，是同個專案中的主管。這位主管 B 也是非常會做團建的主管，雖然只合作短短一年，但也是因為主管 B，專案上一些需要來回溝通或協調，甚至是跨部門要資源的事都是他在幫忙處理。

我跟主管 B 的交情不錯，我說我正在翻譯以前的文章成日文，他二話不說馬上幫我看稿修正；然後因為解決了專案的問題，主管 B 甚至還買了一個彌豆子的公仔給我。

我自己並不是很喜歡用獎品的方式來鼓勵就是了，這的確是一個有效促進個人動機的好方法。

後來偶爾會跟主管 B 還有他女兒一起玩漆彈大作戰 2，當主管 B 得知我想換書桌，還開車載我去ホームセンター買木材。

後來專案變動，我才發現原來主管間的差異那麼大。

現在想來，我在職涯中遇到的主管大多都很厲害，也帶給了我很大的成長與刺激。真的非常感謝在職場遇到的主管們。

一些好玩的事

Happy Friday

當時每個月的最後一個禮拜五會有 Happy Friday，公司會準備簡單的點心跟飲料，大家可以到 Cafe Space 聊聊天。疫情開始後就沒有在舉辦了，算是我很懷念的一陣子。

每個禮拜也會有一天下午是公司例會，宣布完注意事項後，剩下的時間通常會：

讓新同事做自我介紹
可以報名做技術 Talk，主題不限

可以聽到其他專案遇到的問題已經解決方案，以及和同事交流的機會，另外禮拜五的時候也會有前端團隊的分享會。

韓國出差

2019 年底公司舉辦了 UIT Global Workshop，召集來自日本、泰國、台灣、韓國等地的前端工程師，一起到韓國 NAVER 的 Connect One 參加活動。

Connect One 位於韓國春川市，是 NAVER 專門為員工打造的訓練中心。裡面有各式各樣的辦公空間、會議室與禮堂，連宿舍也相當高級。

活動的主要議程，大多是分享實際應用在產品開發中的技術案例。其他時間則主要是吃飯、交流，認識不同國家的工程師。

IMG_2805.HEIC_compressed

LINE Developer Day 2019

緊接著是另一場 Conference，用公司的錢出差到東京參加 LINE Developer Day 2019。當時的參加心得寫在這兩篇：心得（上）、心得（中）：Slack 使用 Armeria 重寫 search 服務。

這場 Conference 讓我收穫最大的地方是：

原來 LINE 有個開源微服務框架 Armeria，而且有被 Slack 使用
BERT 在真實場景的應用

為什麼離職

離職教會我的事人生沒有後悔藥，每次離職都有很多事情可以學習，也會慢慢理解自己能夠發揮的優勢。但是在離職之前，你真的想清楚了嗎？我會以第一線開發者的身份分享一些血淋淋的案例，為未來的自己當作指南，也希望能夠幫助那些曾經迷惘是否要離職的人。 random

離職的理由不是單一事件，比較像好幾條線慢慢收斂到同一個結論。

最根本的一點是，在大公司工作很難跳出框架。往上爬一定有可能，但當時我的認知還不到位，還沒摸透遊戲規則。與此同時，我覺得自己職涯已經遇到了停滯與瓶頸；加上接連兩個參與的服務終止，攤開來看等於沒有績效。

主管也是原因之一。後來遇到的主管都很像 NPC：面對我的問題，他們的建議通常都很 General，我也不認為他們足夠在意團隊，1on1 比較像是為了應付日常工作。這點在我轉到後端之後更明顯，我跟其中一位主管時常出現意見不合與摩擦。

被調到最後一個專案時，產品性質本身比較業務導向，常常會有花了好幾個禮拜才做出一個小功能的感覺。這段期間比較好玩的是有機會參與後端開發，轉到 Backend 之後我學到很多做大規模流量時要注意的事，也負責了推薦系統設計，只可惜最後還在測試階段、還沒上線，我就離職了。而這個最後的專案，又常常需要以增加廣告 impression 為目標，讓我越做越迷惘。

另外更讓我在意的是升職 Driven 底下的那套邏輯。

我看到很多沒有價值的事情卻被包裝得很有 impact，例如社內曾經推行過標準規範統一，於是做了一個設定檔的 Repository 給大家使用，但是風頭過去後就直接放置，那個設定檔年久失修，無法很好地適用到各個專案上，所以最後都是專案各自設定。

不過我後來想通了。就算某件事沒有價值，你也要有能力說清楚它為什麼沒有價值；而很多東西經過包裝可以從 60 分變成 100 分，那也代表如果你認為某個東西有 100 分，就得包裝到 200 分才有辦法被看見。

組織龐大的情況下，很多指標根本無法量化，主管只能看數字、看簡報——當代理指標變成了目標，它就不再是一個好的代理指標。當然，沒辦法在制定好的遊戲規則裡把遊戲玩好，完全是我自己的問題，我既沒辦法改變遊戲規則，也沒有在既定的遊戲規則裡拿到名次。

最後一根稻草是 AI。2024 年剛好是 LLM 模型百花齊放的一年，在大公司裡為了導入 AI，難免需要面臨各種合規、安全性、資料保存的問題，沒辦法那麼容易用上 state-of-the-art 的模型。

我認為 AI 會是未來幾年的潮流，軟體開發也會出現很大的變化，因此想要用更自由的方式探索。我煩惱了很久，還是下定決心離職。要做出這個決定對我來說很艱難，因為要面對的是各種不確定性，但回頭來看，我慶幸我做出了這個決定。

後悔的部分

我的人際關係深受成長背景影響。我不太會主動接觸人，也不擅長社交，甚至更喜歡獨處。

這導致我沒有積極去拓展合作團隊以外的人脈，不管是非工程師部門也好，或是其他專案的開發者也好，我以前並沒有意識到這件事情的重要性。

疫情後辦公室實施遠端，很難主動創造交集的機會，對我來說很可惜。這導致的結果是我離職時走得很寂寞，把設備全部交回去時那種空虛感還是蠻難受的。

一些族繁不及備載的事就放在這裡：

有一位同事是從澳洲來的，他有在開頭講過，但是我把他誤認成是從英國來
有一位同事是法國人，我就問他那你會用筷子了嗎，事後想起來我覺得這樣的問法還蠻失禮的，因為我預設了他不是亞洲人，所以理所當然不會用筷子這件事

比較放在心上的是另一件事。之前同事間發生衝突，當時我選擇了沈默。在我看來事件本身其實不嚴重，可是我的想法並沒有傳達給當事人。

事後我想，他要面對的情緒壓力是很大的。我面對很多不舒服的場合都是如此。但若要持續往上爬，展開不舒服的對話無可避免，甚至很多時候你要面對的都是不舒服的對話。這件事過了很久，但一直記在我心裡。

後來有和合作最久的同事們一起吃飯，非常感謝他們。

學到的事情

我在公司的確得到前所未有的成長機會，不管是面對大流量時如何設計恰如其分的架構，從頭建置伺服器或是與來自各國的開發者交流，和跨部門的團隊溝通，帶領團隊完成數個功能，這些都是難能可貴的經驗，也必須要到這樣的流量跟規模，你才能見識到以前壓根不會去想的事。

技術是武器但不會是全部。尤其在專案過程中，因為 LINE 很多流程都被標準化了。但這很有可能只是主管或上層幫忙喬事情而產生的結果，並不是自己的功勞。
想要發揮影響力，要面對很多跟人有關的事，我在 LINE 學到很多流程、文件、做軟體開發的方法，但關於「人」我還有很多要學

後記

以往提到日本工作，時常會有反對的聲音，比如說日本薪資不高、稅金多、日商文化等等。每間公司都有不完美的地方，LINE 也當然有。但我仍然推薦大家有機會，都可以到這樣規模的公司工作看看。

我自己很喜歡日本。當然，台灣本身也是個能過得很舒服的地方，單就工作環境來說，日本可能還被不少人看不上，覺得矽谷才是更好的選擇——這點我其實同意。但我就是想待在日本啊。

我跟很多來自歐美的甚至是印度的同事聊過，你把電腦放在星巴克自己跑去上廁所，回來你的電腦沒有被偷，或者是你掛著手機走在路上沒有被搶，這件事在歐美是很難發生的。在已發展國家中，日本保有了高度的社會秩序，以及相對低廉的物價。

保持善良，在能力範圍內盡量幫助別人。這聽起來很像廢話，但我看過太多人把技術當成 gate keeping 的手段，越爬越自大；技術門檻遲早會被 AI 拉平，到那時候還留得下來的，會是願意把手伸給別人的人，而不是架子擺得最高的那個。

因此我也更喜歡那些有扎實基礎的工程師，這篇文章都沒提到他，這邊補充一下。關於他，我印象特別深刻的有三件事。

第一件就發生在前面提到的二氧化碳監測那次黑客松。當時我買了一顆 CO2 感測器，它附了 Arduino 的 SDK，我本來想直接拿來用；他卻說，難得玩黑客松就應該學點東西，全用現成套件的話，不就跟平常在做的事（呼叫 API）差不多了嗎？我覺得很有道理，於是我們一起翻那顆感測器的 Datasheet，照著它的 protocol 從頭把通訊實作出來。

第二件是他在寫表單提交（multipart/form-data）的測試時卡住了，跑來問我怎麼模擬一個表單請求。他知道表單只是一種比較特別的 HTTP 請求，但 library 用了老半天就是兜不出來；我看了一下，發現是 form boundary 沒設好，改一下就通了。