Don’t Worry About Where To Start. Just Start.
When writing a blog post or an article, the most horrifying thing in the world is the blank page. Where do I start? How do I make sure to capture interest to keep people reading? Should I talk about ??? or ??? and what about ??? … analysis paralysis, anyone?
The same thing happens in software. Open visual studio, or vim, or whatever editor of your choice. Maybe create a project structure or have rails generate it for you. Then … CRAP?! WHERE DO I START?! What feature do I write first? (well, we know what not to start with, at least) What test do I write first? How do I know if I’m starting at the right place and delivering everything that I need, right away?!
I’ve run into this more times than I can count, on both writing blog posts / articles and writing software.
The Secret Sauce: Start, Realize, Scrap. Repeat.
The secret is not to actually think about where to start. Just start. If you have an idea of what you want the system to do, start writing that idea out in the code. I guarantee that once you actually start writing the code, you’ll realize where you should have started. Great! That’s exactly the point! Writing that first few lines of code or that first automated test will expose all of the things that you don’t have in place. You’re brain will quickly sort through them and figure out “oh, i need to have this core piece in place, first. but, i can do without these other things if I just hard code or make assumptions here, for now.” AWESOME! That’s exactly the kind of response you want from your brain! Once you’ve had these realizations, just toss what you started with into the trash and start over. Or if what you started may actually have value, dump it in a code snippet or source control somewhere so you can grab it later. Chances are, though, that what you think may have value will be completely wrong by the time you get to it.
For example, look at writing a time tracking system. The goal is probably to report who is spending what time, where. So, start by spec’ing out the report (via code of course – test-first style). You’ll quickly realize that it’s hard to report on data you don’t have. However, starting by looking at the end goal will inform you on what the rest of the system should look like. “Oh, I need to show X, Y and Z on the report… I didn’t realize that. I need to build A, B and C to make sure I can show what they need here”. From the end-goal, you can work backwards and figure out where to actually start.
Sometimes you’re not that lucky, though. Sometimes you need to start working before you know what the end goal is. That’s fine, too. Just start working. The key here is to get feedback as early and often as possible, so that you can begin to get a better idea of what the goal is. You’re likely going to throw away a lot of what you start with, in this scenario, so be sure to build things as quickly and cheaply as possible. There is a cost to learning by doing, and we want to minimize that cost as much as possible so we can get to doing something of real value.
On Writing
Incidentally, I apply the same thing to writing blog posts and articles. I just start writing with whatever pops into my head, whether or not it’s a good introduction (and it never is – even this blog post has gone through two iterations of introduction and was originally part of another blog post). Once I have something down on the blank screen, I realize what I actually need in order to set up the correct context. Then I go back to the top of the page and start to flesh out the context. Eventually, I have a starting point for the post / article, but it’s never the thing I started with.