I'll second that, as well as the suggestions to
- get a SQE-type job, coding unit or API tests and
- look at small companies and apply for those lower-end Programmer jobs anyway.

Those things are what I did and... well, actually, after programming for a good long while I'm now a QA manager who does quite a bit of tool-and-test coding and playing mentor to more "junior" programmers... pays better than my last programming gig, whatever you think of QA work.

Anyway... the truth is, many companies "lie" in their job descriptions, especially in terms of years of experience they'd settle for. Less than 3 years experience on a job advert means they'll consider your QA work, especially if it includes some programming of some kind somewhere.

The problem with too many years of QA work is that, eventually, the hiring manager will wonder if you really can write code of your own, or if you really desire to... they'll wonder why you didn't get a programming gig at some point, and you'll have to convince them that the last program you wrote wasn't for a CS class.

Ultimately, to get that programming gig, you need to have written code on projects that produce something you can talk about or show off. JCR says to write code that interests you; as with all things in life, that's going to be what you enjoy and are more easily successful in, so it's great advice. If you can also write code where you work ( even if it's less interesting to *you* ), that's good to do, if you remember it and count it as programming experience on your resume and in interviews.

The important thing is to gain experience writing code, if you want to convince someone that's what you have experience doing. Write code at work, on your own, or, as many suggest, as part of an open-source project... however you do it... write code... have something to talk about in your interview besides test plans and button clicks.