Hello and welcome to our first Crash Course Kids Compilation video. This one is all about engineering. I know that we all want to build things, make stuff, and just plain enjoy and understand the things that others have made. But how do they do it? How do we do it? This collection of videos will help us all understand a little more about engineers and the engineering process. So let's get started.

How do we get around from place to place without having to walk everywhere? How can we communicate with people who live far away? These were problems that people struggled with for a long time, until recently, before there were things like cars and phones and computers. And you know who solved those problems? Engineers. 

But do you know what an engineer is?

(Big Question)

The short answer is that an engineer is someone who wants to know how and why things work. Now, I want to know how and why things work, but does that make me an engineer? Not quite.

Besides being naturally curious, an engineer is a person who designs and builds things, like machines or systems or structures, that help solve a specific problem. There's more than just one type of engineer, too. But no matter what type of engineer someone is, they have to ask themselves three very important questions when they're working.

Number one: What is the problem that needs to be solved? And number two: Who has the problem that needs to be solved? And most importantly, number three: Why is this problem important to solve? Let's take a look at some examples.

(Investigation)

A really famous example of engineering is the Golden Gate Bridge in San Francisco, California. I mentioned that there are different kinds of engineers, and a civil engineer is someone who designs and constructs buildings, roads, and, yup, bridges. 

For the person who designed the Golden Gate Bridge, what was the problem that they needed to solve? People couldn't travel in or out of San Francisco, which is surrounded on most sides by water, without a boat.

Who had the problem? Residents of San Francisco, mostly, but really anybody traveling in the area.

And why was the problem important to solve? Well, you didn't want a whole bunch of San Francisco residents trapped in San Francisco forever, even if it is a super cool city. Plus, you wanted people outside of San Francisco to be able to travel to the city easily if they needed to. So the Golden Gate Bridge was engineered as a solution to this problem. 

In addition to civil engineers, there are also mechanical, electrical, chemical, computer, nuclear, and software engineers, and the list goes on. Let's talk about what some of the other types of engineers do. First up, electrical engineers.

Electrical engineers study electricity. They design electrical systems like circuits and computer chips. Think of an electrical object that you use pretty regularly. How about your microwave? What problem was the microwave a solution to? Cold food, right? You have an electrical engineer to thank for the ability to reheat that leftover pizza you just had for lunch. 

But while you might not have heard of Joseph Strauss or Percy Spencer, the engineers responsible for the Golden Gate Bridge and the microwave, respectively, you've probably heard of Henry Ford, as in Ford cars.

Henry Ford was an mechanical engineer, or someone working in the manufacturing industry, making mechanical things like tools, engines and machines, machines like cars. Ford didn't invent the automobile, but his Ford Motor Company made a lot of them. His Model T car was famous for being affordable for plenty of Americans.

Ford saw that lots of people who wanted to drive cars just couldn't because they couldn't afford the pricey vehicles that were for sale, so he engineered a cheaper model as a solution to this problem. His fellow engineers started to do the same, and now, well, cars are everywhere.

Henry Ford's not the only big name engineer. A famous engineer around today is Marissa Mayer. Mayer is the president of the Internet company Yahoo and is also a software engineer.

Software engineers work on computers and other products that use software to write programs to make them faster and able to do more things.

(Conclusion)

No matter what kind of engineer someone is, their job at its most basic level is problem-solving. Each engineer just specializes in solving certain kinds of problems. While it might seem like there are too many types of engineers to keep track of, just wait 15 years, or 50, or 100 because we'll probably have a ton of different types to add to the list by then.

Think about it. Over a hundred years ago we didn't have jobs in fields like aerospace engineering, where people design and construct planes and spacecraft. We didn't have planes like we do today or need spaceships, so we didn't need people to engineer them. Who knows what machines or tools or everyday objects we'll have in the year 3015. Personally, I'm hoping for underwater cities. 

But whatever these things are, we'll need engineers to make them. So what do you say? Who wants to be an engineer?

