YouTube: https://youtube.com/watch?v=OyTEfLaRn98
Previous: A Change of Scenery: Crash Course Kids #17.2
Next: Defining Success: Crash Course Kids #18.2

Categories

Statistics

View count:367,624
Likes:1,850
Comments:0
Duration:03:40
Uploaded:2015-07-07
Last sync:2024-04-01 04:30

Citation

Citation formatting is not guaranteed to be accurate.
MLA Full: "Defining a Problem: Crash Course Kids #18.1." YouTube, uploaded by Crash Course Kids, 7 July 2015, www.youtube.com/watch?v=OyTEfLaRn98.
MLA Inline: (Crash Course Kids, 2015)
APA Full: Crash Course Kids. (2015, July 7). Defining a Problem: Crash Course Kids #18.1 [Video]. YouTube. https://youtube.com/watch?v=OyTEfLaRn98
APA Inline: (Crash Course Kids, 2015)
Chicago Full: Crash Course Kids, "Defining a Problem: Crash Course Kids #18.1.", July 7, 2015, YouTube, 03:40,
https://youtube.com/watch?v=OyTEfLaRn98.
So, how do engineers even figure out what problem needs to get fixed? And what's the difference between identifying a problem and just complaining about something? In this episode of Crash Course Kids, Sabrina talks about how we can all be better engineers by understanding what problems we want or need to solve.

This first series is based on 5th-grade science. We're super excited and hope you enjoy Crash Course Kids!

///Standards Used in This Video///
3-5-ETS1-1. Define a simple design problem reflecting a need or a want that includes specified criteria for success and constraints on materials, time, or cost.

Want to find Crash Course elsewhere on the internet?
Crash Course Main Channel: https://www.youtube.com/crashcourse
Facebook - https://www.facebook.com/YouTubeCrashCourse
Twitter - http://www.twitter.com/thecrashcourse
Tumblr - http://thecrashcourse.tumblr.com

Producer & Editor: Nicholas Jenkins
Cinematographer & Director: Michael Aranda
Host: Sabrina Cruz
Script Supervisor: Mickie Halpern
Writer: Kay Boatner
Credits...

Executive Producers: John & Hank Green
Consultant: Shelby Alinsky
Script Editor: Blake de Pastino

Thought Cafe Team:
Stephanie Bailis
Cody Brown
Suzanna Brusikiewicz
Jonathan Corbiere
Nick Counter
Kelsey Heinrichs
Jack Kenedy
Corey MacDonald
Tyler Sammy
Nikkie Stinchcombe
James Tuer
Adam Winnik

 Introduction



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?


 The Kinds of Problems Engineers face (0:23)


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.


 The Engineering Process (1:03)



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 ("How does an engineer define a problem?") (1:27)


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 (1:51)



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 (2:37)



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.