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.

About Derick Bailey

Derick Bailey is an entrepreneur, problem solver (and creator? :P ), software developer, screecaster, writer, blogger, speaker and technology leader in central Texas (north of Austin). He runs - the amazingly awesome podcast audio hosting service that everyone should be using, and where he throws down the JavaScript gauntlets to get you up to speed. He has been a professional software developer since the late 90's, and has been writing code since the late 80's. Find me on twitter: @derickbailey, @mutedsolutions, @backbonejsclass Find me on the web: SignalLeaf, WatchMeCode, Kendo UI blog, MarionetteJS, My Github profile, On Google+.
This entry was posted in Analysis and Design, AntiPatterns, Bootstrap, Goals. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • I have similar experiences in writing blog posts. At first I think about how to separate the topic into chapter and how the information of one chapter relates to the others. That way the order of the chapters comes out automatically. I didn’t think about the introduction yet and I avoid it with a purpose. I see the introduction as a place where I prepare the reader for the rest of the post. The introduction is not only a place where I tell what the post is all about but also provide helpful information (i.e. web links) which prepares the reader for things to come. What kind of information that is in specific crystallizes when everything else is written. I read my blog post again and again and suddenly it pops into my mind, “oh I should tell something about that, too”. Sometimes this flows into a foot note, sometimes into the introduction. It depends and I choose what fits best.

  • Joshua Sigar

    Did I read this correctly: from idea in your head straight to code editor?

    What I do is usually list, expand, and prioritize features. Also I sketch nontrivial graphical user interface, which could suggest features. So, basically, it’s a process gathering requirements, designing and defining the scope.

    And then I could start writing code (TDD-style or not).

    Of course I’m free to re-iterate the first steps again but it’s somewhat minimal and I could write code uninterrupted.

    • Depending on the situation – whether it’s a client project, or something that I’m doing on my own; how much I already know / understand about the subject, etc – I’ll do a lot of whiteboarding, writing and idea sketching, too.

      That doesn’t solve the problem of where to start, IME. It informs how I approach the thing I start with and it’s often a necessary part of understanding the system that you are gong to build. It may even help you see the general area that you should start with… but the blank screen is still terrifying to me, at least. Which test to write first… which specific part of which specific screen or class or report or whatever…

  • Andy Rose

    Good advice which can be applied to many things in life be it writing code or tidying the garage. Sometime, though, a little pre-planning will help.

    • planning is almost always necessary. that doesn’t negate the problem of looking at a blank screen, wondering which test or which line of text to write first.