The Bootstrappers: Zero to MVP
\n- \n
- Bolt \n
- v0 \n
- screenshot-to-code / figma-to-code \n
The Iterators: daily development
\n- \n
- Cursor \n
- Cline \n
- Copilot \n
- WindSurf \n
![\"a](\"https://pjchender.github.io/assets/images/assets_FYJIGb4i01jvw0SRdL5Bt_F127ab975cc6145a7925f62ab0e64362e-8fccc5644c24991ffe18ccfc7c8de86b.jpeg\")
在 AI 出來之後，我自己一直在想、身邊的人也常問起的一個問題是：有了 AI 後，我還要花時間、花力氣來學這個嗎？
\n老實說，這個問題最近一直在我腦中打轉，身邊的人常問到：「以後 AI 就能寫程式了，我還需要搞懂這段程式怎麼寫嗎？」——我好像應該回他：「還是得學，因為有些東西 AI 幫不了你」，但話到嘴邊又有點心虛，因為我心裡清楚，也許過不了多久，AI 真的就做得到了。
\n\n這個問題，我來回思辨了很久：是不是以後這些事情，全部交給 AI 做就好了？想到最後，我給自己的答案是——產出可以外包，但你的品味不行。
\n很多人談這個題目，是從「別讓 AI 代替你學習」出發：有哪些東西是 AI 做不到、所以還值得我學的？哪些能力是 AI 沒辦法取代的？
\n比方說，有人會說你應該學程式架構、系統設計，因為這是 AI 目前還做不來的；也有人會說該練的是把模糊的需求問清楚、跟人溝通協作，因為這種事 AI 還接不住。但再往下想就發現，這條路走不通——這些「AI 做不到」，很多其實只是「現在的 AI」做不到，過半年、過一年，它或許就做得到了。
\n也有許多人說，AI 是你能力的放大器，如果你的能力有一分，它可以放大到 10 分；如果你的能力有 10 分，它可以放大到 100 分。延伸的觀點是「你要是偷懶把學習交給 AI，終究會吃虧」。但我在想的是，會不會未來，即使我只有 1 分的能力，AI 也能夠幫我做到 100 分？
\n上面這些答案都說服不了我。
\n如果這些能力都能夠被 AI 取代的話，那還有什麼事情是值得我專注的？
\n我發現的是：如果拿 AI 的能力當標準，答案會一直變，今天還值得學的，明天就被它追上了。拿「AI 取代不了什麼」來決定要學什麼，根本站不住腳。
\n所以在「要學什麼」這件事上，根本不該用 AI 的能力來當比較的尺；真正的尺，得從我自己身上長出來——我認為那就是品味。
\n品味和品質不一樣：AI 其實已經能產出一定品質的東西，可是品味是因人而異的。同一份產出，每個人的感受、判斷、覺得好不好，可能都不一樣——而那個「我覺得這樣才好」，沒有人能替你決定。那就是你獨一無二的品味；產出的品質可以外包，但品味無法外包。
\n\n同樣是寫一篇教學文章，AI 可以幫我把內容生出來，品質也有一定的水準，但「怎麼編排脈絡讀者才好懂、哪個地方該放一張插圖讓人更好吸收」，這些是我的想法，做好了我會很有成就感，這就是我的品味。
\n寫程式也一樣：AI 現在能大量產出程式碼，但這些程式碼該怎麼被整理、整個專案該怎麼架構，讓未來接手的人也讀得懂——這些事情，我親手做起來特別有感覺，知道或相信怎麼樣做才是更好的，這就是我的品味。
\n現在 AI 可以一口氣給你十個版本，每一個看起來都能用、品質也都不錯；品味就是在這十個裡面，挑得出那個我認為真正好的，也講得清楚它好在哪、代價是什麼。而這種眼光，只會長在你真正在乎的領域裡——你不可能對每件事都有品味，但總有一些事，你會忍不住想把它做到好，或者完成後特別有成就感。
\n品味買不到，也 prompt 不出來，它是你親手做過、挑選過、衡量過、經驗過、感受過、在乎過之後，才慢慢長出來的東西。
\n前面雖然說了「有些產出可以放心外包」，但真正更重要的，是先回頭問問自己：你想要在什麼地方，累積出屬於自己的品味？把這題想清楚之後，才輪到下一步——在那個你真正在乎的領域裡，反過來用 AI 來幫自己把品味打磨得更利。
\nAddy Osmani 在〈別把學習外包（Don't Outsource the Learning）〉裡就提醒我們：現在太容易讓 AI 把事情做完、自己卻跳過了學習，bug 修好了，心智模型卻沒往前。
\n舉一個我自己很有感的例子。debug 的時候，你大可以把整段 error trace 直接貼給 AI，請它分析問題出在哪，然後照著建議把錯誤修掉，很快。但下次再遇到同一個錯誤，你還是不知道它為什麼會發生，於是又把同一段貼上去、再修一次——因為你真正外包出去的，不是「修好這個 bug」，而是「如何分析錯誤」這個能力本身。
\n\n不過，同樣是這些工具，換個用法就完全不一樣。現在不少 AI 工具開始提供偏教學或引導式的模式，像 Claude Code 的 Learning output style、Gemini 的 Guided Learning。打開之後，AI 不會急著把答案塞給你，而是引導你自己先想、自己先寫。光是這個小小的切換，就讓你在寫程式的過程裡，更有機會慢慢養出自己的品味——知道什麼樣的寫法、什麼樣的架構，對你來說才叫好；而且每解一個問題，學習都真的留在你身上、一點一滴累積起來，而不是修完就還給了 AI。
\n在 AI 時代，我覺得問題不是「還要不要學」，因為論能力，都有可能被 AI 取代。要問的則是**你想在哪裡展現出自己的品味？哪裡是你做了會有成就感、會真心在意什麼是好、什麼是不好的地方？**那些你想擁有品味的地方，就是你該守住、不該外包出去的學習；其他的，交給 AI。
\n\n順序變了：把上面這題回答清楚了，才輪到第二個問題——那我要怎麼去學？在 AI 時代下，又該怎麼去學？至於具體怎麼學，已經有很多文章在談；我更想先把順序放回來。
\n這些品味和成就感，其實不關乎 AI，也不關乎會不會被取代，而是我自己做起來有感覺、而且在意的事。所以產出當然可以外包，學習也可以讓 AI 輔助；但在外包之前，先認得自己在乎的品味是什麼；那些讓你成為你的部分，才是無論如何都不該交出去的。
\n前陣子我心裡也有許多自我懷疑：我做出來的東西，很多其實也都是 AI 幫我生成、幫我寫的。如果我就這樣把它當成自己的產出，拿去跟別人分享，一方面好像蠻厲害的，另一方面又擔心被批評、質疑我只是複製貼上。
\n但我發現，當我逐漸知道自己想磨出什麼品味時，雖然同樣是透過 AI 產生出來的東西，但那才是我的東西，因為裡面有了我的品味。至於我不在意的部分，就外包給 AI 吧！
\nThe Bootstrappers: Zero to MVP
\nThe Iterators: daily development
\n
![\""the](\"https://pjchender.github.io/assets/images/assets_FYJIGb4i01jvw0SRdL5Bt_F6233ab72b55e4799b36cb6a8e53c15c6-8e8e3faaba90816404e742ab866df194.jpeg\")
![\"Graph](\"https://pjchender.github.io/assets/images/assets_FYJIGb4i01jvw0SRdL5Bt_Fc8407ea276e7418a8be29398fa8b433b-4f50e8592c2db020014274286e52b8b5.jpeg\")
AI 能夠以讓你驚訝的速度，幫助你解決問題中 70% 的部分，但剩下的 30% 可能會讓你非常痛苦，甚至走一步、退兩步（因為每次都有新的 bug）：
\n\n\nNon-engineers using AI for coding find themselves hitting a frustrating wall.
\n
![\"img\"](\"https://pjchender.github.io/assets/images/f428f8ca-ebd3-4f88-88d4-1ecb33603598_2160x2160-58f11bf8b8c8aa545cc351a93d644d59.jpeg\")
![\"Graph](\"https://pjchender.github.io/assets/images/assets_9838a298e8ac92fe9-30f26d4f6989eb29c87d9834ec5bf527.jpeg\")
![\"meme](\"https://pjchender.github.io/assets/images/assets_FYJIGb4i01jvw0SRdL5Bt_Fad173153345d4e249c3b4a307b19cc88-4ea1afa8f45da5c80e9bc9480e75d4f1.jpeg\")
新的 Model 進步的越來越有限：
\n![\"Graph](\"https://pjchender.github.io/assets/images/assets_F6a1a92a374ad4185a7d80b69a46d40d1-f77dac65ec4ad96928f3cecf09648135.jpeg\")
進步的速度也漸趨緩慢：
\n![\"a](\"https://pjchender.github.io/assets/images/assets_Fdd9a4c7494884b2b9d2d59729d760dad-2b64922e847c985bd186231637a088cf.jpeg\")
提升反應的速度
\n在 LLMs 沒有更聰明的情況下，更清楚 AI 適合以及能做到的是什麼
\n越快也表示越聰明？
\nAgent
\n![\"Claude](\"https://pjchender.github.io/assets/images/assets_FYJIGb4i01jvw0SRdL5Bt_F1cc3b93a93c7466c8b5d0c670b8fc912-6e78702a00381a8f5355c4187ec7a03d.jpeg\")
面對人、組織的問題時，想想如果這是在寫程式的話，可以怎麼處理？
\n\n在軟體開發中有並行（concurrency）和平行（parallel）的概念。善用這兩個可以帶來更有效率的工作表現；就像如果能妥善分派工作，將每個工作拆成相對獨立的的任務，同時交付給多個人去處理，就能夠在更短的時間內完成更多的事項。
\n在軟體開發中有分層（layer）的概念，每個 layer 內只負責和管理好自己應該知道的事，如此可以減少程式耦合、讓程式更好維護與管理；就像組織中，並不是所有部門都需要知道所有的訊息，更有效率的做法應該是每個部門只需知道和自己相關的資訊，並把自己部門內的事項負責好後，再交派給其他部門做處理。
\n軟體的世界變化很快，不論是架構、框架、語言，都以非常快速的方式在成長。即時你今天真的設計出了一個完美的系統架構，它也很有可能在幾個月後，或幾年後被推翻，而且很有可能推翻的人還是你自己。因為隨著時間的改變，人的想法會改變、使用者會改變、需求會改變、能夠拿來解決問題的工具也會改變。最重要的不是想出什麼是完美的做法、而是寫出最有彈性、能夠適應未來改變的程式。
\n", "url": "https://pjchender.github.io/blog/2022/12/10/cs-psy/", "title": "軟體開發與心理學", "summary": "\"Soft\"ware and \"Soft\"skill", "date_modified": "2022-12-10T00:00:00.000Z", "author": { "name": "PJCHENder", "url": "https://github.com/pjchender" }, "tags": [ "團隊協作", "反思" ] }, { "id": "https://pjchender.github.io/blog/2022/12/09/why-not-over-work/", "content_html": "這篇主要是寫給自己看的，因為我是一個很容易就會不小心加班，想要把事情完成的人。
我認為下面這幾種情況是「合理」加班：
\n如果是因為工作時程排得太不合理，根本一定是要加班才做的完，而且又不是短期或偶爾需要趕趕專案的這種，我認為這就是不合理也不需要的加班。
不加班的好處實在太多了，這些時間不論是拿來休息或進修都非常好。
\n平常上班的時候，腦袋都在想上班的事情，下班後有時候還沒辦法即時轉換，但一但轉換後，你會發現腦袋有很多想要完成、或想要去做的事：
\n盡可能把事情都在上班時間專心完成，把下班的時間空出來做任何和工作沒有直接相關的事。
大部分的人可能都會覺得加班是為了公司，但我發現，我加班其實常常是為了自己，但這不是說「為了自己」而做就有多偉大。確切來說，我發現我加班常常是因為：
\n可以發現到，其實我加班的本意都不是為了公司，而都是為了自己，可能是減輕焦慮、可能是想塑造形象。
\n如果真的是為了公司好，我其實或許不應該加班。為什麼呢？因為當加班變成一種文化，漸漸的許多人會受不了而選擇離開（包括你自己）。
\n這點是我覺得最可怕的，當公司原本只是幾個人加班或只是因為短期專案衝刺而加班，我覺得這都還好。
\n比較恐怖的是，事情明明多到只用上班時間是不可能完成的，但有些人為了準時交付任務而加班完成，但這樣的「不正常」卻慢慢變成「正常」而被拿來當作比較的基準。當不正常的加班在主管眼中變成了一種正常：「他（加班的人）都可以完成，為什麼你沒辦法？是不是你能力不足？」
\n為了獲得更好的績效或主管的肯定，這時候你可以選擇「一起加班」或「照著自己的步調」—— 選擇前者你會讓自己越來越辛苦，選擇後者你可以「正常」上下班，但在主管眼中，你的產出卻可能變成了「不正常」，進而得到了比較差的考績或無法獲得加薪、升遷...。
\n有興趣的話可以查查「內捲化（involution）」這個詞 ——「原先按時上下班的人開始擔心自己成為劣勢者，也自願加班，久而久之，加班便成為常態，最後變成如果不自願加班，就會影響自己在職場的生存，降低談判力」（維基百科）。
的確，你可能是為了自己而加班，你可能會想「是我自己想要加班的，其他人可以不用照著做」，但是請盡可能減少自己加班對他人造成的影響，其他人會不會因此而有非常大的壓力？如果長時間一直加班下來，你真的不會倦怠嗎？會不會最後，因為給自己的壓力太大，第一個想離開的人，反而是自己。
\n為了公司好，請不要讓公司走向這種不健康的職場文化。
\n好好利用時間，下班了，做做和工作無關的事吧！
\n做和工作無關的事，不表示不能做和程式相關的事，你還是可以用下班的時間學新技術、做 side-project。
![\"time-complexity\"](\"https://i.imgur.com/kng0gyR.jpg\")
剛剛用日常上班前挑衣服的例子和沒學過程式的 00 說明時間複雜度的概念很好理解耶～！
\n例子是這樣的...
\n\n一早要出門的時候，想要從衣櫃中找出紅色的上衣。
\n其中一種方式是像左圖一樣，這是掏寶上很熱門的「疊衣服褲子收納神器」，雖然看起來整理的很乾淨，但如果你要從中找到紅色的衣服，你就得要由上而下一件一件找，最糟的情況就是一直翻到最下面才能找到你要的紅色衣服。
\n另一種方式是像右圖一樣，把衣服用立起來的方式，一眼就可以看到紅色的衣服在哪，直接拿出來，幾乎不用找。
\n左圖的那種方式，時間複雜的就是 O(n)，n 就是衣服的件數，雖然紅色的衣服有可能就放在最上面，一眼就可以看到，但在探討時間複雜度的時候都要考慮最差的情況，所以如果你有 n 件衣服，最差的情況就是要把 n 件衣服都翻過才會找到紅色那件。
右圖的方式它的時間複雜度是 O(1)，在你沒有忘記其實衣服已經被丟到洗衣籃的前提下，你看一眼，翻都不用翻就可以把紅衣服直接取出（請先忽略掉人腦內建的視覺搜尋系統，那是另一個有趣的故事 XD）。這種不用一個一個找，就直接取出的，時間複雜度就是 O(1)。
有了這個時間複雜度的概念後，是不是覺得左邊的那個商品實用性沒這麼高啦～ XDD
\n但我還是附一下購物連結（誤）
\n真的是沒想到學演算法還可以用在購物吧！
\n由於過去求職時在 ptt 上或許多個人網誌中獲得了許多幫助，因此這次也來分享自己面試的心得，希望對於求職的大家們能夠有些幫助。
\n這次求職過程中，在和幾位不同的 Team Lead 或是 CTO 面談的過程中，真的讓我感受到多數厲害的人總是自信而謙虛的，他們不會透過問題來讓你覺得自己不懂，反倒是很 open-minded 讓你感受到雖然這個自己現在不懂，但沒關係，甚至會進一步透過提問來協助你進一步釐清自己的思路。
\n\n\n同樣地，我也期許對於自己的專業能夠是「自信而謙虛」的態度。
\n
過去雖然常聽大神說，工作一陣子後，通常就不用自己找工作，而是靠別人介紹或挖角，但我可能還沒到這個階段，周圍沒什麼人介紹，更別說是挖角，所以還是只能靠自己 XDD。
\n下面是我這次有面試的幾間公司，主要找公司市場不侷限於台灣的公司，面試的職缺全部都是前端工程師。
\n\n首先 Line Pay 和 Line Taiwan、Line Bank 雖然都隸屬於 Line 集團底下，但在台灣是三間不同的公司。Line Pay 的面試過程較嚴謹，這次從投遞履歷到最終回覆的時間約需要一個多月的時間。
\nLine Pay 公司的地點是在大直美福大飯店的側邊，給人非常氣派豪華的感覺。
\n給予連結，並透過線上測試的方式，題目主要是演算法的測驗，印象中是三題。
\n面試的對象是 Taiwan Line Pay 的工程師們，會針對線上測試的作答進行討論，接著會根據過去實作過的專案進行問答，並可利用白板進行概念的解釋與說明。
\n這關給我的經驗很特別，因為是透過視訊的方式和韓國的工程師們進行面試，原本以為會需要用英文會話，但面談現場直接就有一位中韓文的即時口譯，所以並不需要說到英文，和面試官的溝通會完全透過這位翻譯。（心裡 OS：大公司就是直接找翻譯這樣的氣派。）
\n最後會和 HR 進行面談，除了討論期待的薪資，也會針對個人或過去的工作經驗進行暸解。據 HR 表示，目前 Line 和 Line Bank 都搬到同一棟建築物，但 Line Pay 因為剛搬到美福大飯店這邊不久，因此暫時沒有再次搬遷的打算。
\n最後，HR 會與你進行基本的英文會話，確認有基本英文溝通能力。
\nKKStream 則是隸屬於 KKBOX Group 的公司，做的是影音串流服務，可以想成是讓客戶能夠透過 KKStream 的服務建立 Netflix 或 MyVideo 這類影音平台。
\n給予連結，並透過線上測試的方式，題目主要是演算法的測驗。
\n完成線上測驗通過後，會有一份作業，作業內容是用 React 寫一個待有基本的 CRUD 以及搜尋功能的網站（可以簡單想成 TodoList 這類），作業需在此次面試前完成，並提交到 Github 私人的 repo。
\nKKStream 前端目前分成三個組別－Core Tech、BlendVision 和 Enterprise。各組各派一人前來面試，會針對作業內容進行討論，接著則根據過去開發過的專案進行討論。
\n第一關結束後，會根據各組人數的需求將面試者配到適合的組別，也就是一開始投的組別，不見得會是最後的組別，這個部分也可以再和 HR 或 Engineer Manager 進行了解。
\nPM 和 Engineer Manager 比較不是針對技術的部分進行發問，而是針對過去的經驗試著了解自己是個怎麼樣的人。在這次面試中和 Engineer Manager 聊了蠻久的時間，包括帶領 Team 的方式、對於前後端的想法、測試撰寫的想法等等，覺得有非常多的收穫。
\nHR 會針對期待薪資進行了解，並試著了解自己過去的經歷。另外，會與一位主管進行面談，過程比較像是在聊天，互相分享彼此的經驗和價值觀。
\nOneDegree 的前端工程師還有分不同 team，分別是做 2C 和 2B，這裡我是面試 2B 的團隊。OneDegree 主要是開發保險系統，讓保險公司能透過此保險系統建立保險商品，並供一般消費者能夠以網路進行線上投保。
\n給予連結，並透過線上測試的方式，題目包含演算法、React 和 Git 的問答題。
\n主要是與 Frontend Team Lead 們進行面試，一開始會先請面試者以英文自我介紹，並且透過英文進行簡短的問答，主要也是確認面試者有基本的英文能力。接著會切換回中文，同樣是根據過去做的專案進行討論，並且分享彼此對於不同技術上的想法。
\n再來會與 OneDegree 台灣區的總監和 HR 進行面談，這次面談比較不會談到技術上的問題，比較像是互相了解彼此的聊天。
\nOneDegree 的回應速度還蠻快的，對於面試者來說不會有太長時間的等待。
\nPrivé Technologies 的 recruiter 主動聯繫，Privé Technologies 是一間立基於香港的 Fintech，工程師遍佈在世界不同的地方，目前工程師主力是在香港和台灣。
\n給予連結，並透過線上測試的方式，題目主要是前端 JavaScript / React 的測試。
\n透過 Online 的方式與位在香港的 Frontend Team Lead 進行面談，過程全程使用英語。主要是針對過去的專案進行提問，也有詢問到對撰寫測試的想法，並討論「怎麼樣算是好的程式碼」？
\n一樣是透過 online 的方式進行面談，面試官是在台灣的前端工程師（很巧的是過去和他還有短期合作過相同的專案）。一開始一樣會以英文進行自我介紹和簡短的問答，確認面試者有足夠的英文會話能力。接著會切換回中文，討論「怎麼樣算是好的程式碼」、還有聊到 OOP 和 Functional Programming 適合的時機、另外則是 JavaScript 有關的題目。
\n另外，也有進行 online 的 coding test，內容偏向基本的演算法和邏輯實作。
\n印象沒錯的話 CTO 是澳洲人，但在香港待了蠻久的一段時間，目前和 Frontend Team Lead 一樣都在香港，他也曾在 LaLaMove 擔任過 CTO 的職位。
\n面試全程以英文進行，一樣會討論到「怎麼樣算是好的程式碼」，另外則是聊一些個人的經歷、和同事的相處、人格特質等等的。
\nPrivé Technologies 是回覆相當快速的公司，收到回覆後會立即安排下一場的時間，不論是 HR、Team Lead 到 CTO 都給人很和善親切的態度，可以讓人感受到是相當尊重且重視面試者的。
\n慧科是由 Headhunter 推薦，公司主要是做輿情分析的，會去爬各媒體或社群的資料、關鍵字，以此分析當前熱門的議題或輿論風向，市場主要是在中國。
\n第一關會先以線上的方式進行面談，面試官來自台灣、香港和中國。這裡我有一點小烏龍的是，收到通知的時候，看到 email 寫的是「phone interview」，誤以為是面試官會打電話來...，接著等了又等，想說時間到了怎麼都沒打電話來，後來才知道 phone interview 指的是視訊面談 XDD
\n面試主要問過去實作過哪些專案，有沒有處理過複雜的圖表或大量資料需要 render 的經驗，怎麼樣優化和除錯等等。
\n雖然說是 onsite-interview，但除了和台灣的工程師面試之外，同時也會透過視訊和香港以及中國的主管面談。中國的 Frontend 主管問了很多技術相關的問題，從 CSSOM、Web Component、micro-frontend、performance、如何避免瀏覽器被阻塞（block）都有問到。
\n可以感覺的出來 Frontend Team Lead 的知識深度很深，我也並沒有全部都回答得出來，但 Team Lead 人非常有耐心，就像個 mentor 一樣，會給我一些思路讓我再去思考這個問題有沒有其他的可能性或答案，面試完後真的有一點「如沐春風」的感覺不誇張 XD。
\n如果需要準備英文面試的話，也很推薦 Coursera 上這堂免費的課程 English for Career Development，若時間不夠的話，也可以根據自己的需要，直接跳著進度看，不一定要從頭開始慢慢看。
\n從技術面來說，JavaScript 面試的內容除了可以參考很久以前整理過的「JavaScript: Understanding the Weird Part（JavaScript 全攻略：克服 JS 的奇怪部分）」筆記之外，網路上也可以搜尋到非常非常多；React 的話，基本的官方文件一定要看過。
\n\n\n有些東西雖然每天都在用，但若沒準備一時被問到的話，還是可能會沒辦法很快速且順暢的解釋出來。例如，請你解釋 event loop 是什麼。
\n
在上述的面試中，撇除技術問題外，有一些共同常被問的，像是：
\n另外，也可以參考這部 3 分鐘的影片，裡面許多題目大家一定都聽過，但還是可以稍微想一下怎麼回答：
\n\n", "url": "https://pjchender.github.io/blog/2021/04/25/job/", "title": "2021 求職面試心得分享", "summary": "由於過去求職時在 ptt 上或許多個人網誌中獲得了許多幫助，因此這次也來分享自己面試的心得，希望對於求職的大家們能夠有些幫助。", "date_modified": "2021-04-25T00:00:00.000Z", "author": { "name": "PJCHENder", "url": "https://github.com/pjchender" }, "tags": [ "職涯" ] }, { "id": "https://pjchender.github.io/blog/2021/04/19/common-wealth/", "content_html": "![\"ALPHACamp](\"https://i.imgur.com/AbjYRAn.jpg\")
這次很幸運有機會能夠擔任 ALPHA Camp 與天下雜誌合作舉辦的實體／線上活動，也是我自己第一次擔任活動主持人。
\n從小，我家就非常多與天下相關的雜誌，不論是天下、康健、Cheers 都有，因為我爸媽算是很早期的訂戶，所以一開始收到 ALPHA Camp 詢問能否的擔任活動主持人時，我內心是有些興奮的，是一種竟然可以有機會進到從小就一直在接觸的媒體的雀躍感，而且天下雜誌多數時候也給我相當正面的感受，算是台灣媒體界的清流之一。
\n\n![\"ALPHACamp](\"https://i.imgur.com/hMGtyA8.jpg\")
除了天下雜誌相當知名的媒體之外，我也很好奇工程師在當今的媒體產業中究竟扮演了什麼角色。主力是在開發「內容管理系統」？或多在進行資料視覺化的專案？
\n在這次的活動中很幸運能夠聽到已經在天下雜誌 10 多年的資深產品經理－紹謙，和數位轉型過程中加入團隊，負責從專案發想到實際落地的資深工程經理－世彥，一起來聽他們分享天下雜誌的數位轉型。
\n在聽演講前，其實我完全不知道「數位轉型」究竟是怎麼一回事，我單純地以為就是把紙本書變成電子書，或是推出幾個 App 後，就算是完成了數位轉型？
\n然而，在聽完兩位講者的分享後，我深切感受到數位轉型絕對不是「做完了 OO」就叫完成了數位轉型這麼簡單，並非把紙本雜誌電子化、推出幾個手機 App、開發幾個 Web 專案就叫完成了數位轉型。數位轉型的過程相當複雜，牽涉到的不只是使用到的技術、文章撰寫的工具、還包括整個組織架構的調整。
\n\n\n不是完成了某幾個「事件」就叫數位轉型，數位轉型是持續且沒有終點的「歷程」
\n
最早天下雜誌完全是紙本作業、編輯是以寫稿紙作業。過去上稿流程是先有紙本文章然後把文章變成電子檔後放在網路上，現在則轉變成線上文章先推出後，才有實際紙本內容；過去團隊中大部分都是編輯，現在則多了產品經理、軟體工程師、數據分析師等各種角色加入團隊；過去沒辦法從使用者的操作中取得大量的資料，現在則可以透過使用者使用 App 或閱讀文章等資料作為反饋，來協助指導後續的決策和產品修正。
\n如果要我說數位轉型是什麼？我認爲就是不怕潮流的變化，努力學習讓自己能夠跟上最新的事物，不怕面對自己不熟悉的事物，願意不斷嘗試與接受挑戰。這就好像一個永遠不會老的人，不斷地透過新陳代謝讓自己的身體和腦袋維持在年輕的狀態。
\n天下雜誌並沒有在完成了雜誌電子化，推出手機 App、建立網路內容平台後，就因為覺得「完成了數位轉型」而停下來。在近年 Youtube 的普遍和 Podcast 的竄起，天下雜誌也都沒有缺席，推出了 Youtube 頻道和 Podcast 節目，繼續跟著數位的潮流前進。因為數位轉型是一種不怕面對改變，敢於挑戰不熟悉事物的精神，因此它是沒有什麼叫做「已經完成的」。
\n在這場活動中，兩位講者也分享到他們認為什麼樣的工程師是有價值的。
\n其中一點是當 PM 提出一個需求（或功能）時，好的工程師會試著向 PM 去了解這個需求（或功能）是想要解決什麼問題，先把實際想要解決的問題釐清，接著再和 PM 討論如果是想要解決這個問題的話，有哪些可行的做法，因為 PM 一開始提的功能或許只是其中一種解決方式，但工程師在釐清問題後，會多了工程面可行性的評估，進而有機會提出不同的解決方式供 PM 參考與選擇。
\n另外一個特質則是對產品有強烈的 Ownership，工程師不單純只是把 PM 所交付的功能完成，同時他也喜歡自己完成的產品、會好奇使用者使用時的體驗、會去思考怎麼樣能把這個產品做得更好。
\n作為軟體工程師，總是有新的技術、沒用過的工具、沒聽過的詞彙，但許多時候我也會怠惰，覺得學新的好累、現有的東西就夠用了吧？聽完這場活動後，我最大的反思在於，我想有價值的工程師絕對不止是學會了某些技術或工具後，就成為了一個優秀的工程師，反倒是一種態度或精神－一種不怕面對改變，勇於嘗試新事物的精神；一種不怕碰到沒解過的問題，敢於挑戰自己的態度，而這點也正好呼應了這場活動談到的「數位轉型」。
\n很開心初次主持活動就能和天下雜誌合作，而且又能夠聽到兩位非常有經驗的產品經理與工程經理進行分享。
\n![\"ALPHACamp](\"https://i.imgur.com/cIymqLM.jpg\")
![\"ALPHACamp](\"https://i.imgur.com/SXSSCvc.jpg\")
\n\n", "url": "https://pjchender.github.io/blog/2021/04/19/common-wealth/", "title": "ALPHACamp X 天下雜誌：那些年我們一起走過的數位轉型", "summary": "ALPHACamp X 天下雜誌：那些年我們一起走過的數位轉型", "date_modified": "2021-04-19T00:00:00.000Z", "author": { "name": "PJCHENder", "url": "https://github.com/pjchender" }, "tags": [ "反思" ] }, { "id": "https://pjchender.github.io/blog/2021/01/28/agile-scrum/", "content_html": "當主持人意外拿到了一本天下雜誌創刊號的復刻版
\n
![\"agile-scrum\"](\"https://i.imgur.com/HaOuoJd.png\")
由於自己沒有真的很理解過敏捷開發或 Scrum 到底是怎麼一回事，但公司的新專案又開始想要嘗試用這種方式來做 MVP，基於凡事問網友的心態，在 ALPHACamp 社群以及 Twitter 上得到了很多有價值的回饋，很感謝大家分享意見讓我知道。
\n我的問題大概是這樣的：
\n\n「想要請問大家所謂的敏捷開發？\n團隊認為敏捷開發就是要快，不用管太多細節，先推出去收到市場回饋再來修改。但很多工程面的東西像是 DB 的設計，API 的規格的改動，添加幾個欄位還好，但若是動到比較大的架構改起來都很痛。\n是真的想要了解大家在碰到這種情況是怎麼處理？因為我沒有深入理解過敏捷開發，不清楚在實際執行上的細節，只知道每次都說就是要快，先不考慮其他情況。
\n是不是我們沒有掌握到敏捷開發的核心？還是具體來說有那些東西是可以很「敏捷」？哪些東西不適合嗎？\n先謝謝有經驗到大家」
\n下面則整理大家的想法和意見。
\n本人並沒有任何實際了解過敏捷或 scrum 的學習經驗，因此若有任何錯誤或想法，都歡迎提出並一起討論。
首先，敏捷的重點在於快速應對市場需求變化的能力，同時也驗證自己對於產品能否達到市場需求的概念（Proof of Concept, POC），減少過多的時間或人力成本在開發某個專案，做到非常完整，但推出去之後才被市場打臉。
\n這裡直接 quote Jack Sung 所說的：
\n\n\nJack Sung：「敏捷開發並不是短期的速度快，畢竟開發還是需要跑完基本的流程，而是面對市場變化的反應速度比起瀑布流還快，就像 POC(Proof of Concept)，敏捷開發是更務實的去驗證想法，而非一個美好的想像去花費很高的時間跟成本去開發一個未經驗證的產品，等到真的推上線才被市場賞兩巴掌。」
\n
至於什麼叫「完整」或「非常完整」真的是非常藝術的問題，有的人認為東西可以 work 就可以推出，有的人認爲至少要通過自己這一關後才算可以，而設計、工程、一直到商業端每個人的想法也都不同。也許業務認為有東西可以賣就好，設計認為的會是這個產品拿出去可以見人嗎？工程思考的可能是產品夠不夠穩定，有沒有漏洞，資料庫後續如何修改等等。
之所以要敏捷是因為市場的變化太快速，因此當有產品沒有收到預期的回饋時，適時且立即的停止、停損或轉換方向是敏捷的重點與核心。
\n然而，這並不表示要壓縮開發時程或開發品質，如同 Yan 所說的，整個開發流程應該還是嚴謹可靠的，而不是隨便快就好的。
\n\n\nYan：「敏捷開發不單單是針對開發團隊而是整個軟體工程，從訪談>需求>規格>設計>開發>測試>發布，整個流程應該還是嚴謹的，只是它縮小整個目標進行對目標進行快速迭代，中途有錯應該立即修改或終止，這是 scrum 所謂的「快速試錯」，而已經成型產品遇到要整個砍掉重來，長遠來說如果是必要，我也認同需要去做，根據我的經驗以開發來說敏捷並不會減少「開發時間」。」
\n
如同上面所述，敏捷的重點是為了因應市場的快速變化，避免到後來才發現一場空。但這個敏捷並不是快的意思，該有的開發流程還是不能省，Rafeni 分享的這張圖我覺得很到位：
\n![\"Minimum](\"https://i.imgur.com/pVOHha6.png\")
這裡直接引用 ALPHACamp 助教 Yan 所說：
\n\n\nYan：「目標是造車，縮小目標往往會被誤認為先造輪子，但其實應該是「可用的」滑板車，因為只造輪子根本收不到市場/客戶回饋，根本無法知道產品方向對不對；壓縮開發時間＝壓縮開發品質，各種開發模式都是透過流程改善來減少時間成本，而非去壓榨單位去達到節省目的。」
\n
每次開發出來的「可用的產品」，到底是要驗證什麼概念，是否能實際收到市場的回饋都是要考慮的問題。至於給人使用的「產品」和有功能就好的「東西」之間的界線要如何定義，又是另一門藝術了。
\n據 Jack Sung 所說，一般來說走敏捷開發對工程團隊來講是痛苦的，太多東西是無法預期或事先規劃的，因此打掉重練是常有的事，能做的是盡可能在開發時做到解耦、模組化，以減少這個痛。
\n![\"agile-scrum\"](\"https://i.imgur.com/ofC1FFp.png\")
畢竟以上圖來說，腳踏車和滑板車已經是完全不同的概念了，要做到擴充性和預留彈性幾乎就是不可能的事，所以要認知到打掉重練可能是必經的過程。
\n雖然說打掉重練可能是常有的事，但如果總是在經歷「整個」打掉重練，而不是部分功能或模組打掉，或是整個系統架構的調整，這時候就需要再多想想了。
\n如同前幾個段落中的金字塔圖（MVP）所示，在敏捷開發中並非省略掉開發流程來達到敏捷。Rafeni 提到，不應該打著敏捷開發就跳過了規劃、跳過了去思考產品是設計給誰用的、是要幫誰解決問題。 Jacob 則提到，PM 和 RD 溝通不良，或當問題都沒有先想清楚就馬上進到開發，產品設計沒有做好使用者研究時，常常才是導致架構需要不斷大改。
\n\n\nRafeni：「因為起點對了，過程與終點才可能對。否則錯誤的流程也是會導致錯誤的結果的。」
\n
也就是說，如果你覺得常常是整個系統在進行大架構的改動，甚至是經常感受到隕石擊落般的痛快時，那麼不要乖乖的抱著「打掉重練是正常的想法」，而是需要好好的再想想。
\n![\"docusaurus](\"https://i.imgur.com/bAtn21z.png\")
過去的「未整理筆記」一直是使用 hexo 建置的，hexo 用起來其實非常方便，$ hexo generate -d 基本上就搞定了。大概在去年（2020）年中時接觸到 docusaurus 這套由 Facebook 推出的 docs + blogs 的工具，雖然目前還在 alpha.70 階段，但一用就非常吸引我。
Docusaurus v2 對於 markdown 有高度的支援，除了基本的程式碼高亮外，還可以哪些選擇行號要特別標註。下面列出幾點 docusaurus 特別吸引我的地方：
\n雖然有很多文章需要慢慢搬過來，但好險這些文章本來就都是 markdown，要改動的幅度不算太大，這也是我為什麼一直覺得筆記一定要用 #markdown 寫（搭配 Typora 👍），不要太倚賴其他第三方筆記軟體，因為搬家時會方便許多。
\n但因為 docusaurus 和 hexo 的 front matter 不太一樣，所以還是要簡單調整一下。
\n", "url": "https://pjchender.github.io/blog/2021/01/03/happy-new-year/", "title": "2021 部落格搬家到 docusaurus", "summary": "docusaurus v2", "date_modified": "2021-01-03T00:00:00.000Z", "author": { "name": "PJCHENder", "url": "https://github.com/pjchender" }, "tags": [ "網站誌" ] } ] }