此篇為系列文章第二篇，若是你錯過了第一篇誤打誤撞進來這裡，傳送門在這：
自學、哲學、講學：我的程式之路（上）
高中的主線就只有一條，那就是程式競賽。
我先大概說明一下高中的程式競賽，或其實我之前在 ptt 其實就有講過，我這邊稍微再整理一次。
高中的時候資訊競賽這一塊就有官方辦的了，比較重要的比賽是區域性的程式競賽，我的學校（師大附中）在台北市，因此叫做北市賽，全名是：台北市資訊能力競賽。每個學校能夠派出的選手名額有限，因此如果太多人，學校會先辦一個校內賽。
北市賽的獎項分成四種：一等獎 5 個、二等獎 5 個、三等獎 10 個跟入選獎，前十名（也就是一二等）可以參加全國賽。
全國賽就是各個區域賽的前十名聚集在一起比賽，獎項跟區域賽一樣，而全國賽前十名可以保送 TOI 選訓營。
無意間看到一篇文章在分享自己學網頁的歷程與心得，而這類型的文章其實我也曾經想要寫過。
在我寫十年程式自學之路的時候，其實我原本想寫的是像剛才提到的那樣，有許多篇幅在講述自己學程式的經歷以及做過的事。可是我寫一寫發現那時候徵文的主題其實是自學的一些心得，所以才改成後來大家看到的那樣，著重在十年裡面學習到的經驗。
這一篇其實算是個人傳記，在動筆之前想到了以前看過的經典文章：追求神乎其技的程式設計之道，風格大概會比較像那樣吧！就是詳細地紀錄了自己一路上究竟學了些什麼，是怎麼走過來的。
這篇最難的部分大概就是標題了，原本想取叫：「十年程式之路」，發現跟上一篇太過於類似，可能會有人以為是同一篇。幸好靈機一動想出來現在的這個標題，但其實「講學」這個詞用得有點過了，在這邊先跟大家說聲抱歉。講學純粹是為了跟前面兩個「學」相互呼應，我不認為我有到講學的程度，頂多就是分享一些經驗跟教學而已。
好了，前言差不多就到這邊。因為這系列會很長，所以拆成上中下三篇來寫。
在三個月前，我在 ptt 上 po 文（[分享] 免費程式教學(前端)），說我願意提供一系列的免費程式前端教學。只要是有網頁基礎的都能夠報名，歡迎大家寫信給我，並且附上幾個提問的回答，最後我會挑 5~10 個人進行培訓。
上面所指的提問如下：
那篇文章是 3/2 發出的，報名截止日期到 3/11，而 3/15 以前會寄信給被我錄取的人
先來講講當初為什麼會想要開這個免費程式教學吧！其實原文裡面也有寫了，我再講得更清楚一點
在這之前，其實我就曾經辦過類似的活動了，雖然也是程式教學，但其實來找我的都是毫無經驗的初學者，我能給的都是一些比較大方向的建議，例如說跟他們介紹什麼是前端、什麼是後端，介紹幾種程式語言，並且推薦給他們適合初學者的。
上一次教學大概接觸了十幾個人，可是卻幾乎沒有一個「真正碰到寫程式」，都僅止於「想學程式但又還沒開始」的階段
可是這不是我想要的，我想要的是實際讓學生們動手寫程式，並且驗證看看「我的方法」是不是真的有效，至於這個方法是什麼，我們稍後會提到。因此，我這次的教學才會把學生限定在「有前端程式基礎」，那代表我可以往更深的地方去教。
文章 po 出之後在 ptt 上的迴響還行，大約是 30 幾個推，以軟體工作版這種比較小的板來說算多了。但事實上，報名的人數遠出乎我的意料。
到報名截止日期為止，我一共收到了 42 封信。
是我原本想收的人數的四到八倍左右（原本我只想收 5~10 個），而且有很多人都寫得很不錯。其實，從這些信件就可以看出每一個人的個性了，有些人比較懶，隨便寫個三四行就寄過來；有些人很認真，甚至還提供履歷或者是有精心排版。
那怎麼辦呢？我要怎麼從裡面篩出我要的人？
算了，太麻煩了，乾脆就全收吧！
沒錯，我真的是這麼想的。於是，拒絕掉真的不適合的 4 個人以後，最後錄取的有 38 人。
下面附上我當初寄給所有人的錄取通知：
Hi,
收到這封信，就代表你已經錄取了。
但其實說「錄取」我自己也覺得有點怪啦，因為並不是什麼正式的活動，辦這個程式教學的初衷就純粹是我希望四五年前我剛接觸前後端網頁程式的時候，也有人能夠這樣帶著我，給我一些建議。
但那個人始終沒有出現，於是在四五年過後，我決定自己跳下來做那個人。
在寫程式的路上一樣受到了很多前輩們的幫助，Google 跟 Stackoverflow 也惠我良多，就是因為受過太多人的幫助，才讓我一直覺得「回饋」是一件我必須要做的事情。
前言差不多就到這邊了，這封信是統一回給大家的，接著會介紹一下之後這個活動的走向。
這次的報名比我想像中的踴躍，大約有 40 位朋友們都對這個活動有興趣，雖然當初文章寫說只收 5~10 位，但仔細考量過後，發現其實每個人的需求都不太一樣，基本上可以把需求分為兩類。
第一類是想要練習前端基礎，希望我能夠出作業或是給一些指導的；第二類則是已經有前端的程式能力，希望能跟我聊聊工作上相關的事情，例如說我是怎麼到新加坡工作，要達到什麼樣的程度等等的。
針對這兩類的需求，會分為兩種方式來進行。
第一類的話大約每週或是每兩週會出一次作業（或者是之後有可能改成作業全部都先出好，大家自己可以有自己的進度），然後固定時間我會統一講解這次作業裡面你應該可以學習到的知識點，再加上我自己的一些補充。
第二類的話基本上能力沒什麼問題，我也沒有甚麼可以教的，所以主要就是跟你們約個時間，然後我們來聊聊天，就當作是參加什麼技術分享會跟隔壁的人聊聊天就好。不用有什麼太大的壓力，聊一聊也可能發現其實你的技術能力比我強。
大家都已經有寄信對我做個簡單的自我介紹了，現在換我來做個簡單的自我介紹。
我叫胡立，現在在新加坡擔任前端工程師，來這邊大約五個月左右而已。
學程式是從升國中的時候開始，一路上基本都自學，小時候寫 VB，長大之後跑去玩程式競賽寫 C/C++，之後對手機程式有興趣跑去寫 Java, Android，大學時終於踏上網頁之路學習 PHP 跟前端網頁。實習時候發覺自己對前端比較有興趣，就開始比較專攻前端以及 Node.js 後端開發
更詳細的資料你可以參考我的 Linkedin：https://www.linkedin.com/in/hulii，之後的交流大家也不用太嚴肅，就叫我 huli 或是胡立就好，太嚴肅的話我也會覺得怪怪的XDD
有關於這個教學活動，還有以下幾點要跟大家說明：
你可以「隨時退出」，因為你有可能把我想的太強，但實際教學時卻發現我好像沒那麼強，就跟你的期待有落差。如果碰到這種情況，覺得我沒有辦法給你什麼幫助的話，那你可以直接來跟我說或是怕尷尬的話隨便想個理由也可以。這沒什麼的，不用有什麼壓力。
一定要給我回饋。無論我教得好或是壞，都麻煩大家給我一點回饋，我之後會開一個匿名的 Google 表單讓大家填寫，還麻煩大家在教學結束之後給一下 feedback。
學習還是要靠自己。儘管我可能會給你一些方向，給你一些建議，但畢竟師父領進門，修行在個人，你們之後會變得怎麼樣，就看你們自己了。
就差不多是這樣了，在這邊有兩件事情要請大家幫忙，才能讓我們順利開始
以後 Slack 就是我跟大家溝通的管道了，所以麻煩 Slack 的通知要開一下，如果我在 Slack 上面一直沒回你的話，可以多找我幾次或是一樣寫 email 給我。
現在離四月大概還有三週的時間，我會在這段期間內盡量找「每一個人」聊一聊，如果你是第二類，就是想跟我聊一聊的話，那我們的緣分(?)大概就是聊完就結束了，因為之後我也沒有什麼可以幫的了XD
如果是第一類需要教學的，就大概根據你之前的那篇自我介紹簡單閒聊一下，也會聊到目前對這個教學活動的期待以及更具體地、希望我能夠給予的幫助，教學部份的話預計是從四月初開始，我會再找時間統一跟大家 update 一下最新的狀況。
下面附上初步想出來的第一類的教學大綱，如果你覺得下面這些你都會了，那其實沒什麼必要聽我教學，因為我能教的就這些了XD
我擅長的比較偏 js 而不是 css，所以期待能學到什麼厲害 css 技巧的朋友們可能會失望了，我自己也不太會切版，RWD 也會苦惱很久，在 css 這部分比較不能提供什麼協助。
最後幫大家條列式總結一下現在狀況：
感謝大家的配合，
Huli
一開始的兩週我大概跟 20 個同學一對一聊過了，大約七成用語音三成用文字，就聊一聊彼此的狀況、從什麼時候開始學程式的、程式程度大概到哪邊以及對課程大綱的看法。
其實這個課程最重要的就是課程大綱了，我們馬上來仔細看一下！
會擬出這個課程大綱，主要有兩個因素，第一個是因為裡面教的那些東西，剛好都跟我近期的工作內容有相關，因此教起來我會比較得心應手，畢竟自己就在碰這些東西。
第二個原因是因為我在工作上接觸到這些東西的時候，我原本也是什麼都不懂，不知道 webpack 在幹嘛、不知道 gulp 在幹嘛、不知道 infinite scroll 到底怎麼做。可是當我花一段時間理解之後，我知道為什麼當初的我覺得這麼難了。
因為我不知道是用在哪裡，我不知道是幹嘛的，或是說，我不知道「我為什麼要用」，我在網路上找了一大堆教學，每一篇都在跟我說「怎麼用」，卻很少有資料能告訴我：「為什麼要用」、「如果不用會怎樣」
在幾次教學經驗的累積過後，我找到一個我認為比較有效的教學方式，原則就是：
要先痛到，才會得到
這是什麼意思呢？
我有一陣子很喜歡看大公司的一些架構文章，裡面寫說他們怎麼把機器架構調整成適合規模化，講說他們碰到了什麼問題，用什麼解法解決了超大資料量所帶來的 Bug。
我一開始覺得很有收穫：「哇，這些感覺好厲害啊，學到很多」。可是過一陣子之後，才發現自己什麼都沒學到。那些東西過一週之後我就全部忘掉了，好像文章根本沒看過一樣。
後來我忘記在哪邊看到一篇文章，裡面有一段傳達的意思我記得特別深刻（如果有人也看過同樣一篇，麻煩在底下留言，小弟感激不盡），文章裡面寫說，那些都是大公司的高手們痛苦過、經歷過所淬煉出來的「精華」，你怎麼可能期望你看了十分鐘，就能夠擁有他們十年的功力？
「痛過」，是一件很重要的事。
與其直接教他們寫 SCSS，不如先讓他們寫 CSS，然後一直叫他們改顏色，叫他們改東改西。這時候他們就只能一直用文字編輯器尋找->取代，不斷重複這個循環。等到你確認他們真的痛了，再教他們 SCSS。
這時他們會有種「重獲新生」的感覺，「靠！原來還有這種東西喔，這樣就不用改這麼辛苦了，用變數就可以了」，這樣子的學習方式我認為會比起直接教有效許多。
在教他們一樣東西之前，我一定會想辦法讓他們知道說：「為什麼我需要這個」，我認為當這個問題搞懂也同意之後，才會更有動力去學習，也才能知道自己到底在學什麼，學了之後可以幹嘛。
還有另外一件事，那就是比起每一個不同的小作業，比較好的做法是「一個逐漸加強的作業」，這樣在做作業的時候，學生可以不斷地看見自己的進步，不斷地看見專案的成長，而且最後會做成一個完整的，而不是一堆零碎的、破碎的小專案。
因此，我就以這幾個概念規劃出了這些課程大綱，後來有稍作調整：
第十週原本是 React.js，我後來拿掉了，原因有兩個。第一個是我認為 React 放在這邊不適合，還沒到教的時機點，還不夠「痛」，而且跟前面的也沒有什麼關聯。第二個是我改作業發現很多人的 coding style 不好，所以第十週放這個，前面九週作業寫得越醜的要花越多時間改，讓他們「痛」一下。
我必須先承認，上面這個規劃並沒有很好地使用到「痛到才會得到」這個教學原則，這個是我還可以再做得更好的部分，進步空間還很大很大。
而由一個小作業逐漸加強我覺得我算是滿好的掌握到了，一開始先讓他們刻一個靜態版面，再來把 CSS 換成 SCSS，然後把假資料換成真的資料，串 API。接著加上佔位圖以及無限滾動，讓頻道可以一直滾動加載。
第六週的作業目的是拋棄 jQuery，節省檔案大小，也讓他們知道原來不靠 jQuery 還是可以寫 JavaScript 的。第七週把中文換成中英雙語，可以支援兩個語言，第八週改用 webpack 實作模組化，第九週用 gulp 讓他們知道原來很多事情都可以自動化，最後一週修正自己的 coding style。
這樣子逐漸優化的過程，他們在做下一個作業的時候就可以直接接續上一個，把一個專案變得越來越完整。
如同我一再強調的，寫程式不是重點，重點在「解決問題」，幾乎所有事情的重點都在這個。
解決問題又可以分成以下幾點來思考：
我很喜歡一個詞叫做 trade-off，中文可以翻作：權衡、取捨。
尤其是在寫程式的領域中，你做什麼事其實都是一種 trade-off，最常見的例子就是時間換空間或空間換時間，沒有那麼好康的事情讓你又有空間又有時間。好啦，其實有，但那都是用錢換來的。
我在每一週的作業說明裡面，都會提到說我們這週碰到了什麼問題。那解法呢？解法當然就是那一週要教大家的東西囉。以下我們把每一週的課程再剖開來看，自問自答上面那三個問題（解決什麼問題、如何解決、優缺點）：
比起「webpack 是一個打包工具」這種介紹，你讓初學者們知道 webpack 到底是幹嘛的、是要解決什麼問題、要怎麼解決會有用的多。再次強調，問為什麼很重要，知道為什麼也很重要。知道背後的原因，你就可以決定你要不要用這一套解法。
你用一個東西，背後必須要有一個「好理由」。
A：我們改用 TypeScript 吧
B：為什麼？
A：因為潮啊！
如果「潮」這個理由不夠有說服力的話而 A 又提不出其他更好的理由，那就沒有必要改用 TypeScript。
之前有一篇很紅的文章，叫做：在 2016 年學 JavaScript 是一種什麼樣的體驗，我覺得有一個很可惜的點，那就是有些人看完之後的心得都只有：「唉，對啊！前端現在也太複雜了吧！」
但我覺得這篇文章你應該去思考的是：「裡面那些工具是不是真的需要用到？那些工具想解決的問題，到底是不是我碰到的問題？」，這才是這篇文章的重點。
舉例來說，裡面有一段這樣寫：
可別用 jQuery！現在哪還有人用 jQuery。現在是 2016 年了，你絕對應該用 React。
這個理由跟上面的一樣薄弱，一個字：潮！
當然，他也可能是其他意思，也有可能是想表達說 React 是近年趨勢，jQuery 可能會慢慢被淘汰並且不再維護，以後就有維護性的問題。這時候你就可以考慮說：這樣的情形是不是有可能發生？如果真的發生的話，會有怎樣的影響？用 React 帶來的複雜性跟 jQuery 的可維護性哪一個損害較小？
總之呢，重點應該是「你要解決什麼問題，這問題用哪些工具來輔助最適合」，而不是一味的覺得前端怎麼那麼複雜那麼多東西。
是啊，本來就一堆東西啊，可是裡面可能有八成你根本用不到啊！
如果你寫一個一頁式的行銷 landing page 還硬要用 React + Redux + Rx + Webpack 的話，那我也是醉了。
這堂課程的進行方式是這樣的，如上所述，總共十個作業，每一個作業一週，必須「先做作業」，但做不出來也沒關係。每個禮拜二我會直播講解上一週作業並且實際示範如果是我的話，我會怎麼做。
會這樣規劃是因為「自學」無論在哪個領域，都是一個重要的技能。我想先讓同學們對於我要教的內容有概念，甚至是把作業做出來以後，我再重新講解一遍。我覺得唯有這樣，才能讓同學們對我教的東西更熟悉。
這就呼應到我上面提過的「要先痛到，才會得到」，事後有很多同學都反應他們課前預習時覺得有些東西好難，怎麼看都看不懂。可是一看完我的直播教學，就有種茅塞頓開的感覺：「哇！原來這麼簡單」。
如果相反過來呢？假如是我先上課，他們就只會覺得：「喔，是這樣寫」，接著寫作業的時候就直接抄我的解法就好了。他們學到了什麼？學到模仿我的程式碼，然後過一個禮拜完全忘記這個解法。為什麼？因為他們沒有痛過，所以沒有去思考。
來，再次強調，你寫程式的時候要思考！要思考！要思考！只有思考過，深思熟慮過的東西才是你的，你才記得住。
講完了課程大綱的設計理念，以及我自己在這堂課最想要傳達的核心思想之後，該來談一下這堂課程的成效了。
前面有說到一共 38 人收到錄取信，到後來只有 36 人填寫基本資料，兩個人就這樣消失了。
而這 36 人之中，只有 26 人有完成第一次作業，意思是說，有 10 個人連作業都沒做，28% 的人就這樣不見了。因此之後的數據我會把參與這次課程的人數調降為 26 人。
能夠撐完十次作業的，只有 8 個人而已，大約是 30%。
下圖是每一次作業完成的人數
可以看到掉得最多的一次是 hw2 -> hw3，寫 CSS 必備神器：CSS 預處理器，我也不知道為什麼這一週會掉這麼多人。
課程結束之後的問卷回饋，作業沒有做完的理由有：時間無法配合、作業難度太高、懶惰、有其他事情、沒興趣。
而問卷中有一題是：「覺得難度最高的作業是哪一個？」，大多數人的回答都是 hw5（讓網頁變得更完整：加上 placeholder 與 infinite scroll）跟 hw6（返璞歸真：vanilla js），因為以前完全沒有寫過類似的東西。
如果以後要改善的話，可以把 hw5 再細切成幾個單元，而不是一次就完成這兩項，hw6 也可以用類似的方法，這樣對學生來說應該就不會一下子難度跳這麼多，而是慢慢變難。
課程結束之後有請大家填了一下回饋的表單，很幸運地，大家感想都滿多的。我原本想要把原文全部貼上來，但這樣篇幅會太多，有點妨礙閱讀，因此我只擷取部份，刪除掉一些重複的內容。
（以下皆為回饋原文，我只修了一些排版而已）
回饋問卷裡的心得礙於篇幅，貼在這邊不太適合，因此我只貼兩篇寫在自己 Blog 的。
先來說缺點的部分，其實比起優點，我更想聽到的是缺點。因為知道缺點在哪邊才能持續改進嘛，但不知道是這次表現太好還是學生不好意思，缺點的部分回饋的比較少。
身為一個不斷追求進步的老師，就算學生沒講，自己也應該要察覺到一些缺點。
雖然學生說改作業很用心，但其實有時候我一次面對堆積如山的十幾個作業，很多東西都只是快速看過去而已，畢竟老師也是會懶惰的...這是我之後可以再改進的地方
上面我有提到要先痛過才能理解，我覺得作業還可以再切得更細，讓學生更「痛」一點。例如說培養 coding style 的部分，可以先出一個作業規定大家：「變數名稱只能用一個英文單字，例如說 a, e, y 等等，不夠用的話加上數字變成 a0 等等」，做完一次作業之後，隔週再讓大家看自己上週寫的程式，應該會發現看不懂在幹嘛。
這個時候，他們就會知道變數命名的重要性了。
接著談談優點，開頭有提到說這是一場：「三十人的教學實驗」，實驗目標就是驗證我上面講的那些教學理念（要先痛過、要懂目的、要知道為什麼）是否真的能幫助學生學習。
從學生反饋的結果看來，我認為是可以的，這也更加確認了我以後課程的規劃方向。
有關優點的部分，我就直接貼幾個學生的回饋上來吧！從這些回饋裡面就可以發現，我想傳達的，他們都能夠確實接收到。
講解的時候講到很多我原本準備好要問的東西，而且講解方式很容易讓人理解，因為有交代原因，所以也很容易讓人接受。就像安排課程一樣，每個章節循序漸進，就會很容易理解以及接受為什麼要用這些東西，以及這些東西的好用之處。
講解程式會讓人覺得原來寫程式可以這麼清晰簡單，講解過程看似輕鬆卻有架構。當同學聽不懂時會用很多不同角度切入解釋，像是生活化例子或是各種相關連結以加深同學對程式的觀念和印象！
很喜歡老師的教學是讓同學先寫再公布答案，讓同學有機會先嘗試各種自己先想的到或找的到的可能解法，而等到直播課時才公布老師的做法，可以有互相交流切磋的機會，也不會讓同學是腦袋空空去上課。因為都先寫好作業了，在課堂上也更易吸收和整合，也能馬上快速理解哪種情境適合哪種解法，也能一眼發現自己先前卡住的地方在哪，因為都已經卡過了。
在這次程式課也發現寫程式這件事的思考沒有想像中的複雜，可能和老師的教學大綱切的清楚乾淨，以及講解時是以「需求」為出發點。一些新手，像是我，常常在開發過程花了一堆時間，總是在寫連自己也不太懂自己幹嘛或為何而寫的code。寫code時的思考是我在這堂程式課學到的珍貴收穫。
先感謝我的學生們，陪我走過了十週的課程，並且願意在結束之後給予回饋。
我一直覺得，程式教學應該要能有更好的方法，能夠幫助學生更快上手、更快理解。這次的課程讓我驗證了我目前的方向是對的，之後也會一直朝著這方向前進。
如果你對這次課程感興趣，可以前往課程的 Github 頁面觀看課程內容，或是到Youtube直接觀看影片。
也可以直接到我最近才開的線上課程平台：Lidemy 鋰學院註冊課程，完全免費！我把作業內容跟影片都上傳到上面了。（但因為課程已經結束了，所以沒有人會幫你改作業）
我認為這堂課的價值在於「先寫作業，後講解」的教學模式，因此像上面這樣把教學影片公佈出來，我不打算盈利，都是完全免費的資源，開放大家隨意取用，因為這堂課的核心價值已經不見了，所以也沒必要收費。
我希望我的課程在各個環節上都能夠公開透明，因此，若是對學員課後提交的回饋表單有興趣，這邊有學員回饋的完整備份（只有刪除掉一些個人資料）。
最後，感謝大家願意花時間閱讀這篇落落長的文章，若是對我後續的教學實驗或課程有興趣，麻煩請追蹤Lidemy 鋰學院粉絲專頁，後續的消息都會公布在那邊。
感謝。
事情是這個樣子的，原本我眉毛左邊有長一小粒東西，我想說可能是青春痘所以就沒去管
就在上禮拜日晚上（5/21）覺得那邊有一點腫腫的，想說會不會其實是撞到什麼腫起來
晚上睡覺的時候就想說那我揉一下好了，不是腫起來都要揉一揉嗎
接著我就進入夢鄉了
隔天早上起床，就是見證奇蹟的時候了
這篇我原本是回在 ptt 上面的，整理一下之後轉到 blog 來
其實對於這個主題，91 哥的這篇：我為什麼鼓勵工程師寫 blog已經講得很好了，建議大家先看一下這篇文
而我這篇心得文呢，主要是因為看了上面貼的那篇之後滿有感觸的
所以提出幾個自己很有共鳴的點來做延伸
我寫 blog 的最大收穫之一就是幫助自己
很多人都以為寫了技術文章就是要給別人看的，但卻忘記自己也是文章的受眾之一
很多時候我寫 blog 是因為要留下自己的筆記
想說放 Evernote 到時候很難找，不如公開在網路上，還可以讓 Google 幫我備份
而那些筆記對別人有沒有用我不知道，但至少對我自己很有用
有很多不會頻繁接觸的東西，過一陣子沒碰之後你一定會忘記
例如說新電腦的環境設置，我習慣裝 zsh，然後自己改一些配置
可是這種東西一定設定過一遍就忘記了，因此我就整理一下 po 在網路上
前一陣子剛換工作，要幫新電腦設定 zsh 的時候，就跑回去看自己以前的文章
「阿！幸好我那時候有寫下來，這次只要照著做就好了」
或是之前 postgresql 在設定的時候也碰到一些問題，一樣寫了 blog 記錄起來
下一次碰到的時候我完全忘記當初怎麼解了，就會很感謝當時的自己有記起來
又或是最近想寫個 Slack 的 bot 玩玩看，但已經很久沒有寫這東西了
但幸好我 blog 以前有寫一篇 Hubot 的心得，只要稍微看一下，記憶就都回來了
相信我，寫 blog 幫助最大的一定是自己
你看我可以舉那麼多例子就知道，我被自己的 blog 幫助到多少次
若是你在初期真的不知道要寫什麼，沒有什麼 idea 的話
建議你可以從技術筆記開始，可以不用是那麼完整的一篇技術文章
甚至只是整理一些連結也可以！
我以前寫過一篇文章標題叫做：[Android] 到底什麼是context?
裡面我只是整理了一些看到的不錯的連結，當作筆記就 po 在部落格了
結果你現在如果去 Google 搜尋：「android context」，會發現這篇出現在第一頁
只是一篇再簡單不過的筆記，卻帶來意想不到的效果
（但這種奇怪的事不是天天都有啦，當作運氣好的結果就好XD）
再舉一個例子，我當初在理解從 callback, Promise, generator 一直到 async 的時候
有把自己的心得記錄下來整理成文章：[Javascript] Promise, generator, async與ES6
像我現在其實就有點忘記這整個脈絡跟 code 要怎麼寫了
但只要再把文章看完一遍，我就可以回憶起八九成了XD
理解一項東西是一回事，要寫出 blog 文章又是另外一回事
有時候你在研究一個主題，東看看西看看覺得有點 insight 可以寫
或者是覺得有些心得想要跟大家分享，於是決定立刻動筆開始寫文章
可是，寫一寫卻發現這個點好像不太懂為什麼是這樣，那怎麼辦呢？
還能怎麼辦，只好去查一下再把它弄懂
或者是在文章上面寫：其實這部分我也不是很懂...
但如果沒有弄懂的話，你會發現文章愈來愈寫不下去，因為不懂的地方只會愈來愈多
於是你就只好認命，乖乖的再去把更多的文章看完，補足自己不懂的部分
沒錯！在你終於把文章寫完的時候，你的知識又再消化了一遍，又把更多的洞給補齊
這就是寫文章的好處之一，可以強迫自己再一次學習
說穿了，其實寫文章就是把知識重新整理、歸納的一個過程
像是我前幾天寫的一篇文章：我遇過的最難的 Cookie 問題
其實原本我是沒有想要把問題追根究底解決的，可是我文章都寫一半，頭都洗一半了
文章的結尾如果是：這個問題我也還沒有答案...的話，總覺得不太完整
只好硬著頭皮去找更多資料，最後終於把問題透徹地搞懂
我寫這篇文章主要是想告訴大家，原 po 這篇裡面講的寫 blog 的好處都是真的
因為那些好處我幾乎全部都體驗過一遍了
像是把自己的知識公開在網路上，就可以讓全世界的網友來幫你糾正錯誤
這是一個多棒的機會！有些東西如果沒有人來跟你講，你可能根本不會知道
例如我一個月前寫的：讓我們來談談 CSRF
po 完之後有一個朋友傳訊息給我說：「講 CSRF 居然沒講到 SameSite」
我就傻了幾秒跟他說：咦？這個我居然找資料的時候沒找到！
然後就去把相關知識惡補了一遍，再把內容補上去原本的文章
就這樣，輕鬆再賺到了一個新知識
我當初寫 blog 的理由就兩個：幫助自己、幫助他人
對我來說，其他額外發生的好處很多其實都是額外價值，但也會成為你繼續書寫的動力
像是以前寫了一篇講 redux 的 middleware 的文章
（http://huli.logdown.com/posts/294284）
不定時會有路過的網友看過之後來留言，說這是他們找很多資料以後，看過最好懂的文章
這時候內心當然就會小感動XD 至少知道自己的東西是真的有幫助到人
也知道自己真的有能力，可以把一件複雜的事情講的簡單許多
其他的好處像是收到演講邀約、上課邀請甚至是公司的合作機會
或者是聚會時別的工程師會講一句：「阿！我有看過你寫的....」
講到這裡，或許會有人認為說：你能得到這麼多好處，是因為你的 blog 比較多人看啊
聽起來也是挺有道理，可是，如果你不是本來就有名氣的人
剛開始寫 blog 的時候，大家的起跑點都是一樣的，都是 0
我也是一樣，剛開始寫那些筆記的時候根本就沒有人看，也沒有人會來回應
所以這時候我覺得寫 blog 的心態就很重要
假如你一開始的心態就是：「我要靠著寫 blog 成名！」
那這時候你的挫折感就會很大，因為你的 blog 根本沒有人會來看
可是我剛有講過，我寫 blog 的心態是為了要幫自己留筆記
如果有人來看當然很好，但沒有人來看我也沒差，反正我可以幫到我自己就好
但你要相信，真正有價值的內容是不會被埋沒的
如果你覺得你寫的技術文章很棒，真的很有質量，也能夠幫助到很多人
可是卻沒有人知道的話，你可以貼到 Facebook 的技術社團
或者你要投稿 TechBridge 也可以，我們會幫你曝光的XD
我的 blog 有八成的流量都是從搜尋引擎來的
只要你的文章是真的有價值的，就一定會越來越多人點，然後 Google 排名就越來越前面
看的人會越來越多，流量也會越來越多，你就會更有動力寫出更好的文章
這是一個很棒的正向循環，希望大家都能進入到這個循環之中XD
講了這麼多，還沒寫 blog 的人應該對這件事情很心動了
不要再等了，現在就是「好，那我找個時間來寫 blog」的那個「時間」
至少先創一個 blog，大概才花你十分鐘而已
如果你想找一個線上平台，我用了兩年的 logdown（免費版）我覺得很不錯
或者你也可以考慮國外很紅，國內也越來越多人 po 文的 Medium
想要自己架的話可以考慮 Hexo
或其實用 Github Issue 寫 blog 也可以！
不要再等了，讓我們一起寫 blog，一起成長吧
如果想要找跟部落格有關的教學的話，可以參考這篇超級詳細的教學文。
