greenrd

> Though, if true, it would be useful to know. Money could then be directed to research and policy that helps increase IQ.

If I ever get really rich, that is what I plan to do. But the Flynn Effect has started to slow down or stop in many countries, indicating that we've plucked all the low-hanging fruits and we're running out of obvious ways to do that.

We'll probably fall down slightly in terms of average IQs in the population before IVF and genetic selection allows us redress the problem. Don't mention the E word (eugenics) though - germinal choice is a better euphemism.

> What isn't PC on Hacker News is the idea that it isn't society who is against women as programmers, but the environment built by "us". That maybe it isn't this environment that is more accepting than all others, but that "we" just fit in.

I don't find your comment un-PC, because I fail to understand it. What are you trying to say?

> This is of course a failure of meritocracy, in the same way that charisma often trumps skill at a job (which is the big problem for anti social men).

It isn't a failure of meritocracy - in both cases, it's a failure to achieve meritocracy. Pet peeve.

And arguably the best solution to the lack of confidence in women problem is a two step process: to (a) educate women on the difference so that they can (b) try to address it themselves, if they choose to do so. If a woman wants to be a housewife or a teacher, what's wrong with that?

> So I don't know that we have it that bad, or that efforts to attract more woman (even if you consider the given reasons to be bogus) are really misguided.

