I’m told that our “engineering-focused” culture is offputting to women

[-]

gymell@reddit

I've worked with plenty of men who would dig their heels in on exactly this type of thing, especially when the issue with their code is being pointed out to them by a woman. And I've also worked with women who are so insecure that they can't handle even the most diplomatic, constructive criticism or suggestions, even when offered by another woman, and so they dig their heels in too.

So, people dig their heels in for various reasons, maybe sometimes the reaction is related to gender, and sometimes just because people in general don't handle criticism well, and also often it isn't delivered in a constructive way, etc.

In this case it sounds is a breakdown in engineering culture. Where was the code review of this person's O(n2) algorithm prior to being pushed to a deployed environment? What's going on where she could provision a very expensive server environment without prior oversight and approval? What about some training for people who obviously didn't take a CS algorithm course so that they even understand what any of that means? Where is the technical leadership in all this?

[-]

Ok-Letterhead3405@reddit

Omg, yes, exactly this. I work with a guy who copy-pastas shit from file to file and never takes any of my feedback in code reviews, often with the excuse that he'll "do it next time" or that "this ticket has ballooned in scope and I just want to get it merged." That second one is an issue I keep trying to push to be addressed, but people hate anything that is suggested if I'm the one suggesting it, so I have to wait for one of the other guys to bring it up instead. Ugh. Keeps happening.

Meanwhile, I have a woman colleague (I'm also a woman) and even if I leave her 20 pieces of feedback on a way too long MR, she does her level best to get through it and asks for help if needed. I don't think she's a great dev, but she takes feedback well. Unlike the other douchebag. They kinda both suck in their own way.

[-]

Susan's anger was forged in the fires of academia and she has had it with dudes popping up to block her progress.

OP needs to explain why we don't just peg out all the AWS sliders all the time.

any non-profit research

This is me. Pay at my place is pegged at 50% of industry. No location adjustment, effectively no bonus. Last time I looked around, I would have been looking at an immediate 30% base pay raise, plus stock and bonus. The difficulty is that the actually, hugely qualified scientists often make even less, and have spent decades fighting tooth and nail to even get that. And the scientists are in charge. So, non-profit budgets and resentment need to be carefully managed.

[-]

doberdevil@reddit

hugely qualified scientists often make even less, and have spent decades fighting tooth and nail to even get that.

Yeah, I'm aware of that too. Hearing about some of the crazy things they're researching, then learning that they get paid shit was quite eye-opening for me. I've been pretty lucky to get to meet and talk to some of the scientists that were really good at explaining their research and hypotheses in layman's terms.

On the other hand, I guess the goal is to hit a breakthrough, patent it, then spin off a for-profit company. I saw a lot of that too.

[-]

The_Northern_Light@reddit

For one off use, sure, but not when you scale it out to deploying it to your customer!

Plus, this is just one piece of software. She will create further pieces of software. If we help her improve, the next piece will also be better. Hopefully 🤞

[-]

hdizzle7@reddit

absolutely, at scale brute forcing something doesn't work long term. We practice continuous improvement where we iterate stuff over time so it's not this giant looming problem.

[-]

a_slay_nub@reddit

Probably easier to debug in the future as well. There's a time and a place for these solutions.

[-]

Honestly, I'm more suprised that PRs are rejected versus approved; that is, you leave comments that people work out until it's great, and then it gets approved and can be merged. I don't think I've seen a single PR in my org "rejected"

[-]

dweezil22@reddit

To be clear, none are ever rejected. But sometimes when you're 50 comments and 30 commits deep that's a sign that it would be cleaner to start fresh. I've never forced anyone do it FWIW, but for myself I regularly do it. It's kinda like "Oops, in 20/20 hindsight this should have been a draft PR that I submitted for comment"

[-]

I've run into similar issues before and,I feel like women are often socialized to surface workplace problems a bit better than men.

Most male devs I know either don't care enough to fix culture problems "as soon as my vest hits I'm out" or are too concerned about rocking the boat to say anything "I need to keep this job". From my perspective, both mentalities seem to be based on a lack of psychological safety in the workplace.

It's not surprising really, despite lip service to the contrary (usually through agile process virtue signaling), functionally every company I've ever worked for has had basically no accountability for management and full, often exacting accountability for individual contributors.

[-]

14u2c@reddit

I think the word trauma can be overused but honestly there is something psychologically damaging about living under an at will employment regime. It’s hard to speak up about anything when your livelihood could be gone the next day because of it, and for a number of reasons I think men feel this pressure more acutely.

[-]

zayelion@reddit

Yeah. Jumping "work classes" had me sitting with psychological fear of not doing something constantly that took years to get over. "If you can lean you can clean" and the myth of "stealing time".

Covid was eye opening.

[-]

Ok-Letterhead3405@reddit

I came into tech from about a decade of shitty fast food work. You really ain't lying. Covid and turning 40 knocked a lot of that out of me, but I've been lucky that I could continue to work in spite of those conditions.

[-]

zamN@reddit

there is zero efforts to “hire more men in the workplace”. As “red pill” and generic as this sounds, men are extremely replaceable. Even if this isn’t true I think most feel this way. It’s very hard to feel irreplaceable in the workplace unless you have a strong tenure to fall back on

[-]

tjsr@reddit

From /u/14u2c:

It’s hard to speak up about anything when your livelihood could be gone the next day because of it

And from /u/zamN:

there is zero efforts to “hire more men in the workplace”.

Schmittfried@reddit

how men think differently from women

Huh? How is that right-wing? That is one of the core pillars in arguing for more diversity. Different people have different predispositions for certain perspectives due to genetics, upbringing and social constructs, so if you want to get the full picture you need a more diverse workforce. This is also the core reason why gender equality officers are usually required to be women because they are more likely to be able to relate to the discrimination other women have to go through.

So by that very same logic of course it’s also important to have male representation in HR. Without entertaining tjsr‘s specific allegations, of course you would (or should) expect at least some amount of discrimination against men in a company run by only females. Which in fact we do see, male nursery school teachers are deemed less capable (or even worse, pedophiles) all the time.

Human_No-37374@reddit

Pretty much. I'm a woman and seeing some of the things that my male coworkers, my brother, and the most extreme example of my father are all willing to put up with or even just not even notice is appauling. Most of my male coworkers are more willing to say something, but the amount of extreme and explicit classism, discrimination, etc. that I saw my father go through and still go through occassionally these days is absolutely appauling.

[-]

IRefuseToGiveAName@reddit

basically no accountability for management and full, often exacting accountability for individual contributors.

And in my experience it works the exact same way on the other side

I'm not asking for individual attention accolades, since all large features save a select few are a huge team effort. But we pushed our a project in the making for around 18 months last year and the email celebrating it mentioned engineering zero times.

I'm not joking. It was like "I want to give a shout out to {list of customer facing people}, and everyone else involved in getting this off the ground."

I was fucking livid and immediately sent off emails. I guess enough people did the it reached the right people and we got follow-up lip service in the way of "that wasn't meant to be an exhaustive list of course we appreciate our engineers!" Paraphrasing of course, but it was equally dismissive.

I'm rambling now but I got mad again thinking about it just now.

[-]

Donkey_Duke@reddit

This is typical because the people in the board meetings aren’t doing any of the heavy lifting.

I was a scientist during COVID, and worked on developing a solution that would kill but would destroy the viruses DNA, and verifying it was stable in room temp. Honestly, the goal was simple the deadline was insane. My team was divided and we became a 24hr lab for a better part of a month, with zero pay increases because hazard pay was already structured into our pay since we worked in an infectious disease lab.

When we achieved our goal, an email was sent out congratulating us everyone but the scientists. They literally patting each other in the back for having to send out a few more emails and attend a couple more meetings.

[-]

RewRose@reddit

Scientists, Engineers, Teachers, Sanitization workers - everyone is equally beneath the ruling class as the "working folks" or labour

[-]

_lazyLambda@reddit

No set of words in this thread has spoken to me like this one.

How are you gonna say that the work was entirely a result of the people who did 10% of the effort? Im not saying client facing people do nothing but yo im pretty sure its loud and clear how much they've put in. Engineers wise? As if anyone understands that whos not an engineer.

I worked for this stupid af company in Quebec and these clowns would literally have some silly conversation with the customer and then promise them the world on my behalf and even go as far as saying "[me] is the expert on this tech" when its some crypto chain ive never heard of and inevitably things blew up, as id meet with the customer every day and they'd expect the project done MONTHS BEFORE I JOINED and these assholes pinned the whole project failing on me. When they fired me they said "you know, we work really hard to get these projects"

Like bro no you dont, you just throw others in the gulag

I can't say who this company is cuz im sueing them but lets just say they rhyme with Microsoft, and are based out of Montreal

Holy this struck a nerve 😅😅😅

[-]

ACriticalGeek@reddit

You might appreciate this sketch

[-]

Arinatan@reddit

I love how I knew what video this was going to be before I even clicked on it.

[-]

northrupthebandgeek@reddit

Obligatory

[-]

yodal_@reddit

The only sales people I ever liked were at a company where I had enough pull to be able to tell them to fuck off no matter what. Oh, you've already promised the customer X, Y, and Z without checking if it was feasible, never mind possible? Well now you get to tell them that none of it is possible and lose the company thousands if not millions of dollars.

This only worked because I was very trusted and most of the managers up to the CEO had my back. Most of management could see that it was generally worse for us long term if we took jobs we couldn't actually do rather than back-pedal before the contract was signed. After a couple big fuck-ups on their part and enough training from me they learned not to promise the world before at least talking to engineering to see if it was possible. Eventually they even started to get a sense of what was reasonable and what we were going to want to skin them alive for even proposing.

[-]

1amchris@reddit

What was the company haha. Gotta stay away 😅

[-]

_lazyLambda@reddit

Webisoft haha

[-]

basically no accountability for management and full, often exacting accountability for individual contributors.

Oh my god my company has this 1000%

Our director sits down with the entire team twice a year to go over our employee signals score and in every single area where management scores poorly he asks “what can you do to make this better. What work items should we create to address this? Who is going to own these”

Basically it’s turned into “if you give me negative feedback I’m going to create “work items” to do random time consuming bullshit and force you to do them in addition to all of your existing work”

[-]

IRefuseToGiveAName@reddit

what can you do to make this better. What work items should we create to address this? Who is going to own these

This fucking enrages me to no end. If something is wrong it's up to me to come up with the solution? Are you fucking serious? I don't want to have a bunch of fucking meetings to address the fact that management puts zero effort into writing descriptive stories, pressuring us to point them, making dozens of fundamental changes after the fact and then getting upset when there's scope creep or tell us we're being difficult when we tell you something is going to be programmatically difficult because the requested enhancement runs counter to the way the entire design up to this pointy. I want y'all to reflect on the systemic issues that resulted in all that bullshit in the fucking first place because they didn't start when I brought them up.

[-]

im-a-guy-like-me@reddit

I mean, I get what you're saying, but also... So who do you expect to fix it?

I don't want to work with the guy with a whole list of problems and zero solutions. That's just whining.

[-]

Schmittfried@reddit

That’s literally a manager’s job.

[-]

im-a-guy-like-me@reddit

He said his director not his manager.

[-]

Schmittfried@reddit

A director is a manager.

[-]

im-a-guy-like-me@reddit

Except one does the "what" and "why" and the other does the "how".

Making out like they're equivalent is wrong.

[-]

Schmittfried@reddit

That really depends on the scale. One man‘s how is another man‘s why. But also, don’t forget where we started.

They said the director goes through the areas where management does poorly and asks the ICs what those can do to improve it. If that’s not a complete deflection of responsibility I don’t know what is. If management is consistently rated low in certain areas it sure is a director‘s (or even higher) job to come up with a strategy to improve this. That’s literally the job of higher management, setting the direction and establishing a company structure that can achieve this.

The very least would be delegating this „how“ to a lower-level manager, but it’s certainly not an IC‘s job to solve this and it’s borderline insulting to ask an IC „What can you do better to improve management‘s ratings“.

[-]

im-a-guy-like-me@reddit

Haha yeah I think I had the scenario wrong in my mind's eye. I thought they were going to their skip complaining about their team's process (including their direct manager) rather than that manager's performance.

Even still, I stand by saying not to be the guy with a list of problems and no list of things they've attempted or possible solutions. That's not a work thing. That's just a people thing.

[-]

Schmittfried@reddit

Yes sure, it’s always good advice to at least try to be constructive. Even then, the IC‘s suggestions would likely still mostly involve changes on on the org/management level. It’s unlikely any IC could help much with that unless we’re talking about stepping up and becoming a manager/lead yourself.

shimman-dev@reddit

Lords treated their serfs better than this lol.

[-]

MadCervantes@reddit

Sounds like the solution here is a union.

[-]

Ok-Letterhead3405@reddit

what we actually realized is that the men were just used to being treated poorly

Holy shit, I'm keeping that one in my pocket!

And when women are treated poorly on the job, we have more masking to do so that we're not judged as over-emotional or too harsh or argumentative. So, take whatever stress the men are under from that situation, as a whole, not individually, right? Now multiply that by like at least 2-3x for the women. No wonder we burn out at faster rates.

[-]

CheeseAttack@reddit

A minor thing I found that helps more than expected with code reviews:

Instead of rejecting a PR with a comment saying what to change, just leave a comment saying what should be changed, that makes it feel more collaborative and less like a personal rejection.

I have found that people respond much better to this, even with the same exact feedback. Someone seeing the red rejected mark on their PR can be demotivating/upsetting and cause some emotional distress (there were studies done in school even where teachers grading papers in ink other than red resulted in students taking the feedback better).

[-]

Ok_Possibility5671@reddit

Red ink for small stuff that won't hurt as much and Black/Blue for big stuff is better I think. Long-term the coddling can be bad. Focusing on the small stuff one can control and then the more collaborative feel on bigger stuff is good and conveys the right perspective. Just my opinion.

[-]

bwmat@reddit

Not gonna lie, not using the platform's features correctly for 'vibes' like this would drive me crazy

[-]

my_beer@reddit

I'd also suggest wording comments as suggestions/questions rather than as demands

[-]

LetterBoxSnatch@reddit

I didn't even know there was anybody who did differently than this. A rejected PR is always "oh, we don't actually want this functionality / feature" not "this feature is poorly implemented." I comment only because of how surprising it is to me that anyone would ever outright reject a PR made in good faith that would generally improve things if implemented well.

[-]

tarwn@reddit

This is why team norms are important. I've worked on teams that:

Approve PRs if they're directionally good, but expect comments to be addressed before merge. Comment if it can't be approved and reach out to discuss. Never rejected.
Approve PRs only once everything is cleaned up. Reject if team conventions aren't met and it needs some attention. Comment if there is anything directionally questionable for further discussion.
Approve, Comment, or Reject based on no shared guidelines, creating occasional confusion and frustration

Every team should decide what the norms are going to be and make they're written down, reviewed semi-regularly, and new folks are onboarded to them.

[-]

thekwoka@reddit

Reject here means...closing the PR entirely?

Or requesting changes?

[-]

tarwn@reddit

On team #2 it was Request Changes, that was my bad, I knew it didn't sound right. The main difference is that team 1 would mark them approved even if there were smaller changes expected to be made before merge (and wouldn't need re-review), team #2 marked it as request changes if there were any change and only approved once they were applied (so 2 reviews).

[-]

oupablo@reddit

I'm unclear on what other ways PRs can be managed. As far as I'm familiar with the process, this is entirely the way it was designed to function.

[-]

A1oso@reddit

There's a misunderstanding. When reviewing a PR, there are 3 options:

Comment
Approve
Request changes

Having submitted and reviewed my fair share of PRs, "blocking" a PR and adding comments on the relevant lines goes a whole lot better than rejecting it outright with one or two sentences.

Comments on the appropriate lines shows you actually reviewed it critically, and are offering feedback. It's a lot easier to digest and incorporate that feedback, or pushback with justifications on the approach taken. Its a more collaborative approach, rather than "just write the code".

Outright rejection should be reserved for when someone completely misunderstood the assignment.

[-]

dlm2137@reddit

What are you (& GP comment) referring to when you say "outright rejection"? In Github, you can leave a comment (non-blocking), or "request changes" (blocking).

Have you seen reviewers outright close other people's PRs? Or do you use a different git platform that has a concept of "reject" that's different from "close" or "request changes"?

[-]

CheeseAttack@reddit

I was referring to "request changes" and the equivalent for other platforms. And for us just leaving a comment is also blocking as explicit approvals are required in order to merge.

[-]

dlm2137@reddit

Ah interesting. Personally, I don't consider "request changes" to be especially harsh. I see it as a good communication tool that helps distinguish "there are some suggestions / questions here" vs "this is something that needs to change".

But also we will often have >1 reviewers on a PR, but only require 1 approval before merge. So if you want to see a change made before the PR gets merged, you need to do "request changes" to prevent someone else approving before you can look at it again.

[-]

thekwoka@reddit

Yeah the word is literally request....asking...

[-]

Specific_Ocelot_4132@reddit

It’s like when teachers use a purple pen to grade papers instead of a red one to make it seem less harsh. For some people it doesn’t make any difference, for others it does.

[-]

dlm2137@reddit

I get your point about the vibe, but in my case no, it’s not like that example.

If I just leave a comment, the PR can still be merged with someone else’s approval. If I request changes, it can’t be — from that point forward it can only be merged with my approval.

This is useful if an issue is noticed that cannot make it into production. So there is a concrete difference, it’s not just a different color of ink.

[-]

ironymouse@reddit

It can be configured to not allow merging until all comments are resolved

[-]

SurfinStevens@reddit

In my experience it's uncommon for someone to come along and approve if someone has already come through with some feedback until that is resolved. That seems pretty reasonable to expect to me.

[-]

dlm2137@reddit

Yes I think that’s a reasonable expectation, and one that we still have, we just get to signal it a bit differently.

If someone had requested changes, another reviewer can now approve it to say “all good on my end other than that one thing” since they know that will need to get addressed before merge, but now they don’t need to come back and look at the PR themselves again.

Just a slightly different way to communicate basically the same thing that you said.

Another useful thing is that it helps prevent a race condition with PRs — two people reviewing at roughly the same time, so you don’t want the PR to be mergable if one person approves and the other has a blocking comment.

Yes this can all be handled with semantic conventions but I find that things work better if the mechanism matches the semantics — blocking comments actually block merges.

[-]

newyorkerTechie@reddit

Yeah I have same problem on my team so I flag PRs all the time. If I don’t someone Else will let it in

[-]

leeharrison1984@reddit

I use the term loosely, I'd consider someone commenting "Terrible implementation, fix it" equivalent to simply closing the PR. Both represent unhelpful feedback and discouraging behaviors for contributors.

[-]

throwawayhjdgsdsrht@reddit

I've found that comments like "this looks good, approved. Just a nit but would you mind changing XYZ" means that the CR owner will still fix those changes before submitting without it being an aggressive "you can't deploy this". This probably only works within smaller teams or organizations with high trust though.

[-]

fartypenis@reddit

Isn't this how it works in most places? At least where I work PRs are just not approved and merged until all comments are addressed and it passes review, but it's the same request and not rejected.

[-]

Proper-Ape@reddit

Instead of rejecting a PR with a comment saying what to change, just leave a comment saying what should be changed, that makes it feel more collaborative and less like a personal rejection.

Working around the tools that have pretty simple, straightforward and standardized way of categorizing work seems like a good way to introduce miscommunications.

Calm-Positive-6908@reddit

Mental load.

Yeah i think this is it.

Mental load is everywhere for a woman. Not only at workplace, but at home.

[-]

BashFish@reddit

why is one group of people allowed to be worse than the rest AND be coddled?

[-]

Latter-Brilliant6952@reddit

One man’s “coddle” is another’s “consideration/decency.”

You can’t dictate what others should have to tolerate just because someone did it you.

[-]

Efficient-Design-174@reddit

Um, literally every decent engineer I know has some form of impostor syndrome. It has little to do with gender. There is just a lot we need to know in order to do the job and everyone has gaps in knowledge. And some people don't deal well with filling their gaps. They feel it is a sign of weakness or failure. Others struggle with helping others fill their gaps. They point out the gaps in rude and nasty ways. And then there are some people who just have really nice gaps we'd all like to fill, but I digress.

[-]

OdeeSS@reddit

I'm not saying men don't experience imposter syndrome or insecurity. I'm saying that the social/cultural context is more unfavorable for women. Imagine having imposter syndrome, now imagine having imposter syndrome in a field where there are people genuinely antagonistic about your competency due to your gender.

[-]

Latter-Brilliant6952@reddit

yikes. nuance is right. so in an imperfect world where you can’t manage the potential hypersensitivity of an employee & the brutality of the work place simultaneously, which would you prioritize? (Good faith curiosity, i promise)

[-]

Efficient-Design-174@reddit

I can imagine it, though this additional discomfort doesn't make Susan's company infrastructure use any less wasteful.

A person made a mistake. Another person pointed it out. Instead of owning the mistake, additional waste followed: an escalation that wastes OPs and OPs bosses' time. And now we're here on reddit splitting hairs over cultural and societal context.

If owned right, the first honest mistake could have been a funny story and a great learning experience for the team, but for doubling down and escalating I would work to PIP Susan off my team faster than you could say "non-binary".

[-]

OdeeSS@reddit

I think you're focusing on Susan's suboptimal solution when I'm trying to address how we can make an environment better/easier for any/all developers to take critical feedback and feel secure in their roles in a broad and general sense.

I'm not denying that her solution required critical feedback. It's possible Susan's wasn't a fit regardless of how the feedback was delivered.

[-]

Efficient-Design-174@reddit

You have invited us to consider that women have it harder than men in tech. While for some and in some circumstances that may be true, I don't see how that gets us closer to making things easier for any and all developers.

[-]

Dudenoso@reddit

Felt like GP is just full of shit

Really, male programmers are just that full of confidence in their role and not being replaceable? That's the argument they are gonna use?

[-]

az226@reddit

But women are known to be more sensitive to harsh feedback. It’s been scientifically studied.

[-]

Right, women are under more pressure to look a certain way so we should let Susan have her 32TB RAM VM.

[-]

fakemoose@reddit

Yea. To highlight that, OP has already decided that it’s all women devs that can’t tough it out at the company. Not that it’s these few devs as individuals or something with the company culture. But it’s women devs in particular. And I bet that’s going impact how they hire or treat women on the team moving forward

[-]

Green_Rooster9975@reddit

I think this is an underrated comment.

[-]

Legote@reddit

I agree we need to be mindful and more accommodating, but it's just outrageous and extreme sometimes.

It's anecdotal, but I've had a case where someone, whom I've never interacted with in person, accused me of sexual harassment for posting a software engineering meme on a slack channel, about the reality of what they ask you in SWE interviews vs reality of the job. Then proceeded to write a blog post about how the company is misogynistic once she left.

[-]

query_tech_sec@reddit

Um, what was the meme? There are misogynistic memes and it might have been one of those - even though you didn't mean it like that.

[-]

I’ll take a slightly different approach on this point - I’ve worked with a bunch of men and women over my career. In highly technical fields where CS always plays a critical role.

I’m a man, but I was raised by my mother, and I only had sisters. So I guess my argument is that I have a lot of experience, from an early age, navigating female dominated spaces.

I’ve taken the very patient, careful approach while trying to guide and support men. They don’t fucking catch on. I’m not saying you need to be rude, but you often have to be blunt. Not only that, but being seen as “fake nice” by appearing to “sugar coat” the truth will make some men laugh, while others become annoyed.

There are very often significant differences in optimal communication patterns. This is true for all people, but sex is a useful prior.

Going back to the example from OP, when “Susan” rebuffed his critique, it showed not only immaturity, but a lack of business awareness. If this person was very junior, it’s a time to teach. Beyond very junior, it’s a time to question their fit.

[-]

monkey_work@reddit

This is absolutely it. Men are just used to having a rougher tone with each other.

My girlfriend is a social worker and always says you need to say at least 5 times as many good things compared to critical things. I think 5 is a bit over the top and probably inspired by many snowflakes in her work environment. But she has a point. I started to point out at least as many good things in code reviews as I point out things that need to be changed. Devs around me started to adopt the same and it noticeably improved motivation.

I myself notice how uplifting it is to also get praise in code reviews.

[-]

peripateticman2026@reddit

Worst answer possible.

[-]

FriendshipStrong1485@reddit

This is a brilliant take, and I think it digs even deeper.

The reason men are "used to being treated poorly" is that a lot of traditional CS culture is basically a low-key hazing ritual. Think about brutal code reviews, "RTFM" (Read The F-ing Manual) attitudes, and professors who pride themselves on academic rigor by failing half the class.

Men who survive that pipeline are conditioned to see harsh, impersonal feedback as a sign of rigor, not a sign of a toxic culture. Women coming from a more collaborative scientific background see it for what it is: inefficient and hostile. It's not that women need 'softer' feedback; it's that they're correctly identifying a broken process that men have been taught to accept as "normal."

[-]

SnooCapers4506@reddit

I would also add that a lot of cultural issues start and ends with trust.

Why did Susan not feel comfortable voicing her dissatisfaction earlier to his face, for example.

Are there regular meetings to give this kind of feedback in a psychological safe way? Do you regularly try to increase trust between team members?

In my experience, when you work in an environment where people trust each other, it makes everything less stressful, more productive and overall just nicer.

[-]

chocolatesmelt@reddit

That’s been my anecdotal observation over the years. My personal opinion is that this is the general reason you see gender discrepancies in certain professions where men dominate the distribution. It’s not so much that it’s sexist, it’s that it’s often highly demanding and men are more apt to deal with the high demands than women are. Women tend to flock towards professions, careers, and jobs in general that have more reasonable expectations whereas men often just deal with it as a necessity.

My ongoing suspicion is that this also explains some gender pay gaps out there as well where men simply deal with more which leads to less desirable, more demanding, and/or higher volume work loads even in identically labeled roles which lead them to get slight pay boosts. On paper, it may look like men are getting paid more to the same work but per capita I suspect they’re simply doing more and getting paid less per unit of time they invest but overall a higher net take home. That’s just my opinion.

[-]

nedolya@reddit

Christ alive. Gender pay gaps are normalized by industry/job, how many times do we have to go over this. Also "reasonable expectations"? Like the female dominated professions of, say, nursing or teaching? Super famous for being easy cushy jobs, you're so right

[-]

Bobby-McBobster@reddit

This is an absolutely ridiculous suggestion when the problem that OP highlights is not people receiving harsh feedback but people simply receiving feedback.

The reality is men or women, those people are not suitable for the role if they 1) can't write basic algorithms and 2) refuse to improve them when pointed out. The only course of action here is to fire them.

