Hacker News Reader

> 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

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.

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/

Some things are thrilling because they are hard. Software development has the amazing quality that everything that is not-hard is automated immediately, leaving little need for humans doing "easy" work. Highly competent developers are sought after because companies know that they cannot be replaced with a group of average developers. What you say has nothing to do with women, it's obvious advice for good manners. I 'll take it, it's polite to stop being dorky around women, but, on work matters, there should be no rounded edges.

My peers have been obsessed since puberty. They don't have to be lured into the industry because they never could have stayed away. Their 10,000 hours thoroughly shaped them because it came at the expense of a normal social life. Someone who starts at 20 is interested in paychecks, not programming. I would drum today's bottom half out of the industry, not swell their ranks.

You're kinda right. I started programming on BBC Micros when I was 9, and there's really no way around the fact that the only way you can know as much as I do about programming at my age is by having that kind of experience.

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