Monday, July 20, 2009

Getting Over The Initial Excitement Hump

So, you get a new idea for a project. It could be a game, a helpful desktop application, the next big iPhone application, etc... Your brain is working in overdrive with great ideas and you can't wait to start coding. This is normal, and it's great. No better feeling than fleshing out a brand new piece of software that you've come up with.

Chances are, you'll hop right into your IDE and start fleshing up some quick and dirty code to get the thing off the ground. You're probably too excited to bother with design documents and all of that boring stuff. This is fine to an extent, but before you get too deep into your quick proof of concept, you are going to have to make some formal outlines for your project if it is to be of any modest size.

Now that the boring stuff is done, (and unless you are working for a company or making a very large application, you shouldn't have had to spend too much time doing that boring stuff) you can get back to the exciting stuff: programming! At first, things are great. The excitement level is just as high, if not higher than it was at the outset of the idea. But sooner or later, something terrible happens. You lose that excitement and in turn you lose your motivation to work on the project anymore. So, what happened?

It is hard to say for certain, but it seems to be human nature, more specifically our tendency to prefer instant gratification, and who can blame us? We just came up with a new killer app, and we want to take the vision in our head and make it come to life. Such is the attraction to this field to begin with: making dreams and ideas into reality using our skills. However, this comes at a price.

Once you start getting deeper and deeper into your application, that buzz subsides and you are brought back down to Earth a bit when you have to go through all of the mundane tasks to convert your dream into snippets of source code. Of course, the scope of your project as well as the tools and methods you chose to use to create it will have a huge effect on these mundane tasks (converting between data types, proper design patterns, reusable code, GUI, etc...), but at the heart of the matter it is still the same issue: How do you get back that initial excitement after you drop off to the other side of the hump?

I'm not sure I have a good answer for that as I suffer from this situation myself in nearly every project that I start. I find that unless I complete something within a few days, this is almost certain to happen. One issue that plagues me is that I tend to have 3 or 4 of these "killer" ideas floating around at any single time, so once the initial buzz fades during the development of one idea, I go craving my excitement "fix" by starting one of the other ideas, and so the cycle continues. It is an easy trap to fall into for sure.

Income could certainly mitigate these effects. Professional developers encounter these same issues, and maybe more so because they are most likely developing someone else's idea, so that initial rush of excitement may never be there. However, it is their job, so they have no choice but to keep plugging away. On the other hand, if you are working on your own personal project in your free time and you have no financial stake in the application's completion, it can be much harder to get out of the rut. Sometimes just wanting that dream realized isn't enough, as I'm sure we've all come to find out all too many times.

I think the best solution I've found is balance. Although, there is a very fine line to walk. Initial surges are great, but we must take advantage of them and get as much done in those first few days or weeks as possible. Lay the ground work while your motivation is at its highest. Document your code extremely well, otherwise you'll lose time later trying to figure out what the hell you were doing when you revisit the project. That's where the balance comes in. Take breaks. Work on other projects for a few days, but always keep your main project fresh in your head. Ideally, your side projects should be very small pieces of software. Maybe proofs of concepts or something along those lines. It shouldn't be another full-fledged application. During these breaks though, keep your main project fresh in your head. Look over your source code once a day, revisit your design documents, add TODOs to the code if you happen to notice something, but don't add any actual code.

I believe these breaks will allow your mind to rest a bit and will prevent you from getting tired of a project. The side projects will keep your skills sharp as well as give you that initial buzz of excitement from working on something new, and hopefully this excitement can carry back over to your main project.

If anyone has something that works for them, please share. These are just some things I've found that help me.

Cheers.

No comments: