Hi 讀者，
不知道你習慣在手機上輸入或編輯較長的文字嗎？上週我讀到一篇文章〈The Invisible Problem〉（隱形問題），談的是在手機上「編輯文字」的設計問題。作者 Scott Jenson 是在 Apple 和 Google 工作過的 UX 專家，他認為今日 iOS 與 Android 在編輯文字的介面有個共通的問題：想要照搬電腦的那一套，卻沒有滑鼠游標跟功能選單介面可以用。
Jenson 特別強調有問題的是「編輯」而非「輸入」，他問讀者：使用手機時，在已經打好的文字中決定要從哪裡開始編輯，是不是更加困難？他在使用者研究中甚至得到驚人的答案，超過半數的人表示如果要編輯，不如「全選後刪除」再重新打字，因為編輯太麻煩了。我很推薦大家閱讀文章，看看 Jenson 是怎麼拆解、分析問題，當然他也在文中提供自己的解決方案，至於好不好，就要交給各位讀者判斷了。
Titan
[optin-monster-inline slug=”hlq7r8kikxf7imrv22xq”]
[中] Matt／想成為具備商業思維的工程師，從「技術選擇」開始
原文連結｜閱讀時間：5-10 分鐘
身為工程師的你，曾經面臨過以下情形嗎？明明依照同事的需求提供最理想的技術方案，卻因為技術以外的考量被否決。本文想要告訴讀者，如果工程師想要在職涯成長更近一步、增加自己的影響力，學會以商業角度思考問題會是很好的選擇。
文章開頭先談到一個案例：一年多前，技術大神 DHH 宣布他們公司 37signals 在使用 AWS 與 GCP 多年後要「搬離雲端」，看似與業界常見做法背道而馳的決策，背後並非只是技術考量，而是有更多商業層面的思考和分析，例如商業模式怎麼影響他們的成本，最終也證實這個決定可以為他們省下百萬美元。
同時，根據一些調查結果顯示，資訊部門在組織內的角色正在變得越來越具有策略價值，那麼身在資訊部門，或是軟體公司裡的工程師，可以怎麼學習商業思考？不再只是被動等待指令或者其他部門開出需求，而是主動出擊參與商業決策，甚至影響組織更多部門的運作，在更高的層級上創造價值。
[英] Simon Tatham／如何有效地回報軟體錯誤
原文連結｜閱讀時間：15-20 分鐘
這是一篇 1999 年的文章，作者是網路連線工具 PuTTY 開發者 Simon Tatham，他在 22 歲時寫下此文，被翻譯成 14 種語言（包含繁體中文版），一些語境和描述，在 24 年後的今天讀起來很有意思。本文的目的很請楚，就是要告訴大家如何回報軟體錯誤，文中許多內容至今依舊適用，一些小標如「程式不會動」「在我的電腦可以動」「奇怪，剛剛才出問題的啊」想必大家讀起來會很「有感」。
Tatham 認為，錯誤回報必須把真實發生的事實和臆測做很明顯的區隔。必要的時候可以略過臆測，但關於事實的部分絕不能省。其中有幾項要點的確很容易被忽略，例如在描述錯誤時寧可提供過多的資訊（多餘的資訊開發者可以忽略不看，資訊不足反而會阻礙、延遲除錯），又或者要小心代名詞的使用，這容易導致誤解，或是讓開發者難以確定真實情況。
由於 Tatham 有在維護免費軟體，會收到一些來自全球各地使用者的錯誤回報，很多人會為了自己英文不好而致歉，但 Tatham 反而覺得錯誤回報寫得最含糊不清的往往是來自英語系地區。他也說，寫不好錯誤回報並不是使用者獨有的問題，許多程式設計師寫的錯誤回報反而是他看過最糟糕的。另一點有意思的是當年 Tatham 在文中建議軟體應該要在使用手冊中也附上如何回報錯誤的指引，不知道讀者你在使用軟體遇到錯誤時，是不是也能在回報的過程中自然地接收到如何回報錯誤的指引呢？（例如在介面上提供一個 opt-in 的連結）
[中] MH／成為內部產品 PM 的兩週年工作心得
原文連結｜閱讀時間：10-15 分鐘
作者 MH 從公關與行銷工作轉為產品經理，目前在一家新加坡公司擔任內部產品經理。他在文中比較了消費性產品、商用產品與內部產品三者產品經理的工作差異（文中分別以 2C PM、2B PM 和 internal PM 代稱），對於內部產品特性較為陌生的讀者，也可以從內文找到作者的另一篇文章閱讀。
MH 先將三種產品經理的技能重點分項列出，例如 2C PM 的技能重點是數據與驗證、差異化、市場嗅覺與同理心，但是到了 internal PM 則是要更注重利益關係人管理，不過整體而言三者的核心能力並不會有太大差異。他還從自身的經驗出發，分享身為內部產品 PM 所遭遇的五大挑戰：1. 優先排序&敏捷開發 2. 創新 vs. 造輪子 3. 難以界定產品成功指標 4. （要當）多工的 PM 5. 保持彈性、接受改變。
以第一點來說，MH 認為內部產品要做到敏捷開發很難，而且當使用者是同事的時候，情況也變得很不一樣，而且內部產品「受到影響的空間」比起 2C 產品要大得多。又或者像第四點，身爲內部產品 PM 的人，很可能需要身兼客服、業務與行銷等角色，處境相對於一般對外產品的 PM 有很大的不同。
[英] Gergely Orosz／一個好的 side project 長怎樣？
原文連結｜閱讀時間：10-15 分鐘
本文來自我的同事 Karen 推薦。電子報《The Pragmatic Engineer》作者 Gergely Orosz 在今年六月分享了一個富有教育意義的業餘專案「Rides」。專案作者 Juraj Majerik 是一位軟體工程師，為了增進自己對 containerization、multiprocessing、演算法與資料結構等知識的理解，每天下班後大約花一到兩小時，開發了這個類似 Uber 叫車系統的專案，整個專案的走其大約是 2022 年 10 月到今年 4 月。為此他寫了 34 篇文章，詳細記錄他開發的過程和學習心得。
Orosz 說這項專案並不只是一個模擬器這麼簡單，還包含系統監控，更不用說那些詳細的紀錄。要知道 Orosz 可是當過正港 Uber 員工，當過歐洲的工程主管。他認為選擇這樣的題目對於理解複雜系統很有幫助，而且 Majerik 對於專案詳細的紀錄不僅讓人容易理解，更是透露出他對這整件事的理解有多透徹。
整個 Rides 專案可分成六個階段，Majerik 決定開工後並未立刻開始寫程式，而是先畫好他對完成品的草圖，讀者可以對照看看文中的草圖與專案頁面。Orosz 接著陸續解說後面的五個階段：基礎建設、一點商業邏輯和更多基礎建設、基本 UX、專心寫商業邏輯相關的程式碼，以及最後的收尾和系統監控。Orosz 在文中列出此專案五個值得大家學習的地方，他說一般人每天工作之餘其實不太會再去做複雜的業餘專案，Majerik 採取的方式其可貴之處在於每一個步驟都不複雜，卻能組成複雜的系統，而這正是軟體工程的美妙之處：所有看似複雜的東西都能拆解成易於理解和實作的步驟。
閱讀更多內容，請看《RISE-UP 科技人才升級週報》各期目錄。