I'm gonna take a wild guess and say you've probably used a phone. And I bet you've enjoyed the benefits of a little thing we call air conditioning. You know who made those things possible? Engineers. 

We were just talking about engineers in our last video: People who design and build things to solve problems, and there are lots of different kinds of engineers. No matter what type of engineer you wanna be though, civil, mechanical, electrical, or a kind that doesn't even exist yet, there's a series of steps that all engineers follow when they're trying to solve a problem.

This process is called, wait for it, the engineering process. Makes sense to me. So what sort of steps are included in the engineering process, and why do we need it?

(Big Question)

Let's go through it step by step and discover how awesome things are made. First thing you gotta do is just define the problem. I mean before you can solve a problem you have to figure out what it is, right? 

For example, back in the 1800s, an engineer named Alexander Graham Bell was trying to come up with a simpler, cheaper way for people to communicate. Back then the best you could do was a telegraph, which is an old fashioned system of sending messages over electrical wires. Bell identified his problem: communicating with people who were far away was expensive, and took a lot of time. So his invention, or solution to this problem, was something you may have heard of: the telephone. Nice!

Now, once you've figured out what problem you want to tackle, you need to do your research. You can start by just making a list of questions you have and what information you need to start answering them. You can also look around and find what other things already exist that have tried to solve this same problem. Maybe they can be improved.

A good example here is the man who helped us blow stuff up. The chemist and engineer Alfred Nobel invented the explosive known as dynamite. Not because he particularly enjoyed explosions, but because miners and other people who, well, needed to blow stuff up to do their jobs, needed an explosive that was safer to use. So, before he started on that problem, Nobel did research to see what explosives already existed, which ones worked well, and which ones didn't.

This takes us to step 3: develop a solution. After your research is done, this is where you say exactly how you think you can solve the problem, and once you've thought of a good solution, you have to figure out how it'll actually work and what it will look like, so you have to design your solution. 

This is where you get to draw! Civil engineers always sketch out their ideas like buildings and bridges and towers to show what they'll look like when they're done. Gustave Eiffel designed the famous Eiffel Tower in France, and he definitely showed up on day one of construction knowing exactly what it was gonna look like. 

On to step five: build a prototype. A prototype is just a simple model that lets you test out your design. It can be as big as the real thing's going to be or it can be a smaller version. You just need to have a prototype so you can test it!

This may be the most important step in the whole process. Engineers need to test their design to see if it works like they want it to. So, say, if your building's a big tower does it stand up? Does it stay standing up? If you're designing something with moving parts, does it work the way you want? 

Now, take it from me, my future engineers, you might have a great idea, a really terrific solution to a really big problem, but when you get to this step your prototype probably won't work exactly the way you want. At least, not on the first try. Most engineers test their prototypes over and over and over again. That's why a lot of time and brainpower goes into the very last step: evaluating your solutions.

"Evaluating" just means asking yourself whether things are working the way you want, or why they are, or aren't. I like to think of this step as "question everything". This is when engineers review all of the facts and ask themselves questions followed by even more questions. What worked well? Why did it work? Why didn't it work? How could it be made better? And, most of the time the answers to these questions are going to send you back several steps.

Like, once you've figured out why your prototype wasn't working, you'll have to design a new solution and then build it and then test it again. Sometimes engineers go through this process four, five, even six times or more.

Take Willis Carrier, the inventor of modern air conditioning. He tested his prototypes for years before he figured out the design that worked the way he wanted and solved the problem he wanted to fix. Like all engineers, he failed a lot before he succeeded, and that's okay because he learned something from every failure, which made his product even better in the end, and I, for one, am glad he kept going.

(Conclusion)

So, the engineering process is a series of steps that engineers, or anyone, should use when they're facing a challenge. The process is important because it allows engineers to experiment and also to fail. Both of these things give engineers a chance to go back and improve on their original idea, giving us something even better down the road.