To attract more women into tech in the numbers wanted, the only way is to solve the pipeline problem - encouraging girls at a relatively young age to choose programming as a career, and encouraging them to stick with their STEM major in the face of adversity (but ultimately it's their choice, of course). But multiple times on Twitter, I've seen the pipeline problem sneered at, ignored, or downplayed, by women who claim to be supporting women in tech. They've even sometimes attempted to shame me for focusing on the pipeline problem, as if it was somehow grubby and unhelpful.

The reality is, poaching female employees from one company to another achieves precisely zero for gender diversity in the industry as a whole, good as it may be for one company's PR in terms of its own gender numbers.

> Idk, I feel like saying that humans should somehow manage to turn off grouping and categorizing things is kind of lazy.

I don't think that's what danieltillett was calling for at all. Rather, I think he was arguing for not letting group-level categorisations - such as gender or race - totally dominate over and blind us to attributes of individuals that may differ from what we would expect from our preconceived stereotypes of groups. Because when we do that with race, we do recognise that as racist - maybe not when the race in question is white, but in other cases, yes.

I guess it's an incentives thing. How much pushback do journalists ever get in their lives for writing lazy, uninformed and inaccurate articles like that? I'd guess jack squat, because we probably all think we have better things to do with our time than write letters of complaint to the editor. And we're probably right to think so.

Well, because of organisational biases. There are principal agent problems dotted throughout most businesses larger than a single room, and people care more about looking good than being theoretically optimal, and this is recursive. And however bad you think this problem is - it's probably worse. Robin Hanson and Eliezer Yudkowsky have both written good stuff on this subject.

You don't generally hire your CEO - and if, contrary to all precedent, you were hiring the CEO, you'd probably want someone who could speak convincingly and confidently to the media and investors, while speaking authoritatively, firmly and confidently to employees. That could make the difference between a startup running out of money or succeeding.

Funny, I got where I am today by speaking in the manner I was being spoken to in interviews. They seem corporate - I speak corporate. They seem informal - I speak real. It works for me.

No, it's just immature thinking from people who aren't familiar with the workplace and its norms. If it wasn't social media it would be some IRL friends.

Do retrospectives at regular intervals and encourage everyone in the team to bring up (almost) any issues, large or small, in those meetings, and discuss them, with a solution-focused outlook - what can we actually try in order to address this problem?

An essential feature of retrospectives is that upper management, and internal/external customers, are not invited - and do not get to see the raw whiteboard, but only - if they see anything from it - a sanitised summary that's relevant - and diplomatic - for them. This all helps to encourage openness.

Maybe it's the way you tell them. With engineers, a little explicitness goes a long way, and will generally be accepted - unless you're being patronising and telling them something they already know. So try saying "I'm not saying this to gain any sympathy or anything like that, but I had a similar experience, which was... and what it taught me / how it made me stronger was..." I mean that's kind of a stilted template, but you get the general idea.

Now, this might lead to a bunfight about whether those situations were similar, in your colleagues' opinions - but then at least you'd have brought out into the open where your colleagues weren't thinking along the same lines as you - which might not always be what you expected!

Reality check here: I think if she were a man - and not a boy fresh out of school, mind - she wouldn't have been hired in the first place. And yet here we are, seriously arguing about whether her naivety and immaturity should have been enabled and encouraged. There's no question: it shouldn't. That is not how you talk in an interview.

Not even if your interviewer is a woman.

> What kind of filter do I want my employees or coworkers to have at work? Should we systematically favor bravado over vulnerability? My gut feeling is that we should not.

I think structural/procedural solutions can be very helpful to encourage honest discussion. For example, rather than asking "when do you think you can have this done by?" you can ask "let's try to estimate this story in a timeboxed way, as a group, using planning poker". I know it may sound silly to those who have not done it before, but it works really well. It's difficult to explain the real reason why this helps so much without revealing more than I'd rather reveal in public.

Also, and relatedly, to the extent that you wish people to be more open and take ownership of problems such that they can honestly discuss their work-related problems rather than trying to keep you happy and play office politics, you can try to exhibit servant leadership. But you can't really be a servant leader when it comes to some issues, like hiring and firing - and by consequence, performance review. There you have to be firm but fair.

What counterexamples would you offer? Bearing in mind that it may have been intended only to apply to consequences that he was responsible for, not things that he had nothing to do with, but I can't think of any examples of the latter right now.

The point is, these consequences can include everything up to and including termination, and a resultant difficulty in finding a subsequent job that pays as well. The young woman probably didn't think of that when she blurted that out. Or maybe she has a trust fund to fall back on, but the people around her may not, and she wasn't setting a good example.

I can't relate to that at all. Having to stay awake in even more boring meetings? Not being able to write code any more? Why would any programmer want that - unless they didn't actually enjoy their job?

Don't ever trust your employer. I've learned this the hard way. It's 2017 - employers have no loyalty to us when the shit hits the fan - and we should have no loyalty to them. Stay if you like it, go if you don't - because there's probably something better out there.

Neither quitting in a fit of pique nor being fired look good in an interview. You can get away with a prima donna vibe - but only if you're really good - and sometimes not even then.

As a tech lead, it's actually easier for you to admit weaknesses, since your subordinates will be happy if you arrange things such that their job satisfaction is high, regardless of how much or little technical work you do. For a front-line engineer it's more dangerous, particularly if there is a perception (even if unfair) of a discrepancy between how they presented themselves at interview, and how they are presenting themselves now. Front-line engineers also don't necessarily know if their employer is thinking of firing them - they therefore are best advised to play it safe with regards to any little thing that their employer could pick up on as a straw that breaks the camel's back. Better safe than sorry.

But yes, there are times when we all need to ask for help, and even here, there are better and worse ways to do it. Again, for a team lead to express vulnerability can be positive in the right circumstances - because it can allow a junior (or indeed a senior) to puff up their chest with pride as they may then be able to help out their boss, show off their knowledge and look really good - and it can help to bond with the team. In contrast, showing vulnerability as a subordinate, to the wrong manager, can just give them an excuse to fire you. That's happened to me twice - I've learned my lesson.

The person you are replying to didn't say exploitative competition. They just said competition.

Indeed, exposing vulnerabilities (of the personal kind, not the security kind) can be imposing in a very inappropriate way.

Your colleague is not obliged to be your free therapist. Don't impose emotional labour on them if their body language or response indicates they don't want to be having this conversation. You don't know what issues they are dealing with, which may be much worse than your own. Talk to a friend or family member, or pay for a therapist.

The reality of group projects is that all too often, one person ends up doing most of the real work.

Group projects don't need to be more infantilising, they need to be more "shape up or ship out!"

See - even this woman who studied CS and got a job in the field ended up regretting it. And that's hardly an isolated example. I'm not saying all women who study CS regret it - far from it - but maybe James Damore was onto something?

You know that many professors don't actually do a lot of the nitty-gritty work, don't you? They farm that out to their grad students. So in theory all someone has to do is get a PhD and get hired as an academic.

What's worrying is I know a couple PhDs - in STEM - that were granted when they probably shouldn't have been. One lacked any originality, and the other was basically incomprehensible.

I think it means deployed on the customer site, for better communication with the customer. At least, that's what I'd do if I were Palantir.

Feature design phase? Sounds like waterfall. Avoid that too.

GitHub also lost a bunch of PRs and issues sitewide early in their history. They claimed to have restored all the PRs from backup, but I was pretty sure I had opened a PR and it never came back. I emailed support and they basically told me tough luck.

It doesn't say "don't sign all your comments", it simply says "don't sign comments". Also, it should be interpreted in the light of the fact that modern netiquette on other sites like Stack Overflow which have usernames is to never sign your posts.

You can't embed control characters in URLs, though. Of course some web servers and web applications may blithely accept illegal unescaped control characters in URLs. If so, they're buggy.

Darcs was mostly a failure because no-one, not even the original author, could satisfactorily explain its patch model - whereas git's patch model is simple and easy to understand. That has nothing to do with Haskell.

The main lens library in Haskell doesn't exactly have no documentation, but it is pretty much impenetrable without a third-party tutorial or blog post. But persevere - it's really powerful!