I remember when I was a junior/intermediate developer. I was brave, cocky and loved taking risks. The less I knew, the more I was willing to stick my neck out. I’d do things just to prove it could be done; there were no shortages of challenges. But with more experience comes more caution and less risk aversion. This was especially true as I became more aware of the ramifications of my actions. I couldn’t fall back on ignorance and lack of experience as an excuse.
But when it came to thinking up new ideas for products, I couldn’t think outside the box. Nor could I think of anything new and original. For every idea I imagined, I already had an opinion. Either it was too simple, or would get done before I’d have the time to say “boo”. I always found something to demotivate me. I didn’t know how to come up with ideas. What problem could I solve that? What wrong was there in the world that required my particular brand of skill. The only thing I was becoming sure of was that I needed to put myself back in my shoes as a junior developer. Find something that would light that fire. I wanted to take a risk into the unknown.
I don’t believe in pitfalls. I believe in taking risks and not doing the same thing twice.
– Guy Laliberte
Somehow, perhaps after having watched a TED Talk. Or maybe after reading an article in Fortune. I came up with something. It’s super simple. It’s simple enough that I can state it’s purpose in one sentence. It’s also in a field I know little about, but I think has potential. But because I know little about it, I can come at it with a fresh perspective. And because I know the high-level goal, today I have something aim for.
So to keep things not complicated, I decided to put a one year plan together. The purpose of the plan is this. 1) Develop the software platform keeping in mind the overarching goal. No specifics or details beyond something functional. 2) Once I have something working, do research in the idea. Breaking it down into chunks. Categorising everything as a go. 3) Normalise all the information and determine the best direction to go. 4) Once I know enough, develop the features that would best fit in the platform. 5) Develop the features in iterations.
At some during step 5, I’ll have to determine when I can release the platform in beta. It would have to be at some point when the features are still high level enough so users aren’t driven away by a rigid system. But still useful enough to drive users’ focus in the direction I want the platform to go.
So we’ll see how this plan works out. Stay tuned for updates.