One of my favorite television shows is Mythbusters. It’s not that I’m enthralled with the myths themselves, but the engineering required prove the myths correct or incorrect (“Confirmed” or “Busted!”).
Recently, I ran across a session by Adam Savage talking about Colossal Failures. Here is the video if you have an hour to kill (really the first 30 minutes is all you need to listen to), or just skip ahead.
(If you can’t see the video above, please view in your browser and not in an RSS reader)
This video is inspiring for me. Adam talks about two instances where he took on a task where he bit off more than he could chew. First, he talked about having to build a baseball throwing machine for department store display. The store was under tight restrictions, and gave Adam less than a week to design, build, and implement this system. Adam didn’t succeed due to dozens of unforeseen issues.
Second, Adam talked about having to build a set complete with a talking ATM. He ran into tons of issues, and didn’t have anything done for the first day of filming. He was asked to go home, and then several days later was asked to come back to get a verbal flogging from the crew.
What does this mean to us?
Failing is a method of learning. Failing is a bit of a subjective term. If you’ve made a mistake, you’ve failed. Some failures are easier to rebound from than others. However, failures are worth it if you learn something from them.
Adam learned that while he does good work by himself, the common trait of both his examples was that he didn’t ask for help. Some jobs are too large for a single person to take on by themselves. Keep a good network around you of people you trust and respect. These people can be lifelines in the most frustrating times of a project. Don’t have a network? Look for a community event in your area.
How have I failed?
I’ve walked into several situations where I had no idea what I was doing. Being a younger developer, I don’t have the experience as someone with 10 or 15 years experience. In my current shop, most projects are on the shoulders of one or two developers. With any project that has come across my path, I’ve picked them up and ran with them the best I could. As Adam said, I was “making it up as I went.” I made several poor decisions that seemed good at the time. When I discovered they were bad decisions, I took immediate steps to fix them. Never leave a bad decision for someone else to clean up. Step up and accept them, and then proceed to make it right. Adam talked about providing money back to his customers. He accepted his failures, and wanted to take steps to make it right (even if it meant giving up part of his pay).
Preventing Failures
Keep a support structure. Join a user group or visit a code camp. Keep learning. Surround yourself with people smarter than you. Listen to their advice (but take all advice with a grain of salt). One person will sometimes succeed, while a team will never fail.
