There's room for everyone

One of my biggest problems to date has been that I get discouraged when I look at what's already been accomplished in this field. When you are sitting down to work on a trivial idea you've come up with, it's easy to stop and say "Wow, do you have any idea how complex the GCC compiler is? What the hell am I doing with this simple program?!" It's an easy trap to fall into, but a deadly one.

We can't all be John Carmack, Bill Gates, Linus Torvalds, etc etc etc... but that doesn't mean we should find a new profession. Implementing those trivial ideas are essential for growing as a developer, and if you don't go through that process you'll never get to where you want to be. John Carmack didn't roll out of bed one day and write a 3D game engine. He had years of programming experience. Granted, he's a very intelligent man when it comes to math and science, regardless of his programming abilities, but again, he's one of the many exceptions. Most people simply aren't that gifted. However, if programming is the field you want to be in, you can work hard enough at any area of it and become proficient.

The only remedy I've found for this issue is that when you have an idea for a piece of software you'd like to create, don't "Google it". Most ideas that most of us have will be based off of some piece of software that is already in use. Going to Google to check out some of those applications is only going to worsen this issue. I like to get off of my computer, grab a pen and paper and start designing the system "offline". It's actually a lot more productive than sitting in front of your monitor, and you can't get discouraged if you pretend that nobody has ever made this piece of software before.

Going back to the trivial nature of some of the programs we may write... Just as programming books start you off simple before branching into pointers, objects, templates, data structures, etc... you should be doing that with your code. Now, this tends to happen naturally anyways since you can't well write code involving things you don't yet know how to do, but I know I've certainly tried. Not to say that it's always a bad thing to test new waters, but you shouldn't really make a habit of doing something until you understand it. A book progresses rather quickly, but your projects should progress much more slowly in terms of the complexity of the underlying software. This is paralleled by the fact that you cannot simply read a programming book front to back as if it were a novel, it must be an interactive experience in which you are typing the code from the book, doing the examples, doing the projects, etc... The more time you spend building the complexity of your projects up, the better off you'll be in the long run because you'll have an expert-level understanding of everything you've done, which will then make the transition into the really advanced stuff easier.

A great way to do this is to develop your software idea just like a mainstream piece of software. Have iterative releases of your application, adding new features and refactoring code along the way. Make a habit of creating a "TODO" list after each release so that you have specific points to focus on. Ideally you'd have setup some sort of road map at the outset of the project, so you should already have some direction in this regard. Set stern, but reasonable deadlines for your releases, manage a blog documenting the process, invite others to use your applications (friends are fine, as long as they will give honest feedback), etc... Doing all of these things will keep you excited about your project, focused on your project, and you'll absorb a lot more of the techniques than if you just fleshed out your initial idea and say "Meh, that's cool I guess...".

Hope this helps.