So, the next time you fail at something, don't feel too bad. Think about the telephone and the air conditioner and the Eiffel Tower, and then try again.

So those are the basics. But there's a problem. Actually there are lots of problems. How do we define what the problems are for our specific challenge? Let's have a look.

Problems. We've all got them: you, me, T. Swift, Tony Stark. Some problems, like forgetting to do your homework, might seem like a pretty big deal to you, but when you compare them to other bigger problems, they're really not so bad. Like what kind of bigger problems?

Well, the kinds of problems engineers face, like how to safely fly hundreds of people through the air in a small vehicle from one country to another, or how to make an eco-friendly building in a seaside town that can withstand hurricane-force winds, or how to send a bunch of earthbound humans hurtling off into space and, you know, get them back. That homework doesn't seem like such a big problem anymore, does it?

'Kay, to be clear, I'm not saying that you don't have to do your homework. If you didn't, it would definitely be a problem, just not as big as, like, having to invent a spaceship. And that's the kind of stuff that engineers do.

Engineers are people who want to know how and why things work. Not only that, they actually design and build things, like machines, systems or structures, to help solve specific problems.

All engineers, whatever type they are, follow the same series of steps when trying to solve a problem. You'll remember these steps as the Engineering Process and the first step in that process is defining the problem, when an engineer identifies a problem he or she hopes to solve.

But that first step isn't as simple as you think it is. So it's time for our big question: "How does an engineer define a problem?"

(Big Question)

Let's come up with a fake problem to solve and we'll see what we wind up with. Pretend you're on one side of a very big canyon, and you need to get to the other side. So that's the problem you need to solve, right? How to cross this very big canyon?

Sort of, but not exactly. We can do better. If I was an engineer and found myself on one side of that huge canyon, here's how I'd go about identifying the problem.

I'd ask questions, a lot of questions, all the questions!

(Investigation)

I need to cross this very big canyon, but is that my actual problem? Hmm. This canyon is very big and I need to get to the other side. I know, I'll cross a bridge! Wait, is there a bridge? Uh, yeah, there's no bridge.

Okay, can I climb down one side of the canyon and then up the other side? Uh, definitely not! Way too deep! Plus, there's a roaring river at the bottom I'd have to figure out how to cross.

So, I can't cross the canyon by bridge, I can't climb down and up, and I can't swim across it. What's something I can do that doesn't require a bridge, climbing or swimming?

I know! I need to find a way to fly across the canyon. And that's my problem, more importantly, that's my solvable problem: "How do I fly across this very big canyon?".

(Conclusion)

It took a little bit of thinking, and a whole lot of questions, but "how can you fly across the canyon" is an easier problem to address than the much less specific "I'm on one side of a big canyon and I want to get to the other side, and I don't know how to get across it." Which, strictly speaking, isn't a question, it's just complaining about a problem really loudly.

So, defining the problem in a solvable way is really key to being a good engineer. While that first step might seem pretty easy, make sure you treat it like the super-important step that it is, because it sets the stage for all of the steps of the engineering process that follow. If you don't define a potentially solvable problem from the start, you might never, well, solve it!

So, an engineer asks a lot of questions to define a problem as specifically as they can and most importantly, as something that can be solved. So how is engineer Sabrina going to find a way to fly across that gorge? You're gonna have to solve that problem by watching our next lesson.

Problems, problems, problems. We've been learning a lot about engineering lately, and engineering always starts with a problem that needs to be solved. But I'm tired of talking about problems! So let's talk about solutions instead.

We've already learned about how engineers define problems. Now it's time to discover how the define success. I don't mean how they define success, like, in general. Like "success" is graduating from a good school, or "success" is getting a good bonus check at work, or "success" is winning a lifetime supply of macaroni and cheese. Although, I'm not gonna lie, that sounds like success to me.

When engineers define success, they do it in relation to the problem they're trying to solve. So, for example, what does a successful solution to my problem look like? The Big Question we're asking today is What makes a solution successful?

