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.


Curious Observation About Engineering

For a while, I've wanted to develop a small application that I can use to sync my mp3 player with my computer, or vice versa. It tends to be a fairly common thing, as I'm always adding/removing songs from one or the other. It also comes up a lot if I do a new install of an operating system and I'd like to have some music on there temporarily; it's just easier to transfer it from my mp3 player rather than another file system on a hard drive somewhere.

Yesterday, I started thinking about this application again, and today I began fleshing out some things on paper. I was going over things such as how you determine if two files are identical (despite file name, file size, etc... which don't really tell you anything about uniqueness), what sort of sync behavior should be used (mutual-add, mutual-add/delete, etc...), and how to handle the more real-life situation where you've got a number of folders with sub-directories as opposed to just a list of files. I had all of these great ideas of how to solve these problems, and my brain was working overtime for the problems I didn't yet have an answer to. I was looking at source code for some common core UNIX file utilities like diff, cmp, cp, etc... looking for pointers...

And then it happened. I realized that I didn't need to make any sort of application. I realized my "problem" was non-existent. Why, you ask?

With the use of the built-in UNIX 'cp' command (file copy), and a few command line switches, I could achieve my sync behavior.

cp --recursive --update


--recursive handles the issue with multiple levels of directories, and --update handles the issue with determining if files are identical or not, as well as handling the mutual-add syncing.

The curious part comes in with my reaction to this discovery: I was totally bummed! As an engineer, you tend to want to have these problems to solve. Then, you are excited once you solve them. However, realizing there was never a problem to solve in the first place doesn't bring that same excitement, it in fact has the opposite effect.

It does illustrate a few important concepts of engineering though.

1. Don't re-invent the wheel.
2. Keep it simple, stupid!

Some engineers have a tendency to want to use complex or advanced solutions to problems which don't need them. I myself was bummed that such a simple solution would solve this problem, as I had envisioned a much more "sexy" method. This only leads to trouble down the road, and if at all possible, it's better to realize there's a better way to do something before you've finished doing it the wrong way.