“程序媛”往往比“程序猿”更受认可,但前提是不能公开性别 -九游会j9官网ag登录入口

本文由钛媒体综合编译自、和的报道,joyce/编译。

摘要: 科技圈的性别歧视早已不是新鲜,女性程序员的代码接受率可以达到78.6%,比男性程序员的74.6%要高。然而,若女程序员对外公开自己的性别,其代码接受率便出现了大幅下降,只剩下62.5%。

如题,用一句话总结这项最新的学术研究的结论就是,女程序员的代码往往写得比男性更好,而且人们也都知道这一点。

但是,得到这种认可有个前提,就是她们必须保密自己的性别。

做这个研究的是加州州立理工大学和北卡罗来纳州立大学的计算机科学研究人员,他们在github上收集信息,分析了大约400万个用户的行为,并确保这些人都是在去年四月一日才开始注册使用github的用户。

github并不要求用户注明性别信息,不过研究人员采用了一种他们称为“新颖性别关联”(novel gender-linking technique)的技术,识别出了其中超过35%、即约140万人的性别信息,然后将其结合他们提交的约300万个“pull request”的数据来进行分析。

github总部设于旧金山,是一个大型的代码库,全球用户量超过1200万。github上的软件开发者可以协作完成项目,可以检查批评其他人的工作,还可以提出自己的改进意见或九游会j9官网ag登录入口的解决方案。“pull request”是github上的一个指标,若某人贡献的代码成功其他程序员的项目所采用,这就算一次pull request,并且这个新代码会整合进对方的项目。

研究者发现,女性程序员的代码接受率可以达到78.6%,比男性程序员的74.6%要高。然而,若女程序员对外公开自己的性别,其代码接受率便出现了大幅下降,只剩下62.5%。

研究者们试图解释这种现象,于是检验了其他影响因素,比如说女性对源代码做出的改动是否更小、女性是不是只会在某些特定的代码语言上表现更好。事实上,两个问题的答案都是否定的,女性程序员的代码接受率在各种程度、各种语言上都超过了男性。

研究者进一步排除干扰,看看这些数据是否受到“反向偏见”(reverse bias)的影响,即开发者是否会故意优先采纳女性的代码,以提高行业多样性、鼓励作为弱势群体的女性参与进来。然而,即使是将注明性别信息和未注明相关信息的实验者分开来分析,结果都是一样的。

科技行业的性别歧视早已不是新鲜事。一项2013年调查的数据显示,软件开发者中女性的比例只占11.2%。参与研究的那些学生还有点惊讶,因为结果竟然证明女性编写的代码更受认可。然而,“我们的结果显示,虽然github上的女性总体来说更有竞争力,但针对她们的偏见仍然存在。”

卫报采访了几名github上的女性开发者,结果呈现出了这种性别歧视更复杂的一面。

米切尔(lorna jane mitchell)是一名女性软件开发者,她的工作主要都是在github上完成的。她说,没有办法分辨某个pull request是否真的是由于偏见而被忽略,或者只是因为那个项目的发起者太忙而不小心忽略掉了。她在github上的档案注明了自己的女性身份,她也表示自己不会因为这个研究的结果而做出改变。

“我思考过,我还是觉得在档案里明确指明性别是明智的选择,对我来说,自己的女性身份有着重要意义。”米切尔在邮件里写到。

另一位开发者弗洛姆(isabel drost-fromm)在github上的头像是一个女性卡通人物。她觉得,自己在github上工作时从来没有受过歧视,但她一般会用github来完成的工作都是跟相互熟悉、了解的团队合作的。

布莱恩(jenny bryan)是英属哥伦比亚大学的统计学教授,她用github来帮助自己教书,也会用一种叫r的编程语言来进行开发。她也在档案里写明了自己的性别,而且她不认为自己曾经因为性别而受到过区别对待。

“我最多这么说,不认识我的男性有时会跟我解释一些事情,事实上我懂的比他们还多,”她写到,“但是我在r社区里有过交流的男性都了解我,如果说我的性别带来了什么影响的话,那就是他们其实会努力支持我的工作,一起学习并给社区做贡献。”
来自:
4
0
评论 共 0 条 请登录后发表评论

发表评论

您还没有登录,请您登录后再发表评论

