通用工程導論/筆記本/問題撰寫
工程透過玩耍、先做、設計（做）以及最終到解決問題來發展。
在出現問題之前，存在著議題。在議題之前，存在著未知的痛苦，未知的效率、生產力和生活質量的改善。當一個議題出現時，每個人都開始意識到它。一種語言隨之發展，賦予它一個名稱。考慮一下農業。出現了這樣一個議題：人類在一天中只能完成這麼多工作。這個議題變成了一個目標，並被賦予了詞語：“如何在減少人力投入的情況下生產更多食物？” 在這一點上，它仍然是一個議題，因為沒有人擁有這個問題。
問題有所有者。議題引發對話。工程師傾聽議題的對話，並試圖將其轉化為問題，就像律師試圖尋找客戶或醫生試圖尋找病人一樣。大多數人迴避議題，並認為工程師有點古怪，有點不近人情，應該管好自己的事。但律師卻在尋找爭端，醫生試圖讓人們談論他們的痛苦。工程師是否應該停止試圖尋找問題？
成熟的工程師知道何時承擔了過多的責任，需要將議題留給其他工程師。
非工程師會忽略並忍受議題。他們拒絕為它們命名，並談論它們。它們看起來像什麼也沒有，像洞，像敘述中巨大的缺失部分。問“為什麼”會導致意見競爭，想法的所有權以及圍繞工程師所看到的議題進行“文明”的舞蹈。
擁有一個問題並不意味著工程師有責任解決它。擁有一個問題意味著在不設想解決方案的情況下定義問題。目標是找到所有緊張局勢、所有挫敗感、所有迷霧和困惑，並以一種能激發多種解決方案並引發需求討論的方式來描述問題。
學會擁有問題，甚至不去思考解決方案，這與我們大多數人的成長方式相反。我們大多數人會想到問題/解決方案對，並希望有人為我們列出它們。工程師不會建立問題/解決方案對。技術人員會。問題/解決方案配對是現有裝置經驗和專業知識的結果。這與工程無關。
問題可能很大，涉及數百名工程師。理想情況下，專案問題從美國國家工程院重大挑戰開始。大型問題為每個人所知，它們定義了專案，它們涉及客戶。高管希望瞭解和理解大問題。專案問題是協商的結果。
專案很有趣。但是自己動手 (DIY) 活動是為了服務自己。它們建立在現有機會和材料之上。它們利用閒暇時間和金錢。它們是關於我和我的才能的個人藝術的精神練習。它們是敘事驅動的，而不是設計驅動的。它們是我們生活的裝飾。它們很少能盈利。它們很少能提高生活水平或擴大人類物種的領域。專案關乎藝術、文化和文明行為。它們可以被工程化。
工程師透過找出如何為世界上每個人完成這個專案……或任何人都可以遵循的 DIY 套件……或為世界上其他人創造工作來將專案轉化為問題。起點是將“樂趣”轉變為一個議題。痛苦、收益或變化在哪裡？標準在哪裡？最佳實踐在哪裡？它是否曾經被工程化？工程師將透過發現專案的問題來開始“專案”。工程師遠離責備遊戲。問題陳述是協商的結果，工程需求被記錄在案，替代設計被建立等。工程專案/大問題會經歷一些業務流程。成熟的工程師會談論與“大”問題相關的業務流程，因為這最終決定了成功。
需求與大問題相關。它們定義了成功。它們沒有設想一個可行的解決方案。撰寫需求意味著設想不是一個解決方案，而是所有解決方案。它需要創造性的枯竭。這通常是一項不僅涉及當前團隊，還涉及所有其他相關工程師的任務。它通常伴隨著向更大範圍的工程師進行演示。
土木工程需求具有受法律指導的結構。撰寫需求的工程師實際上不應該設想解決方案。需求捕捉所有現有的上下文。它們試圖回答諸如“我們需要知道什麼？”或“需要發生什麼？”之類的問題。目標是將其轉化為一系列數字和數字描述。創造性的枯竭並不意味著專案需要提前完成。這並不意味著需要進行構思和設計。目標是從客戶、高管的角度看待專案，並將其窮盡。
撰寫需求感覺就像試圖攀登混亂、昏暗、模糊的期望。有一種想要用問題來耗盡高管和客戶的衝動。但這永遠不會發生。任何嘗試都會遇到“這就是我付錢讓你做的事情。” 因此，工程師會想出一些需求並將其提交給客戶。然後，客戶會簽署這些數字描述。
在專案的構思和設計過程中，可能會重新協商需求。結果是RFP（投標請求）。如果需求過於具體，那麼世界上只有一家工程公司可以完成這個專案，每個人都會被起訴。如果需求過於模糊，那麼沒有工程公司會競標該專案。如果需求過於強勁，只會收到高價投標。如果需求過低，將會收到大量低價投標。
問題不是個人的。一些學生四處走動說：“我的問題是‘我不擅長汽車’。” 這不是一個工程問題。個人的迷霧或困惑可能是個人問題，但它不是工程問題。工程師永遠不會將個人的無知轉化為問題。如果你不知道某些東西，並且沒有教程可以快速教你，那麼這是世界的問題，而不是你的問題。成為一名工程師。解決問題。建立一個認證。幫助下一代工程師跨越這個問題到另一個問題，而不是重新發現你最初的發現。哥倫布發現了美洲，因為他將其記錄在紙上。美洲存在於口頭交流的世界之外。如果你不能把問題寫下來，那麼你就不是工程師。
工程問題存在於自身之外。一個小工程問題是人們偶然發現的東西，而不是計劃好的東西。工程問題是在做事的過程中發現的。未知是機會，而不是問題。當工程師將事物轉化為個人問題時，他們會失去尊重。
小工程問題是可以被一名工程師在一小時內發現和解決的問題。處理問題讓工程師贏得了“修理”東西的名聲。實際上，工程師只修復他們正在建立的東西。技術人員通常更擅長修復各種東西。工程問題的解決在大多數情況下並不是“修復東西”。
小問題可以透過讓其他團隊成員參與進來而變得更大。如果問題很難（存在於自身之外，與人無關）、定義明確且沒有提供解決方案，那麼擴大一個微不足道的問題可以提高一個人的聲譽。這種問題是工程師的食物。不利的一面是，如果問題微不足道，擴大問題可能會降低聲譽。如果解決方案在另一位工程師的腦海中，而你還沒有學會尊重那位工程師（或與他們交談），那麼你的聲譽就會下降。
當技術員/技術專家遇到挫折時，他們會找人責怪……工程師。而技術專家/專家幾乎總是對的。設計通常存在問題。工程師則無人可責。
工程師有道德和法律義務改進問題解決流程，而不是推卸責任。這使得工程師個人免於訴訟。專案是由一系列問題組成，最終轉化為專案需求。設計是問題的解決方案。每個潛在的解決方案都需要進行驗證。
所有這些問題的背後，是工程師必須面對的挫折和壓力。工程師的目標是學會與這種挫折共處。工程問題解決的第一步是學會管理挫折。
問題是目標本身，而不是達到目標的手段。
問題是症狀的細節，而不是導致症狀的原因，也不是可能的解決方案。
問題是議題、可能性和希望，而不是變化帶來的痛苦。
問題是形式和功能的期望，而不是具體的材料清單。
問題是對輸入的描述（在程式設計專案中是單元測試），以及預期的輸出，而不是演算法。
問題不能與你的學習曲線相關聯。相反，專注於以下三點：
- 我們每個人都存在不確定性、挫折和技能有限的迷霧。
- 目標是瞭解自己……知道自己不知道什麼。
- 每個人都會經歷挫折，找出如何從中獲得靈感。
如果你的學習曲線和不確定性都驅動著你的問題編寫，你將在工程師中贏得尊重……但在社會其他群體中則不然。
世界存在問題，而不是你。如果你無法理解，那是世界的問題。把它變成世界的問題。
不要表達你的學習曲線或不確定性。在簡報中留白，以激發問題。使用“這裡有人知道嗎？”這樣的問題來探索你能力不足的範圍和規模。如果有人回答，準備好當場學習。希望沒有人知道。也許其他人沒有任何想法。也許這個問題真的很尖銳，你真的因為為世界做了一些第一件事而得到報酬！你的腎上腺素應該開始湧動！這就是工程簡報如此重要的原因！
問題必須用贏得社會尊重的術語來描述。這意味著你僅限於對物理、流程或系統的描述，與你自己無關。興奮起來！
只有存在多種解決方案時，問題才算是一個工程問題。集思廣益，列出所有可能的解決方案。你只有列出不止一個解決方案才算是在集思廣益。只需命名它們即可。不要試圖詳細闡述。不要列出諸如“放棄”之類的瑣碎方案，或諸如“尋找其他東西”之類的模糊方案。
列出一個解決方案不是工程活動。問題/解決方案對是技術人員喜歡閱讀的內容，而不是工程師。
不要談論你腦海中浮現的解決方案。不要執著於它們。把它們寫下來，然後等待下一個解決方案出現在你的大腦中。回到問題的緊張狀態。在腦海中重複問題。然後將你的列表與你的團隊成員進行比較。投票。有多少與你的相同？有多少完全不同？它們如何相似？正在出現什麼？
如果你想不出解決方案，不要感到力不從心。也許問題陳述還沒有完全形成。向課堂/其他工程師提出問題。在簡報期間，徵求、鼓勵並記錄來自聽眾（包括你的導師）的解決方案。不要提出諸如“我應該插在哪裡”之類的瑣碎問題，並期望獲得工程界的尊重。
概述軟體目標，即輸入和輸出（單元測試）。解決方案是演算法……不同的演算法可以執行相同的單元測試。視覺化演算法。命名它們。列出名稱，在編寫測試之前不要編寫解決方案。
解決方案不必現實，但必須合理。
測試分為三個部分。一是描述測試協議。
二是實際執行測試。
三是分析結果，並決定是否重新定義問題、執行另一個解決方案測試或提出另一個解決方案。如果正確執行，解決方案中將出現路徑或方向。當這種情況發生時，需要嘗試沿著路徑向下檢視是否最終會取得成功。否則，可能會浪費大量時間/金錢。
技術人員會在第一個有效的解決方案上停止。技術人員會使用泡泡糖、乾草捆紮線、蘇打罐、WD-40 和膠帶解決大多數問題。他們的目標是修復，而不是探索所有可能的修復方法。如果在僅進行一次測試後宣佈問題已解決，不要期望獲得認可。如果單次測試導致問題重述和/或激發了更多解決方案設計，則可以獲得認可。
問題可能隨時發生。通常在執行（設計）過程中發生。在所有情況下，它們都會在執行或專案編寫過程中發生。在所有情況下，它們都會在處理專案時發生。
在你的筆記本中使用小問題、多種解決方案和測試三元組來記錄問題。使用相同的提綱在團隊專案報告中建立可交付成果。在正文中描述大問題，並在執行摘要中進行釋義。