(Big Question)

Okay, let's back up a bit. A solution is, what again? A solution is something that an engineer designs or builds to solve a problem he or she has. Some solutions that engineers have come up with include the telephone, a solution to the problem of how people in different places can communicate with each other. Or the refrigerator, a solution to not being able to keep food fresh for long periods of time. Or light bulbs, a solution to not being able to see at night, using something that's safer, brighter, and more reliable than an open flame.

Every day, engineers design and build solutions, but how do they decide which of the many potential solutions that they brainstorm will be the most successful? I think an example would be helpful here. And we've already invented a fake problem, so why not invent a fake solution too?

Back to the canyon. You know, that insanely deep one with no bridge and the raging river at the bottom of it? Yeah, that one.

(Investigation)

The problem we defined at that spot was How do we fly across this canyon? I'll be your stand-in engineer again. Being a good engineer, I know it's time to identify the criteria for my solution. Basically, I need to figure out what things my solution needs to do in order to be considered successful. Think of it like making a checklist.

Number 1: It should get me to the other side. And let me more specific, it should get me to the other side alive. Number 2: It, the thing that gets me to the other side, should be something I currently have, or can easily access. Number 3: It'd be nice if could reuse whatever it is once I'm on the other side.

Now, if Superman's Fortress of Solitude was nearby, I'd snag him and make him fly me over this canyon, no prob. But sadly, I don't have access to Superman's secret lair, so, like any other engineer, I have to make do with what I have.

So, what do I have? I've got the tent that I camped with, and that's about it. You guys, I can make a hang-glider out of my tent! It's a resource I already have, and if I build it properly, it will get me to the other side alive, which is ultimately where I wanna be. Plus, bonus, I can dismantle the glider on the other side, and use the pieces for heir original purpose: keeping me sheltered from lions and tigers and bears, oh my!

(Conclusion)

So, Superman's a solution in that, if he were real and if I could somehow contact him to get him to carry me over this canyon, he could get me to the other side alive. But he's not the most successful solution, because he doesn't meet all of my criteria. He's not currently with me, and I can't easily find him. I mean, the whole point of a secret lair is that it's secret.

So, a hang-glider meets all of my criteria, which means that's our solution. We'll fly across this very big canyon with a hang-glider. And of all the solutions an engineer can brainstorm to whatever problem he or she has, the most successful one – the one that meets all of, or most of, the criteria is the one that engineers actually attempt to design.

Now, actually making a hang-glider out of a tent is a different step in the engineering process, so it's one that we, kind of fortunately, don't have to mess with today, because I have zero idea about how to build or fly a hang-glider.

And anyway, remember that this is a totally fake made-up solution. Don't go jumping into a canyon or anything with a tent, okay? We're here to solve problems, not create new ones.

We've talked about problems. And hey, we've all got them. But there are other things we need to understand if we're going to be good engineers. One of the biggest concepts we need to tackle is variables. What can we change, and what can't we change, when testing our problems?

Everyone gets a case of the what-ifs sometimes. You know, how you ask yourself questions like What if I run out of popcorn and the movie's not over yet? Or what if it's raining when I walk home from school and I forgot my umbrella?

The threat is real, people. But you know who asks themselves what-if questions everyday? Engineers. These kinds of questions are really important when you're trying to come up with possible solutions to a problem. Like, what if we tried to cross a gorge by building a hang glider from a tent? Remember that?

To come up with solutions to problems, like crossing a gorge, you already know that engineers use a series of steps known as the trusty Engineering Process.

A quick recap: We started by defining a solvable problem. In our case, how can we get across the gorge? We looked at more than one solution and chose a solution that met our criteria. It used the materials we had available, and it would successfully get us across the gorge in one piece. Plus, we could reuse the pieces afterward.

Then, in the real world, an engineer would build a prototype of the solution, and test a bunch of prototypes before actually using it. And if the solution didn't work, they'd go back to the drawing board. Engineers are not quitters!

