Currently hanging out on a boy’s weekend with my 8 year old son (while my wife is out of town), and we’ve been spending some quality time watching a classic kids’ engineering show: Destroy, Build, Destroy! If you haven’t seen the show (and I’m pretty sure most of you haven’t given the limited two year run and subsequent horrible reviews), the premise is interesting. It’s a game show that pits two teams of teenagers against each other in an engineering challenge. The general set up is something like the following:
- The teams are given an end goal, like build an air-cannon assault vehicle and shoot more targets than the other team in a time-limited window. They’re presented with resources (like an old SUV), which is then destroyed for parts.
- Each team is then given time and additional resources to build their project. Halfway through the build, there’s another mini challenge (the setback) which allows for one team to sabotage the other.
- Teams continue the build after the setback challenge, and then compete. The winner gets to destroy the losing team’s creation.
It’s a fun watch, and great for kids with both problem-solving and destructive mindset. For adults, there are some additional lessons that come to mind, particularly for those of us in the software industry. Below, in no particular order, are some of my observations and inspirations.
 | Start with end concept in mind. Concepts are functional, but aren’t perfect. The ultimate goal is to build something that achieves a a specific set of objectives (delivering value) within a certain time frame. Identifying the objective first, and then starting with a simple design, allows for flexibility based on whatever resources you have. You’re not always going to have ideal resources. In the show, the teams are given the remnants of a previously successful project and a few additional resources; however, they’re always starting with less than ideal circumstances. Designs have to be a minimal viable product (MVP) in order for them to succeed in the competition. Good communication skills can often compensate for technical limitations. They’re not a complete replacement, but teams that communicate well with each other can often work their way through technical challenges faster than teams that have strong technical skills but poor communication. Small fixes often add up to big solutions. Usually on each team, there’s at least one person that is slow to contribute. Encouraging them to “do something… anything” often helped lead the team to victory. They may not have contributed as much to the build as other people did, but participating the whole time often gave them the opportunity to perform best when it really counted. Setbacks happen. Sometimes they’re avoidable, but sometimes they’re not. Sometimes they give you the opportunity to rethink the MVP, and come up with alternative solutions. Sometimes they derail you completely. Figuring out how to handle a setback mentally is just as important as handling it technically. Have fun. It’s a competition, and there’s money on the line for these kids. However, there’s something unabashedly FUN about both the creation and the destruction of engineering. No matter the outcome, enjoying the moment is a wonderful activity. |
You can watch the show on YouTube; hope you enjoy this lost classic. https://youtu.be/77atHNtNcwY
Great post! I agree with your line if thinking for for kids and software developers!