每次碰到新的套件，先了解基本的函式運作，然後會找一下有沒有其他人已經寫過的設計模式或範例。
即使了解函式基本運作，但有時候自己透過函式去寫程式，有時候考慮的東西可能並不完善，或了解的不夠透徹，可能寫出來的程式會需要頻繁的修正或重構。
為了避免以上情況，閱讀別人寫過的程式碼，了解原來這些函示別人是怎麼用的，用什麼樣的設計模式、程式上是怎樣的布局。透過別人的經驗來學習撰寫，更了解函式的使用，是非常有效且能少掉很多摸索的時間。
此外，軟體的開發通常是承先啟後的。從頭開始開發新軟體的機會是很少的。即使是重頭開發，隨著時間演進，專案變的龐大，中間需要修正的地方，仍然需要了解程式上前後對應關係，也就是軟體流程，還有專案的開發風格、軟體架構等，才能在適宜的地方進行修改及增加功能。
如果沒有對軟體架構及流程有足夠了解，單就程式發生問題的地方進行修正或功能增加，可能因為在沒有足夠了解的情況下，產生補丁的情況發生。
可以想像一下，如果房子中要增加有線網路，直覺的方式是在房子內拉條網路線，因為網路線的存在使得有線網路正常，即使網路線在房子裡顯得礙眼，但功能一切正常，問題解決。但想想如果不是只要新增有線網路，而是有更多線路需要增加，然後房子裡堆滿各種繁雜的線路？反正功能正常，問題有解決，難道是種好的解決方式？
假設我們先了解一下房子的架構，假設房子裡面已事先埋好暗管以方便增加各種線路，將各種線路埋進暗管裡，房子裡也不會堆滿各種繁雜的線路，是不是個較佳的作法。而這樣較佳的作法，其實就是在動手解決問題前，先理解原本的架構，找出可行的做法。
軟體上也是一樣，先了解既有的軟體架構，才對問題本身找出合適的解法，本身也是透過閱讀開始。
所以在軟體開發上，除了新的函示庫需要了解，軟體的流程、架構，前後關係，都需要透過閱讀來了解。
所以，在開始動手寫程式前，多花點時間閱讀一下。