Snapping Out Of Idea Mode

The other week I came up a brilliant idea. I quickly became obsessed with it, and let myself go down the rabbit hole. I spent the first two days of my Labor Day weekend in a sort of manic state of euphoria, and the idea soon ballooned into a fantasy. Luckily my brother is a much more reasonable person, and quoting me, told me to get back down to earth and just start building it. As a result of this wake up call, I abruptly started being productive instead of living in a fantasy land. I ended up spending the second half of my long weekend actually writing code!

Here's how I did it:

1. Narrow The Idea

The idea I came up with started out small. Then one insight lead to another, and all of a sudden it was this giant multi-phase monstrosity. Unfortunately though, phase two never happens - so I decided to focus on only the first part of the idea. I then narrowed the idea down to an MVP that I could make more or less on my own. Feature wise, what I'll be building is less that 1% of the grand vision - but accepting that reality was the most important thing I did all weekend.

2. Do A Technical Spike

Once I had the MVP defined things became much clearer. I now had the information I needed to sketch out a rough schema, and research how my application would interact with 3rd party services. I didn't let myself get too far into this - I just went far enough to feel confident that I could follow through on this narrowed vision and figure out where I may need help.

3. Stop Making Excuses

I am really into doing TDD at work - and there isn't a single feature in our production code that doesn't have test coverage. While testing has become slightly controversial these days, I strongly prefer developing this way. However, I am still learning how to write good tests - particularly those involving web requests. Seeing as this project is being done by me alone, I decided that instead of worrying about how to write the best tests, instead I'd skip tests altogether and just use this code base as a giant spike to figure out domain logic. If things go well, I'll start over from scratch doing TDD in the future, but I don't need tests to validate the idea, so I didn't let that stop me from coding.

4.Do Small User Stories One At A Time

At work I've learned a lot about how to properly scope out and write user stories. Every Monday we have an IPM (iteration planning meeting) where all the software engineers estimate the stories that the product managers have come up with. We read the stories, discuss the complexity of them, and then come to a consensus of how long they will take to accomplish. Breaking down features this way makes developing them very straightforward. It also has the benefit of creating a sense of momentum and accomplishment since you can literally check things off a list.

Although I've only put in about two weekends worth of work on this project, this strategy of just starting to build has already paid off. I have a bunch of features already made, I feel productive instead of overwhelmed, and I've without a doubt learned more about the domain by making all of the nitty gritty product decisions that have come up along the way.