我们这些“开发者”是不是在把“知识”从下级和同行那里“守”起来?🤦 背景语境 PSA:你觉得常见的东西,对其他开发者来说可能并非如此。所以在屏蔽此类内容之前,请三思。兄弟程序员?难道我们不能更友善一点吗?兄弟程序员?所以问问自己,镜子里的自己?你会做出改变吗?我看到其他文章/推文也发生过类似的情况,有什么我可以帮忙的吗?继续努力!评论区的其他建议 历史岔路

2025-05-28

我们这些“开发者”是否在把关着来自下级和同行的“知识”?🤦

背景环境

温馨提示:你常见的内容,对其他开发者来说未必如此。所以在屏蔽此类内容之前,请三思。

兄弟,程序员?我们就不能友善点吗?

兄弟程序员?

那么,问问镜子里的自己吧!你会做出改变吗?

我看到其他文章/推文也发生了类似的事情,我能做些什么来帮忙吗?

继续努力吧!

来自评论的额外建议

历史岔路

背景环境

我的初创公司联合创始人最近写了一篇关于我之前认为是“常识”的文章,这篇文章迅速走红。

不幸的是,根据互联网的规则,任何“病毒式”传播的内容都会招致相当多的批评,甚至是人身攻击,尤其是在 dev.to 之外;我发现有些内容甚至伤害了我的联合创始人个人。

然而,这与性别歧视、JavaScript 或互联网规则无关(所有这些都存在值得单独强调的有效问题)。

这是关于“开发人员”以及我们在把关“知识”方面所扮演的角色,例如其他人的观点

抛开人身攻击不谈,真正引起我注意并促使我撰写这篇文章的是以下评论:

难道这不是很明显吗?________________ 你是 _____,
永远不要再写这样的 [ ] 文章。

附注:我无意羞辱/指责原作者。这段引文经过了改写,使其无法被谷歌搜索到,并删除了脏话。需要说明的是,确切的措辞有所不同。

我之所以震惊,不仅是因为最后它是多么的残忍,还因为我也曾说过这样的话。

  • SL:真的吗?!push差别这么大
  • EU:好吧,concat需要创建一个新数组,并复制所有内容
  • SL:JavaScript JVM 不会自动优化这种执行吗?因为我没有使用旧的数组
  • 欧盟:嗯,事实并非如此,不幸的是由于规格......
  • SL:我应该写一篇关于这个的文章
  • 欧盟:这不是很明显吗,我怀疑是否值得写
  • SL:我不太清楚
  • 欧盟:(在我的脑海里——我很惊讶你不知道)
  • 欧盟:好的,那值得一试
    SL 代表我的联合创始人 Shi Ling。EU 代表我,Eugene

尽管语气轻松多了,但不写这篇文章的理由是一样的。

作为一名资深开发者,即使只是轻描淡写地忽略这类内容,也会对其他初级开发人员和同事产生寒蝉效应,尤其是在规模更大的组织中。因此,虽然这些言论或许没能吓倒石玲(毕竟是她写的),但却可能让我周围的其他同事闭嘴。

我的批评错了吗?

看看那些关于“我需要重写我的代码”或“我从来不知道”的积极转发和评论的数量。这并不明显,但这篇文章值得写。

然而,真正让我受打击的是,出于“沮丧”或者说不成熟,我后悔地看了评论者的个人资料。

我意识到这不仅仅是一个十几岁的年轻人无心之言。

这位资深工程师非常受人尊敬,他领导着一个庞大的开发团队,背景和我差不多。对我来说,这真是太可怕了。

我看着镜子,想象着未来的自己

镜子里的邪恶

进一步挖掘各种评论后发现,他并不是唯一一个......

这让我想到了下一个观点……


温馨提示:你常见的内容,对其他开发者来说未必如此。所以在屏蔽此类内容之前,请三思。

作为一个行业,编程相对来说还不成熟,历史还不到200年(从Ada Lovelace算起)。而网络行业则更加年轻,历史还不到30年。

这与

  • 科学医学:约2500年历史
  • 建筑和施工:>5000年历史

因此,我们所学习的技术似乎在不断变化,几乎没有任何事物具有稳定的(12 年以上)长期标准。

根据这个定义:你对这一代人所学到的不值得传播的“常识”所做的任何假设,都是对你的下属和同龄人做出的错误假设。

我们还应该摒弃这样的观念:如果一个人不“理解这一点”,那么他就不配被称为开发人员。

需要澄清的是,我的联合创始人绝不是“初级”开发人员。我们两人的专业领域非常不同。

