3 ms·

> 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 d

by h1karu 12y 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 12y ago
That 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.
- h1karu 12y ago
  Agreed. 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/ http://37signals.com/remote/

by h1karu 12y ago

rjknight 12y ago

That 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.

h1karu 12y ago
Agreed. 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/ http://37signals.com/remote/