Slashdot Mirror
Do Women Write Better Code?
JCWDenton writes "The senior vice-president of engineering for computer-database company Ingres-and one of Silicon Valley's highest-ranking female programmers-insists that men and women write code differently. Women are more touchy-feely and considerate of those who will use the code later, she says. They'll intersperse their code ... with helpful comments and directions, explaining why they wrote the lines the way they did and exactly how they did it. The code becomes a type of 'roadmap' for others who might want to alter it or add to it later, says McGrattan, a native of Ireland who has been with Ingres since 1992. Men, on the other hand, have no such pretenses. Often, 'they try to show how clever they are by writing very cryptic code,' she tells the Business Technology Blog. 'They try to obfuscate things in the code,' and don't leave clear directions for people using it later. "
I've seen all genders write obfuscated code--but it worked. And every single time it was because we were under the gun for a deadline or there was simply no other way to do it. It's preposterous to even try to sound like you have empirical data supporting this blanket assessment. There's a big need to fix testosterone-fueled code at Ingres
I could combat her anecdotal subjective statements (probably describing herself) with my own anecdotes or go on a rant about how many of the great programmers are men (like Donald Knuth and his 'literate programming') but what's the point? Men can be just as meticulous as women can at providing good documentation and women can be just as sloppy.
It's good to have a healthy mix of diversity and I wish that programmers were 50/50 split on gender (trust me, I really really do) but it's not because women are better than men at coding. Prime example of American sexism in one of the few forms it exists today.
My work here is dung.
Inflammatory short article to "sex things up" (pun intended); surprising for the WSJ (or maybe not.) Written by a Rebecca Buckman, quoting Emma McGrattan at database company Ingres.
Any such broad classifications such as this should be taken with a *lot* of salt.
That being said, the article reminded me of a large digital systems design project that I had back in college, writing assembly for a 6502 processor in a device we made. My lab partner was a girl (probably only 10% of the class was female) who really, really thought differently than me in a way. It was weird -- some of the things I thought were impossible or not worth doing she would code in 10 hours; and the reverse was true. It was pretty much pure synergy (forgive the cheesy phrase) and we were extremely productive and got along well.
However, to reduce anything like this to gender differences is almost nonsensical. I could have been good lab partners with any number of people that thought differently than me, male or female. Personality is complex, not binary. I know many girls that code beautifully, and many more that can not code at all. This article is kind of interesting cocktail conversation, but nothing more IMHO...
Slashdotter, ID #101. UIDs are in binary, right?
My friends include a woman who writes 100-line SQL statements embedded in a perl-script. You need a magic decoder ring just to see what's there.
// Loop counts from i to j, with increments of one .... } ...and no, his job does not include teaching basics of programming.
A male colleague, OTOH, likes to write code in style such as
for (unsigned int i=0;ij;i = i + 1)
{
There, I've the counterpoint for the article with my own biased view!
What's a prime example? The fact that coding is a male dominated workplace? Or that someone can make blanket, derogatory statements against a group of people based on their sex/race/religion and get away with it?
Never mind, actually. I'd agree either way.
I also comment obsessively because I want to be able to come back to the code a year later and know, quickly, what I did and why I did it.
Many years ago I was porting someone else's C code from 16 bit to 32 bit and came across "//Why did I do this?" at the top of a couple hundred lines of uncommented code that had multiple embedded while anf for loops, with a pow() and a couple of sizeof()'s in there. I had to print it out and trace it by hand to figure out what he'd done, and why. Took awhile.
Too many comments can be ignored, too few can give you heartburn.
Best Slashdot Co
Forget a male/female issue. I think she needs to hire better programmers period. Anyone in a professional code shop that's deliberately trying to write obfuscated code shouldn't be there and she's not doing her job properly if she's not firing them or getting them into remedial classes of some kind.
If someone wrote an article that was the opposite of this, from a "man's point of view" it would be extremely sexist, and the publisher, writer, and anyone quoted in the article would burn in the ninth layer of hell for being such a terrible person.
This sounds like a severe case of deciding on a problem, and then picking out observations to support it. Let's say you have 1000 coders, and 1/10 of your coders (100 of them) write poorly documented code. Now we'll also consider the gender-split - if 1/10 of the coder population is female, and the statistical 1/10 of the coders writing poorly documented code applies to them as well - this means you'll have 10 female coders writing poor documentation, and 90 male coders writing poor documentation. WOW! NINE TIMES as many male coders who can't document code properly, CLEARLY that means that men can't document code, right? Right?
The same sort of thing applied here at the University I teach at - a certain ethnic minority had a very bad reputation as producing cheaters in Comp.Sci. So for a few years, I carefully recorded every instance of cheating, and kept track of the ethnic background of the people getting caught. You know what? The only reason more people of that background were getting caught is because they represented 85% of the population in the department - the overall percentage of them that were cheating was actually LOWER than others.
Perhaps this McGrattan person should concentrate more on fixing the problems than on blaming them on some group she doesn't like.
I know female coders as well and they don't do crap like that. I think your company needs to follow the same advice given elsewhere in this thread and hire better programmers.
I have lots of coders reporting to me. You can't judge the sex, race, age, sexual orientation, etc of the coder from the quality of the code.
Bah! I can think of three female programmers immediately who I've worked with closely enough to comment on their code. Two of them were C++ programmers and I don't remember their code being anything atypical in terms of comments, though one wrote very elegant code. The third works primarily in Java and somehow manages to turn out hideously unreadable code. Conversely, I've seen numerous men who program in a variety of ways, readable and otherwise.
It's now well established that the human brain builds negative stereotypes more easily than positive ones and that people see what they are expecting and apply a double standard. This person sees what she wants to see.
Aide-toi, le Ciel t'aidera - Jeanne D'Arc.
Not only that, but even if the observation (that women write better documented code than men) is true, that would only be a correlation. The gender itself is not causation - if you want to learn something meaningful, find out why the gender is correlated (e.g. women at that company are given more reasonable deadlines, men feel less secure in their positions so they don't care about helping others untangle the 'spaghetti').
Be careful of your thoughts; they could become words at any minute...
One of the better programmers I ever knew was a woman, and also one of the worst. The better one didn't even indent her 'if' statements, much less add comments until I shouted at her and made her review something she had written a few months earlier. The other one, wrote more comments than code... Like she thought she could justify the fact that it didn't work by explaining what it was supposed to do.
Pretty much kills that theory in my book. Men and women often think differently, and even different programmers of the same sex think differently. There are a lot of generalizations one can make about women and men in the world, and argue religiously about whether it is environment or instinct... Somehow I don't think programming style is one of them.
I work on the assumption that the next person to read the code will have at least a vague idea of what the programming language is, and how to speak it, so comments are the subtext to explain what happens, where, and where any obfuscations are. (Deliberately obfuscating is bad; occasionally it's unavoidable, and therefore needs more comment)
I think this is a stereotype like any other. You can't say that one group of people always does something in a given way.
I certainly do not write my code in a "cryptic way" to show off. I find it a little insulting to my entire gender to be pigeonholed in that way.
I was taught that when you write code it should be easily understandable and well commented and that's what I do.
Sheesh.
Greg C.
Gregory Casamento
## Chief Maintainer for GNUstep
but i do know that wildly speculative sweeping generalizations provides lots of fodder for utterly useless watercooler chit chat
congrats slashdot for picking a topic everyone feels entitled to comment on and absolutely no one actually says anything useful on
intellectual property law is philosophically incoherent. it is your moral duty to ignore it or sabotage it
It's also good to see that they can think the same. Both can spew sexist rubbish.
Yeah, been there, wrote my share of spaghetti code to tack on another feature the quickest and least elegant way.
Now add a management that is not willing to invest in refactoring during slower times, and the code will degrade over the years as one quickhack is added to the next.
C - the footgun of programming languages
Actually, this article is almost completely fallacious... Let's look at the facts quoted:
McGrattan boasts that 70% to 80% of the time, she can look at a chunk of computer code and tell if it was written by a man or a woman.
...at Ingres because only about 20% of the engineers are women, McGrattan says. (Most of them are in jobs involving quality assurance or adapting the product to a new locale, she says, and not the "heavy lifting" of writing code.)So, basically, she'd get a higher score if she guessed "man" every time than if she tries to be clever. Clearly, then, she does think some men's code looks like it's been written by a woman, which invalidates to point of the article.
Wooooo there cowboy. It was an old hacker joke. Like all the old "Real Programmers..." jokes. Like real programmers dont need debuggers, they just read the core dump. With cat.
Also I have nearly 20 years of professional software development. You wound me sir.
Women and Men DO think different. The men are evil and women rock tone of this article however is pathetic as are her conclusions.
However you could leverage the fact that men and women think different to gain fault tolerance. If you have two independent programmers do the same work, with the same requirements they will frequently arrive at different solutions. As most know this can be leveraged by comparing the output of both solutions to verify the solution is proper. If one solution was done by a male and the other by a female the probability of difference should go up due to the difference in thought patterns, I would think.
That is a real chance of benefit versus the male hating nonsense she spewed.
I've always lived by the rule that there are three options when it comes to programming:
1. Cheap
2. Fast
3. Correct
You can choose any two options when developing something. Guess which two my clients usually make?
Regarding this, I agree - flamebait, article - I've only ever worked with one other female coder. Her code was the sloppiest thing I've ever gone cross-eyed staring at. Usually that doesn't matter to the clients much as long as it works, her code didn't even work half the time. With 0 lines of documentation 2 out of the 3 projects I worked with her on I ended up completely redoing her responsibilities myself.
Do I judge all women coders by her standard? No I'm not that ignorant.
*DrugCheese rants*
*/
Sorry, I couldn't stand to see an unclosed comment... It was driving me nuts.
If I mod you up, it doesn't necessarily mean I agree with what you've said, sorry.
I've seen 1, ever, a DB programmer, she was supposedly good.
Inept male programmers have an easier time hiding in the crowd. Inept women programmers can't.
Because of this culling effect, the women that are still around are, on average, more capable.
Industries dominated by women have a similar effect. The males end up being better because they need to overcome the inherent prejudice to get the same performance review.
Only if it has stopped.
Thanks for the link. When she refers to gender as "women" and "boys" it really makes it clear where her prejudices are.
As a young man, I have worked hard to mentally apply the words "women" and "ladies" in place of "girls" during recent years because I have found that many females have a reasonable personal preference not to be called "girl" ("chick" is also a bad choice).
In any case, seeing "boys" applied within an "anti-man" argument is a refreshing reminder that women also suffer the negative effects of sexism and bigotry.
Support the 30 Hour Work Week!!!
How does "nothing I'd ever thought about before" and "fairly androgynous" code add up to "at least 80 per cent of the time"?
If you publish shit based on psychic code-reading ability and made-up, pulled-out-of-your-unthinking-ass subjective factoids, you need to publish it as what it is - fiction.
I prefer rogues to imbeciles because they sometimes take a rest.
Maybe it is because of incompatible personalities, and not so much because of gender?
I know your post is a joke, but on a serious note ...anybody with a computer science background knows at least one female programmer. Matter of fact, she's the first programmer ever -- Lady Lovelace.
And if you live in that twisted world of AM/PM.
ics
Sure, women have a different way. In my experience, that is rarely the best, most concise, most efficient way of doing something.
When giving directions, most men will say something like, "Turn north on Smith Street." Technically, it's correct, but most people don't know north from south.
A woman usually navigates via landmarks, such as, "turn right at the Shell station." That can also be confusing if it's *too* generic and the driver is going to be passing a lot of Shell stations. OTOH, it's often a lot easier to see and remember a landmark than a often obscured street sign. That doesn't make it more or less concise than a man's directions.
When giving directions, don't give people your special "short cut route" unless you're having to do so they can avoid construction or other major delay. Short cuts are rarely direct and it's best to have as few turns as possible even it means it's longer mileage-wise. If you write down directions to send, it's best to double check with a map as it's easy to leave out parts when it's somewhere you travel all the time. Or better yet, just Goggle a map, print it out and tuck it into the invite.
As to code, sloppy, lazy code is just that and there's no helping someone with bad habits. But if someone is trying to make it cryptic on purpose to be macho or, more likely, a feeble attempt at job security, they're an idiot. THEY may have to go back one day and rework that code and trust me, they won't remember what they were doing. I think a lot of coders don't document like they should, usually because they're under a deadline. Or they think they won't have a problem because they're working in it all the time. And they almost never go back after the project to document. But consider that, situations change, and you might find yourself changing languages, working for a year or so on another project. THEN just try and go back to ASP after being immersed into ASP.net or Perl or something else. You'll wish you'd paid more attention to documenting.
If you've never been modded as "flamebait" or "troll," you've never tried to argue a minority viewpoint here!
The biggest problem with "brains work differently" is that "differently" is too easily interpreted as "better". People simplify this down to a one dimensional score of IQ. No matter how you rig the scores, one group is going to come out looking "better". Then you get things like how former Harvard President Summers' speech was interpreted. And you get denial for purely political reasons, insistence that everyone is equal because otherwise it would be unfair.
Which is the better chess piece, the knight or the bishop? That's not a good question. It presumes that there's a clear advantage to one or the other when actually it's situational. The knight is regarded as better for closed positions, while the bishop is better for open positions. Nonetheless, chess experts couldn't resist concluding that perhaps the bishop is overall slightly better, and have gone as far as giving computers a blanket preference in that direction. Perhaps the bishop is the better piece for the computer's typical style of massive tactical computation paired with ever more sophisticated but insufficient heuristic rules to compensate for zero understanding of the overall strategic considerations of a chess position. (For instance, computers have been known to continue to grind out move after move in positions where the outcome is already known, positions such as king and knight vs king which is a draw no matter what the players do, because unless specifically programmed to do so, computers do not assess positions from a view of what is possible.) What I wonder is if programming is a situation in which men's or women's style of intelligence seems to work better, or is programming a more varied situation than that?
Intellectual Property is a monopolistic, selfish, and defective concept. It is "tyranny over the mind of man"
The variation among the individuals of a gender is bigger than the difference between the genders.
My other account has a 3-digit UID.
Second, your supporting data makes no sense. Why are you asking about names of famous flute players and comparing to the stats of high school flute players? Those data points may exist, but you have not demonstrated them anywhere in your post. There is no direct correlation between high school flute players and famous flute players unless you can show data that says otherwise. (Such as, "80% of famous flute players played flute in high school", or similar).
Giving directions should be a lesson to coders and developers in general.
....
Turn left (North) on 16th street (Starbucks on the corner)
Go 1.5 miles (about three minutes) to Broadway (Shell Station) and turn left (West)
The problem is that people tend to give directions one way, or another, but not both. Both is always better, even for those that tend to work one way better than another.
I don't mind obfuscated code, if it is well documented as to what it does. It can be more efficient way to get something done.
The some of the best coders make some of the worst documenters, because they think everyone should think like them.
Agent K: A *person* is smart. People are dumb, stupid, panicky animals, and you know it.
Whoah, when did this discussion go from geeks to nerds?
Way to miss the forest for the trees everyone.
1) 80% of software cost goes into maintenance.
2) Developers rarely stick with a position for more than 3-5 years.
It's more cost effective to have code that is easy to maintain, thus her focus on READABILITY. I can't tell you how many man-hours have been lost on our projects because our code is stupid and unreadable. Remember every time you've wanted to throw a brick at the guy before you? Yeah, that's stress that I really don't want yo be paying for on my project. Now:
3) Developers spend more time reading code than writing code.
4) Developers absorb code density faster via code examples than they do via documentation.
So, it's better to write self-documenting code, than to document highly analytical code. That means sensible variable/method names as well as collections/relationships that are relevant, at least where OOP is concerned.
Now, most business software is non-algorithmic, i.e. it isn't really computing so much as it is moving data around. The math isn't all that complex when the hardest thing you have to model is your database and the queries used to run it.
Considering all these things, I often hire programmers with better verbal skills, even at the expense of their analytical skills. Women tend to be more verbal than analytical, thus the authors conclusion. It's also easier to teach optimization and performance than it is to teach English grammar/syntax and how to "port" that to a programming language, and as outlined above, this is the part of the software that is not only the most expensive, but will give you the higher ROI over the life of that software. Enterprisey stuff can linger for tens of years, incurring maintenance costs all the while.
Now if the author had looked beneath the surface of what her gut (correctly) told her into the real cognition of what was going on, she might not have pissed off a bunch of insecure slashdot trolls. She might have even realized what was "better" about what she was seeing and how to train the rest of her staff to perform at that level.
but then again, commenting on a katz story is almost as self-serving as the katz story itself. -tensionboy
Heheh, unfortunately I have.
A lot of people feel the same way about COBOL, but for a language used in more than 80% of the world's businesses it's done pretty well. Say what you will about it, but it has been very influential, and was groundbreaking in its time.
God, schmod. I want my monkey man!
That's good to know. Some of the comments starting making feel like I was a unicorn.
Yeah I know a female programmer - me.
I've known good female programmers and have met a few bad ones (like a database programmer who claimed joins were impossible). I can say the same thing for my male colleagues.
As far as commenting goes, it depends on the programmer.
writing clear, readable code isn't a "guy" thing or a "girl" thing, it's a "good programmer" thing. similarly, writing confusing, obfuscated code isn't a "guy" thing or a "girl" thing, it's a "clueless programmer" thing (unless it's being done for the ioccc, in which case it's totally cool).
do i comment my code? yes, but it's not because i'm "touchy-feely". i hate commenting my code. i hate documenting my work. it's a chore and a bore (and something i often leave until the very end). i do it because it's essential for me to be able to go back to my work in a few months time and understand what the heck it was i was doing/thinking at the time. this was drummed into us at school by our prof, who made code commenting and documentation 15% of the grade. he also required we use informative variable names and write legible code and we'd get dinged heavily if we didn't. i think he was right and so i continue to try to follow his advice every day, and this includes code i write purely for myself, but it goes against my nature.
i'm reminded of one time, early in my career, where i was given a small problem to solve. i solved it, then set about seeing what i could do to make it tighter and more clever, getting very caught up in the process. finally, i was very pleased to have something that used all kinds of nifty, bit-shifting tricks and whatnot and fit all on one line. i was pretty stoked, actually. awesome! it looked cool! the senior programmer mentoring me took a look at it, told me he thought it was way neat, but requested that i redo it all so that it a) was on many lines and 2) made sense to everyone else who'd have to come by later and figure out what i was doing. oh, and could i please be sure to include comments? lesson learned.
soupy twist
2) Don't optimize (unless you must), and even then, leave the unoptimized (readable) code commented out. And only optimize the code blocks than a profiler tells you to... there is no point optimizing a loop that runs once.
// fixing xxxx problem, or // removing yyyy option. When someone comes back to work on it later it really tells them nothing. A better solution is to remove the code and let the CVS do it's job.
I generally agree, with one comment. Don't leave commented code unless it is well documented WHY you are leaving it. In this example I think I would prefer that a good explanation of the purpose of the section rather than leaving the unoptimized code. The reason is that over time there is a good chance that someone will modify the executing code, but not the commented code. I've worked on a number of projects where code was commented out with a note
It is amazing what you can accomplish if you do not care who gets the credit. -- Harry Truman
That's a good point... In this day and age it probably makes more sense to:
a) Write it the easy-to-understand way.
b) Write some really good unit tests (100% or greater code coverage.
c) Optimize the hell out of it, and make sure the tests still pass.
The unit tests work as a form of documentation, as well as for regression testing. a and b can of course be reversed, if you're into that sort of thing. I usually do a bit of both.
Jeremy