You Need to Break Things to Make Things – Coping With This Truth

The past week I’ve been working on migrating all of the breadboard-ed connections and circuitry for the OpenExo to a proper circuit board and project enclosure.

So basically going from this:

To something more like this:

In doing so though, I ended up breaking the following things:

• LED light on main power switch. I might have fried it from too much heat soldering wires to large tabs.
• Force Sensitive Resistor tabs destroyed (why do they make them so damn thin and fragile!?)
• 3 surface mount trimmer pots ripped off of the main servo PCB. (This one may not have been my fault. I suspect that this creature may have been involved…)

I think it’s a universal rule, sort of like Murphy’s Law, that things will inevitably brake as you make.

The question then becomes, how do we deal with this? How do we cope with the setbacks and frustrations of building? How do fail fast and keep iterating? Whether it’s building open source exoskeletons or relationships, “the road is long” and full of potholes.

Accepting the fact that the setbacks and the frustrations are part of the equation. You can’t build something without these. With this acceptance comes an increase in tolerance of the setbacks.

How else can we increase frustration tolerance?

I had a conversation with Phillip at sprout the other night about this. In the world of software development and programming, one has to have or be developing a high tolerance for breaking things while building. Software creation is a constant cycle of failing and fixing very quickly. There is a nice tight feedback loop involved with which one can see very quickly when something breaks and that the train needs to be backed up to be worked on some more. In one hour of programming it’s not inconceivable that I could experience dozens of these cycles. Programming naturally builds up a tolerance to the frustrations and setbacks of building. That’s why a project like Scratch, an easy-to-learn and use programming language, is so exciting. Regardless of its users going on to continuously program software throughout their lives after learning Scratch, it inherently develops tolerance to the failures and frustrations of programming and hopefully of other areas of building as well.

Working with others is also a surefire aid to overcoming the frustrations of building, breaking, debugging and fixing. Several friends and I recently took part in a data analysis and algorithm creation challenge sponsored by the City of Boston. It was trying at times. The fact we were working on it together is what made submitting a solution possible. If it was just me working on it, I’m not sure I would have made it that far working on it alone.

Also recently I was helping my friend put together a bike. When it came to setting up the rear derailleur, we were having trouble getting it to shift to the lowest cog. We were going to call it a night and just keep it as is but then, I believe through our collective will, we soldiered on and through trial and error finally got it to shift!

Building things ain’t easy. But we can set ourselves up to better handle the friction and push through the resistance.