And there's something else engineers do during the process that we haven't talked about yet. and that's defining variables. Excellent! So now we just need to figure out what variables are.

(Big Question)

A variable is just a condition or a value that can be changed. And sometimes a variable is something we can control, where we, as engineers, do the changing. But other times variables are totally out of our control.

So, say we want to see how high a ball bounces after it hits the ground. Let's identify some of the variables involved in that. We can change the height from which we drop the ball. Or we can change the kind of ball we drop. Those are conditions we can change.

But one thing we can't change is the gravity that pulls the ball toward the center of the Earth after we drop it. That's not a variable we can control.

Now, what about our attempt to cross that giant gorge? What are the variables there?

(Investigation)

First, let's think about the variables that we can control. One variable we can change is the weight of our hang glider. We can reduce the weight that it has to carry by, say, leaving our umbrella behind. Or we can add more weight by asking CatBot (19:08) to hitch a ride.

We can also change part of the hang glider's design. If you've ever built a paper airplane, you know that you can change things like the size, or the angle of the wings. These things affect how far or high the airplane flies. The same goes for a hang glider.

What about variables we can't control? Let's talk wind. The wind over a gorge can be nice and breezy. It can also be forceful during a storm. But we can't control that. Sorry. Also, just like bouncing the ball, we can't control gravity.

Now, whether we can control the variables or not, once we've identified what could possibly change when we're trying to solve a problem, we can start asking what-if questions. Like, what if the wind speed is higher than normal? Or what if we decided to leave our umbrella behind? We can use the answers to those what-if questions to help us decide if our solution is going to work, which would be nice to know before we go flying off into the gorge, right?

(Conclusion)

So, engineers identify variables – which are conditions or values that can be changed – when they're looking at and testing solutions to a problem. And by asking yourself what-if questions, you can practice your engineering skills. What-if questions can help you identify variables when looking at a problem.

Just don't ever ask yourself "What if I forget something that I've learned in Sabrina's awesome engineering videos?" 'Cause that's definitely not gonna happen. Right, Catbot?

Come on, bird. And... yes! Crushed it. I just beat a level that I've been stuck on for, like, a month. 

As any good gamer knows, it takes the right move to win. One wrong move, and Poof, a possible win can turn into a loss. The same thing is true for engineering.

Last time we were thinking about the moves we could make that would guarantee the solution to our getting across the gorge problem was a success. And that included identifying variables, or the conditions or values involved in the problem that can be changed.

But what's the big deal? Why do engineers identify variables when they're designing and testing solutions to a problem? 

(Big Question)

Remember, we can control some variables, like the height from which we drop a ball to see how high it bounces. But there are variables we can't control, like gravity. 

Whether a solution to a problem turns out to be successful or not depends on picking the right way to change a variable. The way something turns out, like whether a solution solves the problem or not, is called an outcome. So, let's see how changing variables can change an outcome by playing a game.

(Investigation) 
The goal of this game is to knock down a pile of fluffy pink marshmallows, and to do that, we'll launch Catbot into the pile using a slingshot. There are two variables here that we can control. We can change the angle of the launch, and we can change how far we pull back on the slingshot.

If we change either or both of these variables, then we can get one of three outcomes. We could knock over all of the fluffy marshmallows, knock over some of the fluffy marshmallows, or miss the pile completely. 

Now, I don't want to be stuck on this level for another month. So I'm going for the complete knock-down outcome. Try number one. And, I miss. Completely. Boo!

So I'm going to change one variable: the angle of the slingshot. But I want to pull back on the slingshot just as far as last time, otherwise, I won't be able to tell if the outcome of the second try is because I changed the angle, or if I changed how hard I pulled. 

So, let's see if changing the angle by pulling back just as hard as before gives me the outcome that I want. And, score! Total knockdown. Now, if I wanted to, for my second try, I could have decided to change how hard I pulled on the slingshot. But if I did that, I'd have to keep the angle the same.