[-]

shrodikan@reddit

The part that may be missing is we are only getting OP's side of the story. The old adage of "it's not what you said it's how you said it" may apply here. The O(n^2) vs O(n) is clearly the correct engineering solution while throwing TBs of RAM at the problem is obviously not.

No senior dev worth their salt would disagree. The cost alone is prohibitive much less it being a ticking time-bomb. I would put money on soft skills would help. I don't know. I wasn't there. I just know it's something I've had to work on.

Maybe something as simple as "this code is scientifically sound and you did a great job ensuring it's accuracy. I noticed a way we can improve it to make it far more efficient. Throwing RAM at it isn't a good solution due to cost concerns provisioned AWS instances. Scalability issues. Etc."

It can't be easy being a woman in a male-dominated company god knows. I would NOT call algorithmic complexity "obscure CS trivia" but I assume "Susan" did not have a CS degree. Knowing your audience, not assuming knowledge and working through problems together can go a long way.

[-]

Wide-Pop6050@reddit

Yeah, the way you worded it is perfect. If OP or Susan‘s boss really did start talking about O(n) etc et. I can see how it may have come across wrong.

[-]

Bobby-McBobster@reddit

I don't know. I wasn't there.

How do you know it wasn’t harsh feedback?

How do you know it was? Why would you assume it was?

And what, then, is your explanation why women are reacting differently than men?

Red herring. 2.5 years of median tenure is really not bad.

[-]

failsafe-author@reddit

I didn’t assume it was. But you assumed it wasn’t. That’s different.

The comment you are responding to suggested this as a possible explanation, and you outright rejected it as “absolutely ridiculous”.

So I am open to it as a possibility. You have written it off as not possible. You are making an assumption about the harshness of the feedback, while I am not.

[-]

orangeyouabanana@reddit

These ladies are computational biologists, not software engineers. They are no doubt super smart and capable in their field, but obviously not used to working in an environment where best-practices in software development are utilized. Since this is what differentiates this company from its competitors, as OP mentioned, it stands to reason that these ladies are aware of that and joined to learn these best practices. To that end, I think there could be an opportunity to frame the problem to help change attitudes towards receiving feedback, particularly when it comes to software engineering practices. I myself have a background in scientific computing, and would have relished learning how to convert my algo to O(1) at the beginning of my career in industry.

[-]

StormAeons@reddit

Yeah I’ve worked a lot with computational scientists, data scientists, and ML scientist teams. They always have terrible coding practices, the math is on point and that’s all they generally care about. Doesn’t have much to do with gender in my experience, it’s just common on those teams.

I would say the solution is communicating and vetting hires to make sure they are on board with improving and implementing best engineering practices. Then nobody is surprised and they know it’s important to the team.

[-]

DrXaos@reddit

A way to frame this is to value their experience, as in a software developer writing clean efficient code that gets the science wrong and then having the scientist tell them how to change it, is even less likely to be successful. Scientists usually can learn some software more easily than the software developers can learn the science enough to contribute.

The scientist’s core idea is still a bit more important, and the engineering requests are no different from a domain expert like a statistician on a biological or clinical trial offering advice and correction in their specific domain.

The reality that code starts at scientist first and is criticized makes them feel like being picked on.

[-]

Bobby-McBobster@reddit

Which is why I included point 2).

It's fine to write shit code. It's not fine to not care when pointed out it's shit code.

[-]

Altamistral@reddit

Can't agree more.

We all write shit code sometimes.

I wrote plenty of shit code in my career.

I cherish every time I was told how to improve my shitty code.

[-]

RegrettableBiscuit@reddit

Well, you did find the right place of work for this kind of callous behavior.

[-]

Mirage-Mirage-Mirage@reddit

It’s funny that you see no connection between using language like “absolutely ridiculous” and “harsh feedback”. Great self awareness.

[-]

pineapple_santa@reddit

Some people are unable to take any kind of criticism, but it is not immediately apparent from the post if the feedback was well delivered.

It pays off to reflect on whether you just gave bad feedback or if you are actually dealing with a bad egg.

[-]

At first people were thinking of this as a "how to treat women better" problem, but what we actually realized is that the men were just used to being treated poorly. Things like harsh feedback, minimal support, etc. Addressing these issues not only resolved the issues the women were complaining about but improved morale among the men as well.

It's absolutely this.

The reality some need to face is that women are going to be nearly as equally distributed on the bell curve of ability as men. That means that for every 10 men who might have scored 90s in their exams, there might be 1 woman. And every company, especially with diversity quotas being a thing, are going to snap up the ones on the right side of the bell curve, leaving you with, well... frankly a lot of very low-performing women filling the rest of the employment pool.

This creates a few problems - first being that people (and because the field is male-dominated, this gets interpreted as 'men', even though it would be equally distributed) get frustrated when colleagues under-perform, or are just plain incompetent. And you better bet that if those employees were guys and under-performing, they weren't going to be getting that support or any special treatment - so why the hell would they feel a need to treat others with any level of special treatment that they or their colleagues didn't get.

The second is that it creates a massive disservice to all women. Because of those who get there based on gender diversity quotas, and who get either special treatment or can't be fired because of wanting to meet them, it leaves the impression that other women aren't actually legitimately getting to those positions and attaining their roles because of merit only, or being able to function.

Perhaps we should be encouraging, as an industry, or using women in these kinds of roles as a canary to identify more widespread-cultural problems with a company. Not in interpreting it that women are being treated poorly because they're women, but because if it's this bad for the women willing to speak up about it, it's likely out of control for the remainder of employees and they're just staying silent about it because they've had it drilled in to them to accept it as being 'normal' when maybe, just maybe, it's not.

[-]

BothWaysItGoes@reddit

Did that influence any business and HR metrics? Improved scores on team barometer? Faster time to market? I personally wouldn't like to work in an environment where mild feedback is prioritized over my time and money.

[-]

leros@reddit

It drastically improved team dynamics. Better collaboration, better output, happier employees, etc.

It's funny because men would say things like "I prefer the direct feedback I'm getting now over fluff" but then they come out of things like 1:1s happier and more excited when getting more positive "fluff" in their feedback.

[-]

pheonixblade9@reddit

I explicitly asked for the opposite from my manager at Meta. He had previously been at Amazon for over a decade.

I told him that our 1:1's felt like 30 minutes of all the way I suck and that I do better when I get a mix of positive and negative feedback.

He told me he only gives positive feedback when people go above and beyond.

macoafi@reddit

That's why you pair up the critical feedback with the positive feedback.

[-]

drink_with_me_to_day@reddit

Research shows the 'compliment sandwich' is no longer effective

[-]

pheonixblade9@reddit

because the compliment sandwich feels synthetic and saccharine.

people should listen to the manager tools podcast on how to give feedback. it's worth the time.

[-]

jmking@reddit

Things like harsh feedback, minimal support, etc.

The easiest first step in initiating positive change in this area is to remind people that PRs and docs and so on are also places to share positive feedback - not just criticism.

It flicks a little switch in your brain to instead hyperfocusing on hunting down what's wrong that they should also be looking to call out what's right as well.

A little "I love this abstraction. It really simplifies how we've been integrating these modules and solves for that problem we've been having with inconsistent logging. Do you think this approach would work for App X?"

You're reinforcing good practices, helping spread knowledge, and encouraging collaboration. It also helps foster a culture of appreciation and helps stamp out those feelings of insecurity that lead to weird paranoia and imposter syndrome anxiety.

[-]

dexter2011412@reddit

were just used to being treated poorly. Things like harsh feedback, minimal support, etc.

LoL, literally me

[-]

opened_just_a_crack@reddit

Hitting me in the soft spot..

[-]

n0t_4_thr0w4w4y@reddit

Wow, this isn’t something I would’ve thought of, but reflecting on my experiences, it makes sense. Thank you for sharing.

[-]

mrbrick@reddit

This is something we found at a place I worked for quite awhile. I talked to my wife about it and wondering about things we could do but it kinda turned into this thing about how this is the patriarchy hurting men. The more I thought about it the more it seemed that was likely- but then ultimately I just wanted to do my job and move on and stress less.

I ended up finding a solution and it was quitting and finding a new job doing something else completely

[-]

Ok-Letterhead3405@reddit

Oof. Okay. If I may.

First of all, "engineering minutiae" kinda sounds like a nice way of saying, too much focus on trivial technical details and too little focus on delivering or caring about the end user. I've experienced this as a frontend dev, which is likely quite different work than your team's, but I've come across devs who would want to over-engineer the frontend but then never learn any of the skills they considered "less technical."

You likely have some very talented women who are feeling a TON of pressure to not be "the dumb girl" on the team, who feel outnumbered by men who likely don't seem particularly empathetic, who feel like they can't or shouldn't make mistakes, who maybe were driven to do things more quickly in previous jobs, etc. Velma likely has imposter syndrome and is being defensive in code reviews due to being in a sort of self-preservation survival state of mind.

In other words, for a bunch of reasons having to do with a mix of women's experiences in tech (which often starts in college and early jobs, and can be the most pronounced at that stage) and possibly shittier previous employers, Velma could be dealing with a lot of stuff you can't see, that to you just looks like, "These women just want the job dumbed down." But I bet you Velma and others would be a LOT happier if they could only feel some more psychological safety.

How you get there, well, I think some kind of mentoring that's framed as being good for their careers, and put in a very positive, friendly light, will go a looooong way. Maybe you guys can't do that, but you can implement that kind of attitude on your team at least a little bit, right?

Give positive feedback wherever you can and remind the ladies that they're here because they're good, and hey, if they just learned a bad habit at a previous job, no problem, we can work on that!

If you ask for a lot of re-work on a code review that might bump the time to merge by another day or two, offer to support them in the next standup and communicate to the team that, hey, we found some better way to do this thing, and I'm helping her get it done, it's just going to take a little extra time.

Be open to learning from your female colleagues. I've dealt with at least a couple guys who, sure, they could run circles around me in some areas, but when it came to an area that I had far more interest and experience working in, that they had kinda just neglected to learn more about, they've often debated me a bunch and then complained when I showed them documentation. Don't be like those guys. Even if you feel the debate is necessary, at least try to show that you recognize how much they know in that area and that you appreciate it. On your end, it might just look like you're doing your thing, so you might not realize how it's coming off.

A lot of times, us women don't feel supported. We kinda feel on our own. We're very highly critical of ourselves and too often trying to make too many people happy and feeling very unhappy ourselves.

The name of the game to retaining women is positivity and support. Not babying. Not dumbing down. Just letting them know that you care about their career and are there as a partner in dev, not just another guy they feel criticism from.

The good thing about doing this is, also, do it for everybody! Make an effort to change the team culture. Some team cultures are more like, competitive, arguing, debating. Women like collaboration, which is just as valid. And a lot of more quiet guys or those guys who feel less secure in their jobs for whatever reason, real or imagined, will also benefit from such a culture. People like to frame keeping women in tech as this extra thing that's an additional privilege just given to us and for our benefit, but good inclusion helps everybody.

It's exactly this. OP has not created a safe space for Susan.

[-]

keiser_sozze@reddit

Can you give more hints on what that means and how to improve psychological safety? I’m facing the exact same issue with limited number of women that I’m working with (limited, because women are almost non-existent where I am, >95% of applicants are men), they are statistically much more inclined to push back against technical feedback, I‘m very aware of it and talked about it in 1:1s but so far couldn‘t get anything further than arguments supporting their side, the kind that OP mentioned like „but it works“. I have been so far inclined to believe that their experiences in the industry so far make them take a defensive posture, and that must be somehow related to whatever gender related issues they‘ve faced so far.

