有別於人文學科，工程通常是帶有嚴謹、明確目的的。雖然常聽到程式設計是一門藝術，但這不妨礙軟體工程也帶有工程性質，就如同建築，也是設計與工程兼具，所以不能用程式設計帶有藝術性質就不去遵守其嚴謹性、不去實踐工程的專業素養。

在軟體開發中，從小到大、從深到淺、從定位到產品，從程式碼到文字紀錄，都應當是有明確的目的與定義的。從最為工程師知曉的 SOLID 中的單一職責原則（Single responsibility principle），就講明了一個類別應該只能有一個理由去變動，從這裡概念延伸出去，我們也會要求單一方法應該也只負責一件事情，就如同 Unix 所言「讓程式只做好一件事」。所以我們盡量明確定一個建立每個變數、每個方法、每個類別、每個命名空間、每個套件的目的、它們的職責、以及它們的存在理由與範疇。

如果嚴謹遵守這個概念，變數名稱就會明確、並且只存在需要他的範疇（Scope）、一個方法不會有太多切換用的參數作為開關，因為他只會一次做好一件事、一個類別不會太大，畢竟他只負責一種職責、只代表一種存在。寫出來的程式碼自然漂亮、帶著工程之美。

另外，在規劃軟體時，也要嚴謹的去定位他的價值。如同我們要蓋房子時，盡量在一開始明確定義它的目的，一般的住宅很難改成立體停車場或是大型餐廳、商辦大樓不可能變成工廠，縱然現實可能存在不斷改變的案例，但一旦定位變動過大，該建築可能就會東加蓋、西補強，變得醜陋。

所以我們在做軟體產品時，一定要明確暸解我們開發這個軟體是為了什麼，如果後來打算轉換定位，或許應該考慮的是另外開一個軟體專案，而不是硬要在原本不適合的基礎上實作與當初定位相差甚遠的功能。

而在 API 的設計上也是如此，如果沒有一個一致的風格、沒有系統性的規劃路徑與方法，那麼這個 API 就難以被呼叫者暸解，甚至會耗費無意義的時間在弄懂其不直覺或是反人性的設計，讓除錯成本提高。

除此之外，一個 commit、一個 branch、一個 Pull Request 的存在目的都應該要明確，維持只為一個目的變動、一個理由存在，這樣才不會在未來追溯時產生想找的變動在意想不到的位置裡，而在 Code Review 時也比較能讓讓變動之間的關聯更緊密，讓檢視者更好抓到重點。

程式設計有其藝術性，但軟體開發也確確實實是一門工程學問，它們的美除了來自於各種哲學外，更表現在工程的嚴謹上，不能因為其相對現實實體來說較抽象，就忽略它的工程性質。