相关推荐

  • plsql程序性能分析及优化   经验总结 实施过程中,经常会使用 pl/sql developer 工具进行数据转换和处理业务数据。通过性能 优化来提高程序执行效率是必须掌握的一份技能。性能问题中绝大部分都是由于程序编写的 不合理、不规范造成的。本文档阐述了程序中常见的不优化的脚本编写,导致的性能问题。

  • 本短文着意于消除一些关于基于成本的优化器(cbo)的错误说法,强调一般的错误和问题。background 背景~~~~~~~~~~为了执行任何一个sql语句,oracle都要先导出一个“执行计划(execution plan)”。它基本上就是oracle如何检索出符合给定sql语句要求的数据的执行计划。oracle7和oracle8 都有两种可以为sql语句导出执行计划的优化器:- 基于规则的优化...

  • 什么是成本 i/o成本 我们的表经常使用的myisam、innodb存储引擎都是将数据和索引都存储到磁盘上的,当我们想查询表中的记录时,需要先把数据或者索引加载到内存中然后再操作。这个从磁盘到内存这个加载的过程损耗的时间称之为i/o成本。 cpu成本 读取以及检测记录是否满足对应的搜索条件、对结果集进行排序等这些操作损耗的时间称之为cpu成本。 对于innodb存储引擎来说,页是磁盘和内存之间交互的基本单位,设计mysql的大叔规定读取一个页面花费的成本默认是1.0,读取以及检测一条记录是否符合搜索条

  • 基于成本的优化 标签: mysql 是怎样运行的 什么是成本 我们之前老说mysql执行一个查询可以有不同的执行方案,它会选择其中成本最低,或者说代价最低的那种方案去真正的执行查询。不过我们之前对成本的描述是非常模糊的,其实在mysql中一条查询语句的执行成本是由下边这两个方面组成的: i/o成本 我们的表经常使用的myisam、innodb存储引擎都是将数据和索引都存储到磁盘上的,当我们想...

  • cardinality(集的势)是指集合所包含的记录数,说白了就是制定结果集的行数,这个指定结果集是与目标sql执行计划 某个具体执行步骤相对应的,也就是说,cardinality实际上表示对目标sql的某个执行步骤的执行结果所包含记录数的估 算,当然如果是针对整个目标sql,那么此时的cardinality就表示这个sql最终执行结果所包含的记录数估算。 cardinality和成本值得估算相关很大,因为oracle得到执行结果集所要耗费得i/o资源可以近视得看作随着该结果集所包含 得记录数得递增

  • 1. plsql程序优化原则 1.1 导致性能问题的内在原因 导致系统性能出现问题从系统底层分析也就是如下几个原因: l  cpu占用率过高,资源争用导致等待 l  内存使用率过高,内存不足需要磁盘虚拟内存 l  io占用率过高,磁盘访问需要等待 1.2 plsql优化的核心思想 plsql优化实际上就是避免出现“导致性能问题的内在原因”,实际上编写程序,以及性能问题跟踪应该本着这个

  • 什么是sql优化器? sql 优化器会分析一个 sql 查询语句并选择最高效的方式来执行请求。非常简单的查询可能只有一种执行的方法,与此同时,复杂的查询请求可能有数以千计,甚至数以百万计的方式可供选择。优化器的优化效果越好,就越接近最佳的执行方案,而这个最佳方案将会是执行查询请求的最高效方法。 下面是一条看上去简单的查询 sql : select * from customers c, o...

  • cbo基于成本的优化器:让oracle获取所有执行计划的相关信息,通过对这些信息做计算分析,最后得出一个代价最小的执行计划作为最终执行计划。 还是前面的例子,让我们再来看看cbo的表现: sql> select /* all_rows */ * from t where id = 1; 已选择50600行。 执行计划 ----------------------

  • oracle10g中optimizer_goal参数被废弃问题  如果在oracle10g服务器上产生了一个sql trace文件,直接使用oracle10g的客户端再利用tkprof格式化sql语句的执行计划,不会有问题,如果使用10g以下的oracle客户端,比如9i,8i连接到10g的客户端,那么,如果使用了explain参数产生sql语句的执行计划,则在格式化的语句的执行计

  • sql优化器基于规则优化器和基于成本优化器的区别oracle有两种优化器:rbo和cbo。 rbo的最大的问题在于靠硬编码在oracle数据库代码中的一系列规定的规则来决定目标sql的执行计划的,而并没有考虑目标sql中所涉及的对象的时间数据量,实际数据分布情况,这样一旦规定规则并不适用于该sql中所涉及的实际对象时,rbo根据规定规则产生的执行计划就很可能不是当前情况下的最优执行计划了。下面我们...

  • 原理篇01–优化器与成本 优化器是数据库最核心的功能,也是最复杂的 一部分。它负责将用户提交的sql语句根据各种判断标准,制定出最优的执行计划,并交由执行器来最终执行。优化器算法的好坏、能力的强弱,直接决定了语句的执行效率。综合比较来说,oracle的优化器是功能最强大的。当然,优化器本身是数据库系统中最为复杂的一个部分。 成本是优化器(基于成本的优化器)中反映 sql语句执行代价的一个指标。优化器通过比较不同执行计划的成本,选择成本最小的作为最终的执行计划。如何理解成本、成本如何计算也就成为我 们学习基于

  • 什么是成本我们之前老说mysql执行一个查询可以有不同的执行方案,它会选择其中成本最低,或者说代价最低的那种方案去真正的执行查询。不过我们之前对成本的描述是非常模糊的,其实在mysql中一条查询语句的执行成本是由下边这两个方面组成的:i/o成本我们的表经常使用的myisam、innodb存储引擎都是将数据和索引都存储到磁盘上的,当我们想查询表中的记录时,需要先把数据或者索引加载到内存中然后再操作。...

  • 成本模型,也有叫做代价模型,原文是cost model,下面翻译都使用成本模型。 8.9.5 优化器的成本模型 sql查询的方式多种多样,mysql的优化器使用基于对查询成本进行预估的成本模型来生成执行方案。优化器拥有一系列编译过的“成本常量”来决定使用怎样的执行方案。 除了编译过的成本常量之外,优化器在构建执行方案的时候还会用到一个数据库,也是用来做成本评估的。这些成本评估用的数据保...

  • 基于成本的一些规则或者计算法则,对于理解cost计算和优化器最终的执行计划选择有很大帮助。参考《cost based fundamental》,仅仅列出一些涉及到的内容或者title,可以看出作者在优化器的内部原理和实际体现方面...

  • 196. question 32 in your database server, the parameter plsql_optimize_level has been set to 2. what would this setting achieve? a> it degrades the run time and compiler performance. b> it p

  • oracle cbo优化器有三种变体,每一种都有其特定的内置的实现代码,但它们的目标是一致的——用最少的资源获取给定语句的结果集。参数optimizer_mode决定了优化器模式: all_r...

  • oracle的优化器(optimizer) (cbo优化)   oracle在执行一个sql之前,首先要分析一下语句的执行计划,然后再按执行 计划去执行。分析语句的执行计划的工作是由优化器(optimizer)来完成的。不同的情况,一条sql可能有多种执行计划,但在某一时点,一定只有一 种执行计划是最优的,花费时间是最少的。相信你一定会用pl/sql devel

  • crane 成本优化工具实验记录 准备集群 本文通过 kind 创建一个四节点集群环境: # cat << eof > cluster.yaml kind: cluster apiversion: kind.x-k8s.io/v1alpha4 nodes: - role: control-plane - role: worker - role: worker - role: worker eof # kind create cluster --config cluster.yaml 安装

  • 2014-09-25 created by baoxinjian 一、摘要 1. oracle优化器介绍 本文讲述了oracle优化器的概念、工作原理和使用方法,兼顾了oracle8i、9i以及最新的10g三个版本。理解本文将有助于您更好的更有效的进行sql优化工作。 2. rbo优化器 rbo是一种基于规则的优化器,随着cbo优化器的逐步发展和完善,在最新的10g版本中oracle...

  • 本短文着意于消除一些关于基于成本的优化器(cbo)的错误说法,强调一般的错误和问题。   background 背景   ~~~~~~~~~~   为了执行任何一个sql语句,oracle都要先导出一个“执行计划(executi...

global site tag (gtag.js) - google analytics
网站地图