虽然我可能对 ES5 规范以及 V8 内部工作原理有非常深入的了解,但这扭曲了我对 JavaScript“常识”的看法。

相反,她对 CSS 的各种怪癖以及现代前端框架的vue.js工作原理有着像百科全书一样深厚的知识。我承认,直到今天,我仍然会犯一些非常基本的新手错误。

所以,如果我的假设对一位拥有不同专长的“高级”开发人员来说是错误的,那么对一位新的“初级”开发人员来说,情况不是更糟吗?尤其是在编程训练营兴起的今天。

所以,直到我们能找到一个通用的、稳定的、通用的编程工程标准,我们可以把它当作“常识”,就像建筑师或医生那样(但可能还要再过50年才会有)。我现在正大力强调这一点,因为我们与其他行业截然不同。

永远不要做出这样的假设。

赫拉克利特名言:除了变化,没有什么是永恒的

哎呀,对于那些不相信的老前辈来说,我们很多人(包括我自己)都曾经认为 C 语言风格的内存指针操作是必备的常识,而当这些知识缺失时,我们就会以此为由拒绝聘用初级员工。

我们现在在现代网络开发和他们使用的编程语言方面存在多大的错误?


兄弟,程序员?我们就不能友善点吗?

即使有合理的批评...

  1. 问问自己,你是否可能犯同样的错误?
  2. 您希望有人对您或您所爱的人说这样的话吗?
  3. 这是建设性的批评吗?

我们不应该以“优越的理由”来把关哪些该写,哪些不该写。相反,我们应该用批评来鼓励改进。

例如,有人反复批评。这与基准测试方法有关。然而,与其说是……

史上最差的基准测试

更友善、更有建设性的评论是

我们可以通过做 ____ 而不是 ____ 来提高基准

先说一句,对于大多数关于基准测试的建设性批评,您是对的。虽然由于两者之间存在巨大差异,这可能不会改变最终结果。这是一个值得改进的地方,我和我的联合创始人都对此表示感谢。

或者正如 XKCD 所言

XKCD #1053

说“什么样的白痴不知道黄石超级火山”比第一次告诉别人有关黄石超级火山的事情要无聊得多。

那么你更愿意成为哪一个?


兄弟程序员?

当我说这与性别歧视无关时,我是认真的。

知识的压制可能与性别无关,从资深员工到资历较浅的员工,肯定也存在这种现象。

然而,“Br-grammer”这个短语是故意使用的。

我确信有例外(总是有的),但这更多的是我们大多数人,即开发社区的男性,而不是其他方式。

尽管我没有任何统计数字来支持这一点。

我们社区中的少数群体非常清楚自己的声音被严重压制的感受。

少数群体最注意不要将他人的“知识”拒之门外。

我看到的对我的联合创始人的几乎所有人身攻击/恶意批评都来自我们男性发展社区。

我们必须在这方面改进自己,改善我们的社区。我们可以有意识地公开反对,也可以潜意识地通过言行来表达。

我并不是要求我们每个人都达到不合理的完美主义标准(因为难免会出错),也不是在批评现在的你。

作为一个也犯过错误的人,我想说的是:我们要在个人层面做出细微的、循序渐进的改变,从而推动社区的进步。


那么,问问镜子里的自己吧!你会做出改变吗?

改善你周围的社区。鼓励知识共享(尽管这对你,甚至对我,可能都微不足道)。或者你自己也分享这些知识。


我看到其他文章/推文也发生了类似的事情,我能做些什么来帮忙吗?

而不是正面交锋,然后“喂饱巨魔”。

对于不具建设性的批评(例如,基准较差),请代替作者礼貌地询问

你说的_____是什么意思?内容可以如何改进?

这给了个人一个澄清的机会,因为他们可能并不总是故意伤害,有时可能只是翻译过程中出现了错误。

只要记住保持尊重、建设性和清晰的态度,就能化解任何紧张局势

对于非常尖锐的评论或人身攻击,最好回复评论或作者,同时忽略那些恶霸。让他们知道,还有其他人欣赏他们的作品。同时,也略微指出那些批评。

我个人觉得内容很有用,不管别人怎么说。谢谢

以上内容无论内容类型如何都是通用的(它可以应用于开发社区之外)。

最后,对于那些提出此类批评的开发者,我写这篇文章的部分原因在于,这样我以后就可以向其他人指出这一点。就像他们遇到的情况一样。

我个人认为你们做的很棒,无论别人怎么说。谢谢。对于那些持不同意见的开发者,我们应该鼓励而不是压制我们的同行。