[-]

Ok-Leopard-9917@reddit

You may need to demonstrate that you respect them and their skillset and value their input. Don’t talk over them in meetings, don’t repeat their ideas as your own, don’t provide overly critical feedback, and don’t continue talking for more than 2 min without letting someone else speak.

[-]

kifbkrdb@reddit

I'm a woman in SRE / infra, it's very common for me to be the only woman in my team and one of maybe 2-3 women across my entire department. I don't even think about it most of the time because most places are ok culture-wise. I've been a senior for a bunch of years now, I mentor and give feedback to more junior people regularly now.

I mention this as context because I don't think the issue here is psychological safety or women being defensive due to their gender.

If you're someone who's senior enough to mentor and give technical feedback to more junior staff, a large part of your jobs in general is to clearly communicate technical issues to a wide range of stakeholders and get buy-in for your point of view.

If you consistently can't do that with your female reports / mentees, that's a sign that you have some work to do on your communication skills. It's very likely you're also not getting through to male reports / mentees, they're just more likely to go along with your feedback even if they don't understand it. So take this as an opportunity to understand where you could do better. Next time a woman pushes back on your feedback, take the time to dig into what they've understood from what you said and why they didn't find it convincing.

[-]

Beautiful-Count-474@reddit

If you consistently can't do that with your female reports / mentees, that's a sign that you have some work to do on your communication skills

Or, maybe they just have more trouble understanding technical feedback? Maybe they have some work on their comprehension skills? Or maybe they think they know better than their more experienced superiors? I think it's weird that everyone is putting the onus in the existing culture to change rather than expecting the newbies to adapt.

[-]

Educational-Ant-9587@reddit

If the culture is not great to begin with, then yes, it should change. This will.make it better for everyone, women and men included.

[-]

Wide-Pop6050@reddit

Psychological safety means that people on your team feel supported and like they can have discussions with you and that you will be open to it. I’m kind of confused about how you describe your one-to-ones. If I was Susan’s boss, I would explain the resource issue without using industry specific terms and then talk to her about exactly what needs to be done. Not in a micromanaging way just in a clear way. What do you do?

[-]

ballsohaahd@reddit

Can you explain how you know that when the only information you have is what OP said and what he said didn’t mention any of that?

Genuinely curious what evidence you used to come up with that.

[-]

WalidfromMorocco@reddit

Women-are-wonderful effect.

[-]

Beginning_Tear_5935@reddit

Right?

If I’m going to reject a comment on my PR, I find documentation to justify my position and attach it. Plus, you don’t even have to do this. If you think the comment is nitpicking, then diplomatically ask them to justify their own suggestion.

At that point, they’ll either come up with a good reason and you’d have learned something. Or they’ll admit they were nitpicking and you can graciously thank them for their input and ignore the suggestion.

When I first joined, I used to be nerve-wracked about getting feedback on my code. But now, I actually really love these discussions when it happens. On my team, they get long and passionate. I mentally take sides at the start and then see what position won the “debate.”

[-]

Beautiful-Count-474@reddit

besides the fact that women are generally better at communicating their feelings than me

God, I just love the sexism! Maybe women just aren't good at receiving feedback or adjusting to new situations? Or, men are better at engineering. Isn't sexism great!?

[-]

silvergreen123@reddit

I don't think it's about communicating because she hid this from him. The data show that women leave earlier than men. So it seems much more so that women take feedback more personally than men.

[-]

psyyduck@reddit

That's a great article, but Google's large-scale, impersonal layoffs directly threaten this foundation. The ultimate professional risk is job loss.

[-]

Ok-Leopard-9917@reddit

Does your hiring process include a coding interview? It seems odd to hire scientists without a CS background and then expect them to develop good software. It’s a completely different skillset. Does Susan even want to become a better software developer?

Familiar-Two8331@reddit

This statement reminds me of DEI meetings run by management where you are supposed to discuss problems in the workplace but not be negative.

[-]

Beginning_Tear_5935@reddit

Fair enough.

But I feel like, because it’s for women in tech, it HAS to be about discussing problems?

At least the DEI meetings end after 30 minutes

[-]

bit_shuffle@reddit

Every junior engineer has...

Emotional attachment to their code. They wrote it, after all, right?
A "me" instead of "us" mentality. This is an effect of their training, as well as their youth.

And other "human factors."

If you're doing computational science, your hires are going to skew towards a pool of talent that has more theoretical math training than software engineering training, as you have said.

The traditional engineering programs will have "senior capstone" and that's often the most exposure to team activity the student has until they hit Real World.

One thing I've noticed in a program I'm taking many decades after my math-heavy computer-science-light first educational experiences, is that Software Engineering programs bring students into team projects far earlier than standard engineering or science programs.

Almost all of the classes I've taken under the software engineering department banner on my recent pass through the educational realm, have some kind of team project that runs a full term. There are junior and senior level multi-term courses that are basically "mock jobs" with the full agile/scrum process supported with Kanban tools, peer review and source control, with coursework to be done on a "legacy" code base grabbed from some open-source github repo.

And I mention this because having that early exposure to team efforts, and peer review, forces the student to

Accept the fact that the code they write is going to be critiqued and changed by other people, and possibly not used at all.
Realize that making team contributions that move the project to done are more important than "getting to do the cool part."

So when that software engineering student, who is almost certainly a math lightweight you wouldn't consider hiring, goes into a software-heavy environment... 1 & 2 are not factors. They got over that shit in sophomore year, or didn't finish the program.

By hiring the for math talent first, technical skills second, you are inherently buying into Human Factors 1 & 2. That is your hiring-practice engineering tradeoff.

So I don't think you're necessarily seeing a gender issue that you can fix from within your org. The problem isn't your team's culture, because your team's culture is to pursue industry standard/best practice. It is the failure of parts of the educational system to acculturate young people to the Real World.

I think the women you are hiring are coming from the math-intensive, software-light disciplines, and have always worked alone instead of the context of a team.

Have you got any women in your group who have did school sports? Or had other teamwork experiences prior to coming into the working world? You can see what I mean by looking at your survivor pool.

bluetrust@reddit

Oh my god, I just looked it up. It's $360/hour. $263k/year. This example has to be exaggerated, right?

[-]

_DonRa_@reddit

