This is where the debate goes wrong. Being a decent person to women isn't some kind of personal sacrifice you need to make, it's a strict subset of being a decent person in general. If someone knows less than you about something, you should not mock that person or make them feel inferior, you should help them. That is the right thing to do, irrespective of the gender of the person you're dealing with.
We should think of programming as a large fellowship (the word 'community' is overused, but it would also work here). You meet another person who is interested enough in programming to get started, then that person is your brother or sister. You want to help them, partly because it's the right thing to do and partly because it is in our collective interest to do so. We don't need bad programmers out there, screwing up because nobody helped them, and we don't need to scare off the beginners before they've even had a chance to learn much. Sure, people should have their mistakes corrected just as a journalist might expect to have their typos corrected by a sub-editor, but there's no reason to do it in a harsh or critical way. Just be a nice person about it, it's really not so complicated.
Why do you assume that merely telling someone that they are not qualified is the same as mocking them ? Sometimes the best way to help someone is to let them know that they're going to need a year or more of disciplined study in a particular area before they'll be capable of contributing in a meaningful way to the given project. It's better to tell them that up front than to string them along under the false pretense that they'll be able to "pick up" what is needed along the way
The OP linked to the Hacker School Rules, which state that people should not be humiliated for their lack of knowledge. These rules say that the following responses to encountering an inexperienced person would be wrong:
"omg, you call yourself a programmer but you don't know how to write a thread-safe hash map?"
"well, actually, if you knew how to use git properly you would have done a rebase there"
"you're using MegaTest? everyone knows SuperDuperTest is the best testing framework, use that instead"
Those are all unprofessional and unhelpful things to say. In contrast:
"that's OK, concurrency is pretty hard. if you want to learn more about it, I can give you some pointers but you probably want to build up your knowledge a bit more before attempting this."
"ok, let's take a look at the git log now. you see how the history has some of your 'figuring stuff out' commits in there? well, there's a way of tidying up your commit history before merging it in - there's this thing called rebasing, which we can use to make our history easier to understand. here's a good tutorial on it - give me a shout if you need some help"
"the MegaTest library is OK, but it's not that well-maintained any more and quite a few people have migrated to SuperDuperTest. there's a really good post about the differences here, and you might want to pick that up for your next project"
Obviously, these are caricatures to some extent. But the point is not that people who are getting stuff wrong should not be corrected, the point is that there's a good way and a bad way to correct them, and choosing the good way makes the world a better place for everyone.
This is one of the reasons why I like remote work so much. If most of the work conversation is happening in a basecamp or hipchat which is logged then if a particular team member is phrasing his communication in a demeaning way or doing anything else to discourage others from group-learning then that behavior pattern will be discerned by everyone else relatively quickly and it can be dealt with. In an office team people can get away with being a dick for years without anyone being able to call them on it to correct the situation.
more on these themes here: http://37signals.com/remote/
However, software is an industry. We need more people, and we can't travel back in time to teach the 10-year-olds of 2004 how to code. It's perverse, but part of the reason for the shitty nature of most software projects is the imbalance between demand for good software and supply of people capable of providing it. This is what leads to over-work, death-marches, time pressure and the attempt to prevent programmers getting involved in "distractions" like talking to customers, figuring out what the software should really be doing and so on.
Currently, the best way for employers to maximise the amount of software they produce is to get their best coders to focus on writing code, stripping away any other aspect of the job. Management, analysis, design, testing, all of these get shifted on to non-technical (read: easier/cheaper to hire) people who then fuck it up because they don't know anything about how software works, or at least how the software we need right now should work. Sure, it can be a good thing for developers that demand for their services is so much higher than the supply, but the long-term effects really aren't good. I'd rather work in a world where the obsessive programming-before-they-could-legally-drink people get to be lead developers, but the rest of the team can also program decently. And that means training the latecomers properly. (I appreciate that some of this may seem condescending to the latecomers - in all honesty, I think many people have the potential to be excellent developers given time and encouragement, but I'm trying to stick within the premise of the parent comment).
I'd like to address your Medicine analogy, but it'd be more appropriate if I knew what you were referring to :)