Bottom line, engineers only change one variable at a time. Otherwise, we can't tell why a solution works, or doesn't work.

(Conclusion)

So, engineers don't just identify variables for fun, although it definitely can be. They identify them so that they can figure out which ones they can control. That is, either change them, or keep them the same. 

And that's important to know because changing a variable can affect the outcome, or result, of a solution. So engineers change only one variable at a time when they test a solution, so they're sure of the connection between the variable and the outcome.

Now it's back to my game. I'm coming for you marshmallows. 

Problems, solutions, variables. There's a lot going on with engineering. That makes sense! Engineers want things to work properly, especially when those things are robots and houses.

Okay, listen up, people. I need your help! You're gonna have to help me engineer my way out of a challenge. The challenge being: I kinda dropped my phone down a sewer. I know, I know, I was walking down the street, and it slipped out of my hands, and went right into the storm drain. And, um, I'd kind of like it back.

But that's where you come in. Because this is exactly the kind of problem that can be solved with the help of engineering! 

You know that engineers design and build things, like machines, systems or structures, to help solve problems. And all kinds of problems, not just phones in sewers. How can we cross deep, dangerous canyons? How can we solve complicated math problems if we don't have a pencil and paper?

You can thank an engineer for solutions to all of those problems. Hang gliders, calculators, and the list goes on and on. So now I need your help to unleash the power of engineering to fix my problem.

So, how do we use the engineering process to get my phone back?

(Big Question) (24:35)

First, let's review the process. This is crucial.

One: Define the problem. Okay, I need a way to retrieve my phone from a storm drain.

Two: Consider solutions. There's more than one solution to any problem. So we need to think through different options, and choose the best one. Brainstorm time! I could tie a rope to the drain and lower myself into the darkness. Or I could use a fishing pole to retrieve it. Or I could build a robot that would go down there for me and bring it back.

Now, I don't want to go down there. It's dark, and scary, and the potential for getting sewer water on me is way too high. Next!

What about using a fishing pole? I think my phone will be hard to pull up with a hook. Plus, I won't be able to see where I'm aiming the pole. It seems like this option isn't the best.

What's left? Oh, yeah! the coolest option! Robots are used to do tasks that people can't or don't want to do. And that means a whole lot of robots are being designed for this sort of thing. Not retrieving phones from storm drains, maybe, but flying down into caves, exploring the ocean floor, and even visiting other planets.

So, let's engineer a robot!

(Investigation)

It'll have to be able to fly, and be remote controlled. And, so I can see where it's going, it'll need a little camera. And it'll need a suction cup to stick to the phone and carry it to my loving hands.

Now, next we need to build a prototype that we can use for testing. We need to test, or conduct trials, in order to ensure success. And for those trials to be really useful, we have to isolate the variables.

So, what are the variables of our mission? We've got the depth of the sewer drain. that can't be changed, so it's called a fixed variable. We also have the size and weight of the phone, which are more fixed variables.

Then we have the pieces of our super cool robot. The propellers, the suction cup, the camera. When we finally get to testing the robot, we need to isolate each of these variables, and test them, one at a time, in pretend "missions".  That way, we can see which variables affect how well our robot performs.

Like, maybe the robot can carry something the size of a pencil, but it completely crashes when it tries to hang on to my phone. That would be a failure point. But we can find ways to science around that. If it can't lift something as heavy as my phone, maybe we could make the propellers bigger.

Either way, we'll keep tweaking the variables until we get the outcome we're looking for. Then it's all systems go! Hang on, wet and smelly phone, here we come!

(Conclusion)

Today, we had a challenge. We had to retrieve something from a deep place we couldn't see. And we had to deal with various variables to find a solution. Variables like the depth of the drain, the weight of the phone, and the strength of the propellers that made the robot fly.

