There were a couple of girls who could program rings around me at school, There were also just a couple girls in my programming classes, they were the same persons. During my IT career I encountered relatively few female programmers, and they were all crap (see below). Interestingly they were also all foreign born so my assumption has always been that they were trained as a part of some government program. Never saw a Canadian female programmer in the wild, not one. Again my assumption was that if they had to pay for their own schooling they were going into something either they enjoyed or had an aptitude for. I have nothing against girls in IT but programming is clearly not a strength.

By "they were all crap" I mean that they were almost incapable of using the toolset to do anything they had not explicitly been trained to do, which in my experience is the majority of programming jobs. Also they took longer than a guy would, like 3 times longer. I never came up with a theory to explain that. Every time we hired a female programmer we switched them to other duties relatively quickly.

Girls and accounting however was very common and usually a good match.

The ultimate acid test here is whether the user gets what they need, which is not necessarily what they ask for. The programmer needs to understand how and why the program is being used. Otherwise all you get is a solution, as opposed to the solution. This is one of the reasons why working with offsite developers is so fraught with difficulties.

Of course often the person responsible to spec the project is not the same one doing the coding. So its that person's job to make sure the programmer(s) get's it, and likewise its the programmer's job to make sure he gets it.

Proficiency with the language/platform whatever is a given. As is the ability to translate a real world problem into the world of their toolset.

Seriously, after working in a RDBM all day having to write an SQL query felt like being forced to write COBOL code.

Learning how to program has less to do with the language and more to do with problem solving. Either you enjoy and are good at using the tools at hand -- ie. the programming language/development environment -- to solve problems or you should look at some other career. Accordingly enroll in a beginners programming course and see how it goes. Added bonus is that when you're done you will be better equipped to answer your original question, assuming you enjoy programming that is. Note: it has to be a real language though, not something like HTML or Visual Basic.

Good programmers are like good musicians: Learning a new language (instrument) is mostly just learning new syntax (fingering). Okay, maybe that metaphor is a bit of a stretch but I hope you get what I mean.

Keep in mind that becoming proficient in a language can take weeks or a few months, but becoming an expert takes years.

I was a database programmer for most of my programming career. Within the confines of the development tools it was a fantastically creative and rewarding activity. Sitting with the client to determine what they need (which is usually different to what they ask for) and then coming up with a solution that not only doesn't break existing data relationships but also is expandable so that when they revisit the project down the road (and they always do) you can change the functionality to what they now perceive the needs to be.

I didn't always do it right but we had enough successes that I can look back with pride and a sense of real accomplishment.

Of course the down side to writing DB queries, updates, and reporting is that it can be mind numbingly repeatative and boring. Oh boy, another AR report but this time with butterflies in the margins Please Gawd Kill Me Now. So yeah, if you're on the receiving end of the development team then it can be one of the lower circles of hell.

I regularly worked with web guys and I always thought the designers were able to be creative, but the HTML side seemed like a grind especially dealing with the difference between browsers.

Every time this question comes up my response is always the same: You don't learn how to program; you learn how to solve problems.

IOW unless you have a particular problem -- AKA project -- in mind you'll never learn how to program.

The Towers of Hanoi is a good one to start with. Or research the many sorting algorithms and pick one of them to implement. These are relatively easy projects but require you to learn the basics of variables, operators, and input/output to implement them. And from there you build on your skills with more complex projects.

Otherwise just trying to learn syntax is a waste of time.

Being a programmer is also about picking which set of tools -- language, platform, etc -- is the best for the job at hand, but that comes later. So to start off pick a problem and a language and off you go.