Sometimes the hardest place to find motivation is at the very start. Thinking about code is easy. Software always compiles perfectly in our heads. We don’t obsess over the hundreds of minor obstacles we’ll face along the way. But once we commit to actually writing code, the entire game changes. Motivation can fade quickly.

The experience of writing software is not too different from writing this book. I spent far more time thinking about what I wanted to write about than actually writing. Writing can sometimes be a soul-sucking game of uninspired lines, mental blocks, and fatigue. It’s hard to keep the juices flowing when I run into a gauntlet of personal demotivators.

Natalie Goldberg’s Writing Down the Bones [Gol05] is an entire book on motivation for writers. She offers a simple tip for getting started. Instead of focusing on the big opening, start writing somewhere in the middle of the story. Begin at the point that’s most interesting, right now. Don’t try to write from the very beginning.

We spend so much time concerning ourselves with the big, attention-grabbing opener when, in reality, it’s a rather insignificant portion of the entire story. There’s a considerable amount of work after the opening paragraph. That’s the approach I took for this book. Nothing was written linearly. In the beginning, I focused on a specific topic when that topic inspired me.

We can apply the same concept to building software. We don’t have to start with the home page before the subpages or with the database before the business logic. Instead of starting software at the beginning, we can start at the place where we are most engaged. We have that luxury while many other builders don’t. Unlike building houses, cars, or anything physical, we do not need to start anywhere specific. We can always refactor later. We may take a few circuitous routes, but if they are inspired rather than labored, we’ll get more good work done faster.

So, if you have the freedom to be greedy about where to start writing software, be greedy. Pick a feature you find most interesting and work your way out from there.

This is especially helpful when you’re about to embark on building a big piece of software. Rather than spend three days formulating a timeline and release schedule, commit those days to working on the part of the application that most interests you. A week in, you’ll know how much motivation you really have, and you’ll have a far better idea of when the other parts can fall into place.

If you find yourself quickly losing steam, you can cut your losses then. Still, more often than not, you’ll find the daunting task of building software not so insurmountable. Three solid days (or a week) of building an application, and you’ll know a lot more about what you’re building and how quickly the rest can get done. Putting together a realistic timeline is much easier after you have a bit of inspired work under your belt.