這幾年因為疫情的關係，還有參加研討會大多著重在交流上所以不太特別寫部落格來紀錄聽到的議程。然而，今年的 MOPCON 剛好是被邀稿，選了一個跟以往風格不太樣的的主題，同時也是自己選擇挑戰「創業」要用到的題目，一年的累積剛好在這場活動出現了質變。
渡假
今年一個比較特別的地方是「用自己喜歡的方式休息」也因此選擇提早一天來到高雄「渡假」跟「觀光」不同的地方在於沒有行程安排，想睡到什麼時候、在哪裡停留都是隨心所欲的，這對我來說也是比較喜歡的「休息」方式。
原本的預定是去看台灣設計展不過因為十點左右才出發，因此決定先走到西子灣附近想去的餐廳吃午餐，卻沒有想到竟然還沒開門，只好隨機選擇附近的咖啡廳看個書、吃個點心，然後吃飯，再到餐廳旁邊的甜點店來個飯後甜點。這種沒有時程壓力單純依照現況調整的方式，也許是很適合在軟體產業的工程師、設計師放鬆的方式。
吃飽喝足後就前往台灣設計展，其實除了地點之外也不清楚展覽資訊，也就照感覺從其中一個展區開始逛起來。雖然說是「台灣」設計展，然而大多是高雄當地的公司、設計比賽的作品。這區的展場主要以過去、現在、未來的方式構成，雖然製造業的歷史部分可能因為不太有趣（或者是下午）人相對少，但確實讓我重新思考「設計」為何。
重新關注設計
今年比較特別的大概就是對「設計」相關的事物關注增加了不少，一方面自己對於「品牌印象」這件事情很注重，因此在開始寫文章的同時也重新挑戰生疏已久的多媒體設計領域的技巧。
為了對應工作中有著數十萬行規模的大型系統，開始對 Domain-Driven Design（領域驅動設計）進行研究，原本只是想要將同個團隊的程式碼有系統的組織起來，沒想到卻從戰術中提到的架構受到啟發，進而找到一個有系統組織程式碼的方式。
另一方面，更加重要的戰略部分，也在咖啡廳讀書中構築概念並且在逛台灣設計展的時候對「設計」有更深入的印象，在這些製造業尋求轉變的過程中，導入的也是設計（工業設計、商品設計）所謂的「領域專家」其實也包含工程師（用程式設計師更加精確）也因此領域驅動設計實際上就是找來一群「設計專家」進行跨領域的協作，並且轉換成軟體的過程。
從製作演講簡報體悟到的 Modeling（建模）的統整，就對於 Domain Model（領域模型）的概念有更清晰的理解，也就是我們將觀察到的資訊轉換成程式的過程，這些都是由經驗、專業所發現的規則，因此能夠被轉換為程式。
從「程式設計」的角度來看，我們應該須分資訊科技（IT）和電腦科學（CS）的差異，程式設計應該偏向資訊科技如何應用的部分，而電腦科學更多的應該是怎樣改善跟推進這個領域，這樣說起來「本科生」大多指的是 CS 類型學生，但仍常有在軟體設計不擅長的狀況出現，似乎也就不太意外，因為投入的方向不太一樣，而這大概也是「轉職」之所以能成功的原因。
降低門檻
去年決定要往技術顧問這樣的職涯發展時，第一個關注的就是「轉職工程師如何馬上能有生產力」的問題，過去作為面試官、技術主管一直以來都是靠「運氣」找到適合的優秀人選，然而在過去幾年工程師爆炸增長的時期，這個方法幾乎是無法使用，而我們也更應該關注讓普通工程師也能很好發揮方法。
年初開始的Rails 部署實踐系列算是一種嘗試，試著將知識拆分成小單元的方式來讓讀者更容易學習（雖然最近才意識到是一種實驗）以及今年的演講題目「從 Domain-Driven Design 看網站開發框架隱藏」針對 Rails 框架、架構層面上的問題用實作的經驗、案例深入分析，加上明年會開始更新的「優雅的 RSpec 測試」和正在規劃的付費系列「Rails Developer Foundation（Rails 開發者基石）」系列，都在嘗試提供一個「理論跟實作之間的平衡」以及「了解足以工作的好習慣」這樣的知識。
如何讓新手工程師順利分析問題、如何撰寫出容易維護的程式、如何更快速的實現功能、如何有系統地進行程式碼審查，這些影響著新手工程師加入團隊的難題，要怎麼解決在這一年的文章撰寫、研究、實驗過程中逐漸成形。
建立印象
為了建構「蒼時弦也」這樣的品牌形象，演講的簡報改以 Figma 元件的方式來製造統一的視覺印象，同時受到近期熱門動畫 Cyberpunk: Edgerunner 的 UI 設計風格啟發才完成了這次簡報的呈現。
在困擾後續的設計系統（Design System）該如何建構時，剛好 MOPCON 的議程「為什麼你的產品像縫合怪？」由 Akane Lee 所分享從企業的願景所定調的氣質對應到設計、資訊呈現後為什麼會讓人在印象尚有落差感，讓我從中得到許多不同的啟發。
至少，在過去只能模糊的了解到「願景」的概念，到能夠對於視覺設計、使用者體驗、實際服務的影響能夠有一個清晰的概念，也更清楚在建構這些視覺要素的時候該注意哪些地方、做出怎樣的取捨，才能維持自己所設定的目標。
數據驅動
因為想要靠自己賺到想要的收入，就不能像當員工時一樣用大多靠感覺的「老闆怎麼不加薪」這樣的想法，需要靠自己去了解每一個動作所造成的影響，然後去評估下一次要怎樣的調整或者改進，也因此今年的演講簡報最後是問卷的連結、今年有機會發問卷的技術也都會盡量的去進行調查。
雖然有很多知識是在今年透過各種不同類型的活動學習到，像是 IxDA 的工作坊了解到 Lean Startup（精實創業）這本書的概念，並且逐步調整自己在「想法實驗」上的方式，以及透過今年讀的書來不斷改善自己驗證想法的方式。
這次 MOPCON 的議程我也從「提升學習 UX 體驗的極致 - 以培訓軟體工程師為例」由廖洧杰分享的教學經驗中，注意到自己在系列文章規劃中也該注意的「難易度節奏」以及近一步思考「練習」的意義。
在「如何讓 UX 離商業更靠近 - 敏捷環境為例」由 Scarlett 分享的數據理解方式，很淺顯的易懂可以讓我自己了解該怎麼設定跟搜集指標，以及透過「領先指標」跟「落後指標」的資訊來判斷該如何調整跟規劃，消除了很多在理解數據的「不確定感」
剛好我的演講中提到的「建模」的例子，其實就是商業分析的指標如何從「人去解讀」建模成「程式整理完」後交給人「判讀」這樣的過程
新的課題
經過一年的學習跟累積，到了 MOPCON 這幾天跟人交流、學習後，自己一直在思考的一個知識的體系已經逐漸地成形，然而除了內容之外還差了一點需要去補完。前面提到的很多東西有非常多人能做到，自己該怎麼去製作出一個良好的「體驗」去完成自己追求的「理解」這件事情，他既不是「學會理論」也不是「能夠實作」而是串連這兩者的橋樑，反而是最難以教授的一個區塊。
這個過程中要如何去「融合」然後找到一條自己的「道路」就變得非常重要，像是今年 Odd-e 的 LeSS 敏捷開發課程中，我對於 A-TDD（Acceptance Test Driven Development，驗收測試驅動）開發有很深刻的印象，以及在實踐敏捷中對於「需求」到功能到任務的拆分跟理解，再加上這段時間對 Domain-Driven Design 的研究、IxDA 工作坊學到的新創運作模式、商業思維學院課程中所培養的各種對「商業的理解」以及自己在 YouTube 直播針對理論的實踐，或者星門計畫的 Discord 社群所討論的問題等等，要如何將他們融合，然後產出屬於自己的知識。
基於這些知識，接下來要如何抽離過度複雜的概念，並且將適合新手的知識有系統的傳遞，在許多「不確定」的問題被消除後，該做的事情就逐漸清晰，也變成自己接下來的課題。
通向頂尖
要說意外的話，大概就是因為這幾年的經歷意外的看清楚「頂尖」的路是怎樣的。要說幸運的話大概就是每個人有每個人自己的路，倒是不太需要擔心和其他人有衝突。如果要說不幸的話，不外乎就是有些人的道路太過耀眼，反而讓其他人看不清自己該走的路。
最簡單的問題往往是最困難的，過去卡在知道很多技術知識、實作能力也非常不錯、對需求的理解跟分析也不算差，然而似乎一直沒辦法再進一步，即使學會更多知識、更深入的技巧也還是卡在同一個階段。
然而問題卻很單純，這些過程中有許多「不確定感」並沒有被解決，就如同我們在學習 Domain-Driven Design 的過程中，為什麼每個人的解釋都不同，而且都沒辦法說服對方呢？因為透過主持開發者對話刻意的練習，在準備簡報的過程中就發現了很多「為什麼是這樣？」的疑惑。
以 Domain-Driven Design 15 Years 所提到 Eric Evans 認為在 Domain-Driven Design 書中後半部的「策略（設計）」部分比較重要，但我們在利用戰術實踐的過程中，卻沒有思考「為什麼會這樣做？」進而讓我們無法更精確的分析問題、判斷處理方式。
要突破這樣的限制，只能不斷的透過問自己「為什麼？」然後去驗證、去解釋，然後找到答案，反覆地在一個「領域」中精煉，最後就會達到頂尖的領域。
我們在 Domain-Driven Design 所學到的分析技巧，如果反過來應用在分析「怎麼寫程式」這件事情上也是相當合理的，又或者說這本來就是不同領域專家本身就擅長的事情，所以才被稱之為「專家」
最為困難的就是這樣，要對「已知」提出「問題」需要花費的時間跟精力是非常巨大的，所以這很幸運，因為我們在自己的領域要達到頂尖就極其困難，因此不用擔心有人和自己競爭，反倒是因為看到其他人的成果（像是熱門的產業、職業之類的）而忘記該走自己的路，也許更加危險。