Last week, I talked about three conventions that can help you beat procrastination and get your new Rails project started. By now you should be less overwhelmed by the work in front of you. But you still have a tough choice to make. Which code do you write first? Authentication? The part that talks to Twilio? And how would you even begin to work on the forum post recommender engine?
Yep, at some point you actually have to write the code, and to do that, you need a place to start.
What makes a good starting point?
First, you should take a few minutes and think about the system you’re going to build. Focus on end-to-end paths and what kind of resources those paths call out for. Don’t go overboard! Once your system becomes a little clearer, you can look for paths that fit into these categories:
1. Is this core to the project?
By core to the project, I mean the path that you’d talk about if someone asked you to describe your app in 30 seconds. If you’re working on forum software, posting and replying to a topic would be core to the project. If you’re working on a push notification service, registering a device and sending a notification to it would be a core interaction.
Core interactions are good to write early, since you can start playing with your app with the least amount of effort up front. You’ll have a good foundation for building new features. And that will make the next thing you work on even easier to start.
2. Can this stand on its own?
You could look for features you can write without learning new libraries or new APIs. If you start here, you can stay in the code without constantly switching to a documentation window. You don’t have to switch between “writing mode” and “learning mode.” By avoiding interruption, you’ll also be avoiding opportunities to procrastinate.
If you’ve ever forced yourself to fix an easy bug first thing in the morning to keep from getting stuck in the email-twitter-reddit-email loop, you know how important it is to start in the right mindset. This is a great way to get in that mindset early, and stay there.
3. Does this seem really risky, hard, or complicated?
These can be dangerous to start on. Complicated features usually need more planning, which means more opportunity to get stuck. So how could this be a good place to start?
Developers crave solving interesting problems. Attacking a hard problem can be the most intrinsically motivating way to get started on a new project. Plus, the extra challenge will give you a better chance of hitting flow, which is where the good stuff really happens.
So, which do you choose?
It doesn’t even really matter which of these approaches you choose! All three are good starting points with side benefits, and will point you in the right direction. So pick one (at random, if you need to), and see how you like it.
Because no matter which approach you pick, the secret is getting the TDD flywheel spinning as early as possible, so the momentum can help carry you through to the day you ship.
Do you use any of these approaches when you start a new project? Or do you have your own favorite place to start a new app? Leave a comment and let me know!