What do 24-Hour Theatre Project, 48 Hour Film Project, and a Hackathon all have in common? They’re an adrenaline-fueled rush to see what you can produce in a short period of time. They also help fuel creativity and rejuvenate the desire to learn more about one’s discipline. By creating an absurdly-short time period in which a thing will be worked on, we both allow ourselves to work on a project only for that first “honeymoon” period where we’re enjoying every bit of it and allow for creativity, even at risk of mistakes. If you work on a script, for example, over the course of three years, you’ll not only face periods of apathy but also feel pressure to produce a good final product. A project into which we’ve invested a great deal of time becomes valuable, and, to feel justified in having spent so much (time, energy, money, what have you) on it, must be well-received by its intended audience. By working on a project for a brief but intense stint then having the option to drop it if it’s not working or continue if you really like it after the flash development period, we give ourselves the freedom to explore, to enjoy, and to expand into areas of lower confidence.
I’ve found that my personal projects unfailingly benefit significantly when I reserve some weekends for periods of flash development from which valuable new learning can be folded into the important stuff post-experimentation. This development of new knowledge in a low-risk environment that I can pull back into my higher-stakes project is a critical part of my learning and growth process, and I’m very much enjoying this in my attempt to create an English as a Second Language study program based on crowd-sourced, peer-reviewed pictorial definitions at MHacks this weekend. While I’m hoping to develop something that can eventually become a functional app, it’s a project too big to be really finished in one weekend, especially considering that I changed my strategy eight hours in, threw out the gui I had built as a web app, and began writing it for Android with Facebook API (neither of which I’ve used before). Because I’m investing, at absolute maximum, thirty six hours in any one aspect of it, though, changes like that are entirely possible. Additionally, this being a hackathon instead of a normal development environment allows me to produce a product for myself with the features I find important and in the timeframe I feel suitable.
While I might not produce a fully functional app and I certainly won’t be winning any awards, I’ve already worked out some new strategies for interface design and userflow mapping, and I’m only a third of the way in about to start learning a new API! Hooray, learning opportunities!