Subtitles section Play video Print subtitles The following content is provided under a Creative Commons license. Your support will help MIT OpenCourseWare continue to offer high quality educational resources for free. To make a donation or view additional materials from hundreds of MIT courses, visit MIT OpenCourseWare at ocw.mit.edu. PROFESSOR: Hello, and welcome to 6.01. I'm Denny Freeman. I'm the lecturer. One thing you should know about today is that there's a single hand-out. You should have picked it up on your way in. It's available at either of the two doors. What I want to do today in this first lecture is mostly focus on content. But before I do that, since 6.01 is a little bit of an unusual course, I want to give you a little bit of an overview and tell you a little bit about the administration of the course. 6.01 is mostly about modes of reasoning. What we would like you to get out of this course is ways to think about engineering. We want to talk about how do you design, how do you build, how do you construct, how do you debug complicated systems? That's what engineers do, and we're very good at it. And we want to make you very good at it. We're very good at it. And you know that from your common, everyday experience. Laptops are incredible. As we go through the course, you're going to see that laptops incorporate things from the tiniest, tiniest level, things so small that you can't see them. They're microscopic. The individual transistors are not things that you can see. We develop special tools for you even to be able to visualize them. And yet, we conglomerate billions of them into a system that works relatively reliably. Now, I realize I'm going out on a limb because when you say things like that, then things always fail. But I'll go out on a limb and say, for the most part, the systems we construct are very reliable. We'd like you to know how you think about making such a complicated system and making it reliable. We want to tell you about how you would model things. How do you gain insight? How do you get predictability? How do you figure out how something will work before you've built it? If you're limited to trying out how things work by actually constructing it, you spend a lot of time constructing things that never make it. We want to avoid that by -- where we can -- making a model, analyzing the model, making a prediction from the model, and using that prediction to build a better system on the first try. We want to tell you about how to augment the physical behavior of a system by putting computation in it. That's a very powerful technique that is increasingly common in anything from a microwave to a refrigerator. We'd like you to know the principles by which to do that. And we'd like you to be able to build systems that are robust to failure. That's a newer idea. It's something that people are very good at. If we try to do something, and we make a mistake, we know how to fix it. And often, the fix works. We're less good at doing that in constructing artificial systems, in engineering systems. And we'd like to talk about principles by which we can do that. So the goal of 6.01 is, then, really to convey a distinct perspective about how we engineer systems. Now, having said that, this is not a philosophy course. We are not going to make lists of things to do if you want it to be robust. We're going to learn to do things by actually making systems. This is an introductory engineering course. And so you're going to build things. The idea is going to be that in constructing those things, we've written the exercises so that some of those important themes become transparent. So the idea is -- this is introductory engineering. You'll all make things. You'll all get things to work, and in the process of doing that, learn something about the bigger view of how quality engineering happens. So despite the fact that we're really about modes of reasoning, that will be grounded in content. We selected the content very broadly from across EECS. EECS is an enormous endeavor. We can't possibly introduce everything about EECS in one subject. That's ridiculous. However, we wanted to give you a variety. We wanted to give you a sense of the variety of tasks that you can use, that you can apply the same techniques to. So we want to introduce modes of reasoning, and then show you explicitly how you can use those modes of reasoning in a variety of contexts. So we've chosen four, and we've organized the course around four modules. First module is software engineering, then signals and systems, then circuits, then probability and planning. Even so, even having chosen just four out of the vast number of things we could have chosen, there's no way we can tell you adequately-- we can't give you an adequate introduction to any of those things either. What we've chosen to do instead is focus on key concepts represented by the asterisks. The idea is going to be we choose one or two things and really focus on those deeply so you get a thorough understanding not only of how that fits within, for example, the context of software engineering, but also how that concept ramifies into other areas. Notice that I tried to choose the stars so they hit multiple circles. That's what we're trying to do. We're trying to not only introduce an idea to you, but also show you how it connects to other ideas. So the idea, then, is to focus on a few, we hope, very well-chosen applications that will demonstrate a variety of powerful techniques. Our mantra, the way we intend to go about teaching this stuff, is practice, theory, practice. There's an enormous educational literature that says-- whether you like it or not-- people learn better when they're doing things. You have a lot of experience with that. You have a lot of experience on the other side, too. I'll try to forget the other side, or at least try to wipe it from your brain momentarily to focus on your more fundamental modes of learning. When you were a kid and you were learning your first language, you didn't learn all the rules of grammar first. You didn't learn all the letters of the alphabet first. You didn't learn about conjugating verbs first. You learned a little bit about language. You started to use it. You ran into problems. You learned a little more about language. You learned to go from words like "feed me" to higher level concepts, like "Hey, what's for dinner?" So the idea is that you learned it in an iterative process where you learned some stuff, tried it out, learned some more stuff, tried it out. And it built up. There's an enormous literature in education that says that's exactly how we always learn everything. And so that's the way this course is focused. What we will do is, for example, for today, we'll learn a little bit about software engineering. Then, we'll do two lab sessions where you actually try to use the things we talk about. Then, we'll come back to lecture and we'll have some more theory about how you would do programming. And then, you go back to the lab and do some more stuff. And the hope is that by this tangible context, you'll have a deeper appreciation of the ideas that we're trying to convey. So let me tell you a little bit about the four modules that we've chosen. The course is going to be organized on four modules. Each module will take about one fourth of the course. First thing we'll look at is software engineering. As I said, we don't have time to focus on, or even survey, all of the big ideas in software engineering.