4 ms·
Basically, with rule (1, hacker school rules) they are asking to lower the standards. That's not how things work. Would it be OK if this was about Medicine, not
by return0 13y ago
Basically, with rule (1, hacker school rules) they are asking to lower the standards. That's not how things work. Would it be OK if this was about Medicine, not programming? Would it be OK that your colleague does not know where the bladder is? Have a surgery without anesthesia? Sometimes you can't change the culture without substantially changing the standards, and it is NOT OK to hold women to lower standards of rigorousness.
- MDCore 13y agoSo there are a lot of (1)'s in the artlcle. Are you talking about "Diversity leads to better results" or "Abide by the Hacker School Rules" or "No feigning surprise" ? I'd like to address your Medicine analogy, but it'd be more appropriate if I knew what you were referring to :)
- amtab 13y agoI don't think that the Hacker School rules have a goal of lowering standards, but rather of preventing the one-upmanship which is so common among (usually male) programmers. To someone who may be feeling overwhelmed by the learning curve inherent with transitioning from small academic or recreational coding projects to real-world environments such dynamics could be very demoralizing. Anecdotally, men who stay in tech tend to have a high tolerance for it, but it's secondary to the actual practice of coding and people who are feeling less confident don't need to worry about competing in these games. Of course if someone is working on a real-world codebase they have to know what they're doing, but learning from peers does not need to alienate anyone, at least in principle.
- rjknight 13y agoNo, no, no. 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.
- h1karu 13y ago> 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. 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
- rjknight 13y agoThat would be good advice in that situation. Certainly, allowing people to believe that they can "pick up" programming knowledge without working hard at it would be irresponsible. Telling someone the truth about their work is generally a good idea. You can easily do this in a helpful, non-mocking way, so I don't really see the conflict here. 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.