[flagged]
That's a weird take. How would you know what I'm curious about? Pardon the strawman, but I'm not interested in handwavy explanations which tend to border on bigotry ("$category simply isn't interested in $topic"). I suspect the fundamental reasons are myriad and complex, but that doesn't mean $field wouldn't benefit from more diversity.
> It's impossible to change these distributions without understanding the underlying causes for how they got that way.
Maybe, maybe not. The ratio is certainly a lot less skewed now than when I was a student over 20 years ago. My understanding (or lack thereof) certainly didn't have an impact, but throughout my career I have always tried to be supportive of people who are in some way different from me. Heterogeneity is a good thing. Monocultures result in weakness.
First link that came up in my Google search:
https://www.psypost.org/women-like-working-with-people-men-l...
It is almost certain that differences in interest play a large role in the different distributions of men and women in different occupations. The studies showing this are well known and I have not seen them debunked.
Please note that labelling a claim with strong backing in empirical evidence "bigotry" does not magically change reality to conform with what you would like it to be. You need to produce actual evidence to the contrary.
If you think about it, there not intrinsic ground to support the idea that computer science activities in themselves are more "things" than "people". They may be more "things-oriented" right now _because_ it is currently male dominated, but it does not mean it is a fundamental characteristic of the computer science activities.
I find it interesting because it shows the vicious circle of bias:
step1: "Computer science is male dominated" + "men prefer X and women prefer Y" -> "Computer science is therefore fundamentally X"
step2: "men prefer X and women prefer Y" + "Computer science is fundamentally X" -> "Computer science is therefore male dominated"
It's never going to be as human oriented as something like teaching, being a therapist, or managing people full time.
Also, one of my point is that the "non human oriented" is also part of the image, but not of the reality. I see more and more successful developers that explains that "sit down and write or debug the code" on your own is not a fundamentally big part of the job, but it is in practice a big part because of the current mentality and because some developers want to work like that.
I keep seeing developers thinking that they are "special". But in practice, it is a job very similar to other role in a company. An accountant, for example, also need to sometimes sit down and do careful work that requires not being disturbed. It often feels like developers are talking about "breaking the flow" or "all these useless meetings" or "the managers that invent work to justify their role" or ... as if it is not identical for all the other roles (there are small differences, but nothing justifying that developer is somehow less human oriented than accountant).
Bigger, sure, but not by much. STEM (presumably what you mean by "science fields") are bigger in aggregate ~25% women. Some of these are smaller (~10% of electrical engineers are men). Some are bigger, biology IIRC is about 50/50. Computer science is about 20% women. This is actually pretty close to the average of "science fields" as a whole.
I agree that developers aren't special. But neither is the gender disparity among software developers. People so often forget that gender imbalances >20% is actually the norm not the exception. If you dig through the Bureau of Labor statistics, most jobs have significant gender disparities. Dog groomer have as stark a gender disparity as developers. So do driving instructors, and insurance adjusters. There's actually nothing unusual about the level of gender disparity in STEM.
My comment here is about the idea that the disparity can be explained because "computer science is more thing-oriented and women are more interested in people-oriented activities".
If it was true, we would not see different numbers in different STEM fields.
Personally, I think that the cultural image of the field, rather than it being intrinsically thing- or people-oriented, has a bigger impact. In practice, biology and computer science are both activities where you work on your algorithm. And in practice, I would argue that computer scientists need to have more people skills than biologists, as computer scientists need to interact more between each others and with non-dev people (managers, internal teams that need to have internal tools built, external users giving feedbacks, ...). But biology has an image of "nature and animals" that is associated with women and computer science has an image of "nerd coding alone in his mancave" that is associated with men.
The thing is that these images are cultural, not intrinsic to the activity in itself.
> If it was true, we would not see different numbers in different STEM fields.
No, this does not track. It could also be that some fields in STEM are more people oriented than others. Psychology is over 2/3rd female. If anything, that inconsistency in representation supports the link between things vs. people and women's representation.
And I'm saying that I have taken that into account and I cannot see, in practice, how mathematicians, statisticians or biologists, in their day-to-day job life, are interacting more with people. Some of them are only interacting with their like-minded same-field team member, while software developers need to interact with the company business team, the finance team, the user experience team, the research team, ... plenty of teams that are not talking the same language and have different and sometimes opposite interests.
My sister majored in biology, and after graduation she worked on managing clinical research trials. She'd visit people testing new medications and interview them about their experience with improved symptoms and any side effects. I'm not sure how representative this is of biology as a whole, but personally I can easily see why biology would be more people oriented than software development.
I strongly suspect that the large majority starts in math with not specific plan.
Then, yes, they move away from academia. But it is an error to jump on the conclusion that it is because they wanted to do teaching and not because they saw how academia is for women in math and realized it's not worth the effort.
If indeed the fact that you can do teaching after math studies makes math a people-oriented job, then every studies are people-oriented, because you can always teach any field.
But that's not even the point. I'm not saying math is not people-oriented, I'm saying math is AS people-oriented AS computer science: if you want a people-oriented job, you can have one by doing math or by doing computer science, if you want a non-people-oriented job, you can have one by doing math or by doing computer science.
You are pretending that software developer is intrinsically not-people-oriented. This is incorrect: you need to work in team, both with other software engineers and other totally different teams, you need to build tools FOR other people, listen to them to know what they need and listen to them when they have complains or difficulties. The whole job is "how can I solve OTHER PEOPLE'S PROBLEMS by being the proxy between them and the computer machine instructions". How is that not people-oriented?
Again, there is this very very strange conception that software developer is somehow an extra-terrestrial activity. It feels like software developers have no idea of what other people do. Do you really think that an accountant that spend their whole career working for a specific internal department will meet and interact with more people than what a software developer can potentially? Or the people working in policy? Or the people working in operation and just managing the logistic? What about the cleaners? Is that a people-oriented job? I'm sure they create a lot of interesting relationship when they clean the office when everyone has left. What about a lab technician? What about a restaurant cook? Or an Amazon warehouse worker? (please, don't react to one of these examples, if you don't like one of them, feel free to just swap it to one of the thousand other examples where the employee will have less opportunity to interact with other humans than a software developer)
Sure, not every accountant job does not involve the same level of people interaction, and similarly, there are software development jobs where the dev can go away with not interacting much.
And sure, some developers, who are not people-oriented, find ways to make it work with them avoiding the people-aspect of their work. They usually need a manager to do this aspect of their job for them, and then complain that their manager is useless.
But again, it is not intrinsic to the work of software development. Software development is not a not-people-oriented job. Some people want it to be, they are somehow proud to be not-people-oriented (they are so not-people-oriented that it is very important for them to socially boast about how they are not-people-oriented), and they have big difficulties to admit that their job is not intrinsically not-people-oriented, and because of that, it is a fake image and a distorted reputation (with all the problem it causes: developers that keep moaning when they need to do people oriented tasks as if they are special and should not do it while it totally makes sense that it is part of their role).
https://paulgraham.com/makersschedule.html
There is a very significant cost to having a lot of meetings. At some point someone has to take the requirements and turn them into software that does something. And lots of interruptions destroys that process.
There are entire methodologies designed around these constraints. That is why "agile" methodologies introduced the Sprint concept, so there's enough time to focus on building something that the stake holders can interact with, and then give actionable feedback. Which doesn't really happen when you only discuss requirements in the abstract.
Painters need time to paint uninterrupted. Writers need time to shut the office door and type without distractions. And developers need quality, focused time spent with their text editor.
So developers are completely correct in their emphasis in keeping meetings to only those that are truly useful and required, and guarding their focus time. It is what best serves the customers and other stake holders.
Firstly, I have a news for you: avoiding interruptions is not something special to developers. It's the case for ALL EMPLOYEES, even the ones that have more contact with people. The complexity of the flow may vary between employees, but it's just ego-inflated bs when devs are painting themselves as such snowflake beautiful minds with their so special workflow. There is a very strange mentality of developers not being able to do what other people in the company are able to manage and they therefore need to invent that they are "special".
Secondly, many devs are shit at being able to tell if a meeting is useful or not. I saw very good dev teams, I also saw dev teams where we reduced the amount of meetings and where they started producing useless code that did not do what was needed, while at the same time, some of those devs were saying "see, less meeting, now we deliver twice faster" without even realizing that the useful outputs were twice slower because of all the things that needed to be redone. Unsurprisingly, the number of meetings re-increased and some adults had to supervise the team more closely to make sure they understood what was needed. And of course, some of those devs were complaining, while being totally incapable to even conceived that their twice-faster delivery did not matter if they delivered the wrong output.
So, yeah, NO ONE HERE IS PRETENDING THAT WE SHOULD HAVE USELESS MEETINGS. Simply, I'm pretty sure that some meetings that you consider useless are in fact very useful but your "I-just-generate-code-I-don't-need-to-exchange-with-people-to-understand-what-is-needed" mentality makes you unable to notice it.
And again, while there is some truth and things to learn behind the "maker schedule interruption problem", a lot of devs complaining about it are just people who are not good at their job because they lack basic skills that are required. I'm a scientist working in R&D for a private company. I'm working with devs, I even sometimes write full modules that end up in production (it should be done by proper devs, but I'm stepping in to fill the gaps). Trust me, I know very well the "maker schedule interruption problem" and it is indeed a tricky balance. But the reality is that I see some devs who are working on things way less complicated than me and having way less meeting than me who are using the "maker schedule interruption problem" to justify that they should not do a part of their job (yes, going to the meeting to align your work with the company needs is YOUR responsibility). I'm doing things that require juggling with complicated things in my mind all the time, and yet I'm able to go to these meetings without much problem. If they cannot, it's not the meeting the problem, it's them unable to manage.
When you suffer from the "maker schedule interruption problem", your first reaction should be: "is it because I should learn to work better with interruptions?" followed by "I should try to understand why these meetings exists, in an intellectually honest way", and not "I'm a developer, I'm special, the world revolves around me and if I don't like it, it means it's useless".
To come back to the subject: this is yet another good example of the divergence of what software development intrinsically is and what the software developers invent it is. Software development requires interacting with people, software development requires to be good at managing interruption. Somehow, software developers have invented, probably based on TV show clichés and teenager nerd mentality, that software development is just limited to them playing around with code.
It is people oriented, to a degree. But it's less people oriented than solving other people's problems by engaging them directly, without being a proxy between the user and a machine. To say that software development is less people oriented than being a math teacher isn't saying the former has zero personal interaction or nothing about it is people oriented. It's just less people oriented than most other jobs.
Indeed today there is a lot of devs that don't engage directly with people.
But my point is that "not engaging directly" IS A CHOICE of these individuals, not a fundamental characteristic of the role. And that in fact the role itself requires more engagement than what a lot of devs think they should have.
Please stop reducing "math" to "math teachers". Do you even know that teaching math does not require having enrolled in a math major at university? Any STEM degree will do (and sometimes not even STEM). Also, you can also teach computer science (or worse, if you want to teach math, getting a degree in computer science is as much an option as getting one in math). If it's your criteria, then again, computer science is as people-oriented as math, because people doing computer science can become teacher too.
> But it's less people oriented than solving other people's problems by engaging them directly
But, ideally, devs SHOULD engage directly. They don't do it by choice, and it makes the product of their work LESS GOOD. It also creates strange situation where you need plenty of manager and very constraining processes such as scrum or other planned processes where the devs have to be explained what the people need because they devs are not able to simply ask themselves.
Computer science is more people-oriented than math, in very large portion of the user cases, it works better when the dev engages directly with the people they work for, while for math, people who do math for a living, the majority of the roles involves working on research and development with a very much smaller window of potential interaction with people of varied backgrounds.
> It's just less people oriented than most other jobs.
No, it is not. Intrinsically, the role of software development has way more elements that require interacting with people than a lot of other jobs.
In practice, computer science has cultivated a subculture, in which they started painting the picture of the asocial nerd working in their mancave and glorifying this aspect. The consequence is that women are less interested in computer science not because computer science is intrinsically not for them, but because the stupid mentality that is cultivated by to many people in this field. The consequence is that socially inept people will be more interested in computer science because they see it as a good fit for them.
But, again, when you look at it, on paper, there is absolutely no reason to say that computer science is intrinsically a good fit for socially inept people. If they want a brainy work where they can beaver down on their own little universe without interacting with people, math is 100x more suitable for them. Computer science requires understanding what the client want, and the client surface is big and their background is very varied, which means the dev need social skill to interact with them.
Paul Graham has made multiple fortunes based on the premise that good programmers can learn the soft skills for business much easier than the average business person can learn to code. Mountains of money have been made from this premise.
A good developer is someone who is talented at writing code, and talented at some "people skills" to be able to use their coding talent usefully.
And, yes, a good programmer can learn soft skills for business more easily than the average business person can learn code, because code is very very hard and learning soft skills for business is "just" very hard. There are plenty of people very good at programming that are just useless because they are good at generating code that does not align with what is needed.
Here’s my theory. Learning how to write code causes damage to the mind, particularly in the area of how you relate to other people. When we’re learning to code, men and women both notice this happening, but men care less. Women, on the other hand, tend to think, “this is bad and I should stop.”
It’s hard to become a programmer without becoming a weirdo in the process, and women have a lot more to lose by becoming weirdos. If we knew how to learn programming without the mind damage -- if we could figure out how to allow learners to skip the “coal face” of spending long hours into the night talking to a compiler -- then that would solve the gender imbalance.
Just my theory. For a good long stretch I thought the explanation was that tech compensation wasn't actually all that great compared to what women could earn in other fields, and then the explosive comp growth of the mid-late 2010s happened and I've been wondering about what is the problem ever since.
Wait, what? A math proof does not need to convince anyone: the proof exists or does not exist. If I prove X, then I don't need to convince other people that X is proven, they just have to read the proof.
So, in practice, math is even worst than computer science. In computer science, you have to convince the compiler. In math, you need to convince math. You need to build an algorithm that compiles under the tons of math logic rules.
> if we could figure out how to allow learners to skip the “coal face” of spending long hours into the night talking to a compiler
But learning math and trying to build math proofs is even more "coal face-y". There is no pre-build debugger and you need to check things yourself, by hand, and when it fails it may be because you mess up the algorithm part or the compiler part.
> Learning how to write code causes damage to the mind, particularly in the area of how you relate to other people. When we’re learning to code, men and women both notice this happening, but men care less.
All of that is cultural. The developer mentality cultivates this idea that being burnout and being socially rude is a sign of success and is a manly thing to do.
There is no reason why writing code causes damage, because it does not happen to plenty of other activities that are as grinding. Again, developers are not special, what they do and what they live is similar to a lot of other things.
It feels more like a rationalization: the reason men get worse at relating to other people and become weirdos is because these men are failing at social life because of their mentality.
Professional mathematicians also cut either other some slack. Most proofs published today have small errors — typographical, skipped steps, etc — and those bugs are never fixed. Despite the bugs, we’re confident in the results, and that confidence is a product of social consensus.
On the other hand, also in college, I had my programming classes, where I would turn in my code and they ran it through a test harness, and my grade was the number of tests that passed. So, if there was a syntax error, I got a 0. This was brutally harsh to the good students who attended every class, took notes, and studied, but who did not conform their minds to writing code. But that’s how we learn programming, because the compiler doesn’t care about intentions and “almost” is worth nothing.
Alan Perlis said “programming is an unnatural act.” It’s not harder than other jobs — in many ways it’s easier — but it’s much weirder, and it makes you weird. Professional programmers write bugs, constantly: why can’t they just write the code, without the bugs? Because our minds aren’t built that way.
I have the opposite experience: when learning physics, math was really difficult to negotiate with the professor, because it is mathematically correct or not. They had their table that said "if they have done this, X points, otherwise 0", which is an exactly equivalent system as the one where your grade corresponds to the number of test your software passes. It was easier to negotiate points in the computer science lectures, where I could argue that having used some concepts shown in the lecture (using object-oriented, recursive functions, ...) was worth some point even if I did not finish my algorithm.
I think your experience (and mine) is just because you have been exposed to "beginner tests / optional course" in one field and "higher grade / main course" in the other. Beginner or optional lectures tend to give more leeway.
> Professional mathematicians also cut either other some slack. Most proofs published today have small errors ...
That's just not true: if there is an error, the result is not reliable, and it is therefore extremely important to identify them. It does not mean that the person who made the mistake will be thrown out of the field (of course not, every mathematician has made mistake some time, it's part of the job). And by the way, I wonder how you are in position to know that. You are claiming that "those bugs are never fixed". I've observed math-oriented conferences where some of the talks were all about discussing these bugs. I'm sure if you even have an example of such not-fixed-error, you have absolutely no idea how it was treated later by the scientific community. It's as stupid as saying "firefox 6 has a bug, it never has been fixed (but of course I did not look if they released new version)".
But the problem with this argument is that you are comparing that to a field _that is build around the fact that bugs will always exist_. You have debugger, code review, testing environment, and despite that, every released software always end up have some bug fix updates.
You are arguing that it's different for mathematicians because their publications contain errors (which is at best a very misleading description of the reality), while at the same time, DEVELOPERS RELEASED SOFTWARE WITH BUGS ALL THE TIME, in a way bigger rate and with sometimes way less following (some bugs are even some times considered "will not fix")
I think I’m on solid ground asserting that it’s common knowledge that most proofs have errors. The reason is that professional mathematicians tell us so. Here’s Terry Tao: https://terrytao.wordpress.com/advice-on-writing-papers/proo.... Notice how Tao acknowledges that papers “full of errors” are sometimes not corrected before publication. What does that mean for proofs which have only one minor error, and referees less exacting than Terry Tao?
Chapter 7 of Simon Singh’s book on Fermat’s Last Theorem is also illustrative (Singh liberally quotes from his sources directly so there is no question about what the mathematicians thought). After Wiles submitted his manuscript to Inventiones Mathematicae, the referees began finding mistakes almost immediately and were in constant communication with Wiles to get them corrected. Wiles worked on his proof for seven years; nobody thought there was anything wrong with his manuscript having a lot of errors. How probable is it that we found every error in the Wiles proof?
Here’s a good MathOverflow question on the topic: https://mathoverflow.net/questions/338607/why-doesnt-mathema.... Lots of good responses, and links. What stands out to me is that none of the top answers say “that’s just not true.” Instead those answers about why math proofs “work” even though they’re not completely, rigorously, “correct.”
My big point is that in math, some mistakes are trivial, and others are serious. The job of determining which is which is a job for humans — as you point out! — because it’s a topic for conference talks. But in programming, humans don’t decide how serious a mistake is — the computer does, by what it does. Typo in a code comment? No worries. Typo in a variable name? Broken program. If you abbreviate Norway to NOR in your YAML file, that’s cool. Abbreviate it to NO, and there goes your afternoon (because YAML translates NO to false). It’s the capriciousness, not the difficulty, that separates how people learn the two fields.
Debuggers, code review, and testing environments are primarily professional tools — they aren’t used by learners. By the time a learner of programming gets those tools, the damage is already done; they’re already weirdos, conditioned to accept the output of the computer no matter how capricious, and rewrite their code however it takes to get their programs to work, even if it doesn’t “make sense.”
> I'm sure if you even have an example of such not-fixed-error, you have absolutely no idea how it was treated later by the scientific community.
I don’t know what you’re trying to assert. I’m part of the scientific community. Yes, I’ve written code based on proofs that turned out to have flaws, and then I went and updated the code. The most fun one to talk about would be this one from 2006: https://research.google/blog/extra-extra-read-all-about-it-n...
Anyway thanks again for reading. I had a lot of fun writing up these comments & reading what folks and had to say.
But now, you are providing article that show that math is not a matter of convincing people. In Terry Tao's article, he does not say: there are what I think is error but it's subjective, he says: there are errors, it's a fact, the article does not pass my "compiler". Same with Singh and MathOverflow: in both cases, the existence of errors is not subjective: when an error is discovered, they are demonstrated, and they exist or not.
You also point to something interesting: there is a lot of undiscovered errors. In this aspect, it's difficult to claim that it is not WORSE in computer science, where bugs and vulnerabilities are discovered YEARS after the software was released, and that we are pretty sure there are plenty of bugs not discovered yet.
The compiler will sometimes crash or complain if there is a logic inconsistency. That's exactly the same with math. All your articles and examples are example of bugs that exist despite the math compiler, the same way tons of bugs still exist after the code has been successfully compiled.
The example of "NO" and "NOR" is pretty good, because despite what you say, developers continue to make such mistake. This example is a type mistake, and you have EXACTLY the same mistake in math if you name 2 different unknowns representing different "type" (for example one is a scalar and one is a function) with the same symbol. What happens is that your equations "do not compile" really early and you discover it yourself quite fast.
> I don’t know what you’re trying to assert.
Well, the examples that you gave demonstrate that you are wrong. You were pretending that errors in math are subjective, they are a people-oriented subject and you can convince the professor it's correct even if it is not. All you have presented demonstrate this is not true.
I know it's difficult for you, you really want that computer science is somehow magically less people-oriented than math. It's cognitive dissonance, it's needed for you because you cannot accept that some data does not fit with your model "there is less women in computer science because there is always less women when it's less people-oriented" (the data in question is that another very similar field, as less people-oriented, is having a statistically significant different proportion of women, so it shows there is at least something more at play here). It would be so convenient to explain that the cultural problem in computer science communities and mentality are just "natural" and "explained" rather than something that could have been avoided. But that is just not the case.
(edit: the last link you provide is also quite revealing, with sentences like: "I was shocked to learn that the binary search program that Bentley proved correct and subsequently tested in Chapter 5 of Programming Pearls contains a bug. Once I tell you what it is, you will understand why it escaped detection for two decades.". They are not talking about a mathematical error: the mathematical logic is correct. They are talking about the fact that it fails if the sum value is higher than (2^32-1). I thought you were saying that computer science is different than math because the compiler would have said "no". What I see is that computer science and math are very similar: some errors don't pass the basic tests, and some errors pass the basic tests)
So, no, computer science is not less people-oriented than statistics. You may personally interact less with people, but it is just because you are personally less people-oriented, not because your job is fundamentally less people-oriented.
You mean more skewed? The data shows there are less women now than 20 years ago. There is a lot more talk about women in tech today, but that doesn't mean there are more.
Basically, students who were previously exposed to CS education in high school excel in the introductory courses and often downplay the difficulty of the concepts. This is a very male-oriented perspective to take.
That's why programs like Girls Who Code try to address the gap earlier in the pipeline, since it's hard to fundamentally change the attitudes experienced individuals have in early CS courses. Other approaches some schools have tried include separating intro CS courses by prior experience.
Interestingly, studies have shown that women who stick with the CS curriculum perform as well their male counterparts in higher-level CS courses regardless of their initial exposure to CS, though women often think more poorly of their own abilities [2].
[1]: https://newsroom.ucla.edu/stories/cracking-the-code:-why-are... [2]: http://dl.acm.org/citation.cfm?id=3017771
I tend towards explanations of things that don't involve software developers being a unique, distinct species of cognitive entity, probably because (like you, I assume) I've spent a long career being a software developer and interacting with software developers.
I've only talked to 0.001% of programmers. But of them, in my experience, they tend to not look into your eyes when they talk to you. I’m a programmer, and I got a lot worse about eye contact around the same time I really got into programming. If the software developers you work with all make good eye contact, I'm sure I won't convince you that devs are any different, except to say --
All professions affect the body differently! My dad is a chef. He's got the rounded shoulders and the chubby fingers of a chef. Julia Child, Jacques Pepin, Gordon Ramsay -- they have all got the same "look," because they spent so much time hovering over a cutting board. My dad makes fun of my "skinny little fingers." What I'm saying is that programmers get the same kind of thing, but on their minds.
I don’t have any axe to grind. I’m as certain that women and men are equally as smart, as I am that programmers aren’t any smarter than any other white-collar profession. But something is making undergraduate women drop CS 101, but that didn't also make them drop pre-law in the 90s, or pre-med in the 80s, even in the face of CS compensation approximately doubling in the mid-late 2010s.
So, no, I don't think this works as an explanation any more than the idea that mathematics is somehow more subjective than computer science.