I get a lot of emails these days from fellow programmers with concern, distress, or depression. They're not looking for technical solutions or advice (which is good because I have neither), they're just not where they thought they'd be and are reaching out for "something".
I try to make a point to answer all of them because they're my most important emails. To me, the ones and zeroes inside my fellow humans' heads are far more important than those on any computer.
"1. What are some qualifications of a computer programmer?"
The two most important qualifications are a love of details and a simultaneous appreciation of the bigger picture. You have to understand the landscape that your software will fit into. Then you have to be willing and able to dig down deep and be comfortable building stuff at the lowest level of detail. This takes a great deal of logical thinking, attention to detail, and personal focus.
"2. What is the best part of being a computer programmer? The worst? The most challenging?"
Oh how I wish I could share the joys of programming with non-programmers, but that would be like describing the color blue to a blind man. You just gotta experience it yourself. There's nothing like putting something together and seeing it work the first time. Even if it isn't perfect, that first output is better than sex. Still makes make holler and jump out of my chair! (The output, not the sex.)
I would strongly suggest trying out one of the many "Build an App in x Days or Hours". Grab a book or something on-line. They're everywhere. Follow the instructions and do what they say. Build your app.
One of two things will happen: you'll either feel like I do and you'll be hooked. Or not. Either way is OK, but not giving it a shot this year would be a shame.
The reason you're not passionate about your work is because something is missing. Identifying what is missing is your first step in determining where to go from here.
I have been in a similar situation. Always working. Important stuff. Sometimes cool, often not. But something was always missing.
Architecture not rigorous enough. Inadequate data base design. Insufficient requirements definition. Lousy code base. Unable to scale. Unable to expand or handle completely new features. But I always managed to make it work anyway. Then it occurred to me, if such mediocre systems were able to produce adequate results in commercial environments, what would be possible with great systems?
I'm not going to try to motivate you, because only you can motivate yourself. I'm just going to share my perspective that might shed some light on your issue.
I had the same problem in college until a fraternity brother who had graduated 2 years before told me something I had never thought of. He said, "You may never have a better opportunity to explore new things. Once you settle down with a career and family, all your time will be spoken for. So try everything! How will you know who you are and what you're interested in unless you experiment?"
Some of the best advice I ever got, and since I was a sophomore at the time, I tried as much as I could for the next 2 1/2 years. I still majored in math and became a computer programmer, but I did a lot of stuff that I simply don't have time for today. And I miss a lot of it. Back then, I thought humanities was boring, but now I wish I had a few days to curl up with a good book.
"I'm really just a mediocre programmer with really good domain knowledge"
Your problem is that you have no problem. Let me explain:
I believe that the quality of a programmer is not how much you know, but what you can do with it. So if you have "really good domain knowledge", then you probably aren't a mediocre programmer at all, you're probably a good programmer or even better.
You are not burnt out and I have proof. This discussion. A truly burnt out person would not have even bothered. (Kinda like claiming you're over your ex-girlfriend but still wonder what she's doing all day long). The fact that you asked is not an admission of giving up; it's a cry for help. You still really want this.
I go through what you are experiencing all the time. There are days when I can't stay awake at my terminal. Sometimes I hit a road block and wonder how I'll ever get by. I usually step away for a time, but here is my real secret:
Pick one little thing that needs to get done, no matter how small or unimportant it may seem. If I'm really down, I pick some mundane task like refactoring 25 lines of code, manually updating 50 records, or even changing some naming conventions. But not something big like solving a client-server architecture problem. That's the reason I'm already down. One other thing - the task must be in the heart of your project; cleaning off your desk or reading a journal don't count. Then do the task. Completely. You'll feel a little better, I promise. The next day, do it again, maybe with a slightly bigger task. And again. And again. Who knows, you may be feeling a lot better before you know it.
Here's an idea: get a job. After a year, you'll have plenty of ideas, maybe even one of your own.
I hate to rain on anyone's parade, but the thought of begging for ideas is so alien to me. The best predictor of your success in any endeavor is your own determination. With someone else's idea, you're much more likely to bail at the first sign of difficulty. Once you get a little real world experience under your belt, you'll find plenty of opportunities to encounter something for which you'll have real passion.
Your chances of success increase astronomically when you're working on something you "have to do". The only way to know if you "have to do it" is to have a little background and experience with it. Trading ideas like commodities seems like the least likely way to find something you'll be passionate about.
I hate to break the news to you, but "systems analyst" is a job title that's pretty much exclusive to the enterprise world. For the most part, startups don't really have a place for "business/system analysts". Let me explain:
School of Thought A: Call it SDLC (Systems Development Life Cycle), the project approach, or the waterfall approach goes something like this: Define a need, conduct analysis to answer the question "What", conduct design to answer the question "How", program, test, program, test, compare to the Functional Specs from the Analysis Phase, conduct User Acceptance Testing, promote, deploy, repeat anything as required. The more rigorous the documentation and project management, the better.
School of Thought B: Build something ASAP. Get it out there ASAP. Get feedback ASAP. Iterate indefinitely.
I have always been a "fearless" programmer, but never realized it until recently. Here's how:
"Fear of not knowing the best way to do things (best practices)."
The sooner you realize that there is never a best way of doing anything, the sooner you can release this silly fear. Some ways are better that others, but "any way" is better than "no way". Just get the thing done. Later, when you refactor, you'll have the best of all worlds: code that did the job right away, a better way of doing things, a satisfied customer, and a great learning experience.
Here's an idea: find someone else with a problem and work on that. This works especially well if the someone else is in business, very busy, and has some money. Chances are better that your solution to their problem won't have much competition: if it did, they would have already gone with it.
I know this is the opposite of "scratch your own itch", but I always found that advice overrated. I have always been much more successful scratching other people's itches.
This is the biggest mistake I made in my twenties, and it's such an easy mistake to make that I continue to make it now even though I know better. I continually have ideas popping into my head. And I act on many of them. So much cool stuff. If only I can get this working, it will change the world. And I love being in this mode. It's so much fun. And it can lead to great things:
But you have to know when you're going too far and wasting time, money, and energy. At some point, you have to find a customer. Any kind of customer, just someone besides yourself who wants what you're doing.
I wrote a code generation system that put together nice tight little apps, with UI, database interface, batch processing, and a report generator. It came in really handy for the simple apps everyone seems to need every once in a while.
My cofounder and I sold a few simple apps and then he found an opportunity in a large company for a much more sophisticated app. He quoted based upon the already demonstrated performance of me and my little tool.
Unfortunately, every single unusual thing we ran into was not generatable by the tool. So I had a choice, hand code or upgrade the tool to generate it.