Not really, I can see that easily happening when space complexity goes from O(n) to O(n^2) when working with big data. (If n=1 million that means you'd need something in the order of a million times more RAM for the latter algorithm)

[-]

Imoa@reddit

It likely is not. I worked for a think tank that did economic policy research and we had coding standards much like he describes in his post. We had a dataset that was several gigs in size that people would push onto the stack multiple times over and over. The code took almost 60 gigs to run despite a dataset 1/30 that size.

The focus was on publication and getting it done. Runtime and memory are only important if they cause large cost runovers and preventative measures aren’t valued much - you address it when it becomes a problem. Code takes 4 hours to run? That’s okay - this publication isn’t due for a month. Takes 100GB of memory? No problem just make sure the EC2 is shut off afterwards.

I can ABSOLUTELY see people who learn development in that setting getting frustrated by being held to normal code review / standards - because it was my experience too.

[-]

dlm2137@reddit

Yup. The culture at my startup is similar -- management is explicitly making the trade-off of higher cloud costs with lower costs for developer time. Might be a good idea for our scale, I guess, but I worry that when the tech debt does come due we won't have cultivated the skills necessary to address it.

It's frustrating because I think there is probably some low-hanging fruit in terms of optimizations that we could make, but my manager won't even let me take a look at the cloud costs.

[-]

Imoa@reddit

My salary at the think tank far outweighed the excess cloud costs - especially because most stuff was run on a subset of the data locally, only big runs were done in the cloud so it was just a few hundred.

It’s very hard to convince people that $100 a month in cloud costs is a valid reason to overhaul code - I would even argue they’re right to not do it. The costs of an engineer doing the rewrite are far higher than the inefficiency costs.

I couldn’t even convince my think tank to use a database for the data instead of CSVs, because the economists and researchers didn’t know SQL so the change would be disruptive and slow down delivery in the short term without a commensurate delivery speed up down the line.

DrShocker@reddit

I can't believe I forgot about the zeros, you're right.

Yeah that's kinda an insane difference

[-]

rgbhfg@reddit

Nope. Seen the same play out a bunch of times.

[-]

Piesu@reddit

I would say this may be the way to go.

Hearing "you should do this because I say it is the correct way (because I say so)" sucks and creates resistance.

Hearing "you should do this because it will save company x$" makes sense. And if is x small (specially if it is smaller then what will cost to improve it) then probably you shouldn't do it.

Size of X is the difference between cost saving/code improvement and over engineer and wasting time.

I would say, often when you're asking people to do something, it is nice and useful to justify it in a way that other side can understand/relate.

[-]

Sheldor5@reddit

O(n²) vs O(n) is a no-brainer and shouldn't create resistance ... if it does, get rid of that braindead coworker lol

[-]

Beginning_Tear_5935@reddit

They might not know the difference? If they majored in something like chemistry and learned scripting in a lab.

[-]

aitadiy@reddit (OP)

Velma (the VP) absolutely knew, and agreed that Susan (the scientist) was in the wrong.

Susan's reasoning was that compared to the overall cost of the product (a few hundred dollars), an extra few dollars in compute costs did not matter. I thought she ultimately came around to all the obvious counterpoints I gave her (margins matter, what if the data gets substantially bigger, because we provision VMs on-the-fly, it can be very hard to find that much capacity, etc.), but apparently she was put off?

[-]

look@reddit

If this was just Susan then I’d say it’s probably just an issue with Susan. But it sounds like this is not just Susan…

I’m sure you and your coworkers are all well-intentioned, but this sounds like a communication style problem that may have taken root in the senior/staff culture.

UVRaveFairy@reddit

r/womenintech

[-]

Familiar-Two8331@reddit

If you really want to know the answer to why women are leaving I recommend this.

[-]

Bobby-McBobster@reddit

Big O's before hoes.

[-]

Familiar-Two8331@reddit

The Amazon way.

[-]

kr00j@reddit

\~20YoE Principal over here - with almost zero exceptions, the most competent, helpful, and productive people I've worked with were women, so Susan just sounds like an idiot, nothing more. The number of soft-ass egos I see in this field is astounding: you push back or question anything and it's as though you drowned their dog. Some of these folks would serve well to work in construction or medicine for a few years to see what a real ass-chewing looks like.

Formal-Ad3719@reddit

if you do bad work you SHOULD get bad feedback

[-]

katarh@reddit

No.

"Bad Feedback" in this context doesn't mean "Your performance was bad." Of course you need to let someone know that their work was not up to standards, and that they will need to do better next time.

"Bad feedback" in this case means the manner in which that sentiment is conveyed.

You can give someone good feedback for a bad performance! It's called constructive criticism.

Which one is more likely to motivate an employee to do better next time?

Bad feedback: "Your algorithm work was inefficient and shoddy. I had to rewrite your code. Read through it and do better next time."

Better feedback: "Your algorithm work is functional, but there are a couple of better ways to achieve the same thing. The main problem with the methods you have in this are that it's not efficient. Have you ever had a chance to learn XYZ optimization trick? Let's go through the code together, and you can explain to me why you did what you did, and we can look for ways to improve it."

I used to be a TA in college.

When I graded intro CS, I attached reasonably short articles on the importance of asymptomatic complexity to my feedback all the time.

I’m sure the devs at this company can do the same.

At my first software engineering internship, this was something my boss did all the time as well. I majored in CS and I knew very little about software engineering. He explained things as they came up.

Most of us learn on the job.

[-]

light-triad@reddit

I can’t really suggest comprehensive documentation without knowing more about their company, but a section on big O complexity, and the importance on linear time solutions would likely be helpful. It should give examples of these optimizations, and describe in real world terms the issues with less efficient implementations.

A section on estimating infrastructure costs and how to make trade offs between spending money on more resources vs optimizing code would also be helpful.

[-]

Maybe_Factor@reddit

In Susan's case, it's "linear space solutions", not time, but ultimately both, along with some mention of trade offs between the two, would be in this documentation.

[-]

Schmittfried@reddit

So essentially you do write a „How to be an engineer“ guide. Guess there is no way around it in a field where you have to expect people without an engineering background to work on engineering problems.

Thanks, that gives me something to think about!

[-]

light-triad@reddit

Yeah I work with a lot of data scientists and other types of people transitioning from math/science engineering. I’ve had to level up a few people’s engineering skills. I’m lucky in that

I’m able to spend a lot of time with them to build trust.
The engineers outnumber these people so that usually makes them feel like they need to do to catch up.

But if you’re getting a lot of these people and can’t spend a lot of time with them, centralized documentation is probably the way to go.

[-]

comrade8@reddit

You’d think that the person writing the code would also be aware of the size of the input the code would be running on. If the max size input was still relatively small (in the context of computers), then yes who cares if the solution is n^2. But if the problem space is large enough to where someone says “we can use a machine with terabytes of RAM”, that tells me that either they don’t understand how much cloud compute costs, they don’t care about engineering standards, or they don’t understand the problem space. None of which is really a good look.

[-]

Schmittfried@reddit

To me that response really shouted academia. They’re used to being granted access to huge clusters for the data processing they do in their research and don’t need to pay for it. They are not engineers, they are scientists, who first and foremost care about knowledge gain. That’s perfectly fine, but again that’s why a company that needs engineers has to manage expectations properly.

[-]

scott3387@reddit

Anyone from any scientific background should immediately get the point from one graph alone.

https://www.britannica.com/science/time-complexity

Also women have no excuse any more. Her real problem was that she didn't like being told you are wrong. Women never like that and many will argue they are right just for the sake of not admitting fault. Asking for help is admitting others are better than you. However these days we have ai and it actually does a really good of job of coding. She could just give the code to gpt and ask it to modify it. Then test the output and pass it off as your own work.

[-]

Lindsiria@reddit

This.

I'm a woman in CS who is in a job that is collapsing around us.

I decided to create a discord for disgruntled employees and those who has been let go to help support each other and back each other up. It's 100% networking and support.

All the men were shocked I created this and were shocked at the conditions of their fellow employees. They thought they were 'one of the few' feeling this way. I'm sitting here going... Wtf, it's fucking obvious.

I swear I'm the only one rising issues and calling out management shit. Everyone else is just keeping their heads down and accepting it. The communication issues are so different, it's eye opening.

[-]

Icy_Grapefruit_7891@reddit

I'm a hiring manager for SE and scientific staff for 17 years by now. My experience (but not any real data) after a few hundred hires across three organisations (two large, one smaller):

Generally, there are people of all genders that have good understanding of the software engineering side of things and of the algorithmic/scientific side, but people that combine both, ideally with a strong side of domain understanding, are really rare. It seems that your organisation has been able to find quite a few of these, congratulations!

I can´t say I have noticed a strong gender bias one way or the other in that aspect so far. But also in my observed group, I noticed that far more women then men tend to leave core CS roles and go for other roles that are more soft skill focused such as Project Management or Product Owner.

One aspect that quite a few female staff members have told me in feedback talks is that indeed they have had the feeling that their work gets criticized because they made it (so they feel some form of mansplaining). In my experience, they have been defensive from the get-go and haven`t really been used to absolutely valid criticism, e.g. as voiced in a (perfectly reasonable) Pull Request comment. If I had to guess, I would say that there was a phase where women were receiving a lot of positive feedback "just" for picking up a STEM job in a male-dominated field, and were then not really used to feedback they perceived as negative or critical.

[-]

Maybe_Factor@reddit

It sounds like expecting scientists to write good clean code is too much for them. Let the scientists make algorithms, and hire actual engineers to implement the algorithms. It'll be a lot easier to push back on an O(n\^2) algorithm before it's implemented and tested.

[-]

ChibiRay@reddit

This seems more like a personality or mindset issue than a technical one. Some people approach problem solving differently, rather than viewing feedback as a chance to improve and write cleaner code, they see it as unnecessary hassle and extra work, even if their original method was functional. The key is fostering a culture of continuous improvement and learning within your team. One way to do this is by asking them to propose multiple approaches before they start coding. That way, they’re less likely to feel like their work is being nitpicked after the fact and more likely to see the process as collaborative.

GuavaBrigade@reddit

I’m very surprised to see no one bringing up the idea of centering your feedback on a higher goal. Especially if the leadership response was that OP is “showing off knowledge of obscure CS trivia.” This is a sign you’re not effectively communicating why your feedback is valuable.

Especially in a high performing environment with high expectations. I agree about pair programming as part of it, because this is partially a knowledge / mentorship / skill issue. But also, code review comments like “please follow X rule, it makes things more readable, blah blah” is much more pleasant and collaborative (and will teach the other person to solve these problems before they reach you), than just “fix^”.

[-]

PureQuatsch@reddit

That line about obscure CS trivia also stood out to me. I’m willing to bet cold hard cash that OP is the type to get on a roll about certain CS topics and then not take a moment to breathe, listen, check understanding, or really know how to mentor/guide someone.

I’ve seen a lot of cases like this as someone in management and to me it sounds like code for "People think you’re a smartass who doesn’t listen or support other staff“. It might not even be OP specifically but a culture of it.

[-]

wosayit@reddit

I’d agree if OP was talking about some obscure CS but time complexity is pretty basic and if you don’t understand that then you should go and take a course. Leads are there to mentor and guide not teach CS101.

[-]

dilla_zilla@reddit

I think you've missed the point that these aren't computer scientists/SWEs, they're computational biologists. While they may well have learned time complexity in CS101, it wasn't reinforced by the rest of their CS education because they never took it. They've never done a LC style interview where those questions would be asked because that isn't their job.

nedolya@reddit

100000%, people in academia and/or hard sciences have a completely different experience with coding. Maybe they took a computer science for scientists class in college at best. It's a profession gap more than anything else, and probably also communication. I mean yeah maybe she's just incapable of accepting feedback. But if it's a widespread issue......? There's no way every single woman they hire has the same personality

[-]

maigpy@reddit

this isn't so much about the cs trivia. To me what stood out was the 32tb max memory comment. very out of touch

[-]

Wide-Pop6050@reddit

I think a lot of software engineers don’t want to admit this point. If leadership thinks that you are talking about obscure trivia, it is your job to show them why it is important and relevant to the business. It is also about trade-off - if that extra hour of computing time with expensive but not crazy it might be worth just dealing with it to the business. More worth it than it would be to redo the code.

[-]

stikves@reddit

[-]

MostTattyBojangles@reddit

Once a PR is submitted it’s often too late to do a decent review without creating rework or even coming up against ego or hurt feelings.

Pairing or even just a quick alignment before picking up the work can save a lot of pain.

It’s also helpful to set up custom linting rules that enforce your engineering standards, or even benchmarks that can be applied automatically knowing the constraints of your prod infrastructure, because then it takes the ego out of the equation because the CI pipeline is the blocking the PR, not a colleague. I like these a lot because you tend to need a strong reason to bypass a linting rule.

[-]

halfercode@reddit

It’s tough to provide feedback that requires a complete rewrite after the work is done

I agree with that. One technique I've found that works well is an early/30% PR, which sketches out a non-working solution, with a code example or partial change, and a description of what would be left to do.

[-]

midwestcsstudent@reddit

Yeah sounds like she should have run the design by someone else before writing it all, though. Whether that was her fault or the org’s fault… we don’t know.

[-]

shto@reddit

Very interesting post. Thank you for sharing.

A few notes from my side.

the biggest AWS VM has 32 TB of RAM, so until we hit that I don’t see any problem.

There is a pro and con argument to be had on this specific conversation. "Throwing money at a problem" is a valid solution in some cases. However, there is a limit too, and if you can fix something in an hour and save some money and time, why not do it? Not sure if there was some time crunch behind the pushback though.

I would say that this is where personality, personal choices in how to respond, and power imbalances come into play – are you more senior than she is? Does she have a problem with that? Does she have a bad attitude towards taking feedback? Is this the hill she wants to die on?

I get plenty of what I find ridiculous / exaggerated feedback from peers, but 90% of the time I apply it, because we all own the code and PR reviews are a team-effort in itself.

feeling that I was “trying to run circles around her by showing off my knowledge of obscure CS trivia.”

She is doing a lot of assuming there. Not a psychologist, but this could show a certain insecurity about her own skillset. Maybe she has a chip on her shoulder? The alternative could be to look at this as an opportunity to learn, i.e. "how great it is to work at a company where I work with smart people that help me understand how to improve my code." (I would personally think like that)

I will of course assume that your feedback was given in an elegant / neutral tone. Judging from your writing above I expect that to be the case.

That said, Susan did not directly voice this displeasure to me, and with some guidance, ended up implementing the fix. Her tool now runs great in production.

I could see there being a difference in the comfort men and women have in confrontation, and that may translate into how these conversations happen in the workplace. This also to your point about other men being fine with feedback about their code under- or over-performance.

While I have actually worked with many women that have given direct feedback, I feel like that is also the organization we are in – if a manager receives feedback from person A about person B, they will direct person A to give feedback to person B directly, and only if the situation is not resolved that way, get involved. Maybe this is something where your manager could step in too.

In the end, you obviously have 2 choices: lower the standards or keep them. This also boils down to what hill you are willing to die on.

Lowering the standards would mean higher code throughput, likely more cost for the infrastructure, and who knows: more team cohesion? At the expense of a meh codebase that will likely devolve to the lowest common denominator.

Keep the high standards with your above mentioned benefits and pitfalls.

IMO, keep the standards high, but make it abundantly clear when people join the team that those standards exist and that people will have to abide by them; they will have to make changes to the code that include performance. You can reframe it positively from the get-go by explaining that this is a unique opportunity for them to continue learning and have a codebase that is easily parseable (less mental strain etc.)

Tell your manager that any feedback conversations need to be had directly between people. Even if it is out of their comfort zone it's much better to have those conversations directly rather than "going behind someone's back" via a manager.

Good luck and thanks for the interesting post.

[-]

khunibatak@reddit

I have been working in scientific environments and before that in Enterprise Software. I don't think this is a gender issue as much as being a science issue. For example, there was basically zero disconnect between women and men in the Enterprise company.

What I found in academia was that nobody considered anything other than jupyter notebooks and huge CSVs with investing time in. To be entirely fair, if someone is aiming for a career in academia, learning about CS/SWE things doesn't seem to be worthwhile at first. I think it's better to gently introduce "engineering standards" as a worthy endeavor that can only help developers (even scientist developers) rather than be a distraction.

None of that happened.

You didn’t grok the post.

[-]

salty_cluck@reddit

I’m providing a list of things that OP can look at and reflect on if he really wants to understand what would make an organization have gender discrimination issues. They are common sense.

If he didn’t do any of that he’s good. But my point is that this doesn’t read as a gender issue and “Susan” and OP are not aligned on what code expectations are at this organization.

If there is a gender issue, it’s impossible to tell because we get OPs view only, which at best reads like OP is dancing around what he’s actually trying to convey.

[-]

DrFloyd5@reddit

It is ignorant to suggest a list and assume it is the sum total of all possible gender issues. Clearly something else is going on here. There is a disproportionate number of women leaving. If they have a common reason for leaving there is clearly an issue not on your holy list.

[-]

tinmanjk@reddit

Why so negative with all the don'ts.

Let's just summarize OP's post on what women like

Pushing back on why O(n^(2)) memory is not necessarily worse than O(n) for production use instead of admitting that they didn't take the best approach outright
TBs of memory
Labeling good engineering as “engineering minutiae”

[-]

shrodikan@reddit

It's true the women in my life love when I write my code O(n^2). /s

It's obviously defensiveness and might have been avoided by improved soft-skills. A developer with sound scientific understanding but (probably) a lack of a CS degree. Instead of reading what was said try reading what was felt by Susan. Basic soft skills help a lot.

I was responsible for reviewing her code, and she pushed back when I told her this would be unacceptable for production use.

This right here is the problem if this was OP's response to "Susan."

A better response would be "You obviously understand the subject matter very well as this code is accurate. I noticed a way we can make this more efficient. This will use a lot of memory. walk "Susan" through the fix. Get it deployed. High-fives all around.

"Are you familiar with O(n) or algorithmic complexity? This is how it is calculated. This is how you can be mindful of it in the future..."

This would establish a mentor-mentee relationship instead of saying "your code is unsuitable for production and will blow up there."

[-]

midwestcsstudent@reddit

Yeah this is crazy.

[-]

Ok then, keep putting up with shitty working environments because there’s CLEARLY nothing you can do about it.

[-]

Sheldor5@reddit

if nurses are getting paid that little money why don't they simply change that?

the majority of workers (no matter the industry) don't want to change anything because they are afraid of risking their position/job or are just comfortable ... I can change myself and speak up and hope that my coworkers do the same so we can create a strong unit but most simply don't want to (lazy, scared, "change is bad", ...) ... I had this conversation with a lot of friends who were complaining about their shitty jobs but none of them wanted to change something because that would mean they had to change action and mostly also risking their job by simply speaking up

now we changed the topic from evolution theory to human psychology lol

[-]

michaeldain@reddit

Amazing thread. I’ve always puzzled over the hackathon problem. In my perspective, regular work would be embroiled in miscommunication of outcomes. Making stuff was never the issue. Unlike this example, the idea of scaling the memory isn’t bad if the real issue was to see if the goals were worth reaching before optimization. But in the hackathon a small team and a day seems to solve real business problems. Likely because they were solvable! Or show real talents and capabilities. That psychological safety is there. No penalties for failure. This is where the engineering mindset has to battle the real problems, what’s the outcome we desire?

[-]

AYamHah@reddit

Welcome to engineering? I don't think this is a gendered issue. I think a lot of women engineers would be offended that you couldn't critique their work on something so fundamental as the time or memory complexity of the solution. Like, are you an engineer or not? That's the only question here. Susan needs to take some time to understand the nuances of the problem.

[-]

liprais@reddit

subpar works deserves and calls for subpar words.

[-]

severoon@reddit

The computational biology division is about 90% men. About 25% of our hires are women, but their tenure at the company is much shorter than men’s (median of 2.5 years, compared with 5.5 years for men). A VP at the company (“Velma”) was tasked with improving this attrition discrepancy, and she met 1:1 with all senior members of the division, including myself.

…

Velma is being extremely rigorous about identifying this as a systemic problem; she went through transcripts of all of the division's exit interviews over the last few years, and interviewed multiple current team members.

How many of the people that Velma talked to are women? Is she interviewing them in a gender-blind fashion, or is she bringing them all together to discuss? Keep in mind that discussing with each other can include the higher-ups, but it can also be useful to have them discuss out of earshot of management so that they can identify individual interactions without feeling like they're putting anyone specific in the crosshairs, and then report back to management the results without identifying anyone specific if they don't want to.

I'm guessing that while 90% of the staff are men, I'm guessing that there are few if any women as you move up the org chart. Without even looking at reasons to do with bias, just based on the numbers you gave that women turn over much more quickly and you hire 25% women while they make up only 10% of staff at any given time, that means they are churning at the bottom a lot more. The thing to note here is that when your VP talks to high-up staff, she's talking exclusively to men.

This is, in and of itself, a problem. If you were to look at an org chart and see that there's some other underrepresented group that is a minority at your company even when adjusted for population, and they exclusively inhabit the lowest rungs of the ladder, that's going to create an association in everyone's mind that the two things are related. The company has to work hard to bring in some women at a higher level when head count is available there, either through internal promotion or hiring.

When it comes to solutions, everyone should be involved in contributing, but women should be driving which solutions are trialed. When it comes to nailing down the actual problems, though, this should be coming principally from the women.

according to Velma, Susan was actually very upset that I asked her to implement the O(n) fix, feeling that I was “trying to run circles around her by showing off my knowledge of obscure CS trivia.”

If this is representative of the feeling of women at the company, then there's one of two things going on here. One possibility is that, somehow, the underlying message isn't getting through. The other possibility is that there's a skill or a pipeline issue that's affecting women more than men.

I would test the former by bringing the women together and pushing on them a bit to get them to verbalize what this means, exactly. What's underlying it? Even if this is an accurate description of their feelings, it's a weird way to respond to critical feedback. That makes me wonder if there's some other gender dynamic at play here. Figure out what that is.

Test the latter by pulling the resumes of every woman hired in the last few years. How does the background of the women compare to the men? Are you getting men with more CS background, and women with more bio science background? I suspect this is the case, since CS is notorious for being male heavy, which is not so with biological and life sciences. If someone didn't study CS, then it's somewhat reasonable for them to say something like, "order n, order n squared, what's the difference?" Someone with a CS background would never say that. This says to me that women are generally "scientists who are also programming" whereas the men tend more towards "programmers who are also doing science" … does that line up?

If there's a significant discrepancy in the backgrounds of men vs. women, consider expanding your pipeline of females with a CS background, and focus on growing the CS skills of your existing female employees.

[-]

Dotagal@reddit

I have a suspicion it’s not about the standards or the actual feedback but how it was given. I think judging by how the title of this post was written OP wanted to frame this a certain way so that folks would take his side.

[-]

dexter2011412@reddit

quick to jump to assumptions now are we.

How else would you frame it? The post and content seemed within margin of error.

[-]

Dotagal@reddit

It’s not an assumption it’s an educated guess from my lived experience as a female engineer . I’ve dealt with enough people in my decade of experience to see through posts like this one

[-]

dexter2011412@reddit

and they were sharing theirs and asking for advice

[-]

Dotagal@reddit

Okay and? I don't understand what your point is

[-]

dexter2011412@reddit

That your assumption was wrong. And you didn't suggest how to rephrase it.

You added nothing to the discussion here.

[-]

Dotagal@reddit

I don’t think my assumption wrong. I added something to the conversation and that’s calling out op for writing this in bad faith.

[-]

RobinReborn@reddit

judging by how the title of this post was written OP wanted to frame this a certain way so that folks would take his side.

Don't we all want people to take our side?

I agree that it's probably how the feedback was given, people want validation.

[-]

katarh@reddit

There is a pretty good book out there called Thanks for the Feedback that is about how to give and receive criticism gracefully, both as a manager and as a subordinate.

Unless this was a trivial tool, why was a full solution implemented without any approvals? Sounds like time to blame the process here. RFCs and design docs, even code reviews exist for a reason.

[-]

Pavel_Tchitchikov@reddit

I kinda have several issues with this post too. It’s not that I don’t believe his claims could ever happen, but it’s more that his description of things smells like he’s giving a pretty biased view and omitting or rewording things to fit his own narrative.

Thinking back, there is a definite pattern of women on the team writing code that is generally scientifically sound but poor from an engineering/CS standpoint. I did not realize that women specifically were consistently being put off when asked to address these problems.

I’m not saying this can’t happen, but then I’d wonder if you just have hiring issues when it comes to women. most or all women in your team fit this description? Why are you consistently hiring under-performers like this? Maybe using a (competent) woman as part of the hiring process could also help, if you don’t have one already. We don’t have many women in my team but they’ve all earned their stripes and that makes a difference. I just don’t find we have noticeable different treatment and approaches when having to deal with an issue caused by a woman vs one caused by a man, but maybe that’s just not that common.

Instead, she said that the overwhelming reason women are dissatisfied is our focus on “engineering minutiae” (her exact words)

that I was “trying to run circles around her by showing off my knowledge of obscure CS trivia.”

To me this sounds like someone being pedantic in a situation where the optimisation suggested doesn’t actually have any effect because the function in question uses such small inputs, or it so rarely is used, that changing it would save you 0.000001 of a second or something.

I mean, the example OP gave could not be more straight-forward (O(n) vs O(n^2), consequences legitimately leading to TBs of memory being wasted… but I can’t help but wonder if that’s legitimately a good representation of the situation, given the complaints about “engineering minutiae” he received.

[-]

official_business@reddit

I mean, the example OP gave could not be more straight-forward (O(n) vs O(n2), consequences legitimately leading to TBs of memory being wasted… but I can’t help but wonder if that’s legitimately a good representation of the situation, given the complaints about “engineering minutiae” he received.

The way I read it is that Susan doesn't have the CS background to understand how serious a problem it is, and is interpreting the code review as malice.

If you know the size of your customer's data sets, and you're dismissing memory or CPU cycle waste of that order as "engineering minutiae" then my alarm bells would be going off.

It's something that can be benchmarked and measured with unit tests. It's easy to demonstrate.

[-]

Pavel_Tchitchikov@reddit

I fully agree with you, but it’s pretty nearly useless overoptimisation if you have a super well-engineered algorithm that only a small set of your programmers (those with CS theory / formal algorithmic backgrounds) understand, and that runs in 2 seconds instead of 5. I guess it’s the “minutiae” term that made wonder if this is the reality.

Of course, it could very well be that:

the algorithm is in fact not particularly difficult to understand, and/or
the algorithm has a drastic impact on production, because it operates on large enough datasets such that it runs your crucial operations in 2 seconds instead of 5 minutes.

In this case I’d strongly question the competency of his women in his team here, but I would equally question the competency of the person describing this as “minutiae”: this is not just minor details, this is something that has a huge effect on the production as a whole. This is no longer someone being pedantic with “obscure CS knowledge”, this is something that has huge long-term consequences on your entire business, and something every dev should be aware of. It’s irrelevant to whether or not the person they’re speaking to is a woman. Susan is either woefully incompetent and OP should push back and find more competent people, or train his current team such that they meet the expectations of devs. Susan framing something like this as a “hey women don’t take well to this sort of feedback” sounds insane to me, which is why I guess it doesn’t seem to match up to her “engineering minutiae” term employed. She just wouldn’t use that term if she understood the impacts being indicated by OP here, but it sounds like she’s either not hearing/understanding them, or OP just didn’t explain to Susan properly. I’m not saying it’s not possible, but I’m just guessing that there’s some severe miscommunication here (Susan didn’t understand the criticality of the job, or OP didn’t understand understand the example Susan gave) and that the way OP is framing the story is probably quite different to how Susan understands it.

[-]

Daedalus1907@reddit

>We don’t have many women in my team but they’ve all earned their stripes and that makes a difference. I just don’t find we have noticeable different treatment and approaches when having to deal with an issue caused by a woman vs one caused by a man, but maybe that’s just not that common.

OP mentioned in a comment that it's hard to hire people with biotech/data/CS background and tend to settle for 2/3. I'm guessing that it could just be the women are more likely to have primary skills in the biotech/data side of things.

[-]

fakemoose@reddit

Then they need to recognize and understand that their new hires won’t be proficient in 3/3 things. And it doesn’t really seem like they do.

My current team sounds similar to OPs but a different field. Some of us have code reviewed at small increments for this reason. We all come from different backgrounds and it’s not all strictly software. So we want to catch the small issues before they become big issues.

[-]

starbrightstar@reddit

Yes, I’d bet it’s also how the feedback was given. There’s this tone that men use (as someone in tech myself), that is just so frustratingly annoying. I’ve never heard women use it, but hear it constantly in men’s voices. It’s talking down to the person like they’re stupid.

I’ve also heard men use it on other men, who also end up leaving. But I’m not sure the men speak about it like women speak up.

[-]

aerrin@reddit

And possibly the culture around feedback in general, having to rework something, knowledge gaps, etc.

[-]

Noobsauce9001@reddit

#2 is my hunch!

[-]

alohashalom@reddit

I second #2

[-]

thr0waway12324@reddit

Alternative idea:

Split your team’s responsibilities. You have scientists who focus on scientific code and run experiments and such. Then you have engineers who take the scientific code and scale it up while consulting with the scientist to make sure the core implementation remains intact.

This isn’t just a theoretical idea either, it is actively implemented in practice in many fields and one such prominent example is in trading firms. There you will find quants who are essentially the “scientists” in this case. And they also hiring engineers who build the platform and scale up the quant algorithm implementations.

[-]

Thefriendlyfaceplant@reddit

I just finished 'Learning Systems Thinking' by Diana Montalion.

Not at all what I expected, I thought it would be more abstract and analytical but instead it was more about soft skills within system's architecture. Still highly valuable and an enjoyable read even if it only crystallised much of what I already knew.

Anyway, it also dips in culture, tech communication and feedback.

https://www.oreilly.com/library/view/learning-systems-thinking/9781098151324

That's not to say there''s a solution. I much agree with the top comment by Ieros, these are hard and complex subjects, details matter and feelings do not. You have to be able to tear into each other's logic without it getting personal. Generally speaking this is not something women are equipped for as the predisposed as well as conditioned to regard scrutiny as a threat. Women are used to lingering tensions that escalate and destroy reputations while men forget it by the time they've finished their lunch.

And I say 'generally' because I also know women who are utterly impervious to taking things personally and actually welcome harsh feedback while also being able and willing to dish it out without things lingering onward.

Sorry I don't have a solution here. Sometimes there may not be one.

[-]

-TRlNlTY-@reddit

I think this can be addressed by improving the hiring standards. Considering how much more women your company has employed than the industry average, it sounds like they are lowering standards to make some numbers go up. I am saying this only based on your story with Velma, there could be other reasons.

[-]

thekwoka@reddit

Well, if doing good work isn't something the women want to do...

It sounds like they are hiring scientists from a specific field, not CS grads.

[-]

OutrageousBat9796@reddit

Possibly but he's mentioned how they've trained people up several times throughout this post so I'd imagine someone with a decent technical background would be trainable

[-]

Schmittfried@reddit

If they are willing. It doesn’t sound like Susan is even interested in engineering. But that might just be due to the presentation in this thread.

Given how many physics/mathematics/biology graduates end up in adjacent fields m and considering they have a larger share of female graduates than engineering disciplines it’s absolutely plausible that a computational biology company ends up hiring several women who don’t even want to be engineers.

Which would mean the hiring process needs to be adapted to filter for, if not engineering skills, at least willingness to pick them up.

[-]

valium123@reddit

Exactly, keeping in mind that there a percentage of misogynist men who don't want women to work at these places. Almost every woman in tech faces this at some point like engineers being asked to fetch drinks at conferences etc.

[-]

OutrageousBat9796@reddit

True. I could be biased here but it's the fact the complaint says obscure CS trivia. I can remember working with a female dev who was by far the strongest dev on the team and the other senior (who was by all accounts useless) would go on these borderline hilarious info dumping rants about completely irrelevant things whenever she made a 'win' or was right about something/he was wrong. Fortunately she saw the funny side of it but had this developer not been such a blatant f up I'm not sure it would have been such a funny story. The scenario op gives absolutely sounds like he was correct and it's important to be keen to improve work when presented with a better solution, however the way she's phrased it makes me wonder whether there's other stories where perhaps it's quite a different narrative

[-]

psyyduck@reddit

These days you can often just throw spaghetti code into the LLM and it will spit out a 9/10 refactor. How is this still a problem?

[-]

Wide-Pop6050@reddit

Honestly, something about this comment is off-putting. Presumably these people were hired for other reasons, since their code was spaghetti. Do you acknowledge their skill set? I don't think the issue here is really men vs. women, it seems like classic engineering vs. not

[-]

Schmittfried@reddit

and give them the resources (mentorship) they need to learn the missing piece

Maybe you should add a third, non-negotiable criterion: if they even want to become engineers.

It might be a misunderstanding due to your summary, or maybe Susan replied like that because she felt unnecessarily criticized, but as it looks right now Susan didn’t even consider your suggestion worthwhile, which indicates to me that she is interested in science and not engineering. Which is perfectly valid, but maybe not a good fit for your org.

[-]

yall_gotta_move@reddit

Two things:

Are you hiring? I miss doing science, but I haven't gone back to it because the lack of engineering rigor would kill.
I suspect the issue is not the feedback that's being given but rather the way that it's being delivered. I strongly recommend https://conventionalcomments.org/ for reviews.

[-]

mc-funk@reddit

This is so great! Wish I’d known the conventional commits concept had been applied this way when I was working with some … choice people … before. Lacking a clear agreed-upon standard, the people delivering the comments aren’t generally the best qualified to distinguish between poorly given feedback and a poor reception for other reasons.

[-]

Efficient-Design-174@reddit

The conventional comment thing looks like a crutch for those who don't know how to provide constructive criticism to each other. Just be kind and fearless in your comments and leave the silly "suggestion (non-blocking)" noise to the LLMs.

[-]

mc-funk@reddit

It saves a lot of time to be able to provide a common reference rather than find the tactful yet assertive way to explain to someone that their comments are obnoxious and full of subjective, vague qualitative nonsense, especially when they are above you on the food chain…

[-]

Markietas@reddit

So this has been a major sticking point for my company for a while now in several categories (going as far to customer relations/ service).

We have a lot of people who have come out of an academic setting and are now trying to either write high performance code or do field tasks interfacing with paying customers etc.

I can mentor someone to death, but some people really need to hear from the top that these things are important. People like you and me naturally take pride in our work and look farther out than our core tasks to try and guess where there will be issues and optimize.

I've finally got our CEO to start making comments about this kind of stuff aimed at the borader team (my efforts were somewhat helped by a customer dramatically dropping out directly citing a team's disorganization), and I've been seeing some more proactivity from the people who have been less "rigorous" in the past.

For my part I try to not only show new hires the level of work we expect them to be at, but I also try to put as much time as possible into making sure they understand the WHY.

[-]

KellyShepardRepublic@reddit

Wouldn’t you want a and c? You can teach a software engineer data science and commonly learn it anyways but the other way around it is not so common cause the code breaks down too quickly to be useful.

[-]

Where do you work? I’d love to apply, everything you’ve described seems right up my alley, I’d love to work in a place that does biotech and also takes code quality seriously

[-]

angelicosphosphoros@reddit

Do you provide some adjustment period or training for new hires with pure scientific background?

As a software engineer, I got few courses at my university about creating good architecture, software design and testability. None of the more mathematically focuses students had these, and it shows.

[-]

I have a few thoughts as an experienced dev who also happens to be a woman.

Engineers, male and female alike, appreciate an engineering focused culture. I do, and it has nothing to do with my gender. People like their position at work to be one that is valued.
However, you can’t just have an engineering focused culture without good communication skills. No matter how experienced a teammate is, it helps to start with a high level explanation of the problem before deep diving into solutions and technical details. It helps others to context shift from their silo to yours so you can get on the same page. Susan may see the interaction as “running circles around her” if you’re going from 0 to 60, brain dumping at her instead of bringing her up to speed on what you’ve discovered. Even though she wrote the code, she may be working on something else now and need a quick refresh before a deep dive.
Just because Velma says the women aren’t complaining about bro culture, feeling dismissed, etc, doesn’t mean it’s not happening. Opening up to a higher up, like a VP, can backfire - even if the VP is also a woman. Many times women prefer to move on to other opportunities rather than be the squeaky wheel about something that likely won’t change in a particular workplace (and in these days of anti-DEI sentiment, could put a target on her back). We don’t want to have to do all this extra mental labor fixing the culture when it’s not part of our job.
Velma telling you exactly what Susan shared with her is a bit of a red flag. Was Susan under the impression that she was talking to Velma in confidence? This could point to a wider cultural issue.
You’re in a unique position in biotech because people tend to come in either from the “bio” side or the “tech” side. These are two very different foundations. Having a formal CS background in college definitely shaped how I function as a dev. Biology tends to be less male-dominated than tech, leading to more women coming in with the bio foundations and less of a formal CS background.
Did you use the specific O(n)/O(n2) terminology? These are terms that a former CS major will understand but a biotech or bio major might not. It’s actually a pretty intuitive concept to understand, but if you’re just saying O(n) with no context it does come off as “Cs trivia”. A simple explanation of what makes the solution better would go a long way.

[-]

sleepyguy007@reddit

susan should have be fired and you guys are lucky she left, and is using the sexism card to claim she isnt incompetant. thats it.

[-]

zayelion@reddit

You can take this as a failure of engineering standards over something gender related. Women are more sensitive to communication failures and, as Google found, tend to act as the glue between separated groups of people. You can see this as class of documentation failure and requirements craft failure from a non-people perspective.

The problem discussed wasnt an issue about complexity with Susan, it was an issue of communicating goals. For her the goal she was hired for, and all the women was communicated as science and not software engineering. The job is actually engineering and by getting beaten up the men realized this and men are kinda ok with getting told they are failures. Women not so much, especially when they have options.

The fix here is communicating financial requirements and business vision to them as part of the requirements process and business process. So the ASK of the business continues through to the writing of code, not stopping at the project manager. Over time the developers realize "oh yeah, this is a business, do things that make money" as an implied line of requirements. This is just part of the engineering mantra "write shit down, dont get hit by a bus"

[-]

Inner-Frame2095@reddit

Gender over skill

[-]

chaos_battery@reddit

As a broad generalization, women are more suitable for soft roles - think flight attendant, waitress, school teacher, Secretary, realtor, or any role involving people and social skills. That doesn't mean ALL women but in general if the stereotype fits... What I'm getting at is I've seen women in software engineering and I have nothing against it. It does lean heavier towards men but they should be able to handle the same feedback we get on pull requests. You presented a logical argument and she was unwilling to hear it and felt that the company paying exorbitant amounts for RAM was a solution. That's all she had to do was acknowledge your approach was logical and correct rather than making it about gender.

[-]

demosthenesss@reddit

The real issue OP is dealing with is likely a bunch of sexist jerks like you working there.

[-]

GoodnessIsTreasure@reddit

That's such a strong statement.

I would calculate a few things: * How long will it take me to rewrite it? * Would that rewrite be as easy for someone else to understand and for our team to maintain? * If we don’t fix it now, what about our dev process would make it more expensive to fix later? * How much more a year would it cost us in compute to just run the larger VM? ($50? $5000?) * What’s the likelihood we start seeing 5x more often or maybe even 10-100x? * What’s the benefit to making it run faster outside of cost savings? Do people need it sooner or does 20 mins not matter for how this data is being used?

I’d then compare the cost to implement now vs the cost to ignore and solve later and make the decision if it’s worth it to spend time “fixing” this or building another feature/fixing another bug.

[-]

bigbry2k3@reddit

Basic A.I. would recognize her solution as not optimal and provide feedback. So my suggestion is try to integrate A.I. into the review process. It could be less personal that way. Also a custom A.I. review process would be best based on your companies policies.

[-]

nneiole@reddit

You are generalizing about women based on one example? Or were there other concrete stories, except Susan, which didn’t make it to the post?

Also, reaction to „asked to address the problem“ differs very much based on the tone of this request, may be the problem is not that you asked her to correct O(n2) to O(n), but that you made her feel stupid by how you worded that?

[-]

aitadiy@reddit (OP)

Yes, there were several other examples that didn't make the post. Velma the VP identified this as a consistent problem, of which Susan is just one example.

you made her feel stupid by how you worded that?

The exact exchange went something like this:

Me: this uses too much memory, we'll need to address this

Susan: why? the highest memory consumption I saw was around 800 GB, and AWS has big machines. I'll run with 1 TB just to be safe.

Me: those are very expensive, and can be difficult to provision on-demand. also, it looks like memory scales like the square of the input, so we'll quickly bust past a TB if the input grows (which it likely will).

S: but AWS machines go up to 32 TB.

Me: those are even more expensive and harder to provision. plus, it's even possible that inputs will grow beyond a factor of 5-6x, which would blow past even 32 TB. let's just fix the underlying issue? I think it will be straightforward.

[-]

nahnette@reddit

You should definitely add this to the main post! Lots of good advice in this thread however.

What I notice is that in this exchange, you don’t end as collaborators, but as superior and subordinate. She does the fix because you told her to, not because she sees the value in the fix.

If you ended the conversation with “just fix it it’ll be easy” (paraphrasing your paraphrasing), that’s a conversation ending phrase. So no surprise she didn’t voice her dissatisfaction to you - depending on what words you actually used you might have closed the door on further discussion.

So my suggestion would be to look out for moments where you can either tell people what to do, or you can recruit them to join your cause. Look up the process of memory consumption with her, and compare it to the cost of developer time to implement a proper fix. Don’t end the conversation till your colleague understands the why of something - it’ll pay off in employee retention, and maybe she’ll notice another colleague playing fast and loose with resources and she’ll be the one to help them find a better way.

If this is tricky, try and find where your values align and start from there.

Final thought, what’s your ratio or praise to criticism? Off the top of my head, in relationships 5:1 nice to negative is recommended. And that’s with people you’re close to and have solid rapport with! If you’re below 1:1 that could explain why some colleagues meet you with a more defensive, combative attitude even if your criticisms have merit.

[-]

optio___espacio_@reddit

They aren't collaborators, they are explicitly a supervisor and a subordinate.

[-]

sedatesnail@reddit

Thanks for starting this topic. I've gained a lot of insight from the responses. Here's my 2 cents

"Me: this uses too much memory, we'll need to address this"

I can see how this phrasing could put somebody on the defensive. The words "too much" without any clarification are subjective and invite debate. And you may have good reason to believe memory will be an issue, but without communicating the reasoning it sounds dictatorial.

Further, the words "address this" could be perceived as being critical and condescending. I can imagine somebody, especially somebody who doesn't know you yet, hearing "You messed this up, now I have to help you do get it right"

Consider these alternatives

"I'm concerned this will use too much memory. What did you observe during development?"

This communicates that the memory may be an issue, and invites your peer to discuss it with you. From there you can introduce your reasoning as appropriate.

Or:

"I've had issues with our data scaling unexpectedly. I think this might be a concern here. What do you think about refactoring so that we can avoid that?

This introduces the idea that changes are made, but now it is based on your experience and not just some edict. Also, refactor is more concrete and less charged that "address this"

I think in both cases your coworker would respond similarly to your original phrasing, but it would be a collaboration now, instead of her defending her work.

[-]

Human_No-37374@reddit

wtf is this

[-]

capGpriv@reddit

Was this a conversation made over pr comments or did you try talking more directly?

[-]

aitadiy@reddit (OP)

For this particular example, both. Initial feedback was given via PR comments and the O(n^(2)) issues were specifically followed up in person. I don't know about the breakdown for the other instances Velma mentioned.

[-]

capGpriv@reddit

Honestly this pretty much exactly what I’d of done (similar field), but I have had months long arguments to stop bad physics algorithms

I’d question if they are struggling with training, the standard of code coming fresh out of unis and most scientists is bad, and often has an element of dunning kruger effect. (Not to say the people aren’t smart, they just lack the right training)

At least you aren’t having to deal with matlab

[-]

tinycockatoo@reddit

Hey, I'm a woman developer lol. I think the issue here is more about people from biosciences/data science lacking engineering fundamentals than anything else. Biosciences is a female-dominated field, whereas computer engineering is male-dominated, so when you hire those people and they work side by side as developers, it might seem like it's a gender thing.

Not to say women aren't more sensitive to feedback in general, but it doesn't seem Susan had quite the grasp on these underlying engineering issues. I'm on the data field, and it's pretty common to just let our machines go wild because we're doing exploratory work. I mean, I'm trying to fix this gap for myself, too, now that I've joined a team that does software that actually lasts.

On feedback: this is a very personal opinion, but I don't think softening feedback is the way. I am neurodivergent and struggle to understand criticism when it's coated in fluff. I realized I'm a soft, young-looking person, and also I'm generally very nice and helpful, so no one wants to be the bad guy and "hurt me" lol. It's a nice sentiment, but I think it holds me back from developing my skills. I absolutely love working with older cranky senior devs because my learning pace skyrockets.

Ideally, to ease this kind of friction, I think good practices could be written in "golden standard" docs. Then, in code review, you could refer to them instead of looking like you're nitpicking (you were not, just talking about optics here). Having a checklist of minimal standards to be met to have a new feature accepted – even something awfully generic like "easily understandable code", "optimize use of computing resources" – may coax people to think more carefully about it? That's my two cents, hope it's helpful

[-]

RandomChance@reddit

there are some pretty strong built-in generalizations and biases in this synopsis that you might want to examine.

Also, wild guess but from Susan's feedback, it sounds like she didn't understand what was being suggested, probably due to jargon that she wasn't familiar with, and lack of explanation or feeling of safety to admit she didn't know. Also info on what other deadlines were in place and the specifications of the assignment might put her position in context.

The very worst managers I've ever dealt with always had a "you should know this" attitude instead of a "let me teach you this attitude."

it also sounds like you need written guidelines on production standards. If that metric is important then it needs to be documented and built into the specs.

I don't believe this is a gender issue.

[-]

noonemustknowmysecre@reddit

The world of scientific computing is famous for shoddy software:

Yeah. Fact. It's a bunch of software made by non-programmers. Really smart people that learned it on the side and bulldozed their way past good practices and went right for the interesting hard problems that needed solving.

(Her pushback was along the lines of “the biggest AWS VM has 32 TB of RAM, so until we hit that I don’t see any problem.”)

. . . The COST!? Jeeeeesus, that would get any dev here a serious line of ridicule for trying to pull such a bullshit point and not seeing the obvious problem.

Yeah, for a vice principle, Velma doesn't understand what your company actually sells nor understands that the job you perform IS that engineering minutiae nor why peer reviews are valuable.

BUT. Read the room and see which way the winds are blowing. You sure as shit aren't going to win that fight if you buck heads. You will be accused of "bro-y culture, intellectual dismissal, and outright sexism". Do not engage. "Yes boss", and let the whole thing collapse.

Velma agreed wholeheartedly that we would not change our rigorous engineering standards .... She just asked that I be aware of it,

Oh. Good. That means she's not bucking heads over this either, but instead wants you to silently let the whole the collapse without any direct orders from her. It means a lot to her to avoid being personally responsible for the company's downfall.

Shit-can it and keep doing your job.

writing code that is generally scientifically sound but poor from an engineering/CS standpoint

That just means they're self-taught coders. Scientists. Plenty of dudes in that camp and plenty of women with real comsci or SW engineering degrees. Well no, those are extreme diamonds in the rough, but of the women in tech, you get the idea.

[-]

whipdancer@reddit

Omg, I read through a fraction of the responses and started having flashbacks of prior companies I had worked for.

[-]

Hudell@reddit

Maybe asking everyone to adhere to best engineering practices even when writing new stuff might be too much and you should have someone or some team dedicated to the engineering side of the solution?

I don't mean to completely shield the scientists from having to write good engineering solutions, but simply to be ok with them not focusing on it when writing new stuff. Sorta like having separate (internal) deliverables. Add a separate (official) step for reviewing things from the engineering perspective where the scientist and an engineer work together to improve things when needed.

Benefits I see of doing it this way:

separate feedback on the two kinds of work. If someone does an impressive job at something but they are not good at the engineering stuff, a separate review process would allow the first review to be completely positive, which helps morale a lot more.
would simplify the review as you could have people approve things only from one perspective without reviewing the other at the same time.
I think it would make it easier for them to learn the engineering best approaches too, though in some people this could have the opposite effect, if they absolutely do not care about it and see it as "that's the engineer's job" (but maybe that is also OK and you don't really need every scientist to be good at this? Dunno)

Potential negative side of this: Having it completely separate, while also making it more "official" at the company level, also makes it stand out more and some change in leadership down the line could easily cause the whole thing to be blindly cut off.

[-]

The_Northern_Light@reddit

Maybe just setting expectations for that team during interview/onboarding? Some message like “not being a good programmer when we hire you is okay, but we will teach you how to be a good programmer because that’s something we care about”?

From there you can just treat it as an education / training issue?

What country are you in? United States?

[-]

eddie_cat@reddit

The premise of your post is offensive. Your engineering focused culture is off-putting to scientists who aren't engineers. Plenty of women are engineers.

[-]

EngineerFeverDreams@reddit

The bias may be in hiring. In an attempt to be seen as less bias, you add a bias to allow less technically skilled women join the team. Being more rigorous in technical assessments in the hiring process may be how you address this early on. I would express the values you have for strong engineering standards so everyone understands when they join.

[-]

Common_Source_9@reddit

Tone policing is already the standard in most business environments, why are you still complaining about it?

[-]

jamie-tidman@reddit

Big O notation is not "obscure CS trivia".

It sounds like there is a disconnect between your team's engineering standards and hiring practices if people are being surprised by this. If the field usually demands less software engineering rigour, it's not necessarily surprising that people are unprepared for this going into the job.

I feel like you should make sure you test for CS and software engineering basics more during the hiring process.

[-]

asurarusa@reddit

I think that Velma is misattributing the problem. It’s not the rigor that’s the problem it’s the tone and the lack of handholding inherent in technical feedback that she thinks is putting women off.

I am a woman and I reviewed the code of another woman on my team who frankly, did a shit job. There was a problem almost on every line and when I got done there were a ton of comments and there was a lot of stuff where I was like ‘there is a much simpler way to do this’, ‘you’re recreating things from the standard library’, etc

Her pr got approved anyway and my manager gave me a talk about being ‘nicer’ and made the comment that while my feedback was valid it came off as overly critical and combative and I needed to be more thoughtful about how I expressed the issues with people’s code.

The end result is I had to start writing comments like “this approach is valid and I like your clever implementation, but I’m concerned about the complexity and think there’s a better way to do x, have you considered y” I also started letting minor things go if there were bigger technical issues so it didn’t seem like I was finding excessive fault.

[-]

Human_No-37374@reddit

I'm ngl, if I saw someone giving me those types of comments I'd either think they were being patronising on purpose of was taking the mick out of me.

[-]

Donkey_Duke@reddit

One thing that was obvious to me was her thinking using one terabyte of data was okay, because it’s within the system’s limitations. This seems like expectations aren’t being well communicated.

[-]

Ban_Cheater_YO@reddit

O(n^2) and O(n) dofference in your cide is not "obscure" CS "trivia". How do folks like these get hired to toles that require production code to go smoothly?

[-]

Esseratecades@reddit

If we're using Susan's case as a representative then she's fundamentally wrong, but I'm inclined to wonder if the issue is really what the standards are, or how they're being communicated.

It's not very reasonable or likely that women tend to leave sooner because you ask them to meet the same programming standards as men to accomplish things that are factually better. My guess would be that that's how the real issue is presenting, but isn't actually the root cause.

I feel like the situation is a clash of egos between different points of view, that could be easily bridged because one thing everyone understands is money.

Algorithmic efficiency matters at the end of the day it saves money, and everyone knows the value of a dollar.

Making everyone reframe the efficiency as a necessity could help to sand down friction.

[-]

MyStackRunnethOver@reddit

The point here isn’t “Susan is a woman so like other women she writes suboptimal code”

The point here is Susan felt like her code reviewer was trying to run circles around her”

That is the problem that you as a principal must address: how do you make sure that junior team members understand your technical culture, how code reviews factor into that culture, and what sort of interactions they should expect in code reviews as they ramp up and grow into non-junior engineers

The talk I usually have with junior team members is “code reviews are an opportunity for us all to make sure that every piece of committed code meets our team’s standards and accomplishes our goals of maintainability and performance, to make all our lives easier. Especially early on, you’re going to get a lot of comments and suggestions for improvement, and that’s just because when you’re starting out, there are a lot of things you don’t know about how our code works, how we structure things, and what best practices are important in our domain. Don’t be alarmed by this and trust that as you write more code and learn more about how to write great code, you’ll get steadily fewer comments / revision cycles. That number will almost never be zero, it’s not zero for me or other senior folks on the team except on very small changes, because another pair of eyes almost always picks up something you’ve missed. So don’t take things personally because we’re all trying to get better, and that’s why we do code reviews: to learn and improve”

[-]

Skullclownlol@reddit

The point here is “Susan felt like her code reviewer was trying to run circles around her”

You should quote the entire context:

Furthermore, according to Velma, Susan was actually very upset that I asked her to implement the O(n) fix, feeling that I was “trying to run circles around her by showing off my knowledge of obscure CS trivia.” That said, Susan did not directly voice this displeasure to me, and with some guidance, ended up implementing the fix. Her tool now runs great in production.

If the fix is "stop assuming people are trying to fuck with you for no reason, just listen to the advice, and if you're that worried then learn to communicate so you ask your +1 at least once", then the problem is - in many layers - not with OP.

You can add as much grease to the wheels as you want, if people don't want to help themselves it still won't fix anything.

[-]

MyStackRunnethOver@reddit

Susan gave that line as feedback in an interview about why she left the company. Not to OP’s face

I agree that Susan’s communication isn’t good. But OP’s question is about retention of female coders and how to deal with the trends which their VP has identified across multiple exit interviews. “Lol Susan is dumb” doesn’t make the retention issue go away

Unfortunately, at some point, we as engineers need to accept the fact that if X always happens on our team, then there’s something about our team which makes X happen. Even if we never tried to make X happen, even if we don’t like X, you can only get unlucky so many times before it’s no longer bad luck doing the work

This is also part of the work of being a principal. For a more junior engineer “female engineer tenure averages 2 years below male engineer tenure” is a sad fact of life. For a principal engineer it’s evidence of a problem with the team. To blame the individual mentioned in the sole given example is to ignore the pattern, and therefore miss the point

[-]

Skullclownlol@reddit

There's a lot I think we agree on, and I would even say some of it simpler: Environments are always worth improving if we can, even if there's nothing wrong. Being more welcoming/accommodating/resilient always creates more opportunities.

But I also think stuff like this isn't helping you at all:

Susan gave that line as feedback in an interview about why she left the company. Not to OP’s face

That's bad. Like, if Susan never tried improving her environment by communicating before leaving, then that's on her. And it's clearly not about trust or being afraid of losing her job, since she feels comfortable saying so after leaving.

The trend of women sticking around less is worth investigating, absolutely.

And I also think using Susan as an example for all women would be a disservice to those women.

[-]

macoafi@reddit

This, and also:

Whoever's doing the hiring at OP's office could/should talk about this aspect of the culture during interviews, so new employees come in understanding that continual improvement is part of the culture.

[-]

jk_tx@reddit

Sure, but there's only so far you can (or should) go to coddle incompetence. At some point people need to start acting like grown-ups.

[-]

valium123@reddit

I as a woman insulted a male developer for using up with bubble sort 🤦‍♀️

I've seen dozens of male developers complaining about the same stuff, so are you trying to say that only women have these issues?

[-]

Stokealona@reddit

This sounds like an onboarding problem to me. If this isn't the norm in your industry then expectations need to be set during the hiring process and then the onboarding material needs to reflect this and 'hand hold' new starters.

[-]

przemo_li@reddit

Ask your VP to do exit interviews from male colleagues too. Difference in emphasis on good and bad parts may also help finding out what's going on. (E.g. dinner employees may not even realize their are treated differently via absence of certain behaviors towards them)

[-]

Round_Head_6248@reddit

Susan had other priorities than you. I assume your priorities align with your company’s, and she wasn’t interested in strengthening her CS skills. I’d assume that’s a bad fit. All those assumptions given, there is little you can do if more of the women have a stronger priority on the biology and don’t see programming as a very important tool. They probably didn’t study cs for that reason: they aren’t interested in the cs-y programming parts, and if their lead insists on that, tough luck. There is nothing you can do to fix this except specialization : some employees work more on the programming side, others on data/biology or whatever. (This is how I would always do it, because I value specialists more than Allrounders)

[-]

gnuban@reddit

What can work well in these types of situations is to write down a list of objective criteria that the code needs to meet to be deployed into production.

This makes the feedback feel less personal to the author or subjective on the part of the reviewer.

It also lets the author review the list themselves, read up on the subjects, and reach out for help on their own terms.

I think this can change the feeling of going through the review from "here let me show you how it's done" to "did you do you due diligence?", which will feel a lot less disempowering.

In the end, there will always be some subjectiveness in the final review step. But moving as much as possible of that into a formal list/standard keeps it to a minimum and sets expectations.

[-]

przemo_li@reddit

Don't trust either your VP nor your own tasks.

On my CS course at technical university, analytical math course was conducted by female and she rocked it. That's the math that can tell e.g. you how much precision you gain by switching algorithms. There is no more CS minutiae them this.

So: be a sport and check negative variants of the same story. Namely that "CS minutiae" is conflict free term for "they undermined my scientific credentials", or "guys get different feedback". Appearances are important here too. Just because core team does not feel like they are over the line doesn't mean people won't feel actual differences.

Good luck on investigations!

[-]

Ok_Conference7012@reddit

There's no way that she pushed back against a code review. You probably just sounded like an asshole if this was her reaction

[-]

bigohoflogn@reddit

I actually suspect this comes down to a scientist mindset vs a software engineering aspect. In my experience as a software engineer working in scientific programming, the people (men and women) from a scientific background often have a significantly different way of approaching programmjng and in a way that often pulls me into conflict over approaches, best practices, etc.

I think the other comments on psychological safety in the team are worth thinking about. This can be resolved by providing additional training support in software to all new members on the team, in the same way that I assume you provide support on teaching computational biology concepts to primarily software employees.

Although there are some gender politics at play (i.e. people who are feeling less secure in their positions react more strongly to negative feedback and are less likely to push back) I actually think this is more about different backgrounds and you just happen to have more women from a bio background than software (which statistically tracks)

[-]

bwainfweeze@reddit

I see some of the same with QA and operational people. Even ops people that used to be programmers can start to be less worried about rigor. Which is super weird when two of these groups are focused on quality and reliability.

[-]

Zebirdman@reddit

Just want add, it probably would have helped to given more context around why the inefficient method was not desirable. From a person's perspective who doesn't understand operational constraints throwing terrabytes of ram at the problem might seem fine especially why not if we have the option. It would have helped to - highlight the parts you were happy with. Always provide positive feedback where it's due if you can. - explain why running larger vms is not desirable even if the option is there ( cost, inefficiency, will break later anyway if data set gets larger) - that it may seem like nit picking but these are the kinds of things that will set her apart from other colleagues in her field. Can even highlight that if your able to optimise processes like this you can create real tangible savings which tie in with renumeration (lets be pragmatic, money helps)

Beyond that I would say you have by the sounds of it created a great engineering culture. Don't compromise just learn to communicate why it matters.

[-]

bwainfweeze@reddit

[-]

speckledlemon@reddit

Also CS itself is a science - do scientists not see it that way?

No. Most see it as a chore required to implement their science, and many do not distinguish between "computer science" and "software development".

[-]

dudeaciously@reddit

The culture clash is not gender based. Subconsciously, women are being hired for non-technical foundations, like communication with customers.

Common anti-pattern is to bifurcate people into technical vs. good English.
I came across a smart nath guy who was deep into ML math. He was surprised at how much coding he needed to learn. Totally frustrated.

Please hire programming women that like math. Then ML.

[-]

bighappy1970@reddit

I think the crux of the issue is that expectations are not known in advance. It’s a pretty shitty experience to write some and then have get slapped with undisclosed requirements.

For over engineering it’s pretty simple - tell them “do the simplest thing that will work, nothing more.”

For performance, tell them that performance requirements should be defined in advance- if they are not defined, ask questions and get them defined- if their implementation meets the performance requirements they won’t be asked to change it, even if a better algorithm will improve Big O performance.

I’m guessing that the problem is the guess and check nature of code reviews that’s the problem- if you don’t communicate expectations in advance then it’s not reasonable to tell them they did something wrong and have to fix it.

[-]

speckledlemon@reddit

This is not dissimilar to reviewing architectural-scale decisions during PR-style code review: it should not be done, but we do it anyway.

[-]

I have been very impressed by the comments on this post!

[-]

waffleseggs@reddit

The whole post is packed with unsubstantiated generalization of common stereotypes with only anecdote to support.

> The world of scientific computing is famous for shoddy software

> We take pride in having a very well-engineered codebase, and it’s a large factor in the company’s success in a very competitive market

> there is a definite pattern of women on the team writing code that is generally scientifically sound but poor from an engineering/CS standpoint

Individuals should not be promoted beyond mid-level if they are found to hold such sweeping categorical bias and discrimination. If there truly were serious (obvious to explain) issues with the code, I see no reason why 100% of women with basics in the fundamentals couldn't figure that out and take corrective actions. The real question is why such a high-ranking individual is unable to communicate the issue effectively or why the woman in question felt it necessary to not hear his argument or push something through prematurely. This sounds like a very broken cultural problem to me.

[-]

skakskskah@reddit

Thank you… this post is awful. One woman wrote inefficient code so that’s why all the other women left?

[-]

Sure-Business-6590@reddit

This is what you took from this post? Are you disabled? There is nothing even mildly contributing to this idea in this post.

[-]

ok_computer@reddit

I wonder if the code deployment is 24/7 running app or a batch/ schedule/ on demand data job? 1TB RAM is pricey but is the O(n) algorithm in the same readability neighborhood as the more immediate O(n2)? What is the actual cost hit in tangible and immediate dollars, not some prospective 10x load? Because you can be 100% technically correct but off the mark on the correct way to handle situations interpersonally.

More importantly, when some scientist’s code ships, are they the sole owner / debugger/ and responsible for features or performance? I ask this because I have zero opinions to share about working with different sexes or genders, but I do about working with scientists and inheriting their code.

As you mentioned, scientists are not software engineers. It’s incredible that your company has fostered a culture of clean scientific code. However, what is the cost or worth to you in maintaining that absolutely? (Political discussions, staff turnover, is your compute costs rivaling the revenue, has a manager approached you about compute costs or resources?) Can you draw demarcation lines around some non-core components or features. And might a research scientist’s time be better spent thinking about things that programmers are not trained to conceptually think about? Serious question I am not being snarky. Would you be willing to ship suboptimal algorithms with the understanding that engineering can do minor performance refactors? If it is a basic change, that is fine to ticket out to an engineering minded person. There is a bonus of someone else learning the feature via improvement.

I wouldn’t want to be shedding any high valued employees that were trained over 2-3 years on how to write better scientific algorithms to competitors and would recommend keeping the talent happy as long as the work product is not slobbish.

My point is if the O(n2) to O(n) fix was as obvious as you say and the data volume wasn’t yet an issue, then my opinion is to ship it and patch by a performance minded engineer. I say this regarding fields/disciplines and not genders like your title, but the diversity of problem solving between scientists and engineers can make really good projects when we stay in our swim lanes. I’d rather not burn political good will over imaginary performance hits and would rather keep a 1000’s long backlog until someone approaches us about compute costs and keep the creative talent buzzing away and not looking to move to the next competitor. Because as you said, many don’t care about Code First. And in your industry code is not the specific product.

I wouldn’t focus on sexes/genders aspect and would consider roles/disciplines and tolerance for rework.

[-]

ownhigh@reddit

I’m a senior woman engineer and I’ve experienced (sometimes extreme) pushback to simple code quality feedback, things like optimizing queries and writing tests. So I know where you’re coming from.

In my case, the majority of the poor quality code and pushback on improvement has been from men. That’s due to demographics, not because men are worse engineers or less interested in career development.

This statement seems suspect to me: “Thinking back, there is a definite pattern of women on the team writing code that is generally scientifically sound but poor from an engineering/CS standpoint.”

Characterizing all code written by a gender at your company as poor, or even over-engineered, etc. comes across as unlikely. It’s possible the outcomes you’re seeing are responses to bias mentoring and management rather than truisms about gender.

[-]

coolj492@reddit

“trying to run circles around her by showing off my knowledge of obscure CS trivia.”

I think one way of parsing this is that when you give this kind of technical/engineering based feedback to someone without that context, you need to explain why a certain standard exists and exactly what tactile benefit it has.

For example if her solution requires provisioning 1TB of compute then you can show her how much that would cost the org over a year and why a more efficient oslution is necessary. And if its a "softer" standard difference like code readability then you can explain that cleaner code = easier to debug = faster incident MTTR. You might not have to explain this to experienced SWEs but this is a situation where everyone benefits massively from those mateiral explanations

[-]

EmotionalQuestions@reddit

It also occurs to me that if Susan learned to code as part of getting her thesis done (assuming PhD) she may never have encountered big O notation and the concepts behind what it means to write customer usable production software?

[-]

coolj492@reddit

yeah in a lot of bioinformatics/compbio classes "intermediate" CS fundamentals like Big O aren't really the priority, let alone stuff like cost/compute. So a lot of it just comes to meeting the folks you're working with where their expertise is by explaining why concepts that are basic to us are important

[-]

suurkate@reddit

I am a woman and a high-performing mid-level SWE in FAANG. I maintain rigorous engineering standards. I have been lucky to rarely experience what felt to me like sexism since starting my SWE career. I’m providing that context to establish that I both do know what I’m talking about, and am not constantly looking for misogyny in the workplace.

I do not for one second believe that you’re providing us the full, unbiased set of facts. There is a thinly veiled implication that women cannot follow rigorous standards. You go out of your way to say that when men need correcting, it’s only because they are just too smart (“a bloody clever piece of code”.)

[-]

Antoak@reddit

I got curious, and 1tb hourly pricing isn't as nearly as bad as I thought it would be. For sustained prod workloads it's definitely a non-starter, but if it's a one off then rewriting it might actually cost the company significantly more.

Still think it's a terrible implementation.

IMO the issue is probably tone- Several of my coworkers have been sweethearts but come across as indifferent assholes when matter of factly pointing out issues.

[-]

Opposite-Hat-4747@reddit

Honestly, just look into the “how”. It’s not the same to hear “your solution is unacceptable for prod” than to hear “good work, but before we go to prod we should optimize memory to save costs”.

Probably my example sucks as well, because I’m terrible at giving feedback, but having people skills and the ability to tell people off politely in a way that they see as a growing opportunity is a skill in and of itself.

Maybe the men at your company are just used to the harsher treatment but the women expect to be treated better.

[-]

Spare_Virus@reddit

2.5 years is standard at most companies. Is there a chance that people leaving are pressed for a reason and that's what they can muster up?

[-]

EmotionalQuestions@reddit

Another note is that the industry/field is a small world. I never provide the "real answer" why when I quit a job.

[-]

malevolentTomatillo@reddit

What in the sexist bullshit is this?

Maybe there are women on your team who don’t optimize for performance. But there are many men in the industry who also don’t. And there are many women who do. So why are you making this about gender?

Honestly it instantly felt like an AI post.

[-]

mpanase@reddit

the incompetent and stubborn female coworker

kinda true

the martyred male engineer lead who is punished because he was correct

not true

the meddling disconnected VP with a gender agenda

not true

I think you construed a story in your mind quite different to that told by OP, tbh

[-]

lionhydrathedeparted@reddit

TLDR but as soon as I saw this stupid person suggested paying for a 32 TB RAM machine rather than do a simple algorithmic fix I knew they were a moron.

No. There are perfectly competent woman engineers. I know many. There are also stupid ones, from every demographic.

[-]

maxip89@reddit

In my eyes it is more a commuication problem "how you tell it" susan.

This is not a women/men whatever problem, I repeat. There are just different type of programmers:

Career Programmer:
You didnt see them very long in the dev section of a company. Their code is just "it works" and "behind me the wave". Try everything to get promoted next day. Want to have some "drama" to blame others just to look in the right spot light as victom or hero.

Chill Programmer:
Avoid every form of stress. This is the prefered type of programmer, because he tries to avoid problems even if they require the long uncomportable solution. Just to avoid some prod issues and beeing stressed fixing it.

Grandpa Programmer:
Programmes everything in Fortran, never wants to learn something new. His way always worked out why should he align when everyone can. He is in this company since ww2 and thinks this gives him some more power over decisions even when they are democatic. When they are democratic descided they often just ignore it.

Think yourself, in which category are YOU and in which is SUSAN. Knowing which type you have gives you an advantage in making developing for everyone more fun and reliable.

Just my 2 cents.

I see your company has much money (When you have the money to run a 32TB RAM instance on AWS when there is a different solution possible).

Maybe you can drop the company name for applying :).

[-]

Are informal channels of mentoring favoring men?

It's just surprising that women tend to have less knowledge about these engineering issues, when such type of problem or information is not gendered. I'm wondering if men are learning about these issues and how to solve them from informal channels, like other men helping them, while women do not have that. If women are being mentored by other women who don't have that knowledge or viewpoint, then it would follow why these issues are around women employees. And if they are not mentored by anyone, well, you have the same outcome.

[-]

DallasActual@reddit

I've seen plenty of great women in engineering who would have produced a production-ready implementation because they understood the memory and processing constraints. So, I doubt this was about what was said and more about how it was said.

If you turned in an algo that didn't meet the brief, how would you have wanted to be told?

[-]

Sfacm@reddit

My experience with women engineers has actually been quite different. At my university, women made up over 40% of the engineering cohort. They were some of the most principled and reliable collaborators I worked with — very committed to engineering fundamentals, highly rigorous in their approach, and generally less confrontational than many of their male peers. If anything, they were the opposite of “anti-engineering.”

That’s why I find it striking that in your case, the feedback points specifically to “engineering minutiae” as a source of dissatisfaction. It makes me think this might not be about women being less interested in engineering rigor per se, but rather how the culture around that rigor is communicated and reinforced. The same principle can feel like empowering professional discipline in one setting, and like gatekeeping or status-display in another. Context and framing matter.

I don’t believe there’s any inherent gender gap in engineering, or anything else for that matter. It’s societal norms influencing everyone’s behavior — remove those, and the so-called gaps disappear.

[-]

corny_horse@reddit

FWIW, my anecdotal experience is that I've encountered both men and women who are like Velma here from when I did medical research. Some of the most intelligent domain experts I know are extremely sensitive to feedback about their code or technical approach. (I don't think it's a "me" problem, as almost everywhere I've worked other than academia reports that I'm perhaps even too timid in criticism.)

[-]

NoddyCode@reddit

You've mentioned that your team is a bit of an exception in scientific computing, and that the skillset required is somewhat niche and not all hires have a SWE background. Is it possible that new employees are coming in from a background where their work was acceptable and being caught off guard by the strict standards? Perhaps they feel their general intelligence is being questioned rather than just their programming skills.

Adding to this, women in tech can be very sensitive to criticism from men if they get the idea that they're being put down due to their gender, even if you totally don't intend it that way. After once "jokingly" being called a "diversity hire", it took a long time for me to separate my personal imposter syndrome fears from feedback I received, even with new teams. Some things in your post that make me think this might be part of it:

> I was responsible for reviewing her code, and she pushed back when I told her this would be unacceptable for production use.

Is "unacceptable for production use" the phrasing you used? For someone not yet comfortable in their role, this can come across as very harsh and dismissive of their capabilities, especially if they're jumping into the deep end of a new programming philosophy.

> Furthermore, according to Velma, Susan was actually very upset that I asked her to implement the O(n) fix, feeling that I was “trying to run circles around her by showing off my knowledge of obscure CS trivia.”

This further implies that Susan was not very experienced with SWE, so you might as well have said "Why are you using spinkle instead of dinglegorp? That's just not going to work". Again, coming from a place where they may have been knowledge tested by other men on their teams, this can come across as demeaning. Though these new hires may be experienced in their scientific fields, you may need to treat them like junior devs when it comes to the code: gentle guidance and check-ins along the way to make sure they understand what's required.

> and with some guidance, ended up implementing the fix. Her tool now runs great in production.

Who gave this guidance and how did they give it? You may want to talk with them to see how your approaches differed. Maybe do a mock PR review with them for a new hire and see how they might phrase things differently. Did Susan receive recognition for her now well-working tool? Even if it required more guidance than you'd expected, it helps to focus on that end result as their achievement, even if the road was bumpy. "Hey, you did it!" vs "ugh, finally" can make a big difference in how you give your feedback.

[-]

QuroInJapan@reddit

From the way you’ve described it, it sounds less of a gender issue and more of a “someone who can’t take legitimate feedback” issue.

As a manager, if someone on my team showed a pattern of such behavior, they’d 100% be getting a bad review and, possibly, terminated if things didn’t change.

[-]

restlessapi@reddit

The problem in your company isnt any of these things in the comments (I didnt read literally of them).

The problem in the company is that the engineers do not understand where they are adding business value.

Developers often think that their job is to write code/software. This is incorrect. Their job is to provide business value. The medium they use to do so is through software. Software is the cost every business pays to achieve some business value. But make no mistake, that software is always cost.

When you have engineering discussions, do you ask "Is this providing the most value to the business?" or do you talk about some ethereal hand-wavy engineering standard in the sky?

Does it provide business value when the only way to run a software solution is O(n\^2), and you need to use a 32TB RAM (absolutely absurd) AMI? Of course not.

Does it provide the business with value when the software is so micromanaged and over-optimized that changes are difficult and tedious? Of course not.

You understand this already, but you need to frame it like this to your engineers.

[-]

Comprehensive-Pea812@reddit

just use more rams type of people actually come from men also citing early optimization is root of evil.

just mention that we have budget constraints.

susan sound more like bad engineer, as I have met women who can discuss about cryptography efficiency

[-]

Haunting_Welder@reddit

Not sure what scalability has to do with gender, but a 1 TB VM would cost about $100k a year. Unless the redesign would cost that much, I’d say rewriting the algorithm makes more sense.

[-]

PsychoticOctopus@reddit

Why were the issues with Susan's solution not flagged before she wrote the whole-ass solution? The whole team should have discussed the solution before a single line of code was even written. At the very least, Susan should have submitted an ADR of her solution for review by the team. This sounds like a problem with your team's processes.

[-]

PettyWitch@reddit

I agree with you. I’m a woman with 16 years and any team I’ve ever been on we would at least discuss high level solutions beforehand. The problem is OP’s process, not necessarily the women.

I also really think there is a culture problem there. I have been told many times to substantially change a solution for one reason or other and I just do it, I don’t mind. I respect the people telling me my solution wasn’t good enough. I’ve learned a lot from them... And I just get them back at standup by pointing out how despotic they are! (We all get along great.)

[-]

carlmango11@reddit

It depends how large the project was. There's a threshold under which you shouldn't have to write up and discuss how you're going to code something.

[-]

Particular_Ad_644@reddit

It sounds like Velma may have misplaced her glasses again. The obvious solution is to inform all candidates about the engineering culture and to make sure they can fit in and cont to it.

[-]

DigThatData@reddit

“trying to run circles around her by showing off my knowledge of obscure CS trivia.”

A few thoughts on this:

It sounds like maybe part of the disconnect here was insufficient communication of business requirements and/or impact of the proposed change on the amount of value delivered. It's a lot harder to care about your work if you don't understand why you're being asked to do it.
I'm sensing maybe some impostor syndrome, especially if this sort of thing is a trend. How is your org on positive feedback, especially forms of validation?
Are you doing anything to actively make the women who have stuck around feel wanted and seen/heard? They probably have a lot of insight into why other women have left, I'm a bit surprised "interviewing the ones who stayed" didn't seem to be part of the story here.

[-]

privately_millenial@reddit

What I see in your example is a complete lack of psychological safety. Critical feedback is fine (and I find that at least starting out in a new position, expected) but, if I have no shared context, we don’t talk about anything besides work and every single PR that I put up is absolutely shredded with comments about code quality, I’m going to get frustrated.

Is there no place to talk about directional approach while onboarding? Are people not talking about their tickets in standup? And moreover do people feel comfortable talking about mistakes and being less than perfect?

It sounds like you have incredibly high standards and no qualms about forgoing niceties in pursuit of those standards.

Based on your examples it sounds like there is a lack of communication around standards and no attempts noted to improve these things or create an environment where pushback is allowed.

There’s a common archetype of the 10x engineer who is just absolutely miserable to work with as a human and it sounds like you’ve hired exclusively for that archetype.

SoInsightful@reddit

Can't speak for scientific computing, but in software development, "we will fix it later" is a meme, echoed in quotes like "there is nothing more permanent than a temporary solution". A "future fix" rarely simultaneously survives continuously changing priorities, forgotten context, missing documentation, people entering and leaving the codebase, code becoming riskier to change with time etc.

If you slap on an expensive VM as a solution for what is actually a software engineering problem, be prepared to be stuck with the expensive VM forever.

[-]

james7132@reddit

I've worked in a few spaces where research scientists are not allowed to productionize their PoC scripts and are required by management to go through, and work with, engineers to turn it into that state, rather than require the research scientists to handle it. This takes a bit longer, and occasionally the scientist will make an assumption about access patterns that fundamentally don't scale, and thus puts engineering in a tough spot, but this tends to still work very well in the general case otherwise.

Susan sounds like someone that got pushed into STEM without having the analytical/reasoning skills you would typically find in ~~male~~ CS majors.

Fixed it for you

[-]

Temporary_Emu_5918@reddit

As a woman who has worked in (is working in) a toxic environment, I think there's more to this. You (and potentially Susan) are framing this as a 'rigor' problem. But it's not necessarily saying having rigor is bad, but HOW is that rigor communicated. The amount of times I've had two men turn a "rigorous" discussion into both of them insulting each other in meetings is too damn high. Or fighting on PRs over things like implementations, when a team discussion would be more warranted or something could be addressesed by having a team standard. Have been talked over and ignored in meetings. Have had certain (male) team members co-opt my meetings. Frequently talking over or excluding other female colleagues from meetings.

Frankly, I've seen many men write mediocre code so either you guys are hiring poorly or this is complete bs.

Let's not even start with making weird jokes about their sex life at company events. Weird jokes about what clothes I wear (all work appropriate).

[-]

queenofdiscs@reddit

I think the way you're framing this problem as "our engineering focused culture is off putting to women" reveals that you're blaming "your high standards" as the problem rather than yourselves as likely poor teachers and supporters of anyone, not just women. As it turns out, teaching is a completely separate skill from recognizing big-O notation and it would appear that you and your team are rather deficient in these skills. I would expend your effort in learning how to give constructive and supportive feedback - this is what a truly engineering-focused culture is.

[-]

im-a-guy-like-me@reddit

The unoptimized VM solution is costing the business money for no reason. Vagina or no, that's unacceptable.

The fact it came up with more than one lady kinda seems like the reasons behind your decisions were not properly communicated.

"Your way sets money on fire for no reason." is impossible to defend.

[-]

firecorn22@reddit

Idk it's hard to make claims based on this especially since most of your team doesn't sound like software engineer and sound more like scientists who also code and other scientific domains outside of CS can have really low standards for what is considered good code so going from something that as good enough for a PhD program to getting told it's trash can probably hurt some egos.

Im not too familiar with the exact standards biology PhD programs typically have for code quality but I imagine it can get pretty low especially if it's wet work focused and I know that the life sciences are pretty gender stratified so maybe there is a connection there

[-]

ptolani@reddit

when I told her this would be unacceptable for production use.

I'm guessing there is a lot hidden in this. How the conversation took place, tone, respect, etc.

[-]

sanityjanity@reddit

I am a woman, and a software engineer. I am NOT put off by "engineering focused" culture.

I *am* put off by men who constantly interrupt and belittle me, and I am put off by management that picks out me and the gay guy to plan a social activity. I am put off by the coworker who can't explain his thinking, and just yells out "woman!" at me.

Frankly, I'm insulted and irritated that anyone would think this is about focusing on engineering. I love focusing on engineering. I am tired as fuck of men.

[-]

DootyBusta@reddit

Bro nobody is reading all that.

[-]

freethenipple23@reddit

... The issue is not that women dislike engineering.

They're saying that you're so focused on issues that you don't consider your delivery of your message when communicating to them.

They probably don't feel respected.

I'm not sure I can give advice for you on this, as I have similar struggles, but saying "women just don't like being engineering focused" is... Broad strokes dude.

[-]

lordavengerbg@reddit

I think you are not focusing enough in the training on the engineering part, how important it is and how it can affect the product. They probably cannot make the proper connection between unoptimized code and bad product.

In general I think over the last 20 years there is very little focus everywhere on code optimization (bar some very specific fields). The main focus is writing code fast and releasing new product and new updates and features. The general cloud computing field is also advertising in a way like hardware is limitless, while they don't really have a lot of their big machine SKUs available per datacenter.

Also from my experience a lot of male coders will do stuff regularly, just to prove that it is possible, while women like to know why they are doing something and how it matters.

[-]

Well_Intentioned-@reddit

Can you check the assumption that the issue is male vs female? Is it possible that you have high attrition from folks with a medical background vs folks with an engineering background? Maybe setting expectations early in the onboarding process would ease the medical experts into the engineering side.

[-]

N43N@reddit

I was also wondering how big the sample size is we are talking about here

[-]

wrex1816@reddit

People generally give a "nice" reason for leaving in their exist interview, to not burn a bridge. You need to read between the lines to see the real reason.

This doesn't take a rocket scientist to figure out. Women join your company and leave quickly, and this isn't a once off, it's a pattern.

Ya'll are either being hostile or outright creepy towards women. Maybe address that.

[-]

This is fairly common in quant trading firms, fwiw

[-]

Kelbeth@reddit

I realize this is just an example but this sounds more like a personal issue of someone not liking their code being critiqued than a gender based issue

[-]

aitadiy@reddit (OP)

If this were just a one-off with Susan I would agree. The problem is that Velma has definitively identified this as a systematic issue (by going through all of the team's exit interviews over the last few years, and interviewing multiple current team members.)

[-]

Kelbeth@reddit

If it's not a one off then you need to reflect on how you are performing reviews and structuring feedback. Maybe you're unintentionally patronizing. Otherwise, what you've explained in your post is a perfectly valid criticism of production code.

[-]

So a VP at your company feels comfortable describing engineering as "minutiae" and "CS trivia"? This proves your point that the bar must really be that low in scientific computing. I would be more troubled by that than anything else.

[-]

aitadiy@reddit (OP)

So a VP at your company feels comfortable describing engineering as "minutiae" and "CS trivia"?

But at the end of the day what matters is money. Translate the resources the O(N2) algorithm costs compared to the O(N) algorithm. If that's significant than they're going to me more likely to hear you out.

I find it strange though to suggest female developers don't care as much about sound engineering. And have always found the idea of reducing standards to get more diversity to frankly be condescending and bigoted.

But at the end of the day do what your bosses are telling you.

[-]

mpanase@reddit

OP is citing Susan as an example.

The bit where OP says "She gave an example of an interaction I had with “Susan” on our team" should be a pretty good clue of it.

[-]

tinycockatoo@reddit

And have always found the idea of reducing standards to get more diversity to frankly be condescending and bigoted.

But at the end of the day do what your bosses are telling you if you like your job.

But OP said Velma wasn't pushing towards lowering standards, in fact, it was the opposite. I think he's looking for advice on giving feedback.

[-]

alpbetgam@reddit

As someone in academia, I'm all too familiar with the problem of bad coding. A lot of my peers are simply not interested in "software engineering" as a discipline - they want to be scientists, not software engineers. If you're trying to hire people who know both biology and good software engineering, the demographics will probably lean towards software engineers, i.e. very male dominated.

My guess is that the women you hire tend to be less interested in software engineering than the men, on average. You should try to set expectations right from hiring that the job is a mix of science and software engineering.

[-]

aitadiy@reddit (OP)

As someone in academia, I'm all too familiar with the problem of bad coding. A lot of my peers are simply not interested in "software engineering" as a discipline - they want to be scientists, not software engineers.

100%. I think you have to be in academia to truly understand the nature of the "I'm a scientist, not an engineer" mentality.

You are probably right that a larger fraction of male hires had more explicit exposure to software engineering. That said, we hire plenty of men who initially embody the "scientist, not engineer" mentality when they're first hired, but quickly learn to embrace the merits of good engineering when they realize that it matters tremendously when they're shipping a product, not writing a conference paper.

Velma thinks that women find this transition offputting, and she is trying to get to the root of that problem.

[-]

for1114@reddit

Uh, I might have an insightful perspective on this as an outsider to these larger team programming efforts.

I made my career as a one person software engineering company, commonly known as a freelancer. I worked on a ton of radically different projects.

The most engaging team efforts were an amazing group dynamic. I was the sole programmer. The person to press the last compile button on the project. There were people coordinating with the client in the design phase. People doing the graphical design and illustrating. One person who was a software engineer coordinating between me, the artist-designers and the QA people tracking bugs. When in that bug tracking phase, after I had spent months in my home studio coding with no phone calls or emails, I would log in and JIRA or whatever flavor of tracker they had, had a list of bugs. I'd do what I could, negotiate, make it work, you know how it goes.

Just pointing out how well a team like this works. We all have discrete roles. We are all in charge of our piece. We are the expert of what we do. There is no competition there. Project managers are as important as programmers, as artists as HR as the cold caller.

I can't really comment on male/female mindsets on coding because it was mostly me doing the coding. I had an opposite sex coding partner situation not take off once, but I felt it was more of I'm just a solo coder and all the extra time dividing up tasks and coordinating coding styles and includes just seemed like bloat for my programming style. It didn't seem like a good way to train someone nor did it seem like a good way to code a project.

I realize some projects are huge and yeah, inherit other people's code and you do what you can to match.

I've met amazing technical scientist women engineer types. Honestly, they are often Asian women. I think it has to do more with having a task master attitude than a body/mind arrangement.

[-]

ummaycoc@reddit

Insert extra levels on the promotion ladder and make this somehow be part of promotion. You can even just reorganize the salary ranges so nothing really changes and it’s just like Engineer 2.5 or such.

But like someone said maybe there’s also ways to support and give feedback that are better. If possible do both.

[-]

chillermane@reddit

calling something that is a massive design flaw minutia is bad.

reflect over the coming months over potential ways we can address it

This is not a good approach - Velma said you did nothing wrong so why is she suggesting you change it? That’s a really weird situation she’s going putting you in.

Honestly I would be very alarmed of this situation because you are being asked to treat women differently because they are women. That is antithetical to a good engineering culture. Engineers should be treated the same regardless of their gender

[-]

lvlint67@reddit

This is not a good approach - Velma said you did nothing wrong so why is she suggesting you change it?

Why would a VP say soemthing like that to an employee? Is it possible that OP did no one thing categorically wrong but that there was still room for imporvement?

Should we ignore the problem and just aceept that women are less rigorous engineers than men? I'm not sure i buy the premise and deeply suspect OP is lost in confirmation bias.

[-]

Previous-Piglet4353@reddit

And also to have shitty expectations for code quality and CI/CD just because they are women.

Now, sorry to be so much more harsh:

How is any of this not considered sexist? Imagine if you said that women on a construction site don't have to put rebar in their concrete and can just freepour some slabs, just because they're women. That's not equality, it's bigotry (and narcissism) of low expectations.

[-]

lvlint67@reddit

not the usual suspects, like bro-y culture, intellectual dismissal, outright sexism... I did not realize that women specifically were consistently being put off when asked to address these problems.

I do not someone in this chain. Either your story is misrepresetning reality, the relay of the tale from HR is misrepresenting reality, or Susan was misrepresenting reality.

.. Or each injected subjective bias into the discussion and along with this being an "Exit interview" (where developers famously no longer give a shit) the entire core message has been lost.

As a guy, I can tell you, "I was objectively, measurably and demostrably correct" isn't the best retrospective to have. The problem CLEARLY lies in the messaging. To that end, i'd bet you a beer that the impression of the company is infact more "bro-y" than the stories and exit interviews let on.

I’m told that our “engineering-focused” culture is offputting to women

I'm further willing to bet, that if you asked Velma directly if she agrees with your take away phrased like this, she would not.

[-]

AxiomaticSuppository@reddit

The computational biology division is about 90% men. About 25% of our hires are women, but their tenure at the company is much shorter than men’s (median of 2.5 years, compared with 5.5 years for men).

Is the distribution of skill level and age among men and women at your company the same? If not, the phenomenon you're seeing could be the result of something other than gender.

Also, it would be interesting to hear what other data points Velma had available to her that suggested women were leaving because of a "focus on engineering minutiae". The example you shared was very clearly about good engineering practices and not "minutiae".

If the problem had more to do with how feedback was conveyed, that should be explored. But it doesn't sound like that was on the radar here.

[-]

TyrannosaRex@reddit

Might be worth deep introspection into your hiring and asking why the women who got through, got through. Are you filtering out the women with the engineering-mindset you seek? And if you don't have the records, fix your hiring so that everyone involved has to give detailed written feedback.

[-]

neonskimmer@reddit

A classic and enduring mantra in software is "Make it work; Make it right; Make it fast". There are tons of takes on this you can find. It's attributed to Kent Beck. You might have heard "premature optimization is the root of all evil".

The most popular interpretation I think is start by writing code that solves the problem. Second, do it properly. Refactor, design it properly, name things properly, make it reusable, etc etc. depending on the context. Lastly is performance.

All of this is extremely context dependent. YMMV, batteries sold separately etc. Not suggesting that what your team is doing is not amazing. I wish more companies did it that way.

Anyways. Here's how we've solved it where I work. The really smart scientist folks write their (technically correct, but objectively awful) code in Python. Let's call that the canonical implementation.

Next, someone who's really good at programming and knows enough about the science creates a much more performant version using a high performance language and approach. Through collaboration, we ensure that it has the same output as the canonical implementation.

The "bad code" version might go through many iterations as the problem space is refined, etc.

It would be more efficient if the scientist learned better coding skills. And she might! But in this case we feel that her time and mental energy is better spent at a higher level of abstraction

[-]

HiImWilk@reddit

There may have been more subtle things.

Being a queer man, I get hit with a lot of “Do you know what this line does”? about relatively basic code. It only gets more irksome as the years tick on. Yes, I know what a LINQ sum function does.

The worst version is asking a question about something specific, only to wind up receiving a 30-minute lecture on how API controllers work (I’m a senior backend engineer). I’ve seen QA’s get hit with an explanation of how to test code, when they were actually asking about a missing variable.

It sounds like you’re a little better than that, but if your teammates are doing that, your less heinous behavior will still come across as insufferable, even if you’re being comparatively nice.

This cycle sucks too, because now Susan probably feels like a total dumbass for thinking “Here goes more mansplaining”, when it was actual correction, which only makes one get more defensive.

The big red flag for me is the “tendency to overengineer”. Idk why, but misogynistic men just love doing that shit. They love being “Stupid Smart” because it allows them to feel better than others. “Can’t understand my convoluted bullshit that performs .2% better? Guess you’re just dumber than me”.

One guy defending a column FK-ing out to 10 tables (one of which is in another database) saying “I don’t think we should bother redesigning the system just because you had a hard time understanding a column”.

Code was shit, btw. The organization was shut down a couple weeks ago. Mounting production issues and constant delays caused subscriptions to drop to near zero.

[-]

austinwiltshire@reddit

Am I misreading your post?

It sure seems like you conclude that the discussion with Velma was eye opening to you, that it caused you to see that women and men coders WERE different.

My god, if that's your takeaway, you aren't fit to be principle.

[-]

neurorgasm@reddit

Could be anything along the following spectrum.

Bad case: People, in general, don't have a background in those practices, which were also not present in their interviews, role descriptions, and/or previous teams. The 'engineering excellence' may mostly be in yours/VP's heads, or considered irrelevant branding, and other people don't understand its value or feel comfortable questioning it. You may be coming off as a bully, arbitrary, or pedantic, and misinterpreting people who've come to expect that as being on board with the practices you're asking for.

Good case: Most people, including many women, understand and use engineering practices to a positive effect. They're comfortable teaching others about them, including but not limited to during reviews. They don't just academically understand them, but have tangible first-hand experience of their value. This forms a common understanding of how every PR should be written before a single line is committed, preventing rework. Folks are incentivized, supported, and rewarded in becoming better engineers. This is an expectation people are onboarded to and held to explicitly. In this case, Susan is simply a difficult person who refuses clear evidence in front of them due to inflexibility, dismissive attitude, or other personal (non-gendered) problem.

Now I am going to guess that the truth is somewhere between these two points. If you try to make your strongest case for one extreme or the other, what seems wrong? What seems to have a grain of truth? I think that will show you what you can improve.

I would not over-interpret VP's request because it does sound more like a "keep your eye on it, suggest changes or tell me if you see anything along those lines" type request than a "we need to fix a definite problem" request. But in my experience, it is easy to think you're closer to the good engineering culture than you actually are. Especially if that culture is referred to as "minutiae".

[-]

SethEllis@reddit

Receiving critical feedback is an important part of becoming an experienced engineer. However, such feedback can beat people down if it's not accompanied by an understanding of how it assists in your career progression. It might seen intuitive to us that developing such competency is part of your individual progression as part of a team, but this is not a universal experience across cultures.

So I would suggest that this is actually a failure of proper coaching. You can't assume that everyone understands the process. Managers/lead/senior engineers aren't doing a good job of coaching jr engineers through the career progression. This leaves juniors unclear where their career is going, and they don't associate such feedback as a routine step on their career progression. Instead it's just harsh criticism from a job that is going nowhere.

[-]

recaffeinated@reddit

I suspect the fact that you're assigning this to gender is the reason that so many women don't want to be on your team.

[-]

Previous-Piglet4353@reddit

Social equalization goals should never be a substitute for merit.

Social equalization goals should also never be a substitute for operational standards and practices.

So it's a matter of the culture and expectations that needs changing, and everyone should be briefed on what to expect of themselves, of their contributions, and what standards you need for robust interop and efficiency.

[-]

mpanase@reddit

Over the years I've found that I can have a conversation with a friend that's 95% engineering-focused. And that's a great afternoon out with a few beers.

Women tend to want a much much bigger portion of personal conversation. About people, about travel, about art, ... things with less technical connotations.

Exactly the same in the workplace.

I'm going to guess you guys are very technical and happy to skip the chitchat?

If you bombard me with chitchat, I'll be less receptive to the topic you actually wanted to address because you wasted my time with stuff I didn't want to do. But without the chitchat "warmup", women tend to less receptive because you didn't set up the relationship properly.

note: yep, gross generalisations for a general topic.

[-]

morim@reddit

I love that the post is asking how to deal with a valid problem in the workplace without sexism and then you just go on and be full 100% sexist in your opinion 🥰

Tbh I dont know any of my women coworker's son's names but when my men coworker's football teams loses a match, its the first thing I'm hearing about in my daily meeting. 🫠

[-]

mpanase@reddit

The post is highlighting a difference between men and women.

Guess what? Men and women are different.

Introverted people and extroverted people are different.

If you live in society, you adapt to each other to give everybody the opportunity they deserve.

That's the opposite of sexism.

note: "when my men coworker's football teams loses a match, its the first thing I'm hearing about in my daily meeting". Yep. Exact same thing. Somehow you think one is sexism and the other is not... think about it.

[-]

morim@reddit

You say that women like to talk more but then you're over here writing several lines of text over two sentences. Think about it 🤫 is it really women that like to talk more or are you just being sexist?

[-]

whataterriblefailure@reddit

you didn't get what "%" and "proportion" mean, did you?

[-]

morim@reddit

You do realize that women have to deal with these stereotypes every day, right? Read the room.

[-]

mpanase@reddit

You say that women like to talk more but then you're over here writing several lines of text over two sentences

Wow. That incredible logic of yours is amazing. Special.

[-]

whataterriblefailure@reddit

https://pursuit.unimelb.edu.au/articles/how-gender-shapes-our-facebook-chats

https://www.researchgate.net/publication/253291274_Gender_Differences_in_Language_Use_An_Analysis_of_14000_Text_Samples

https://gender.study/psychology-of-gender/gendered-language-patterns-men-women-communication

https://www.europeanproceedings.com/article/10.15405/epes.23097.46

weird when people get downvotes in an engineering-focused sub, just for referring to scientifically proven stuff

[-]

Spare_Environment867@reddit

Adding my 5c experience: in school, the ratio was about 1:15 when I went to a computer (not just software) engineering school. Projects like ruby girls or other female oriented grassroots educational programs imho contributed to improving this ratio, and it's also been 20 some years since college so who knows, maybe the ratio is better these days...

[-]

l_m_b@reddit

I think there's a difference in how we're socialized to, well, socialize (which includes giving and receiving feedback, and what's acceptable communication styles, and how much we're willing to put up with) based on assigned gender roles.

From what you describe, yes, the particular example indicates a suboptimal technical choice (and I'm in no position to comment on whether that materially matters to your business success). It probably should have been caught earlier, but there's that. It happens.

That both Velma and you attribute this to fundamental gender differences however (and not to a myriad of other possible explanations), that is telling.

(That Velma is apparently also a woman doesn't mean she can't fall prey to internalized biases as well; we all do, just like other -isms. Arguing that one is free of them is usually the best indicator that one absolutely isn't.)

To me, that strongly suggests that there are gender biases at work, and that they're being denied. That makes them impossible to address and overcome.

That it's not "intellectual dismissal" but "the rigorous engineering standards (that they fail to meet)" is also telling (see previous paragraph). What else is the latter but the former?

"Susan" could well have been a junior dev on any team, with (perceived as) harsh feedback received so late that it results in lots of extra work, which of course is unpleasant to hear. Or she could have made a reasonable assessment of "well, here we are, this is the better use of company money". In either case, the conversation clearly didn't go great, but there's no gender-based conclusions to draw from that either.

Internal reflection is important, and I think you all should absolutely continue with that.

I think what you should consider is to bring outside experts on this very subject matter (yes, the dreaded D.E.I.; it's actually fairly awesome once folks stop feeling threatened :-)).

There are trainings and coaching opportunities that help understand and address these, and I'd be fairly certain that that's going to be more success- and insightful than internal reflection by people who all likely don't have relevant training and experience.

[-]

ArdentGamer@reddit

This just seems like an ego problem on her end. She doesn't like being told that she's wrong and just wants to do it her way because she wasn't the one to come up with the more efficient solution. The fault is in her character, not in how she is treated or her gender but it is often the case that ego problems among women are ignored or perceived as something else(i.e. "girls will be girls").

[-]

kbielefe@reddit

In general, women tend to take criticism more personally, especially if they see it as something they couldn't anticipate. Try to frame your criticism as instead "helping the solution to use less memory so we can save the company some money."

Your mention of the words "minutiae" and "trivia" make me think you mostly need to do a better job of explaining things like big-O that people were not previously expected to be familiar with. If you don't want to sound like you're "mansplaining", just ask first, "Are you familiar with big-O notation?"

Also, I know you can't include every detail on reddit, so you may have already done this, but make sure to point out the good things about the solution. For example, the O(n^(2)) solution is probably much more straightforward.

[-]

That’s kind of interesting. But how can one(me) land a position at your company, the work sounds very interesting?

[-]

VibrantGypsyDildo@reddit

Well, if the outcome is offputting to a certain gender...

What can you do?

It is a part of our jobs to deliver the added value.

We can't trade our genitalia for productivity.

[-]

adambkaplan@reddit

As you pointed out, your industry and its academic prerequisites are not known for software engineering skills. I notice this too amongst data science graduates- their expertise is analysis, not coding.

If your team expects others with non-CS degrees to understand computer science + software engineering terms up front, you are setting them up for failure. It is on you teach these things with empathy and in terms that are easy to understand.

I think you need to provide more details on what "test" and "prod" actually are here. Is prod just another single user using the tool one time? Maybe the O(n\^2) solution was fine given the circumstances?

If it wasn't fine, then also remember that people get defense when you tell them they are wrong in some way. It's just natural. Don't beat them up over it, especially when it comes to their performance reviews, and just move on. She likely would have seen the problem anyway.

[-]

snorktacular@reddit

What are the qualifications for working in the computational biology division of a company such as yours? Are the men and women being hired from the same pipelines? Or do the women tend to be straight out of school with less practical experience? Or if not, are they coming from other companies, the ones with abysmal code standards, where these issues would never have been raised?

This sounds like an issue that can be addressed with being up front that this is part of the culture in the hiring process, but more importantly with training and creating a sense of ownership over code quality during the onboarding process. Tying this "minutiae" to the success of the company like you have in your post. These are clearly intelligent scientists, it's not that they can't learn. But if this is the first time they've ever heard this type of feedback in their entire careers, then of course they're going to think it's strange and nitpicky. I'm reading between the lines a bit here, but I have a feeling that this is at least part of what's happening. There are likely other layers to the problem, but this is something that's in your control to address.

If you say out the gate, "We hired you because you're highly qualified and intelligent, which is why we need your help maintaining engineering excellence to support our business goals. We know it might feel unconventional but it's been a key differentiator in the success of our business. Here are the ways we'll support you as you explore this new skill set." Then I imagine they won't feel so blindsided.

It's like if you spend your whole career creating dashboards, CI pipelines, etc. where green is healthy and red is unhealthy, and then you join a new company that says your new dashboard needs to meet accessibility requirements for colorblindness. Important? Sure, especially in a field where the majority of employees are men and men are significantly more likely to have red/green colorblindness. But it would sound completely out of left field if it's never come up before. Maybe you'd roll your eyes and think, accessibility is a frontend thing, what's their deal? It would feel like a drag any time you worked on dashboards, and eventually you'd decide to go somewhere else where you won't get nitpicked to death.

[-]

CheeseAttack@reddit

A minor thing I found that helps more than expected with code reviews:

Instead of rejecting a PR with a comment saying what to change, just leave a comment saying what should be changed, that makes it feel more collaborative and less like a personal rejection.

I have found that people respond much better to this, even with the same exact feedback. Someone seeing the red rejected mark on their PR can be demotivating/upsetting and cause some emotional distress (there were studies done in school even where teachers grading papers in ink other than red resulted in students taking the feedback better).

[-]

mia6ix@reddit

This sounds like a communication issue - which explains why women appear to be more sensitive to it than men. In my experience as a CTO, male engineers will live with and work around serious flaws in communication and documentation for long periods, whereas female engineers will zero in on such issues immediately and identify them as obstacles. If you improve the DX for women in your org by addressing the root cause of this, it will improve the whole org, because the problem itself is not gender-specific.

IMO, it’s a failure on your part as an engineering lead that Susan ever got to the point where she submitted work that so grossly undershot your expectations. Your performance standards, including preferred solutions and architecture styles, need to be clear and well-documented. Onboarding and training of new hires should focus on teaching these standards and expectations and setting engineers up for success, so that they know how to submit work that you will approve. Starting small so that revisions are small, and growing the tasks/projects over time also helps new hires get the hang of standards before the stakes are high.

[-]

BullfrogRound4235@reddit

Don't hire women.

[-]

KnightBlindness@reddit

Could you not modify your interview questions to make sure you only hire candidates that are able to think algorithmically and are capable of applying appropriate data structures?

[-]

Refactoring code to be more efficient seems like a normal thing to do no? I don't see this as a technical problem just part of the process. I honestly can't imagine burning through that much ram.

[-]

Steve_Streza@reddit

If your industry has poor engineering standards, you should not be surprised when you hire people with poor engineering standards. As someone at a principal level, you need to proactively elevate those people (and/or filter them out at hiring), not just react when they show up with a bunch of code you don't like.

[-]

DualActiveBridgeLLC@reddit

I will start by saying that when I have worked with women previously I had amazing experiences. All three had been forged in the crucible of working with men who were more misogynist than I think the profession wants to admit. As a hiring manager I literally told my boss last week that I think we need to have at least one woman on the team and am working to poach them from another project.

I did not realize that women specifically were consistently being put off when asked to address these problems.

This is ridiculous. Performance of the code is a clear metric necessary to success of the project. Every single woman I worked with would understand and accept that feedback. Maybe your boss is trying to explain that the way you you provide feedback is important...because it is. I guess this one is really hard for me to understand because every minority I have worked with was pretty top notch because to even get into this profession it takes pretty think skin especially for people at a disadvantage.

[-]

4gyt@reddit

Not even once

[-]

Slow_Philosophy5629@reddit

Explain too much? You're mansplaining. Not enough? You're neglecting them. The difference? An invisible moving target.

[-]

tinmanjk@reddit

I think women as a gender are more than capable of fitting in a "harsh engineering culture". Just think of our grand-grandmothers who had to raise 5+ children while also working actively on the farm.

I've never actually heard any of the types of complaints OP mentioned from good female software developers. Never. And they are good because they understand that there is a certain type of intellectual honesty and rigor that comes with our profession and embrace it. They do not argue that On2 is not that big of a deal when On is on the table.

[-]

Noobsauce9001@reddit

Hm, something feels like it doesn't add up, at least in my experience. I mean I've worked with a lot of great women and none of them would scoff at a serious runtime efficiency, that's just part of our job.

We can look at it from a gender angle but I see a more fundamental issue- there's a group of employees who are having problems, and didn't feel safe to admit it to y'all directly.

My gut is telling me it's either the communication style at the company, one that builds a lack of trust.. or there's a lot of socialization/favoritism played between those who like each other, and their being the uncommon demographic (<10% of your devs are women, right?) leaves them in some sorta out group.

Yeah I feel like someone who is high up on the engineering team is maybe kind of a dick to them? I can't know for sure. Good luck either way.

[-]

Grand-Juggernaut6937@reddit

It sounds like your hiring process is focusing too much on demographics and not enough on qualifications.

You aren’t doing women any favors by bringing them on and then embarrassing them when you inevitably have to reject their bad ideas. You’re wasting your time to scorn capable men and embarrass women who still need to grow.

[-]

Overall-Abrocoma8256@reddit

Culture of rigor is hard to build back once it degrades. If you touch code, you are responsible for its performance. If scientifically minded people don't want to get down to the nitty gritty of the code, they should stick to only reviewing or writing test cases, or design.

trying to run circles around her by showing off my knowledge of obscure CS trivia

Sounds like a difficult to work with person to me.

[-]

Rymasq@reddit

I’ll be honest, when it comes to accomplishing great work people have to be willing to take criticism or see the other side. It’s why a lot of winning cultures get labeled as “toxic”.

From the example you provided, it sounds like a social norm was different between you two. Some cultures accept direct confrontation and some prefer to communicate across a wide range and let things “trickle”, or be “figured out”. Regardless of what you feel about the approaches, both exist.

To me it sounds like you are not setting expectations correctly. It’s perfectly fine for a company to have a standard for coding. It’s obnoxious to be told about that standard after you work on and think something is finished.