Together, we came up with a pretty awesome design solution. But, like I said before, there can be lots of different successful solutions. So here's your challenge: Can you come up with your own solution? What would your robot look like? How would it get the job done and navigate the variables?

Put your brain to work and see what you can come up with.

I just want to thank you so much for helping out in the last episode. I needed to get my phone out of the storm drain, and together we designed a solution. Our robot was just one of the many possible solutions and maybe you had an even better idea at home. If you did please send it my way, I'd love to check it out.

But, I've got a whole new challenge for you. Have you ever just wanted some space to yourself, a place to relax, do your own thing. eat Nutella straight off your fingers and burp with abandon. Yeah, I need that. That is a thing I need. You know what could help? I bet you already guessed it. Engineering. So, how do we use the engineering process to solve this problem?

(Big Question)

Well, first we've got to define the problem. I need a place that is secluded and quiet. I need it to provide privacy and a sense of my own-ness. Sounds pretty great, right?

What about a big box to use as my space? It's secluded, and it can be all my own. Solution-wise, it's a start, but a small one. We need to consider more options. What if I made adjustments to a space I already have: my room! I can hang blankets from the ceiling to help block out sounds from outside. And then I could also sing my head off to T. Swift if I wanted to without bothering the rest of my family.

To top things off, I could add a "Do Not Enter" sign to my door. Like, a serious sign, bold font, all caps. Respect my sign!

Okay, we've got two options. What else? What if, instead of adjusting a space I already have, I create a new space?

There's a word for what we're talking about here: architecture. Maybe we could become not just engineers, but architects: engineers who design buildings. Even though the title of the job is a little different, the process is still the same. So, before doing architecture, we've got to weigh our options and choose the best design to take into trials.

Let's think about the box idea first. It's probably too small. I'd either be squished or be half hanging out of it.

Okay, how about tricking out my room? Again, while I'd feel like I have a sense of privacy, I know that at any point any one of my family members could bust in. And the blankets on the walls will muffle some of the sound, but wouldn't totally block them out.

But, hey, here's an idea: what about a tree house? It would be totally my own. It would be far enough from my house that any weird burps, or loud renditions of Shake It Off wouldn't bug my family. Of course, it would take some work, some architecture work. So, architect activate!

(Investigation)

Let's build a tree-house. It'll have a drop-down rope ladder that I can pull up for optimal privacy. And it'll have windows so I can spot when someone's on the way over and properly prepare myself. I can even use the blanket wall idea from my second proposal to muffle the sound. Of course, I'll need space for lounging, and reading, and dancing around. But before we start building, you know what we've got to do. Build a prototype and test it.

And in order to conduct useful trials, we need isolate the variables. What are the variables of this particular mission? The size of the tree-house we choose, and the weight of the tree house are really important variables, because we gotta make sure the tree-house can stay in the tree.

What about variables when it comes to soundproofing the thing? The number and size of the blankets that I use would be one, and so would be the amount of noise I plan on making inside the tree-house.  

And we have to keep in mind failure points too, like the tree might be able to support little old me in a small wooden tree-house, but if I have a friend or two over the load might be too heavy. That would be a serious failure point.

As for keeping things nice and quiet, maybe my thickest, heaviest blankets can block a soft rendition of You Belong With Me, but they might fail when I belt out Shake It Off, or have a burping contest.

You've gotta test these things. So we'll keep working with the variables until we've got a working design, then it's time to build.

(Conclusion)

Architects use the same process – the engineering process – when planning buildings, from skyscrapers to small family homes. I came up with what I think will be a great tree house, but as always, there can be lots of different successful solutions.

So, here's your challenge: Can you come up with your own architecture solution? What would your building look like? How would it meet the success criteria and navigate the variables?

So, if we've learned anything, it's that engineering is about solving problems. Sometimes, those problems are big. And sometimes those problems are small. But engineers need to figure out the answers to those problems to make new things that will make life easier. Or sometimes just to make us all safer.

If you enjoyed this, check out the rest of our channel, and subscribe!