You know, it's hard to believe it, but at some point parents forget what it felt like being a teenager, and senior developers being junior. I know I'm going hard against the grain here, but I think you're better off doing as jblow did, not as he says.
Priority #1: survive, life gets better. In any organization that's large enough to have a pecking order, sh*t rolls downhill. Your CEO meets the customer's CEO and sees some fish on the office walls. He decides that an aquatic theme will increase sales, and passes it on to project management. PMs are slightly bemused, but figure out some web pages that can feature animated fish, and vet the idea with senior developers, who agree it can be done before the next trade show. The senior developer creates the fish_type, group_of_fish and fish_animation tables, grabs a few morsels that are fun to implement (new web technologies, yay!), and passes the rest to you. Congratulations, you're the junior developer at the bottom of the scrap heap! You not only have to deal with all the crap nobody else wanted, but will also explain it as lines of code to your computer. And, after re-implementing several times to address all concerns from meetings you were never invited to, it turns out the customer's CEO had borrowed the office and actually hates fish since choking on a herring bone 32 years ago.
How do you deal with all this? Well, maybe quitting will find you a better job as a junior developer. (Also, maybe an uncle you never knew suddenly leaves you his fortune.) But realistically, the way most people do it is the same as jblow's. You find ways to survive, improve your resume, and eventually move uphill to have more choice in kinds of crap you need to deal with. Sharing your hard-earned wisdom with junior developers will only be the cherry on top at that point...
What you seem to assume is normal is some kind of career hell I would never want to be in (nor have ever been in).
During my first internship at a "normal" corporation, I felt exactly like septerr does now. I can't imagine following the career path most programmers go down, even if it is going to pay well. How did you avoid (or is it even possible to avoid) going through that corporate phase and skipping right to working on something that you may love but may harbor more intrinsic risk?
I have gaps in between every job I've ever held, but those gaps are strategic. In them, I figure out what I really want to do, and whether I have the tools to do what I really want to do. I applied to YC's first class of S05, as I was finishing up college. I didn't get in. I figured that if investors wouldn't talk to me, I'd learn how to do a bootstrapped startup, so I went to work for a bootstrapped financial software startup. After 2 years there, I quit and founded my own bootstrapped startup, this time in Web 2.0 casual games. It failed too. In examining the failure, I figured that I lacked enough real-world experience to understand what the real markets were, I'd exhausted my pool of potential co-founders, and I had this continuing anxiety about how to do software development "the right way" and make programs that scale. So I moved out to California to work for Google Search. I'm on my own again, but I got everything out of Google that I hoped to get out of it (and more!).
If you're doing it right, each job is an opportunity to get a lot more than money. It's a chance to build technical experience, to challenge yourself, to look at how people with way more experience than you make decisions, to understand how an industry works, and to see how an organization fits together.
It reminds me of my favorite quote from one of the best books about building any type of "Professional Services" company:
"The health of your career is not dependent so much on the volume of business you do, but the type of work you do (whether or not it helps you learn, grow and develop), and who you do it for (whether or not you are increasingly earning the trust of some key clients). In any profession, the pattern of assignments you work on is the professional development process - you just have to learn how to manage it."
First, you'll want to become a expert in your company's product domain. This will make your creative flashes much more relevant, and therefore more likely to see the light of day.
Second, start small. Use your own time to create a new tool which you know your team will find useful, and use the opportunity to teach yourself something new while you're at it. After a few successive wins you'll be allowed more and more leeway to apply your creative energies during company time, and the impact of your successes will grow.
Third, don't ask your manager for permission to work on Side Project X, at least not until you have somewhat of a reputation for delivering useful innovations. It truly is easier to beg for forgiveness than to ask for permission.
Lastly, give your colleagues a sense of ownership. People tend to be much more supportive of innovations that they feel they're a part of.
As someone almost as old as jblow who has worked across a wide gamut of different companies from very small to very large, this is sometimes true, but is by no means universal.
You would rationally think that if you are directly improving team productivity, customer satisfaction and the bottom-line that'll earn you more autonomy, but office politics are not always on the same continent as rationality.
You have to remember that if you're not the owner of a company, you have no rights to the products that company makes. Whatever privileges you have you keep by the grace of the owners, and when they change ...
Ofcourse, if you're the owner you're unlikely to actually be able to write code all the time, having to deal with the soft parts of the business. The grass is always greener on the other side I suppose.
My first job was a 16 person company doing industrial automation. I was a first-year CS student. They let me write their TCP/IP stack. Second job, TA at the mechanical engineering dept. They needed visualization software for their work on the European space project. Third one, 10-person company writing one of the very first CD recording tools, with prototype hardware.
I was lucky. Each of them was willing to take what in retrospective looks like a huge risk on me. I was crazy and just said "sure, I can do this" to those jobs. I was learning a lot, fast.
But the beauty was, I had no career to consider. Had I failed, it would've been OK - when you're new in the field, that can happen. You'll have to find a new job, but nobody will be surprised if you have quite a few jobs when you start out.
That's when you take the risks, go for the crazy things.
When you're a decade or two (or almost three. Jeebus!) into your career, it's a different proposition. At that point, you get hired for the experience you bring. Taking crazy risks is something that most companies would like you to avoid. (I'm blessed. My current employer still lets me take risks. I just spent 4 weeks in a code base I never touched before and have things in production now :)
Did I love working on the things I started out with? Not really. But I loved being pushed to my limit. I still do. So how do you skip the "corporate" phase?
By taking a job that's outside your comfort zone. Your own startup or smaller employers are your best bet for that. But there are big companies that let you take risks, too.
Ultimately, it's a balancing act. How much safety in your income do you need, and how much risk are you willing to take? If you can push the risk side, it'll lead to more interesting jobs.
Maybe not exciting, but it never sounded "soul crushing". I never really expected to be having a blast at work; it's just a job. Should I be expecting more?
Starting a startup really sounds like more stress and annoyance than "fun" to me personally, after reading stories of them on this website. Are you sure the "more risk" one is worth it? Corporate programming work really doesn't seem that bad from what I've heard of it realistically, despite how derided it is here. Startups on the other hand sound like killing yourself by programming 13 hours straight every day for some company that's probably going to fail and getting below-market pay compared to the easier and better-paying corporate side.
I do hope you are wrong.
Anything else you get is a bonus.
Far too many people are concerned with the anything else part, and it reflects the enormous privilege we have today in western society.
Some of them are great employers. Some of them are terrible. But none of them will feel like working for a large corporation.
Do the least amount required in your current job to pay the bills, then, on the side, improve your skills. You don't need to climb up the corporate chain and suck dick until it's your dick being sucked.
The "Good HS grades -> Good college -> Good junior level job at a corporation -> stick at that corporation until you get a good senior level job" is firmly stuck in the 60s, 70s and 80s for a reason. The highest salaried jobs in programming are going to kids job-hopping from company to company in the Bay Area, graduating from average colleges (some minority not even having a degree) working at top companies who's HR departments publicly disavow the previously worshiped legitimacy of the GPA (word is, Google HR isn't even allowed to look at your GPA).
I recently glanced over this test Andreessen-Horowitz was giving out to recruit software engineers for some in-house development thing they were doing. In the description for the application, they said : "A resume is a plus, but you don't need to have it."
I know that, obviously, people with college degrees from top colleges have a higher rate of success in the corporate marketplace. Killer resumes and years of experience will likely get you very far. Sticking around at a successful company for a lot of years will likely get you a very respected senior role with really awesome stock options.
But the point is, for whatever very small but still existent minority, 19 year old college dropouts that have done 3 6-month jobs are still getting hired. Which means that a killer resume and corporate ladder climbing aren't hard-and-fast requirements anymore -- the only hard-and-fast requirement is merit. Obviously years of working within a single environment will get you a lot of merit, and obviously Google will start locations in Ann-Arbor and Pittsburgh just cause UMich and CMU are there, but that's just because Google values those areas for their high rate of merit, not for their pre-existing prestige.
And what OP is describing certainly shows that he is not properly developing his merit.
Now, in the 60s through 80s, there weren't really too many resources available to improve your merit on your own. So if you were in a shitty position you mostly just grit your teeth until you got in a slightly better position to improve your merit that involved less teeth-gritting and more enjoyable skill growth, and then used that skill growth to get into a slightly better position, ad infinitum where the base case is your retirement. So the best advice was to stick in a single corporate environment until you stopped being a junior and started becoming a senior because there was no more efficient way to develop your merit.
But nowadays, there are resources aplenty and much more efficient ways of developing merit. It's very easy to get cheap access to field-defining textbooks and online lecture videos and PDFs and ebooks and cheap personal computers with which to tinker around with and yadda yadda yadda, all of which can be done by any reasonably smart and dedicated but unexperienced young person, all of which is a much better use of said young person's time than climbing the corporate ladder until you got a job that didn't make you want to kill yourself.
So it's very possible to develop your skills and your merit without the prestige that you used to need in the form of a killer resume or long corporate history or stellar college grades.
So as long as you mastered your data structures & algorithms, your theoretical computer science, so as long as you mastered programming principles and can really say you're an expert in a language because you spent many man hours hacking away with that language at home, so as long as you know your OO, so as long as you prep up with the plentiful blog posts there are about mastering interviews (even for specific companies -- Steve Yegge has written a couple blog posts about mastering the Google interview, and for specific languages -- and I've very recently come across a very useful and thorough blog for knowing the ins-and-outs of Java for mastering interviews that demand expertise in that language), you can get an awesome job. Even if you never land a interview with Google or Facebook (because at that scale, so many hopeless hopefuls apply and you couldn't possibly scale HR with the rate of applicants, so you sort of have to rely on less-than-perfect prestige requirements like college degree from a decent college or networking with other good companies in the Valley. But I'm saying that the modern age allows for extremely low barriers for finding quality applicants and getting quality knowledge to become a quality applicant, and while there are certain institutions where you still sort-of need to reply on prestige, for the most part the industry is becoming a lot better) , you can definitely land a phone screen with an awesome software shop at least better than whatever shitty position you're currently in, and then you can get the interview after you display competence in the screen, and then you can land the job. And after that, it's all improving : improving your skill with awesome workmates in an awesome environment, and then eventually moving on to greener pastures at ... greener?... companies if it is your desire to do so.
Note that I'm not saying getting a more fulfilling job is easier by any means. Top companies will still only take top people. Just that, as barriers between companies and applicants lower and modern technology makes judgment of qualification more efficient, "top" is going to rely more on merit than prestige. And you do not gain any merit from staying at a shitty job.