通用工程导论/笔记本/问题撰写
工程通过玩耍、先做、设计（做）以及最终到解决问题来发展。
在出现问题之前，存在着议题。在议题之前，存在着未知的痛苦，未知的效率、生产力和生活质量的改善。当一个议题出现时，每个人都开始意识到它。一种语言随之发展，赋予它一个名称。考虑一下农业。出现了这样一个议题：人类在一天中只能完成这么多工作。这个议题变成了一个目标，并被赋予了词语：“如何在减少人力投入的情况下生产更多食物？” 在这一点上，它仍然是一个议题，因为没有人拥有这个问题。
问题有所有者。议题引发对话。工程师倾听议题的对话，并试图将其转化为问题，就像律师试图寻找客户或医生试图寻找病人一样。大多数人回避议题，并认为工程师有点古怪，有点不近人情，应该管好自己的事。但律师却在寻找争端，医生试图让人们谈论他们的痛苦。工程师是否应该停止试图寻找问题？
成熟的工程师知道何时承担了过多的责任，需要将议题留给其他工程师。
非工程师会忽略并忍受议题。他们拒绝为它们命名，并谈论它们。它们看起来像什么也没有，像洞，像叙述中巨大的缺失部分。问“为什么”会导致意见竞争，想法的所有权以及围绕工程师所看到的议题进行“文明”的舞蹈。
拥有一个问题并不意味着工程师有责任解决它。拥有一个问题意味着在不设想解决方案的情况下定义问题。目标是找到所有紧张局势、所有挫败感、所有迷雾和困惑，并以一种能激发多种解决方案并引发需求讨论的方式来描述问题。
学会拥有问题，甚至不去思考解决方案，这与我们大多数人的成长方式相反。我们大多数人会想到问题/解决方案对，并希望有人为我们列出它们。工程师不会创建问题/解决方案对。技术人员会。问题/解决方案配对是现有设备经验和专业知识的结果。这与工程无关。
问题可能很大，涉及数百名工程师。理想情况下，项目问题从美国国家工程院重大挑战开始。大型问题为每个人所知，它们定义了项目，它们涉及客户。高管希望了解和理解大问题。项目问题是协商的结果。
项目很有趣。但是自己动手 (DIY) 活动是为了服务自己。它们建立在现有机会和材料之上。它们利用闲暇时间和金钱。它们是关于我和我的才能的个人艺术的精神练习。它们是叙事驱动的，而不是设计驱动的。它们是我们生活的装饰。它们很少能盈利。它们很少能提高生活水平或扩大人类物种的领域。项目关乎艺术、文化和文明行为。它们可以被工程化。
工程师通过找出如何为世界上每个人完成这个项目……或任何人都可以遵循的 DIY 套件……或为世界上其他人创造工作来将项目转化为问题。起点是将“乐趣”转变为一个议题。痛苦、收益或变化在哪里？标准在哪里？最佳实践在哪里？它是否曾经被工程化？工程师将通过发现项目的问题来开始“项目”。工程师远离责备游戏。问题陈述是协商的结果，工程需求被记录在案，替代设计被创建等。工程项目/大问题会经历一些业务流程。成熟的工程师会谈论与“大”问题相关的业务流程，因为这最终决定了成功。
需求与大问题相关。它们定义了成功。它们没有设想一个可行的解决方案。撰写需求意味着设想不是一个解决方案，而是所有解决方案。它需要创造性的枯竭。这通常是一项不仅涉及当前团队，还涉及所有其他相关工程师的任务。它通常伴随着向更大范围的工程师进行演示。
土木工程需求具有受法律指导的结构。撰写需求的工程师实际上不应该设想解决方案。需求捕捉所有现有的上下文。它们试图回答诸如“我们需要知道什么？”或“需要发生什么？”之类的问题。目标是将其转化为一系列数字和数字描述。创造性的枯竭并不意味着项目需要提前完成。这并不意味着需要进行构思和设计。目标是从客户、高管的角度看待项目，并将其穷尽。
撰写需求感觉就像试图攀登混乱、昏暗、模糊的期望。有一种想要用问题来耗尽高管和客户的冲动。但这永远不会发生。任何尝试都会遇到“这就是我付钱让你做的事情。” 因此，工程师会想出一些需求并将其提交给客户。然后，客户会签署这些数字描述。
在项目的构思和设计过程中，可能会重新协商需求。结果是RFP（投标请求）。如果需求过于具体，那么世界上只有一家工程公司可以完成这个项目，每个人都会被起诉。如果需求过于模糊，那么没有工程公司会竞标该项目。如果需求过于强劲，只会收到高价投标。如果需求过低，将会收到大量低价投标。
问题不是个人的。一些学生四处走动说：“我的问题是‘我不擅长汽车’。” 这不是一个工程问题。个人的迷雾或困惑可能是个人问题，但它不是工程问题。工程师永远不会将个人的无知转化为问题。如果你不知道某些东西，并且没有教程可以快速教你，那么这是世界的问题，而不是你的问题。成为一名工程师。解决问题。创建一个认证。帮助下一代工程师跨越这个问题到另一个问题，而不是重新发现你最初的发现。哥伦布发现了美洲，因为他将其记录在纸上。美洲存在于口头交流的世界之外。如果你不能把问题写下来，那么你就不是工程师。
工程问题存在于自身之外。一个小工程问题是人们偶然发现的东西，而不是计划好的东西。工程问题是在做事的过程中发现的。未知是机会，而不是问题。当工程师将事物转化为个人问题时，他们会失去尊重。
小工程问题是可以被一名工程师在一小时内发现和解决的问题。处理问题让工程师赢得了“修理”东西的名声。实际上，工程师只修复他们正在创建的东西。技术人员通常更擅长修复各种东西。工程问题的解决在大多数情况下并不是“修复东西”。
小问题可以通过让其他团队成员参与进来而变得更大。如果问题很难（存在于自身之外，与人无关）、定义明确且没有提供解决方案，那么扩大一个微不足道的问题可以提高一个人的声誉。这种问题是工程师的食物。不利的一面是，如果问题微不足道，扩大问题可能会降低声誉。如果解决方案在另一位工程师的脑海中，而你还没有学会尊重那位工程师（或与他们交谈），那么你的声誉就会下降。
当技术员/技术专家遇到挫折时，他们会找人责怪……工程师。而技术专家/专家几乎总是对的。设计通常存在问题。工程师则无人可责。
工程师有道德和法律义务改进问题解决流程，而不是推卸责任。这使得工程师个人免于诉讼。项目是由一系列问题组成，最终转化为项目需求。设计是问题的解决方案。每个潜在的解决方案都需要进行验证。
所有这些问题的背后，是工程师必须面对的挫折和压力。工程师的目标是学会与这种挫折共处。工程问题解决的第一步是学会管理挫折。
问题是目标本身，而不是达到目标的手段。
问题是症状的细节，而不是导致症状的原因，也不是可能的解决方案。
问题是议题、可能性和希望，而不是变化带来的痛苦。
问题是形式和功能的期望，而不是具体的材料清单。
问题是对输入的描述（在编程项目中是单元测试），以及预期的输出，而不是算法。
问题不能与你的学习曲线相关联。相反，专注于以下三点：
- 我们每个人都存在不确定性、挫折和技能有限的迷雾。
- 目标是了解自己……知道自己不知道什么。
- 每个人都会经历挫折，找出如何从中获得灵感。
如果你的学习曲线和不确定性都驱动着你的问题编写，你将在工程师中赢得尊重……但在社会其他群体中则不然。
世界存在问题，而不是你。如果你无法理解，那是世界的问题。把它变成世界的问题。
不要表达你的学习曲线或不确定性。在演示文稿中留白，以激发问题。使用“这里有人知道吗？”这样的问题来探索你能力不足的范围和规模。如果有人回答，准备好当场学习。希望没有人知道。也许其他人没有任何想法。也许这个问题真的很尖锐，你真的因为为世界做了一些第一件事而得到报酬！你的肾上腺素应该开始涌动！这就是工程演示文稿如此重要的原因！
问题必须用赢得社会尊重的术语来描述。这意味着你仅限于对物理、流程或系统的描述，与你自己无关。兴奋起来！
只有存在多种解决方案时，问题才算是一个工程问题。集思广益，列出所有可能的解决方案。你只有列出不止一个解决方案才算是在集思广益。只需命名它们即可。不要试图详细阐述。不要列出诸如“放弃”之类的琐碎方案，或诸如“寻找其他东西”之类的模糊方案。
列出一个解决方案不是工程活动。问题/解决方案对是技术人员喜欢阅读的内容，而不是工程师。
不要谈论你脑海中浮现的解决方案。不要执着于它们。把它们写下来，然后等待下一个解决方案出现在你的大脑中。回到问题的紧张状态。在脑海中重复问题。然后将你的列表与你的团队成员进行比较。投票。有多少与你的相同？有多少完全不同？它们如何相似？正在出现什么？
如果你想不出解决方案，不要感到力不从心。也许问题陈述还没有完全形成。向课堂/其他工程师提出问题。在演示文稿期间，征求、鼓励并记录来自听众（包括你的导师）的解决方案。不要提出诸如“我应该插在哪里”之类的琐碎问题，并期望获得工程界的尊重。
概述软件目标，即输入和输出（单元测试）。解决方案是算法……不同的算法可以执行相同的单元测试。可视化算法。命名它们。列出名称，在编写测试之前不要编写解决方案。
解决方案不必现实，但必须合理。
测试分为三个部分。一是描述测试协议。
二是实际执行测试。
三是分析结果，并决定是否重新定义问题、执行另一个解决方案测试或提出另一个解决方案。如果正确执行，解决方案中将出现路径或方向。当这种情况发生时，需要尝试沿着路径向下查看是否最终会取得成功。否则，可能会浪费大量时间/金钱。
技术人员会在第一个有效的解决方案上停止。技术人员会使用泡泡糖、干草捆扎线、苏打罐、WD-40 和胶带解决大多数问题。他们的目标是修复，而不是探索所有可能的修复方法。如果在仅进行一次测试后宣布问题已解决，不要期望获得认可。如果单次测试导致问题重述和/或激发了更多解决方案设计，则可以获得认可。
问题可能随时发生。通常在执行（设计）过程中发生。在所有情况下，它们都会在执行或项目编写过程中发生。在所有情况下，它们都会在处理项目时发生。
在你的笔记本中使用小问题、多种解决方案和测试三元组来记录问题。使用相同的提纲在团队项目报告中创建可交付成果。在正文中描述大问题，并在执行摘要中进行释义。