我整個職涯都在幫助人們打造軟體。這是一系列信件，講述當「打造工具」變化得比「打造背後的原則」還快時，會發生什麼事。每一封信都提醒我們：技術雖然變化很快，但真正重要的問題往往始終如一。
--
親愛的過去的 Jenna，
當初讓你一頭栽進科技業的那個原因——它永遠都在變——也正是會讓你一直留在這裡的原因。
工具幾乎每週都在變，而且有時候變得更好，有時候則不是。那些自認一點都不技術、甚至根本不算開發者的人，會在一個下午用這種叫做英文的新程式語言做出 App。產品會在你喝完第一杯咖啡之前就從點子變成部署完成的狀態（你現在有個幼兒，所以你反正很少能在咖啡變冷前把整杯喝完）。「我不會寫程式」或「我不是技術人」已經不再是打造產品的障礙。
考量到你幾乎整個職涯都在幫助別人打造軟體，這確實很令人興奮。但我們不能把「有能力打造」和「有智慧去打造」混為一談。
你在過去二十年養成的最有價值的習慣之一，就是問一個簡單的問題：
「我們應該做這個嗎？」
對你職涯中的大多數時間來說，「我們能做出來嗎？」是個很難的問題。時間、預算、複雜度，也許技術還沒到位。但那些限制通常只是暫時的。有足夠的人力、時間和金錢，幾乎什麼都能做出來。可是真正的問題一直都是：我們應該做這個嗎？這是不是我們時間的最佳用途？這能解決客戶真正需要解決的問題，還是反而製造了新問題？我們選擇不做的是什麼？
這些問題沒有改變，但它們周遭的環境變了。
今天，幾乎任何人都能打造軟體。從 Lovable、Bolt、Replit、Claude Code、Codex 這些工具，到接下來還會出現的下一個工具，打造軟體的門檻已經低到前所未有。現在「我們能做出來嗎？」這個問題太容易回答了。答案幾乎總是「可以」，所以我們就做了。這個問題，以及它帶來的阻力，已經消失了。它不再幫助我們判斷什麼值得被做出來。
我們會做，是因為只要 15 分鐘。我們會做，是因為之後還可以回來迭代。我們會做，是因為好奇。我們會實驗。而實驗總是很奇妙地會變成正式產品。那個給團隊用的內部工具？現在已經有人依賴它了。欸，現在它也開源了。那個你週末幫孩子足球隊做的小專案？在最新的 API 變更後需要更新。那個你用 AI 幫自己做的 App？恭喜！你現在是它的終身維護者。
軟體向來比起維護，總是更容易被做出來。還記得那些花在讓測試重新跑起來的衝刺嗎？還記得為了修補依賴套件帶來的安全漏洞嗎？還記得因為某個稅務計算服務被替換掉，結果在各個系統之間追著那一分錢跑，最後挖出一堆進位誤差嗎？我們接受這些成本，是因為工程資源很稀缺。這種稀缺不一定總是壞事。它迫使我們去問更重要的問題，例如什麼東西值得存在。
AI 讓打造軟體變得大幅更容易。於是每一個新的 App、功能、腳本、內部工具，甚至週末專案，都會變成某個人的責任。但現在，我們移除了許多原本會讓我們在創造之前停下來的阻力；而正是這些阻力，迫使我們去問這些重要問題。
而且因為更容易打造，軟體開始看起來都差不多了。當大家都能使用同樣的模型、工具和基礎元件時，就很容易做出跟別人一模一樣的軟體。
這不代表我們就不要做了！但這確實代表標準已經改變。
現在，真正的差異化在於你是否看見了別人沒看見的東西。你是否真正深刻理解了客戶與他們的問題。你是否拿掉了不必要的東西，而不是又加了一個新功能。你是否解決了一個值得解決的問題，而不只是證明自己做得到。
程式碼從來都不是差異化的關鍵。回頭看，我合作過最好的工程師，之所以被記住，是因為他們一開始就知道哪些問題值得去解決。
你也會更常問到一個相關的問題（而且不只是針對你正在做的事，也包括別人在做的事）：「這東西有存在的必要嗎？」這是留給改天的另一封信。
你可能會想讚嘆自己現在能多快把東西做出來。你應該這麼做。但不要讓「做起來很容易」這件事，降低了你對「什麼值得存在」的標準。當「我們能做出來嗎？」變成一個越來越容易回答的問題時，也請同樣迅速地提高你對「我們應該做這個嗎？」的回答標準。
下張明信片再見。
原文出處：https://dev.to/jennapederson/you-can-build-it-should-you-9e0
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