以上任何做法都要牢记,因为你有可能把批评性评论从作者身上转移到自己身上。如果评论针对你个人,不要轻易接受。要坚强,不要理会它。

要知道,你已经尽了自己一份力,让内容创作者知道,批评并非唯一的声音。作为接受批评的一方,即使他们最终保持沉默,我也要说,这在很大程度上有助于让他们知道,曾经有人在那里。

致敬所有默默奉献的英雄们。谢谢你们。


继续努力吧!

对于我的联合创始人来说,即使你以前在工作中面临双重标准,或者现在融资时面临投资者的三重标准,或者在撰写内容时面临互联网的残酷。

致所有其他职业妈妈、单身妈妈、 LGBTQ 和其他少数群体。

  • 继续编码
  • 不断进步
  • 继续写
  • 继续做你正在做的各种伟大的事情
  • 不要让批评压垮你
  • 突破玻璃天花板
  • 并出色地完成你的工作

和平🖖


来自评论的额外建议

另外,请考虑阅读recurse.com/social-rules

感谢@picocreator撰写这篇文章

顺着这个思路,我非常赞同 Recurse Center 的社交规则——尤其是其中关于“不要假装惊讶”的那条。他们对此的解释是:

假装惊讶是指当别人不知道某事时,你表现出惊讶。在这种情况下,表现出惊讶会让人因为不知道而感到内疚,从而降低以后提问的可能性,这反而会让他们更难学习。

“不假装惊讶”这个名字不太好。当有人在你不知道某事时表现出惊讶时,无论他们是假装惊讶还是真的惊讶都无关紧要。效果是一样的:下次你有问题时,你更有可能保持沉默。这条规则的准确名称应该是“当有​​人不知道某事时不假装惊讶”,但这名字太拗口了,目前为止,现在这个名字已经沿用了。

假装(或真的)惊讶绝对不像你提到的某些例子那么刻薄,但它仍然会让初来乍到的人不敢发声或寻求帮助。我只是想提醒一下,因为我觉得有些人(即使出于好意)很容易无意中就这么做。

并了解被动/主动守门之间的区别

我认为这个问题是双重的。

一方面是主动把关。人们到处宣扬他们自己或他们使用的工具不够好。

有了 Java 之后,你该如何使用 PHP?有了 C# 之后,你该如何使用 Java?既然 PHP 已经是一门真正的编程语言,为什么还要转向 JavaScript?

甚至我的编程技术教授也说 JavaScript 只是一个玩具,与 Java 相比根本不算什么。

人们总是因为各种莫名其妙的理由互相批评别人的工作成果,而不是互相帮助。这种情况必须停止,我觉得行业中女性和少数族裔的增多会促进这种情况的发生。CoC 像野火一样蔓延,人们也普遍变得更加友善。我在 dev.to 上看到的那几个老派超级书呆子很快就没待多久了。

另一方面,我们被动地守着大门,或者干脆就是无知。我想这就是你所说的。这可能有很多原因,我只能谈谈我遇到的一些。

我经常觉得自己是个水平平庸的开发人员,所以我并不重视自己所学的大部分知识,这让我觉得自己是业内学习最晚的人之一。我花了一年时间才理解函数,花了几个月时间才理解闭包,又花了一年时间才理解单子等等。我一直是个学习很慢的人,游泳9岁,骑自行车14岁,所以我想这就是我感觉其他人都已经掌握我刚学到的东西的原因。

我还和很多老派的超级书呆子共事过,他们选择技术作为项目,通常表现得好像自己什么都懂似的。我花了几年时间从事自由职业和写博客,才发现他们大多只是在吹牛,还有很多人,他们懂的还不及我的一半,很想和我一起工作或向我学习。


历史岔路

对于那些对上面使用的年度数据的准确性感兴趣的人。


我已经考虑这篇文章有一段时间了,它有意以一种不责怪个人过去行为的方式写成,而是鼓励他们反思如何做得更好。

写作并非我的强项,而且我确信我处理这个问题的方法也可能存在缺陷。任何关于此问题的类似经验的讨论,无论是鼓励他人,还是提出其他可能的想法,甚至对本文进行修改,都将不胜感激。

文章来源:https://dev.to/uilicious/are-we-developers-gatekeeping-knowledge-from-our-juniors-and-peers-4gc6
PREV
为什么每个人都在争论 CSS/UX 和 JS
NEXT
5 个 Docker 致命陷阱 😱 - 针对新用户 结束语