Principle 4.8: Experiment to illogical extremes! (and pull back according to taste)

Back when I was on a robotics team in high school, I was absolutely convinced there was a single determining factor that could tell you which team would have the best, fastest, most agile, most brilliant robot of all the F.I.R.S.T. Robotics Competition entries -- it was always the team that could create the most prototypes. Whether it was the team that could create the most versions of their robot before finalizing a competition robot, the team with the most modular robot, or even the team that did the most prototyping design exploration, the teams that tried the most things always ended up being most successful. This thus frustrated me when our team would design by spending a few days talking and debating ad nauseum about different designs. How can you tell if you never try?

Long after my robotics days, this principle has long stuck with me, even if I struggle to adhere with it. No matter what it is -- an art piece, an engineering project, or an essay -- the more I can iterate, the better it turns out. It almost feels like a hack in its simplicity -- maybe it seems incredibly obvious to others, but I am constantly astounded by the efficacy of iterating over even meticulous design. It's a gorgeous design philosophy -- one that rests on inspiring exploration and play, one that encourages extreme failure. It's a design philosophy inspired by the natural course of evolution that have perfected us a species and world.

It's equally astounding how hard it is of a principle for me to follow. It seems like a ton more work to design something 4-5 times rather than once (even though, given the results, it really isn't). For example, HW 2 of this class sits in a half-made state currently, and I'm expecting to pull a long night Tuesday to get it done. Because I am a dumbass.

So here's some maybe more attainable promises I'd like to make to myself to encourage design experimentation:

1. Source control everything. Even though we think of Git as a tool used only for bigger projects outgrowing a single person, its ability to branch and checkpoint things quickly and easily make it perfect for rapid prototyping. In hindsight, I would've saved myself headaches on even tiny projects had I had made a repo.
2. Create MVPs and checkpoints. Just like the outline to a story, "minimum viable products" let me assess the state of a project as a whole and prioritize what should get done first (or at all), and what should I change, moreso than perfecting one little part and moving on.
3. Sketch. "I'm coding it myself so I just will translate it direct from my head, right?" If theatre has taught me anything, it's that you can't see everything in your head. Drawing forces you to think about the way things piece together that you'll easily overlook if not sketched.
4. GIVE YOURSELF ENOUGH TIME! Self-explanatory. MVPs will help.