How should people who enjoy building things and have aptitude in math and science become engineers? Answering this is our quest. This is intentionally different from asking ‘how should engineering be taught?’ or ‘what is the right structure for engineering courses?’ because engineering is not merely a body of content that passes from the teacher to the student. It is a mindset and a collection of habits in addition to an evolving base of knowledge.
We will first compare two different approaches to engineering education and then introduce a third that we believe better aligns with our proposed habit formation goals. The most established and common form of education is “Direct Instruction” (DI), and Olin and other schools have responded to this with a different system that I will rename for clarity as “Structured Exploration” (SE) though it is known internally as “Do-Learn”.
In Direct Instruction, students do readings in preparation for class, attend lectures, do problem sets, do explicitly structured laboratory experiments, take tests, and may do a final project for the course. This is the traditional pattern familiar to students of most technical subjects. DI has many advantages: It is easy to design courses with this format and simple to teach. Students already understand this pattern from prior schooling. Because concepts build upon each other within and between courses, the dependency chain of prerequisites is clear. The curriculum becomes straightforwardly modular and easily reviewable by others. However, its format does not prepare students for the practice of engineering. When building something new, the formal theory is often not known beforehand. Even if the scientific knowledge exists, the process of discovering it and learning how to apply it to solve problems does not come with an answer key. Aspiring engineers must learn how to explore a new field by familiarizing themselves with the relevant literature, designing experiments that answer open technical questions, and then ordering the construction of prototypes to develop new technology. DI does not incorporate this uncertainty. Even though the didactic DI approach makes course design simple, it allows students to follow from the conceptual sequence of the readings and lectures instead of requiring them to contend with unclear problems. Further, by focusing on pure reception of content, DI risks losing the “joy of building” that motivated most students to pursue engineering.
What if the pattern were flipped such that building new things drove learning? This is the premise of ‘Do-Learn’ or ‘Structured Exploration’, and ‘experiential learning’. In DI, the learning precedes the application in what is usually a limited final project in the course or senior project. In SE, students are given an application and some ‘structure’ such as relevant papers, book chapters, or hardware and need to ‘explore’ the domain to build it. Then, there is formal treatment and review of the content necessary for the problem alongside a report.
We can take the example of an early Olin class project in “A Whole New Engineer” (p. 21) for SE: Professor Gill Pratt “challenged students to design and build a pulse oximeter (a device that measures your pulse and blood oxygenation) during the first six-week module. Rather than starting with lectures about circuits, he introduced the idea of what a pulse oximeter is and conceptually how it works and then acted as a coach as students began to wrestle with the concept. Students read patents; they built simple circuits; they blew up simple circuits – but at the end of six weeks, they had successfully constructed a working pulse oximeter. It wasn’t pretty; it didn’t work as well as a commercial device, but it worked, despite the fact that the students who built it had just finished high school and had never worked with circuits before.” Building the pulse oximeter motivated learning.
To design courses in the SE style, professors select problems that will illustrate certain concepts and allow students to discover them. This improves student ownership over learning instead of treating it as something that is simply received. Software Engineering needs this more than other fields because it changes more rapidly. What one’s professors learned probably came from a different era. Further, because software engineers may work on automation or optimization solutions for many different domains in their careers, they especially need to develop this concept acquisition skill. Through its curated structure, SE serves as scaffolding to the experience of diving into a new domain. Courses should offer progressively less of this structure through the curriculum to gradually build student autonomy.
Compared with DI, SE better prepares students to engage with uncertainty and builds their confidence in their ability to learn in a self-directed manner. It shows how theoretical knowledge and its acquisition relates to practical implementation. Student’s motivation to build can help propel them through the curriculum instead of something that happens on the side or late in their studies.
However, there are also many costs to SE, which may be under-reported by its advocates. First, it can be a source of anxiety for many students, especially those who are falling behind. While engaging with the ambiguity of a problem can be exciting for those on top of their work, for those who are struggling it can appear as an unnecessary obstacle or cause of frustration. In DI, students can work through an established course structure that is laid out clearly on the syllabus. They can draw from their familiar study habits to churn through the readings and the problem sets. If the course does not make it clear how all the concepts that should have been encountered through each lab or experiment fit together, then the big picture can also be lost. Missed connections then can compound over the course of the curriculum.
Second, developing a curriculum composed mostly of structured explorations requires much more effort than DI. Each exploration needs to illustrate the intended principles while having scope reasonable for a course. The treatment of each topic will naturally take longer because it must allow for false starts and failed experiments within student exploration. Third, SE courses are harder to make legible: other instructors even at the same institution may have difficulty reviewing the course plan, and might not be able to rely as strongly on the coverage of certain topics in courses intended as prerequisites, or student retention of them. In traditional DI, each course functions as a well-understood module in the curriculum that facilitates communication and planning. Fourth, measuring student progress becomes harder, especially for individual contribution in team projects. All of these are acknowledged trade-offs for the sake of promoting a habit-forming learning experience that better matches engineering practice.
But the most serious problem with SE as it is frequently implemented is that it does not actually ‘complete the cycle’ of engineering practice with reviewed iteration. “Do-Learn” promises that the formal learning happens alongside and partially after the first practical engagement with the material. Without taking the results of the first exploration, presenting them to peers, and re-doing the design, SE only covers the first steps of the engineering process. A proof of concept for a pulse oximeter is only the beginning. Instead, we propose “Crystallized Engagement” (CE) as Exploration, Formal Theory, and Integrated Application: first gain hands-on experience and learn the theory in parallel, then do it again while methodically applying the theoretical knowledge. In DI and SE, student projects often turn into proofs of concept that barely work for the demo in front of the class and are then forgotten. While rapid prototyping is a valuable skill, engineering as a discipline requires analyzing failure modes and getting systems to work reliably. Finally, engineers need to be able to pass the baton to others through technical review and complete documentation. The curriculum should include all of these steps for comprehensive preparation. The first completion of the engineering cycle directs students to ‘begin with the end in mind’ of an intentionally designed, reliable, and well-documented system, instead of staying in a tinkering mindset.
This proposed Crystallized Engagement takes even longer than Structured Exploration by requiring additional iterations on specific projects. However, it does not need to be used in every course, just as the time investment for SE might not be everywhere justified. Given that these approaches aim to develop engineering mindsets and skills, it is likely sufficient to introduce them early to ‘plant the seed’ of these ideas and then allow them to naturally grow through the curriculum through a variety of projects. It is difficult to avoid sacrificing breadth for depth with this approach, but because we have the engineering mindset as a core goal, we believe it is worthwhile.
Mike's Engineering Blog 