r*m
2 楼
http://www.yinwang.org/blog-cn/2015/03/03/how-to-respect-a-prog
怎样尊重一个程序员
得知一位久违的同学来到了旧金山湾区,然而我见到他时,这人正处于一生中最痛苦的
时期。他告诉我,自己任职的公司在他加入之前和之后,判若两人。录取的时候公司对
他说,我们对你在实习期间的表现和学术背景非常满意,你不用面试,甚至不用毕业拿
学位,直接就可以加入我们公司成为正式员工。然而短短一年后的今天,这位同学已经
完全感觉不到公司对自己技能的尊重。Manager让他做一些乱七八糟没技术含量的事情
,还抱怨说他做事太慢,并且在他的evaluation上很是写了一笔。在人格尊严和工作安
全感的双重打击之下,这位同学压力非常大,周末经常偷偷地加班,仍然无法让
manager满意。
我很了解这位同学的能力,在任何一流公司任职,肯定是绰绰有余了。他的名字我当然
保密,然而他所任职的公司因为太过嚣张,我不得不直接指出来——这就是被很多人向
往得像天堂一样的地方,Google。这位同学所描述的遭遇,跟我几年前在Google的实习
经历如出一辙。我仍然记得,Google的队友在旁边看着我用Emacs,用小学老师似的口
气对我说:“按Ctrl-k!” 我仍然记得,在提交队友完全无法写出来的高难度代码时
,被指责和嘲笑不会用Perforce。我仍然记得,吃饭时同事们对所谓“Google牛人”眉
飞色舞的艳羡。我仍然记得,最后我一个人做出整个团队做梦都做不出来的项目的时候
,有人发出沉闷的咆哮:“快——写——测——试!” ……
我的这位同学也算得上本领域顶尖的专家了。如此的践踏一个专家的价值,用肤浅的标
准来评判和对待他们,Google并不是唯一一个这样的公司。我之前任职的好几个公司,
或多或少都存在类似的问题。很多时候也不一定是公司管理层无端施加压力,而是程序
员之间互斗的厉害,互相评判,伤害自尊。从最近Linus Torvalds在演讲现场公然对观
众无理,你可以看出这种只关心技术,不尊重人的思潮,在程序员的社区里是非常普及
的。
后来我发现,并不是程序员故意想要藐视对方或者互相攻击,而是他们真的不明白什么
叫做“尊重”,他们不知道如何说话才可以不伤害另一个程序员,所以有时不小心就让
人怒火中烧。所以说,尊重他人其实是一个“技术问题”,而不是有心就可以做到的。
因为这个原因,我想在下文里从心理和技术角度出发,指出IT业界不尊重人现象的起源
,同时提出几点建议,告诉人们如何真正的尊重一个程序员。我希望这些建议对公司的
管理层有借鉴意义,也希望它们能给与正在经受同样痛苦的程序员们一些精神上的鼓励。
我觉得为了建设一个程序员之间互相尊重的公司文化,应该注意以下几个要点。
认识和承认计算机系统里的历史遗留糟粕
很多不尊重人现象的起源,都是因为某些人偏执的相信某种技术就是世界上最好的,每
个人都必须知道,否则他就不是一个合格的程序员。这种现象在Unix(Linux)的世界
尤为普遍。Unix系统的鼓吹者们(我曾经是其中之一)喜欢到处布道,告诉你其它系统
的设计有多蠢,你应该遵从Unix的“哲学”。他们仿佛认为Unix就是世界终极的操作系
统,然而事实却是,Unix是一个设计非常糟糕的系统。它似乎故意被设计为难学难用,
容易犯错,却美其名曰“强大”,“灵活”。眼界开阔一点的程序员都知道,Unix的设
计者其实基本不懂设计,他们并不是世界上最好的程序员,却有一点做得很成功,那就
是他们很会制造宗教,煽动人们的盲从心理。Unix设计者把自己的设计失误推在用户身
上,让用户觉得学不会或者搞错了都是自己的错。
如果你对计算机科学理解到一定程度,就会发现我们其实仍然生活在计算机的石器时代
。特别是软件系统,建立在一堆历史遗留的糟糕设计之上。各种蹩脚脑残的操作系统(
比如Unix,Linux),程序语言(比如C++,JavaScript,PHP,Go),数据库,编辑器,
版本控制工具,…… 时常困扰着我们,这就是为什么你需要那么多的所谓“经验”和
“知识”。然而,很多IT公司不喜欢承认这一点,他们一向以来的作风是“一切都是程
序员的错!”,“作为程序员,你应该知道这些!” 这就造成了一种“皇帝的新装现
象”——大家都不喜欢用一些设计恶劣的工具,却都怕别人嘲笑或者怀疑自己的能力,
所以总是喜欢显示自己“会用”,“能学”,而没有人敢说它难用,敢指出设计者的失
误。
我这个人呢,就是这种“黑客文化”的一个反例。我所受到的多元化教育,让我从这些
偏激盲从,教条主义的心理里面跳了出来。每当有人因为不会某种工具或者语言来请教
我时,我总是很轻松的调侃这工具的设计者,然后告诉他,你没理由知道这些破玩意儿
,但其实它就是这么回事。然后我一针见血的告诉他这东西怎么回事,怎么用,是哪些
设计缺陷导致了我们现在的诡异用法…… 我觉得所有的IT从业人员对于这些工具,都
应该是这样的调侃态度。只有这样,软件行业才会得到实质性的进步,而不是被一些自
虐的设计所困扰,造成思维枷锁。
总之,这是一个非常重要的“态度问题”。虽然在现阶段,我们有必要知道如何绕过一
些蹩脚的工具,利用它们来完成自己的任务。然而在此同时,我们必须正视和承认这些
工具的恶劣本质,而不能拿它们当教条,把什么事都怪罪于程序员。只有分清工具设计
者的失误和程序员自己的失误,不把工具的设计失误怪罪于程序员,我们才能有效地尊
重程序员们的智商,鼓励他们做出简单,优雅,完善的产品。
分清精髓知识和表面知识,不要太拿经验当回事
在任何领域,都只有少数知识是精髓的,另外大部分都是表面的,肤浅的,是从精髓知
识衍生出来的。精髓知识和表面知识都是有用的,然而它们的分量和重要性却是不一样
的。所以必须区分精髓知识和表面知识,不能混为一谈,对待它们的态度应该是不一样
的。由于表面知识基本是死的,而且很容易从精髓知识推导衍生出来。我们不应该因为
自己知道很多表面知识,就自以为比掌握了精髓知识的人还要强。不应该因为别人不知
道某些表面知识,就以为自己高人一等。
IT公司经常有这样的人,以为精通一些看似复杂的命令行,或者某些难用的程序语言就
很了不起似的。他们如果听说你不知道某个命令的用法,那简直就像法国人不知道拿破
仑,美国人不知道华盛顿一样。这些人没有发现,自己身边有些同事其实掌握着精髓的
知识,他们完全有能力从自己已有的知识,衍生制造出所有这些工具,而不只是使用它
们,甚至设计得更加完善和方便易用。这种能够设计制造出更好工具的人,往往身负更
加重要的任务,所以他们往往会在被现有工具的用法迷惑的时候,非常谦虚的请同事帮
助解决,大胆的承认自己的糊涂。
如果你是这个精通工具用法的人,切不可以把同事的谦虚请求当成可以显摆自己“资历
”的时候。这同事往往真的是在“不耻下问”。他并不是搞不懂,而是根本不屑于,也
没有时间去考虑这种低级问题。他的迷惑,往往来源于工具设计者的失误。他很清楚这
一点,他也知道自己的技术水平其实是高于这工具的设计者的。然而为了礼貌,他经常
不直接批评这工具的设计,而是谦虚的责怪自己。所以同事向你“虚心请教”,完全是
为了制造一种友好融洽的气氛,这样可以节省下时间来干真正重要的事情。这种虚心并
不等于他在膜拜你,承认自己的技术能力不如你。
所以正确的对待方式应该是诚恳的表示对这种迷惑的理解,并且坦率的承认工具设计上
的不合理,蹩脚之处。如果你能够以这种谦和的态度,而不是自以为专家的态度,同事
会高兴地从你这里“学到”他需要的,肤浅的死知识,并且记住它,避免下次再为这种
无聊事来打扰你。如果你做出一副“天下只有我知道这奇技淫巧”的态度,同事往往会
对你,连同这工具一起产生鄙视的情绪。他下次会照样记不住这东西的用法,然而他却
再也不会来找你帮忙,而是一拖再拖。
不要自以为聪明,不要评判别人的智商和能力
在IT公司里,总是有很多人觉得自己聪明,想显示自己比别人聪明。这种人似乎随时都
在评判(judge)别人,你说的任何话,不管认真的还是开玩笑的,都会被他们拿去作
为评估你智商和能力的依据。
有时候你写了一些代码,自己知道时间不够,可是当时有更重要的事情要做,所以打算
以后再改进。如果你提交代码时被这种人看到了,他们就会坚定地认为你一辈子只能写
出那样的代码。这就是所谓“wishful thinking”,人只能看到他希望看到的东西。这
种人随时都在希望自己比别人聪明,所以他们随时都在监听别人显得不如他聪明的时候
,而对别人比他高明的时候视而不见。他们只能看到别人疏忽的时候,因为那是可以证
明他们高人一等的有利证据。
当然,谁会喜欢这样的人呢,可是他们在IT公司里相当的普遍。你不敢跟他们说话,特
别是不敢开玩笑,因为他们会把你稀里糊涂的玩笑话全部作为你智商低下或者经验不足
的证据。你不敢问他们问题,因为他们会认为你问问题,说明你不懂!我发现具有这种
心理的人,一般潜意识里都存在着自卑。他们有某些方面(包括智力在内)不如别人,
所以总是找机会显得高人一等。我还没有想出可以纠正这种心理问题的有效方法,但如
我上节所说,意识到整个行业,包括你仰慕的鼻祖们,其实都不懂很多东西,都是混饭
吃的,是一个有效的放松这种心理的手段。
有时候我喜欢自嘲,对人说:“我们这行业的祖先做了这么多BUG来让我们修补。现在
你做了一坨屎,我也做了一坨屎,我的屎貌似比你的屎香一点。”这样一来,不但显示
出心理的平等和尊重,而且避免了因为谦虚而让对方产生高人一等的情绪。说真的,做
这行根本不需要很高的智力,所以最好是完全放弃对人智力的判断。你不比任何人更聪
明,也不比他们笨。
解释高级意图,不要使用低级命令
随时都要记住,同事和下属是跟你智力相当的人。他们是通情达理的人,然而却不会简
单地服从你的低级命令。像我在Google的队友的做法,就是一个很好的反面教材。其实
这位Googler只是想告诉我:“删掉这行文本,然后改成这样……” 就是如此一个简单
的事情,然而她却故弄玄虚,不直接告诉我这个“高级意图”,而是使用非常低级的指
令:“按Ctrl-k!……” 语气像是在对一个不懂事的小学生说话,好像自己懂很多,
别人什么都不知道似的。
有哪个Emacs用户不知道Ctrl-k是删掉一行字呢,况且你现在面对的其实是一个资深
Emacs用户。我想大家都看出来这里的问题了吧。这样的低级命令不但逻辑不清楚,而
且是对另一个人的智力的严重侮辱。你当我是什么啊?猴子?如果这位Googler表明自
己的高级意图,就会很容易在心理上和逻辑上让人接受,比如她可以说:“配置文件的
这行应该删掉,改成……”
在项目管理的时候也需要注意。在让人做某一件事之前,应该先解释为什么要做这件事
,以及它的重要性。这样才能让人理解,才能尊重程序员的智商。
不要期望新人向自己学习
很多IT公司喜欢把新人当初学者,期望他们“从新的起跑线出发”,向自己“学习”。
比如,Google把新员工叫做“Noogler”(Newbie Googler的意思),甚至给他们发一
种特殊的螺旋桨帽子,其寓意在于告诉他们,小屁孩要谦虚,要向伟大的Google学习,
将来才可以飞黄腾达。
这其实是非常错误的作法,因为它完全不尊重新员工早已具备的背景知识,把自己的地
位强加于他们头上。并不是你说“新的起跑线”就真的可以把人的过去都抹杀了的。新
人不了解你们的代码结构和工程方式,并不等于你们的方式就会先进一些。Google里面
真的有很多值得学习的东西吗?学校的教育真的一文不值吗?其实恰恰相反。我可以坦
然的说,我从自己的教授身上学会了最精髓的知识,而从Google得到的,只是一些很肤
浅的,死记硬背就可以掌握的技能,而且其中有挺多其实是糟粕。我在Google做出的所
有创新成果,全都是从学校获得的精髓知识的衍生物。很多PhD学生鄙视Google,就是
因为Google不但自己技术平庸,反倒喜欢把自己包装成最先进的,超越其它公司和学校
的,并且嚣张的期望别人向他们“学习”。
一个真正尊重人才的公司会去了解,尊重和发挥新人从外界带来的特殊技能,施展他们
特有的长处,而不是一味期望他们向自己“学习”。只有这样,我们才能保持这些锐利
武器的棱角,在激烈的竞争中让自己立于不败之地。如果你一味的让新人“学习”,而
无视他们特有的长处,最后就不免沦为平庸。
不要以老师自居,分清“学习”和“了解”
如上文所说,IT行业的很多所谓“知识”,只不过是一些奇技淫巧,用以绕过前人设计
上的失误。所以遇到别人不知道一些东西的时候,请不要以为你“教会”了别人什么东
西,不要以为自己可以当老师了。以老师自居,使用一些像“跟我学”一类的语言,其
实是一种居高临下,不尊重人的行为。
人们很喜欢在获得了信息的时候用“学习”这个词,然而我觉得这个词被滥用了。我们
应该分清两种情况:“学习”和“了解”。前者指你通过别人的指点和自己的理解,获
得了精髓的,不能轻易制造出来的知识。后者只是指你“了解”了原来不知道的一些事
情。举个例子,如果有人把一件物品放在了某个你不知道的地方,你找不到,问他,然
后他告诉你了。这种信息的获取,显然不叫“学习”,这种信息也不叫做“知识”。
然而,IT行业很多时候所谓的“学习”,就是类似这种情况。比如,有人写了一些代码
,设计了一些框架模块。有人不知道怎么用,然后有人告诉他了。很多人把这种情况称
为“学习”,这其实是对人的不尊重。这跟有人告诉你他把东西放在哪里了,是同样性
质的。这样的代码和设计,我也可以做,甚至做得更好,凭什么你说我在向你学习呢?
我只是了解了一下而已。
所谓学习,必须是更加高级的知识和技能,必须有一种“有收获”,“有提高”的感觉
。简单的信息获取不能叫做“学习”,只能叫做“了解”。分清“了解”和“学习”,
不以老师自居,是尊重人的一个重要表现。
明确自己的要求,不要使用指责的语气
有些人很怪异,他根本没告诉过你他想要什么,有什么特别的要求,可他潜意识里假设
已经告诉你了。到了后来,他发现你的作法不符合要求,于是严厉指责你没有按照他“
心目中的要求”办事。这种现象不止限于程序员,而且包括日常生活中的普通人。举个
例子,我妈就是这种人的典型,所以我以前在家生活经常很辛苦。她心目中有一套“正
确”的做事方式,如果你没猜出来就会挨骂。你为了避免挨骂,干脆什么事都不要做,
然后她又会说你懒,所以你就左右不是人 :)
IT公司里面也有挺多这样的人,他们假设有些信息他已经告诉你了,而其实根本没告诉
你。到了后来,他们开始指责你没有按照要求做事。有些极其奇葩的公司,里面的程序
员不但喜欢以老师自居,而且他们“传授”你“知识”的主要方式是指责。他们事先不
告诉你任何规则,然后只在你违反的时候来责备你。我曾经在这样一个公司待过,名字
就不提了。
现在举一个具体的场景例子:
A: 你push到master了?
B: 是啊?怎么了?
A: 不准push到master!只能用pull request!
B: 可是你们之前没告诉过我啊……
A: 现在你知道了?!
注意到了吗?这不是一个技术问题,而是一个礼节(etiquette)问题。你没有事先告
诉别人一些规则,就不该用怪罪的语气来对人说话,况且你的规则还不一定总是对的。
所以我现在提醒各位IT公司,在技术上的某些特殊要求必须事先提出来,确保程序员知
道并且理解。如果没有事先提出,就不要怪别人没按要求做,因为这是非常伤害人自尊
的作法。其实,在任何时候都不应该使用指责的语气,它不但对解决问题没有任何正面
作用,而且会恶化人际关系,最终导致更加严重的后果。
程序员的工作量不可用时间衡量
很多IT公司管理层不懂得如何估算程序员的工作量,所以用他们坐在自己位置上工作的
时间来估算。如果你能力很强,在很短的时间内把最困难的问题解决了,接下来他们不
会让你闲着,而会让你做另外一些很低级的活。这是很不合理的作法。打个比方,能力
强的员工就像一辆F1赛车,马力和速度是其他人的几十倍。当然,普通人需要很长时间
才能解决,甚至根本没法解决的问题,到他手里很快就化解掉了。这就像一辆F1赛车,
眨眼工夫就跑完了别人需要很久的路程。如果你用时间来衡量工作量,那么这辆赛车跑
完全程只需要很短时间,所以你算出来的工作量就比普通车子小很多。你能因此说赛车
工作不够努力,要他快马再加鞭吗?这显然是不对的。
物理定律是这样:能量 = 功率 x 时间。工作量也应该是同样的计算方法。英明的,真
正理解程序员的公司,就不会指望高水平的程序员不停地工作。高水平程序员由于经常
能够另辟蹊径,一个就可以抵好几个甚至几十个普通程序员。他们处理的问题比常人的
困难很多,费脑力多很多,当然他们需要更好的休息,保养,娱乐,…… 如果你让高
水平的程序员太忙了,一刻都不停着,有趣有挑战性的事情做完了就让他们做一些低级
无聊的事情,他们悟出这个道理之后,就会故意放慢速度,有时候明明很快做完了也会
说没做完。与其这样,不如只期望他们工作短一点的时间,把事情做完就可以。
当然这并不是说初级的程序员就应该过量工作。编程是一项艰苦的脑力活动,超时超量
的工作再加上压力,只会带来效率的低下,质量的降低。
不要让其他人修补自己的BUG
这个我已经在一篇专门的文章里讨论过。让一个程序员修补另外一个程序员的BUG,不
但是效率低下,而且是不尊重程序员个人价值的作法,应该尽量避免。
在软件行业,经常看到有的公司管理让一个人修补另一个人代码里的BUG。有时候有人
写了一段代码,扔出来不管了,然后公司管理让其他工程师来修复它。我想告诉你们,
这种方法会很失败。
首先,让一个人修复另一个人的BUG,是不尊重工程师个人技术的表现。久而久之会降
低工程师的工作积极性,以至于失去有价值的员工。代码是人用心写出来的作品,就像
艺术家的作品一样,它的质量牵挂着一个人的人格和尊严。如果一个人A写了代码,自
己都不想修复里面的BUG,那说明A自己都认为他自己的代码是垃圾,不可救药。如果让
另一个人B来修复A代码里的BUG,就相当于是让B来收拾其他人丢下的垃圾。可想而知,
B在公司的眼里是什么样的地位,受到什么样的尊重。
其次,让一个人修复另一个人的BUG,是效率非常低下的作法。每个人都有自己写代码
的风格和技巧,代码里面包含了一个人的思维方式。人很难不经解释理解别人的思想,
所以不管这两人的编程技术高下,都会比较难理解。不能理解别人的代码,不能说明这
人编程技术的任何方面。所以让一个人修补另一个人的BUG,无论这人技术多么高明,
都会导致效率低下。有时候技术越是高的人,修补别人的BUG效率越是低,因为这人根
本就写不出来如此糟糕的代码,所以他无法理解,觉得还不如推翻重写一遍。
当我在大学里做程序设计课程助教的时候,我发现如果学生的代码出了问题,你基本是
没法简单的帮他们修复的。我的水平显然比学生的高出许多,然而我却经常根本看不懂
,也不想看他们的代码,更不要说修复里面的BUG。就像上面提到的,有些人自己根本
不知道自己在写什么,做出一堆垃圾来。看这样的代码跟吃屎的感觉差不多。对于这样
的代码,你只能跟他们说这是不正确的。至于为什么不正确,你只能让他们自己去改,
或者建议他们推翻重写。也许你能指出大致的方向和思路,然而深入到具体的细节却是
不可能的,而且不应该是你的职责。这就是我的教授告诉我的做法:如果代码不能运行
,直接打一个叉,不用解释,不用推敲,等他们自己把程序改好,或者实在没办法,来
office hours找你,向你解释他们的思想。
如果你明白我在说什么,从今天起就对自己的代码负起责任来,不要再让其它人修补自
己的BUG,不要再修补其他人的BUG。如果有人离开公司,必须要有人修补他遗留下来的
BUG,那么说话应该特别特别的小心。你必须指出需要他帮忙的特殊原因,强调这件事
本来不是他的错,本来是不应该他来做的,但是有人走了,没有办法,并且诚恳的为此
类事情的发生表示歉意。只有这样,程序员才会心甘情愿的在这种特殊关头,修补另外
一个人的BUG。
不要嚷着要别人写测试
在很多程序员的脑子里,所谓的“流程”和“测试”,比真正解决问题的代码还重要。
他们跟你说起这些,那真的叫正儿八经,义正言辞啊!所以有时候你很迷惑,这些人除
了遵守这些按部就班的规矩,还知道些什么。大概没有能力的人都喜欢追究各种规矩吧
,这样可以显得自己“没有功劳有苦劳”。这些人自己写的代码很平庸,不知道如何简
单有效地解决困难的问题,却喜欢在别人提交代码让他review的时候叫喊:“测试很重
要!覆盖很重要!你要再加一些测试才能通过我的review!”
本来code review是让他们帮忙发现可能存在的问题,有些人却仿佛把它作为了评判(
judge)其他人能力,经验,甚至智商的机会。他们根本不明白别人代码的实质价值,
就知道以一些表面现象来判断。我在Google实习,最后提交了质量和难度都非常高的代
码,然而一些完全没能力写出这样代码的人,不但没表示出最基本的肯定,反而发出沉
闷的咆哮:“快——写——测——试!” 你觉得我会高兴吗?
我并不否认测试的用处,然而很多人提起这些事情时候,语气和态度是非常不尊重,让
人反感的。这些人不但没有为解决问题作出任何实质贡献,当有人提交解决方案的时候
,他们没有表达对真正做出贡献的人的尊重和肯定,反而指责别人没写测试。好像比他
高明的人解决了问题,他反倒才是那个有发言权的,可以评判你的代码质量似的:“我
管你代码写得多好,我完全没能力写出来,但你没写测试就是不够专业。你懂不懂测试
的重要性啊,还做程序员!”
人际交往的问题经常不在于你说了什么,而在于你是怎么说的。所以我的意思并不是说
你不该建议写测试,然而建议就该有建议的语气和态度。因为你没有做实际的工作,所
以一些礼貌用语,比如“请”,“可不可以”……是必须的。经常有人说话不注意语气
和态度,让人反感,却以自己是工程师,不善于跟人说话为借口。永远要记住,你没有
做事,说话就应该委婉,切不可使用光秃秃的祈使句,说得好像这事别人非做不可,不
做就是不懂规矩一样。
礼貌的语言,跟人的职业完全没有关系。身为工程师,完全不能作为说话不礼貌的借口。
关于Git的礼节
Git是现在最流行的代码版本控制工具。用外行话说,Git就是一个代码的“仓库”或者
“保管”,这样很多人修改了代码之后,可以知道是谁改了哪一块。其实不管什么工具
,不管是编辑器,程序语言,还是版本控制工具,比起程序员的核心思想来,都是次要
的东西,都是起辅助作用的。可是Git这工具似乎特别惹人恼火。
Git并不像很多人吹嘘的那么好用,其中有明显的蹩脚设计。跟Unix的传统一脉相承,
Git没有一个良好的包装,设计者把自己的内部实现细节无情地泄露给了用户,让用户
需要琢磨者设计者内部到底怎么实现的,否则很多时候不知道该怎么办。用户被迫需要
记住挺多稀奇古怪的命令,而且命令行的设计也不怎么合理,有时候你需要加-f之类的
参数,各个参数的位置可能不一致,而且加了还不一定能起到你期望的效果。各种奇怪
的现象,比如"head detached",都强迫用户去了解它内部是怎么设计的。随着Git版本
的更新,新的功能和命令不断地增加,后来你终于看到命令行里出现了foreach,才发
现它的命令行就快变成一个(劣质的)程序语言。如果你了解ydiff的设计思想,就会
发现Git之类基于文本的版本控制工具,其实属于古代的东西。然而很多人把Git奉为神
圣,就因为它是Linus Torvalds设计的。
Git最让人恼火的地方并不是它用起来麻烦,而是它的“资深用户”们居高临下的态度
给你造成的心理阴影。好些人因为自己“精通Git”就以为高人一等,摆出一副专家的
态度。随着用户的增加,Git最初的设计越来越被发现不够用,所以一些约定俗成的规
则似乎越来越多,可以写成一本书!跟Unix的传统一脉相承,Git给你很多可以把自己
套牢的“机制”,到时候出了问题就怪你自己不知道。所以你就经常听有人煞有介事的
说:“并不是Git允许你这么做,你就可以这么做的!Unix的哲学是不阻止傻人做傻事
……” 如果你提交代码时不知道Git用户一些约定俗成的规则,就会有人嚷嚷:“
rebase了再提交!” “不要push到master!” “不要merge!” “squash commits!
” 如果你不会用git submodule之类的东西,有人可能还会鄙视你,说:“你应该知道
这些!”
打个比方,这样的嚷嚷给人的感觉是,你得了奥运会金牌之后,把练习用的器材还回到
器材保管科,结果管理员对你大吼:“这个放这边!那个放那边!懂不懂规矩啊你?”
看出来问题了吗?程序员提交了有高价值的代码(奥运金牌),结果被一些自认为Git
用的很熟的人(器材保管员)厉声呵斥。
一个尊重程序员的公司文化,就应该把程序员作为运动健将,把程序员的代码放在尊贵
的地位。其它的工具,都应该像器材保管科一样。我们尊重这些器材保管员,然而如果
运动员们不懂你制定的器材摆放规矩,也应该表示出尊重和理解,说话应该和气有礼貌
,不应该骑到他们头上。所以,对于Git的一些命令和用法,我建议大家向新手介绍时
,这样开场:“你本来不该知道这些的,可是现在我们没有更好的工具,所以得这样弄
一下……”
怎样尊重一个程序员
得知一位久违的同学来到了旧金山湾区,然而我见到他时,这人正处于一生中最痛苦的
时期。他告诉我,自己任职的公司在他加入之前和之后,判若两人。录取的时候公司对
他说,我们对你在实习期间的表现和学术背景非常满意,你不用面试,甚至不用毕业拿
学位,直接就可以加入我们公司成为正式员工。然而短短一年后的今天,这位同学已经
完全感觉不到公司对自己技能的尊重。Manager让他做一些乱七八糟没技术含量的事情
,还抱怨说他做事太慢,并且在他的evaluation上很是写了一笔。在人格尊严和工作安
全感的双重打击之下,这位同学压力非常大,周末经常偷偷地加班,仍然无法让
manager满意。
我很了解这位同学的能力,在任何一流公司任职,肯定是绰绰有余了。他的名字我当然
保密,然而他所任职的公司因为太过嚣张,我不得不直接指出来——这就是被很多人向
往得像天堂一样的地方,Google。这位同学所描述的遭遇,跟我几年前在Google的实习
经历如出一辙。我仍然记得,Google的队友在旁边看着我用Emacs,用小学老师似的口
气对我说:“按Ctrl-k!” 我仍然记得,在提交队友完全无法写出来的高难度代码时
,被指责和嘲笑不会用Perforce。我仍然记得,吃饭时同事们对所谓“Google牛人”眉
飞色舞的艳羡。我仍然记得,最后我一个人做出整个团队做梦都做不出来的项目的时候
,有人发出沉闷的咆哮:“快——写——测——试!” ……
我的这位同学也算得上本领域顶尖的专家了。如此的践踏一个专家的价值,用肤浅的标
准来评判和对待他们,Google并不是唯一一个这样的公司。我之前任职的好几个公司,
或多或少都存在类似的问题。很多时候也不一定是公司管理层无端施加压力,而是程序
员之间互斗的厉害,互相评判,伤害自尊。从最近Linus Torvalds在演讲现场公然对观
众无理,你可以看出这种只关心技术,不尊重人的思潮,在程序员的社区里是非常普及
的。
后来我发现,并不是程序员故意想要藐视对方或者互相攻击,而是他们真的不明白什么
叫做“尊重”,他们不知道如何说话才可以不伤害另一个程序员,所以有时不小心就让
人怒火中烧。所以说,尊重他人其实是一个“技术问题”,而不是有心就可以做到的。
因为这个原因,我想在下文里从心理和技术角度出发,指出IT业界不尊重人现象的起源
,同时提出几点建议,告诉人们如何真正的尊重一个程序员。我希望这些建议对公司的
管理层有借鉴意义,也希望它们能给与正在经受同样痛苦的程序员们一些精神上的鼓励。
我觉得为了建设一个程序员之间互相尊重的公司文化,应该注意以下几个要点。
认识和承认计算机系统里的历史遗留糟粕
很多不尊重人现象的起源,都是因为某些人偏执的相信某种技术就是世界上最好的,每
个人都必须知道,否则他就不是一个合格的程序员。这种现象在Unix(Linux)的世界
尤为普遍。Unix系统的鼓吹者们(我曾经是其中之一)喜欢到处布道,告诉你其它系统
的设计有多蠢,你应该遵从Unix的“哲学”。他们仿佛认为Unix就是世界终极的操作系
统,然而事实却是,Unix是一个设计非常糟糕的系统。它似乎故意被设计为难学难用,
容易犯错,却美其名曰“强大”,“灵活”。眼界开阔一点的程序员都知道,Unix的设
计者其实基本不懂设计,他们并不是世界上最好的程序员,却有一点做得很成功,那就
是他们很会制造宗教,煽动人们的盲从心理。Unix设计者把自己的设计失误推在用户身
上,让用户觉得学不会或者搞错了都是自己的错。
如果你对计算机科学理解到一定程度,就会发现我们其实仍然生活在计算机的石器时代
。特别是软件系统,建立在一堆历史遗留的糟糕设计之上。各种蹩脚脑残的操作系统(
比如Unix,Linux),程序语言(比如C++,JavaScript,PHP,Go),数据库,编辑器,
版本控制工具,…… 时常困扰着我们,这就是为什么你需要那么多的所谓“经验”和
“知识”。然而,很多IT公司不喜欢承认这一点,他们一向以来的作风是“一切都是程
序员的错!”,“作为程序员,你应该知道这些!” 这就造成了一种“皇帝的新装现
象”——大家都不喜欢用一些设计恶劣的工具,却都怕别人嘲笑或者怀疑自己的能力,
所以总是喜欢显示自己“会用”,“能学”,而没有人敢说它难用,敢指出设计者的失
误。
我这个人呢,就是这种“黑客文化”的一个反例。我所受到的多元化教育,让我从这些
偏激盲从,教条主义的心理里面跳了出来。每当有人因为不会某种工具或者语言来请教
我时,我总是很轻松的调侃这工具的设计者,然后告诉他,你没理由知道这些破玩意儿
,但其实它就是这么回事。然后我一针见血的告诉他这东西怎么回事,怎么用,是哪些
设计缺陷导致了我们现在的诡异用法…… 我觉得所有的IT从业人员对于这些工具,都
应该是这样的调侃态度。只有这样,软件行业才会得到实质性的进步,而不是被一些自
虐的设计所困扰,造成思维枷锁。
总之,这是一个非常重要的“态度问题”。虽然在现阶段,我们有必要知道如何绕过一
些蹩脚的工具,利用它们来完成自己的任务。然而在此同时,我们必须正视和承认这些
工具的恶劣本质,而不能拿它们当教条,把什么事都怪罪于程序员。只有分清工具设计
者的失误和程序员自己的失误,不把工具的设计失误怪罪于程序员,我们才能有效地尊
重程序员们的智商,鼓励他们做出简单,优雅,完善的产品。
分清精髓知识和表面知识,不要太拿经验当回事
在任何领域,都只有少数知识是精髓的,另外大部分都是表面的,肤浅的,是从精髓知
识衍生出来的。精髓知识和表面知识都是有用的,然而它们的分量和重要性却是不一样
的。所以必须区分精髓知识和表面知识,不能混为一谈,对待它们的态度应该是不一样
的。由于表面知识基本是死的,而且很容易从精髓知识推导衍生出来。我们不应该因为
自己知道很多表面知识,就自以为比掌握了精髓知识的人还要强。不应该因为别人不知
道某些表面知识,就以为自己高人一等。
IT公司经常有这样的人,以为精通一些看似复杂的命令行,或者某些难用的程序语言就
很了不起似的。他们如果听说你不知道某个命令的用法,那简直就像法国人不知道拿破
仑,美国人不知道华盛顿一样。这些人没有发现,自己身边有些同事其实掌握着精髓的
知识,他们完全有能力从自己已有的知识,衍生制造出所有这些工具,而不只是使用它
们,甚至设计得更加完善和方便易用。这种能够设计制造出更好工具的人,往往身负更
加重要的任务,所以他们往往会在被现有工具的用法迷惑的时候,非常谦虚的请同事帮
助解决,大胆的承认自己的糊涂。
如果你是这个精通工具用法的人,切不可以把同事的谦虚请求当成可以显摆自己“资历
”的时候。这同事往往真的是在“不耻下问”。他并不是搞不懂,而是根本不屑于,也
没有时间去考虑这种低级问题。他的迷惑,往往来源于工具设计者的失误。他很清楚这
一点,他也知道自己的技术水平其实是高于这工具的设计者的。然而为了礼貌,他经常
不直接批评这工具的设计,而是谦虚的责怪自己。所以同事向你“虚心请教”,完全是
为了制造一种友好融洽的气氛,这样可以节省下时间来干真正重要的事情。这种虚心并
不等于他在膜拜你,承认自己的技术能力不如你。
所以正确的对待方式应该是诚恳的表示对这种迷惑的理解,并且坦率的承认工具设计上
的不合理,蹩脚之处。如果你能够以这种谦和的态度,而不是自以为专家的态度,同事
会高兴地从你这里“学到”他需要的,肤浅的死知识,并且记住它,避免下次再为这种
无聊事来打扰你。如果你做出一副“天下只有我知道这奇技淫巧”的态度,同事往往会
对你,连同这工具一起产生鄙视的情绪。他下次会照样记不住这东西的用法,然而他却
再也不会来找你帮忙,而是一拖再拖。
不要自以为聪明,不要评判别人的智商和能力
在IT公司里,总是有很多人觉得自己聪明,想显示自己比别人聪明。这种人似乎随时都
在评判(judge)别人,你说的任何话,不管认真的还是开玩笑的,都会被他们拿去作
为评估你智商和能力的依据。
有时候你写了一些代码,自己知道时间不够,可是当时有更重要的事情要做,所以打算
以后再改进。如果你提交代码时被这种人看到了,他们就会坚定地认为你一辈子只能写
出那样的代码。这就是所谓“wishful thinking”,人只能看到他希望看到的东西。这
种人随时都在希望自己比别人聪明,所以他们随时都在监听别人显得不如他聪明的时候
,而对别人比他高明的时候视而不见。他们只能看到别人疏忽的时候,因为那是可以证
明他们高人一等的有利证据。
当然,谁会喜欢这样的人呢,可是他们在IT公司里相当的普遍。你不敢跟他们说话,特
别是不敢开玩笑,因为他们会把你稀里糊涂的玩笑话全部作为你智商低下或者经验不足
的证据。你不敢问他们问题,因为他们会认为你问问题,说明你不懂!我发现具有这种
心理的人,一般潜意识里都存在着自卑。他们有某些方面(包括智力在内)不如别人,
所以总是找机会显得高人一等。我还没有想出可以纠正这种心理问题的有效方法,但如
我上节所说,意识到整个行业,包括你仰慕的鼻祖们,其实都不懂很多东西,都是混饭
吃的,是一个有效的放松这种心理的手段。
有时候我喜欢自嘲,对人说:“我们这行业的祖先做了这么多BUG来让我们修补。现在
你做了一坨屎,我也做了一坨屎,我的屎貌似比你的屎香一点。”这样一来,不但显示
出心理的平等和尊重,而且避免了因为谦虚而让对方产生高人一等的情绪。说真的,做
这行根本不需要很高的智力,所以最好是完全放弃对人智力的判断。你不比任何人更聪
明,也不比他们笨。
解释高级意图,不要使用低级命令
随时都要记住,同事和下属是跟你智力相当的人。他们是通情达理的人,然而却不会简
单地服从你的低级命令。像我在Google的队友的做法,就是一个很好的反面教材。其实
这位Googler只是想告诉我:“删掉这行文本,然后改成这样……” 就是如此一个简单
的事情,然而她却故弄玄虚,不直接告诉我这个“高级意图”,而是使用非常低级的指
令:“按Ctrl-k!……” 语气像是在对一个不懂事的小学生说话,好像自己懂很多,
别人什么都不知道似的。
有哪个Emacs用户不知道Ctrl-k是删掉一行字呢,况且你现在面对的其实是一个资深
Emacs用户。我想大家都看出来这里的问题了吧。这样的低级命令不但逻辑不清楚,而
且是对另一个人的智力的严重侮辱。你当我是什么啊?猴子?如果这位Googler表明自
己的高级意图,就会很容易在心理上和逻辑上让人接受,比如她可以说:“配置文件的
这行应该删掉,改成……”
在项目管理的时候也需要注意。在让人做某一件事之前,应该先解释为什么要做这件事
,以及它的重要性。这样才能让人理解,才能尊重程序员的智商。
不要期望新人向自己学习
很多IT公司喜欢把新人当初学者,期望他们“从新的起跑线出发”,向自己“学习”。
比如,Google把新员工叫做“Noogler”(Newbie Googler的意思),甚至给他们发一
种特殊的螺旋桨帽子,其寓意在于告诉他们,小屁孩要谦虚,要向伟大的Google学习,
将来才可以飞黄腾达。
这其实是非常错误的作法,因为它完全不尊重新员工早已具备的背景知识,把自己的地
位强加于他们头上。并不是你说“新的起跑线”就真的可以把人的过去都抹杀了的。新
人不了解你们的代码结构和工程方式,并不等于你们的方式就会先进一些。Google里面
真的有很多值得学习的东西吗?学校的教育真的一文不值吗?其实恰恰相反。我可以坦
然的说,我从自己的教授身上学会了最精髓的知识,而从Google得到的,只是一些很肤
浅的,死记硬背就可以掌握的技能,而且其中有挺多其实是糟粕。我在Google做出的所
有创新成果,全都是从学校获得的精髓知识的衍生物。很多PhD学生鄙视Google,就是
因为Google不但自己技术平庸,反倒喜欢把自己包装成最先进的,超越其它公司和学校
的,并且嚣张的期望别人向他们“学习”。
一个真正尊重人才的公司会去了解,尊重和发挥新人从外界带来的特殊技能,施展他们
特有的长处,而不是一味期望他们向自己“学习”。只有这样,我们才能保持这些锐利
武器的棱角,在激烈的竞争中让自己立于不败之地。如果你一味的让新人“学习”,而
无视他们特有的长处,最后就不免沦为平庸。
不要以老师自居,分清“学习”和“了解”
如上文所说,IT行业的很多所谓“知识”,只不过是一些奇技淫巧,用以绕过前人设计
上的失误。所以遇到别人不知道一些东西的时候,请不要以为你“教会”了别人什么东
西,不要以为自己可以当老师了。以老师自居,使用一些像“跟我学”一类的语言,其
实是一种居高临下,不尊重人的行为。
人们很喜欢在获得了信息的时候用“学习”这个词,然而我觉得这个词被滥用了。我们
应该分清两种情况:“学习”和“了解”。前者指你通过别人的指点和自己的理解,获
得了精髓的,不能轻易制造出来的知识。后者只是指你“了解”了原来不知道的一些事
情。举个例子,如果有人把一件物品放在了某个你不知道的地方,你找不到,问他,然
后他告诉你了。这种信息的获取,显然不叫“学习”,这种信息也不叫做“知识”。
然而,IT行业很多时候所谓的“学习”,就是类似这种情况。比如,有人写了一些代码
,设计了一些框架模块。有人不知道怎么用,然后有人告诉他了。很多人把这种情况称
为“学习”,这其实是对人的不尊重。这跟有人告诉你他把东西放在哪里了,是同样性
质的。这样的代码和设计,我也可以做,甚至做得更好,凭什么你说我在向你学习呢?
我只是了解了一下而已。
所谓学习,必须是更加高级的知识和技能,必须有一种“有收获”,“有提高”的感觉
。简单的信息获取不能叫做“学习”,只能叫做“了解”。分清“了解”和“学习”,
不以老师自居,是尊重人的一个重要表现。
明确自己的要求,不要使用指责的语气
有些人很怪异,他根本没告诉过你他想要什么,有什么特别的要求,可他潜意识里假设
已经告诉你了。到了后来,他发现你的作法不符合要求,于是严厉指责你没有按照他“
心目中的要求”办事。这种现象不止限于程序员,而且包括日常生活中的普通人。举个
例子,我妈就是这种人的典型,所以我以前在家生活经常很辛苦。她心目中有一套“正
确”的做事方式,如果你没猜出来就会挨骂。你为了避免挨骂,干脆什么事都不要做,
然后她又会说你懒,所以你就左右不是人 :)
IT公司里面也有挺多这样的人,他们假设有些信息他已经告诉你了,而其实根本没告诉
你。到了后来,他们开始指责你没有按照要求做事。有些极其奇葩的公司,里面的程序
员不但喜欢以老师自居,而且他们“传授”你“知识”的主要方式是指责。他们事先不
告诉你任何规则,然后只在你违反的时候来责备你。我曾经在这样一个公司待过,名字
就不提了。
现在举一个具体的场景例子:
A: 你push到master了?
B: 是啊?怎么了?
A: 不准push到master!只能用pull request!
B: 可是你们之前没告诉过我啊……
A: 现在你知道了?!
注意到了吗?这不是一个技术问题,而是一个礼节(etiquette)问题。你没有事先告
诉别人一些规则,就不该用怪罪的语气来对人说话,况且你的规则还不一定总是对的。
所以我现在提醒各位IT公司,在技术上的某些特殊要求必须事先提出来,确保程序员知
道并且理解。如果没有事先提出,就不要怪别人没按要求做,因为这是非常伤害人自尊
的作法。其实,在任何时候都不应该使用指责的语气,它不但对解决问题没有任何正面
作用,而且会恶化人际关系,最终导致更加严重的后果。
程序员的工作量不可用时间衡量
很多IT公司管理层不懂得如何估算程序员的工作量,所以用他们坐在自己位置上工作的
时间来估算。如果你能力很强,在很短的时间内把最困难的问题解决了,接下来他们不
会让你闲着,而会让你做另外一些很低级的活。这是很不合理的作法。打个比方,能力
强的员工就像一辆F1赛车,马力和速度是其他人的几十倍。当然,普通人需要很长时间
才能解决,甚至根本没法解决的问题,到他手里很快就化解掉了。这就像一辆F1赛车,
眨眼工夫就跑完了别人需要很久的路程。如果你用时间来衡量工作量,那么这辆赛车跑
完全程只需要很短时间,所以你算出来的工作量就比普通车子小很多。你能因此说赛车
工作不够努力,要他快马再加鞭吗?这显然是不对的。
物理定律是这样:能量 = 功率 x 时间。工作量也应该是同样的计算方法。英明的,真
正理解程序员的公司,就不会指望高水平的程序员不停地工作。高水平程序员由于经常
能够另辟蹊径,一个就可以抵好几个甚至几十个普通程序员。他们处理的问题比常人的
困难很多,费脑力多很多,当然他们需要更好的休息,保养,娱乐,…… 如果你让高
水平的程序员太忙了,一刻都不停着,有趣有挑战性的事情做完了就让他们做一些低级
无聊的事情,他们悟出这个道理之后,就会故意放慢速度,有时候明明很快做完了也会
说没做完。与其这样,不如只期望他们工作短一点的时间,把事情做完就可以。
当然这并不是说初级的程序员就应该过量工作。编程是一项艰苦的脑力活动,超时超量
的工作再加上压力,只会带来效率的低下,质量的降低。
不要让其他人修补自己的BUG
这个我已经在一篇专门的文章里讨论过。让一个程序员修补另外一个程序员的BUG,不
但是效率低下,而且是不尊重程序员个人价值的作法,应该尽量避免。
在软件行业,经常看到有的公司管理让一个人修补另一个人代码里的BUG。有时候有人
写了一段代码,扔出来不管了,然后公司管理让其他工程师来修复它。我想告诉你们,
这种方法会很失败。
首先,让一个人修复另一个人的BUG,是不尊重工程师个人技术的表现。久而久之会降
低工程师的工作积极性,以至于失去有价值的员工。代码是人用心写出来的作品,就像
艺术家的作品一样,它的质量牵挂着一个人的人格和尊严。如果一个人A写了代码,自
己都不想修复里面的BUG,那说明A自己都认为他自己的代码是垃圾,不可救药。如果让
另一个人B来修复A代码里的BUG,就相当于是让B来收拾其他人丢下的垃圾。可想而知,
B在公司的眼里是什么样的地位,受到什么样的尊重。
其次,让一个人修复另一个人的BUG,是效率非常低下的作法。每个人都有自己写代码
的风格和技巧,代码里面包含了一个人的思维方式。人很难不经解释理解别人的思想,
所以不管这两人的编程技术高下,都会比较难理解。不能理解别人的代码,不能说明这
人编程技术的任何方面。所以让一个人修补另一个人的BUG,无论这人技术多么高明,
都会导致效率低下。有时候技术越是高的人,修补别人的BUG效率越是低,因为这人根
本就写不出来如此糟糕的代码,所以他无法理解,觉得还不如推翻重写一遍。
当我在大学里做程序设计课程助教的时候,我发现如果学生的代码出了问题,你基本是
没法简单的帮他们修复的。我的水平显然比学生的高出许多,然而我却经常根本看不懂
,也不想看他们的代码,更不要说修复里面的BUG。就像上面提到的,有些人自己根本
不知道自己在写什么,做出一堆垃圾来。看这样的代码跟吃屎的感觉差不多。对于这样
的代码,你只能跟他们说这是不正确的。至于为什么不正确,你只能让他们自己去改,
或者建议他们推翻重写。也许你能指出大致的方向和思路,然而深入到具体的细节却是
不可能的,而且不应该是你的职责。这就是我的教授告诉我的做法:如果代码不能运行
,直接打一个叉,不用解释,不用推敲,等他们自己把程序改好,或者实在没办法,来
office hours找你,向你解释他们的思想。
如果你明白我在说什么,从今天起就对自己的代码负起责任来,不要再让其它人修补自
己的BUG,不要再修补其他人的BUG。如果有人离开公司,必须要有人修补他遗留下来的
BUG,那么说话应该特别特别的小心。你必须指出需要他帮忙的特殊原因,强调这件事
本来不是他的错,本来是不应该他来做的,但是有人走了,没有办法,并且诚恳的为此
类事情的发生表示歉意。只有这样,程序员才会心甘情愿的在这种特殊关头,修补另外
一个人的BUG。
不要嚷着要别人写测试
在很多程序员的脑子里,所谓的“流程”和“测试”,比真正解决问题的代码还重要。
他们跟你说起这些,那真的叫正儿八经,义正言辞啊!所以有时候你很迷惑,这些人除
了遵守这些按部就班的规矩,还知道些什么。大概没有能力的人都喜欢追究各种规矩吧
,这样可以显得自己“没有功劳有苦劳”。这些人自己写的代码很平庸,不知道如何简
单有效地解决困难的问题,却喜欢在别人提交代码让他review的时候叫喊:“测试很重
要!覆盖很重要!你要再加一些测试才能通过我的review!”
本来code review是让他们帮忙发现可能存在的问题,有些人却仿佛把它作为了评判(
judge)其他人能力,经验,甚至智商的机会。他们根本不明白别人代码的实质价值,
就知道以一些表面现象来判断。我在Google实习,最后提交了质量和难度都非常高的代
码,然而一些完全没能力写出这样代码的人,不但没表示出最基本的肯定,反而发出沉
闷的咆哮:“快——写——测——试!” 你觉得我会高兴吗?
我并不否认测试的用处,然而很多人提起这些事情时候,语气和态度是非常不尊重,让
人反感的。这些人不但没有为解决问题作出任何实质贡献,当有人提交解决方案的时候
,他们没有表达对真正做出贡献的人的尊重和肯定,反而指责别人没写测试。好像比他
高明的人解决了问题,他反倒才是那个有发言权的,可以评判你的代码质量似的:“我
管你代码写得多好,我完全没能力写出来,但你没写测试就是不够专业。你懂不懂测试
的重要性啊,还做程序员!”
人际交往的问题经常不在于你说了什么,而在于你是怎么说的。所以我的意思并不是说
你不该建议写测试,然而建议就该有建议的语气和态度。因为你没有做实际的工作,所
以一些礼貌用语,比如“请”,“可不可以”……是必须的。经常有人说话不注意语气
和态度,让人反感,却以自己是工程师,不善于跟人说话为借口。永远要记住,你没有
做事,说话就应该委婉,切不可使用光秃秃的祈使句,说得好像这事别人非做不可,不
做就是不懂规矩一样。
礼貌的语言,跟人的职业完全没有关系。身为工程师,完全不能作为说话不礼貌的借口。
关于Git的礼节
Git是现在最流行的代码版本控制工具。用外行话说,Git就是一个代码的“仓库”或者
“保管”,这样很多人修改了代码之后,可以知道是谁改了哪一块。其实不管什么工具
,不管是编辑器,程序语言,还是版本控制工具,比起程序员的核心思想来,都是次要
的东西,都是起辅助作用的。可是Git这工具似乎特别惹人恼火。
Git并不像很多人吹嘘的那么好用,其中有明显的蹩脚设计。跟Unix的传统一脉相承,
Git没有一个良好的包装,设计者把自己的内部实现细节无情地泄露给了用户,让用户
需要琢磨者设计者内部到底怎么实现的,否则很多时候不知道该怎么办。用户被迫需要
记住挺多稀奇古怪的命令,而且命令行的设计也不怎么合理,有时候你需要加-f之类的
参数,各个参数的位置可能不一致,而且加了还不一定能起到你期望的效果。各种奇怪
的现象,比如"head detached",都强迫用户去了解它内部是怎么设计的。随着Git版本
的更新,新的功能和命令不断地增加,后来你终于看到命令行里出现了foreach,才发
现它的命令行就快变成一个(劣质的)程序语言。如果你了解ydiff的设计思想,就会
发现Git之类基于文本的版本控制工具,其实属于古代的东西。然而很多人把Git奉为神
圣,就因为它是Linus Torvalds设计的。
Git最让人恼火的地方并不是它用起来麻烦,而是它的“资深用户”们居高临下的态度
给你造成的心理阴影。好些人因为自己“精通Git”就以为高人一等,摆出一副专家的
态度。随着用户的增加,Git最初的设计越来越被发现不够用,所以一些约定俗成的规
则似乎越来越多,可以写成一本书!跟Unix的传统一脉相承,Git给你很多可以把自己
套牢的“机制”,到时候出了问题就怪你自己不知道。所以你就经常听有人煞有介事的
说:“并不是Git允许你这么做,你就可以这么做的!Unix的哲学是不阻止傻人做傻事
……” 如果你提交代码时不知道Git用户一些约定俗成的规则,就会有人嚷嚷:“
rebase了再提交!” “不要push到master!” “不要merge!” “squash commits!
” 如果你不会用git submodule之类的东西,有人可能还会鄙视你,说:“你应该知道
这些!”
打个比方,这样的嚷嚷给人的感觉是,你得了奥运会金牌之后,把练习用的器材还回到
器材保管科,结果管理员对你大吼:“这个放这边!那个放那边!懂不懂规矩啊你?”
看出来问题了吗?程序员提交了有高价值的代码(奥运金牌),结果被一些自认为Git
用的很熟的人(器材保管员)厉声呵斥。
一个尊重程序员的公司文化,就应该把程序员作为运动健将,把程序员的代码放在尊贵
的地位。其它的工具,都应该像器材保管科一样。我们尊重这些器材保管员,然而如果
运动员们不懂你制定的器材摆放规矩,也应该表示出尊重和理解,说话应该和气有礼貌
,不应该骑到他们头上。所以,对于Git的一些命令和用法,我建议大家向新手介绍时
,这样开场:“你本来不该知道这些的,可是现在我们没有更好的工具,所以得这样弄
一下……”
h*k
3 楼
笑话你不会用git不写unit test的人,可能是公司里对你最真诚的人了。
l*g
6 楼
有写这文章的功夫可以把git从头到尾学一遍了。
n*7
7 楼
怎样尊重一个精神病?
B*r
8 楼
哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈
哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈
哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈
哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈
笑尿了
哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈
哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈
哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈
笑尿了
d*k
10 楼
如果有人离开公司,必须要有人修补他遗留下来的
BUG,那么说话应该特别特别的小心。你必须指出需要他帮忙的特殊原因,强调这件事
本来不是他的错,本来是不应该他来做的,但是有人走了,没有办法,并且诚恳的为此
类事情的发生表示歉意。只有这样,程序员才会心甘情愿的在这种特殊关头,修补另外
一个人的BUG。
这段可以上糗百了
【在 r**m 的大作中提到】
: http://www.yinwang.org/blog-cn/2015/03/03/how-to-respect-a-prog
: 怎样尊重一个程序员
: 得知一位久违的同学来到了旧金山湾区,然而我见到他时,这人正处于一生中最痛苦的
: 时期。他告诉我,自己任职的公司在他加入之前和之后,判若两人。录取的时候公司对
: 他说,我们对你在实习期间的表现和学术背景非常满意,你不用面试,甚至不用毕业拿
: 学位,直接就可以加入我们公司成为正式员工。然而短短一年后的今天,这位同学已经
: 完全感觉不到公司对自己技能的尊重。Manager让他做一些乱七八糟没技术含量的事情
: ,还抱怨说他做事太慢,并且在他的evaluation上很是写了一笔。在人格尊严和工作安
: 全感的双重打击之下,这位同学压力非常大,周末经常偷偷地加班,仍然无法让
: manager满意。
BUG,那么说话应该特别特别的小心。你必须指出需要他帮忙的特殊原因,强调这件事
本来不是他的错,本来是不应该他来做的,但是有人走了,没有办法,并且诚恳的为此
类事情的发生表示歉意。只有这样,程序员才会心甘情愿的在这种特殊关头,修补另外
一个人的BUG。
这段可以上糗百了
【在 r**m 的大作中提到】
: http://www.yinwang.org/blog-cn/2015/03/03/how-to-respect-a-prog
: 怎样尊重一个程序员
: 得知一位久违的同学来到了旧金山湾区,然而我见到他时,这人正处于一生中最痛苦的
: 时期。他告诉我,自己任职的公司在他加入之前和之后,判若两人。录取的时候公司对
: 他说,我们对你在实习期间的表现和学术背景非常满意,你不用面试,甚至不用毕业拿
: 学位,直接就可以加入我们公司成为正式员工。然而短短一年后的今天,这位同学已经
: 完全感觉不到公司对自己技能的尊重。Manager让他做一些乱七八糟没技术含量的事情
: ,还抱怨说他做事太慢,并且在他的evaluation上很是写了一笔。在人格尊严和工作安
: 全感的双重打击之下,这位同学压力非常大,周末经常偷偷地加班,仍然无法让
: manager满意。
P*L
11 楼
话糙理不糙
Google 里面大材小用的事太多了,成天逼着人写 unit testing 也是醉了
【在 r**m 的大作中提到】
: http://www.yinwang.org/blog-cn/2015/03/03/how-to-respect-a-prog
: 怎样尊重一个程序员
: 得知一位久违的同学来到了旧金山湾区,然而我见到他时,这人正处于一生中最痛苦的
: 时期。他告诉我,自己任职的公司在他加入之前和之后,判若两人。录取的时候公司对
: 他说,我们对你在实习期间的表现和学术背景非常满意,你不用面试,甚至不用毕业拿
: 学位,直接就可以加入我们公司成为正式员工。然而短短一年后的今天,这位同学已经
: 完全感觉不到公司对自己技能的尊重。Manager让他做一些乱七八糟没技术含量的事情
: ,还抱怨说他做事太慢,并且在他的evaluation上很是写了一笔。在人格尊严和工作安
: 全感的双重打击之下,这位同学压力非常大,周末经常偷偷地加班,仍然无法让
: manager满意。
Google 里面大材小用的事太多了,成天逼着人写 unit testing 也是醉了
【在 r**m 的大作中提到】
: http://www.yinwang.org/blog-cn/2015/03/03/how-to-respect-a-prog
: 怎样尊重一个程序员
: 得知一位久违的同学来到了旧金山湾区,然而我见到他时,这人正处于一生中最痛苦的
: 时期。他告诉我,自己任职的公司在他加入之前和之后,判若两人。录取的时候公司对
: 他说,我们对你在实习期间的表现和学术背景非常满意,你不用面试,甚至不用毕业拿
: 学位,直接就可以加入我们公司成为正式员工。然而短短一年后的今天,这位同学已经
: 完全感觉不到公司对自己技能的尊重。Manager让他做一些乱七八糟没技术含量的事情
: ,还抱怨说他做事太慢,并且在他的evaluation上很是写了一笔。在人格尊严和工作安
: 全感的双重打击之下,这位同学压力非常大,周末经常偷偷地加班,仍然无法让
: manager满意。
h*a
12 楼
没看出有人成天逼着写unit tests. 估计就是他提交一个大的code review没有unit
test有人提出来让他加test罢了。这是非常合理的要求。作为一个production system
,没有test coverage是不可想象的。
Google里面是不是有大材小用的情况和他这篇文章并没有直接关系。他最大的困难是不
能证明自己是大材。按道理来说一个大材不应该在几个学校和所有的加入过的公司都失
败,呵呵。
倒是他自己不断用想象的东西去恶意猜测曾经的同事,比如别人做不出他做的东西,或
者别人code review的comments是出于恶意之类的。
【在 P*******L 的大作中提到】
: 话糙理不糙
: Google 里面大材小用的事太多了,成天逼着人写 unit testing 也是醉了
test有人提出来让他加test罢了。这是非常合理的要求。作为一个production system
,没有test coverage是不可想象的。
Google里面是不是有大材小用的情况和他这篇文章并没有直接关系。他最大的困难是不
能证明自己是大材。按道理来说一个大材不应该在几个学校和所有的加入过的公司都失
败,呵呵。
倒是他自己不断用想象的东西去恶意猜测曾经的同事,比如别人做不出他做的东西,或
者别人code review的comments是出于恶意之类的。
【在 P*******L 的大作中提到】
: 话糙理不糙
: Google 里面大材小用的事太多了,成天逼着人写 unit testing 也是醉了
a*3
13 楼
好文章。其实程序员是一个最容易发现凤凰男思维的职业。
system
【在 h*****a 的大作中提到】
: 没看出有人成天逼着写unit tests. 估计就是他提交一个大的code review没有unit
: test有人提出来让他加test罢了。这是非常合理的要求。作为一个production system
: ,没有test coverage是不可想象的。
: Google里面是不是有大材小用的情况和他这篇文章并没有直接关系。他最大的困难是不
: 能证明自己是大材。按道理来说一个大材不应该在几个学校和所有的加入过的公司都失
: 败,呵呵。
: 倒是他自己不断用想象的东西去恶意猜测曾经的同事,比如别人做不出他做的东西,或
: 者别人code review的comments是出于恶意之类的。
system
【在 h*****a 的大作中提到】
: 没看出有人成天逼着写unit tests. 估计就是他提交一个大的code review没有unit
: test有人提出来让他加test罢了。这是非常合理的要求。作为一个production system
: ,没有test coverage是不可想象的。
: Google里面是不是有大材小用的情况和他这篇文章并没有直接关系。他最大的困难是不
: 能证明自己是大材。按道理来说一个大材不应该在几个学校和所有的加入过的公司都失
: 败,呵呵。
: 倒是他自己不断用想象的东西去恶意猜测曾经的同事,比如别人做不出他做的东西,或
: 者别人code review的comments是出于恶意之类的。
g*g
14 楼
几个人的小公司他也混过,最后还不是被开了。如果他真如自己想象那么牛逼,那种公
司没有混不出来的道理。
system
【在 h*****a 的大作中提到】
: 没看出有人成天逼着写unit tests. 估计就是他提交一个大的code review没有unit
: test有人提出来让他加test罢了。这是非常合理的要求。作为一个production system
: ,没有test coverage是不可想象的。
: Google里面是不是有大材小用的情况和他这篇文章并没有直接关系。他最大的困难是不
: 能证明自己是大材。按道理来说一个大材不应该在几个学校和所有的加入过的公司都失
: 败,呵呵。
: 倒是他自己不断用想象的东西去恶意猜测曾经的同事,比如别人做不出他做的东西,或
: 者别人code review的comments是出于恶意之类的。
司没有混不出来的道理。
system
【在 h*****a 的大作中提到】
: 没看出有人成天逼着写unit tests. 估计就是他提交一个大的code review没有unit
: test有人提出来让他加test罢了。这是非常合理的要求。作为一个production system
: ,没有test coverage是不可想象的。
: Google里面是不是有大材小用的情况和他这篇文章并没有直接关系。他最大的困难是不
: 能证明自己是大材。按道理来说一个大材不应该在几个学校和所有的加入过的公司都失
: 败,呵呵。
: 倒是他自己不断用想象的东西去恶意猜测曾经的同事,比如别人做不出他做的东西,或
: 者别人code review的comments是出于恶意之类的。
c*9
15 楼
老邱体。
【在 r**m 的大作中提到】
: http://www.yinwang.org/blog-cn/2015/03/03/how-to-respect-a-prog
: 怎样尊重一个程序员
: 得知一位久违的同学来到了旧金山湾区,然而我见到他时,这人正处于一生中最痛苦的
: 时期。他告诉我,自己任职的公司在他加入之前和之后,判若两人。录取的时候公司对
: 他说,我们对你在实习期间的表现和学术背景非常满意,你不用面试,甚至不用毕业拿
: 学位,直接就可以加入我们公司成为正式员工。然而短短一年后的今天,这位同学已经
: 完全感觉不到公司对自己技能的尊重。Manager让他做一些乱七八糟没技术含量的事情
: ,还抱怨说他做事太慢,并且在他的evaluation上很是写了一笔。在人格尊严和工作安
: 全感的双重打击之下,这位同学压力非常大,周末经常偷偷地加班,仍然无法让
: manager满意。
【在 r**m 的大作中提到】
: http://www.yinwang.org/blog-cn/2015/03/03/how-to-respect-a-prog
: 怎样尊重一个程序员
: 得知一位久违的同学来到了旧金山湾区,然而我见到他时,这人正处于一生中最痛苦的
: 时期。他告诉我,自己任职的公司在他加入之前和之后,判若两人。录取的时候公司对
: 他说,我们对你在实习期间的表现和学术背景非常满意,你不用面试,甚至不用毕业拿
: 学位,直接就可以加入我们公司成为正式员工。然而短短一年后的今天,这位同学已经
: 完全感觉不到公司对自己技能的尊重。Manager让他做一些乱七八糟没技术含量的事情
: ,还抱怨说他做事太慢,并且在他的evaluation上很是写了一笔。在人格尊严和工作安
: 全感的双重打击之下,这位同学压力非常大,周末经常偷偷地加班,仍然无法让
: manager满意。
r*g
16 楼
虽然他被骂得多,觉得这篇文章还是有道理。抽出来几个小标题:
分清精髓知识和表面知识,不要太拿经验当回事
不要自以为聪明,不要评判别人的智商和能力
解释高级意图,不要使用低级命令
程序员的工作量不可用时间衡量
分清精髓知识和表面知识,不要太拿经验当回事
不要自以为聪明,不要评判别人的智商和能力
解释高级意图,不要使用低级命令
程序员的工作量不可用时间衡量
t*r
17 楼
就事论事,不能因人而废其言。这篇写得不错!
n*y
18 楼
这篇写得相当的好,虽然我不赞同他的其他文章和态度。
m*a
24 楼
曾在google混过,有些组里确实dickhead不少
j*f
28 楼
程序员这行要做好需要发挥创造性,太多规矩限制不是件好事,脚本语言的流行也说明
了这一点。现在的趋势就是简单,快。我觉得google的文化不是强调创造性吗?不过估
计装逼的少。
了这一点。现在的趋势就是简单,快。我觉得google的文化不是强调创造性吗?不过估
计装逼的少。
r*g
30 楼
你这个具体表现引申的太过了。没在文章里看出来。
文中说得尊重不过是少说一点'ctrl-k', 对人不懂基本工具时少一点指责,这些被尊重
的要求都是合理的。
【在 b**********s 的大作中提到】
: 不是大才小用,而是所谓小才子以为大才。如果都是大才小用,那么多大才,google怎
: 么装得下呢?
: 另外文章或者文章赞同者的一个观点是,程序员是需要被尊重的,而且应该得到和学校
: 里一样的尊重,具体表现是要把程序员当体育明星,配备一大堆助理,程序员只做最重
: 要的事。问题是,公司和学校一样吗?你在学校,是交学费的,即使TA/RA,也是low
: pay的,人家当然“尊重”你;在公司就不一样了,你的工资高
n*d
33 楼
这活宝前两年自己又偷偷找Google人内推过,只不过连面试都没拿到
n*n
34 楼
写的不错。有英文版吗?
【在 r**m 的大作中提到】
: http://www.yinwang.org/blog-cn/2015/03/03/how-to-respect-a-prog
: 怎样尊重一个程序员
: 得知一位久违的同学来到了旧金山湾区,然而我见到他时,这人正处于一生中最痛苦的
: 时期。他告诉我,自己任职的公司在他加入之前和之后,判若两人。录取的时候公司对
: 他说,我们对你在实习期间的表现和学术背景非常满意,你不用面试,甚至不用毕业拿
: 学位,直接就可以加入我们公司成为正式员工。然而短短一年后的今天,这位同学已经
: 完全感觉不到公司对自己技能的尊重。Manager让他做一些乱七八糟没技术含量的事情
: ,还抱怨说他做事太慢,并且在他的evaluation上很是写了一笔。在人格尊严和工作安
: 全感的双重打击之下,这位同学压力非常大,周末经常偷偷地加班,仍然无法让
: manager满意。
【在 r**m 的大作中提到】
: http://www.yinwang.org/blog-cn/2015/03/03/how-to-respect-a-prog
: 怎样尊重一个程序员
: 得知一位久违的同学来到了旧金山湾区,然而我见到他时,这人正处于一生中最痛苦的
: 时期。他告诉我,自己任职的公司在他加入之前和之后,判若两人。录取的时候公司对
: 他说,我们对你在实习期间的表现和学术背景非常满意,你不用面试,甚至不用毕业拿
: 学位,直接就可以加入我们公司成为正式员工。然而短短一年后的今天,这位同学已经
: 完全感觉不到公司对自己技能的尊重。Manager让他做一些乱七八糟没技术含量的事情
: ,还抱怨说他做事太慢,并且在他的evaluation上很是写了一笔。在人格尊严和工作安
: 全感的双重打击之下,这位同学压力非常大,周末经常偷偷地加班,仍然无法让
: manager满意。
f*k
35 楼
说得挺好的
最二的行为就是总觉得自己很牛,还要去教别人自认为“牛”的东西。
最二的行为就是总觉得自己很牛,还要去教别人自认为“牛”的东西。
i*k
36 楼
你们太因人废言了。。。。。
他所说的尊重别人是多么重要的一件事。
别人不尊重你,你也不去尊重你后面的人,久而久之,你们已经不知道什么是尊重了。
你们只要一看见王垠这个作者,就表示出各种不屑,认为他的所作所为配不上别人尊重
他,这本身就是王垠所指出来的你们身上的严重问题。
system
【在 h*****a 的大作中提到】
: 没看出有人成天逼着写unit tests. 估计就是他提交一个大的code review没有unit
: test有人提出来让他加test罢了。这是非常合理的要求。作为一个production system
: ,没有test coverage是不可想象的。
: Google里面是不是有大材小用的情况和他这篇文章并没有直接关系。他最大的困难是不
: 能证明自己是大材。按道理来说一个大材不应该在几个学校和所有的加入过的公司都失
: 败,呵呵。
: 倒是他自己不断用想象的东西去恶意猜测曾经的同事,比如别人做不出他做的东西,或
: 者别人code review的comments是出于恶意之类的。
他所说的尊重别人是多么重要的一件事。
别人不尊重你,你也不去尊重你后面的人,久而久之,你们已经不知道什么是尊重了。
你们只要一看见王垠这个作者,就表示出各种不屑,认为他的所作所为配不上别人尊重
他,这本身就是王垠所指出来的你们身上的严重问题。
system
【在 h*****a 的大作中提到】
: 没看出有人成天逼着写unit tests. 估计就是他提交一个大的code review没有unit
: test有人提出来让他加test罢了。这是非常合理的要求。作为一个production system
: ,没有test coverage是不可想象的。
: Google里面是不是有大材小用的情况和他这篇文章并没有直接关系。他最大的困难是不
: 能证明自己是大材。按道理来说一个大材不应该在几个学校和所有的加入过的公司都失
: 败,呵呵。
: 倒是他自己不断用想象的东西去恶意猜测曾经的同事,比如别人做不出他做的东西,或
: 者别人code review的comments是出于恶意之类的。
g*g
38 楼
路遥知马力,这哥们也不是一天两天了,都自称天才十年了,到头来每篇文章都要鼓吹
他上课多么牛逼,在Google做Intern多么牛逼。大家都审美疲劳了。论能力,你要说
above average,强于一堆老印老中我都信,但天才的标准要高太多了。换句话说,他
大约是老中码农史上口头和实际能力差距最大的一个,要尊重他比尊重公孙永浩还难。
好歹后者还忽悠了很多钱,他貌似是帮女友交完学费就被踢了。
【在 i****k 的大作中提到】
: 你们太因人废言了。。。。。
: 他所说的尊重别人是多么重要的一件事。
: 别人不尊重你,你也不去尊重你后面的人,久而久之,你们已经不知道什么是尊重了。
: 你们只要一看见王垠这个作者,就表示出各种不屑,认为他的所作所为配不上别人尊重
: 他,这本身就是王垠所指出来的你们身上的严重问题。
:
: system
他上课多么牛逼,在Google做Intern多么牛逼。大家都审美疲劳了。论能力,你要说
above average,强于一堆老印老中我都信,但天才的标准要高太多了。换句话说,他
大约是老中码农史上口头和实际能力差距最大的一个,要尊重他比尊重公孙永浩还难。
好歹后者还忽悠了很多钱,他貌似是帮女友交完学费就被踢了。
【在 i****k 的大作中提到】
: 你们太因人废言了。。。。。
: 他所说的尊重别人是多么重要的一件事。
: 别人不尊重你,你也不去尊重你后面的人,久而久之,你们已经不知道什么是尊重了。
: 你们只要一看见王垠这个作者,就表示出各种不屑,认为他的所作所为配不上别人尊重
: 他,这本身就是王垠所指出来的你们身上的严重问题。
:
: system
b*s
44 楼
作为程序员,我也希望得到别人的尊重。但要看怎么个具体的尊重了。我们来看看作者
要的具体的尊重巴(不完全):
- 解释高级意图,不要使用低级命令
- 不要期望新人向自己学习
- 不要自以为聪明,不要评判别人的智商和能力
- 让一个程序员修补另外一个程序员的BUG,不但是效率低下,而且是不尊重程序员个
人价值的作法,应该尽量避免。
- 不要嚷着要别人写测试
- 高水平程序员由于经常能够另辟蹊径,一个就可以抵好几个甚至几十个普通程序员。
他们处理的问题比常人的困难很多,费脑力多很多,当然他们需要更好的休息,保养,
娱乐
- 一个尊重程序员的公司文化,就应该把程序员作为运动健将,把程序员的代码放在尊
贵的地位。
他所有的意思是,自己是“高水平程序员”, “可以抵好几个甚至几十个普通程序员
”。所以对待他需要更多的尊重,比如不可以“使用低级命令”,不要期望他向自己学
习,不要评判他的智商和能力,不要嚷着要他写测试。
现在我来驳斥这些论调巴:
他开篇说要尊重程序员,但又分为“高水平程序员”和“普通程序员”,那么尊重他这
样的“高水平程序员”,以他的作法,算不算不尊重“普通程序员”?如果不能尊重“
普通程序员”,他的真实立意和文章标题是不是矛盾呢?
下面再说他那些具体尊重程序员,或者尊重“高水平程序员”的具体条目,总而言之是
把程序员的代码放在尊贵的地位。问题是,不管是普通程序员还是“高水平程序员”,
你的程序是不是尊贵在公司里要看市场价值,你不能用学术价值来衡量。这里有很多管
理概念,一个组织只有在市场成功,程序才有市场价值,程序才有可能有尊贵的地位,
比如作者瞧不起的UNIX的程序,人家没什么了不起,你瞧不起可以自己再写一遍嘛。你
既然用人家的,就得承认人家的价值。如果公司想在市场成功,基本程序之外的很多东
西是必须的,比如维护,管理效率,这些都决定了程序需要测试,程序需要作者以外的
人来修改。
最后,我们暂且认同他的观点,即程序员分高级普通的,待遇也不同。现在问题来了,
凭什么作者就是高级程序员呢?他在他具体工作范围是专家,可是在他所在的公司是不是
啊?很显然,他离开的公司,学校的研究团队,人家继续运作阿。那么推广一下,如果
新人程序员来了,不管你过去在自己领域多么牛鼻,你要承认在新的领域,你需要向别
人学习,包括很多低级命令,包括写测试,包括修改别人的程序。
前面是从计算机领域来驳斥作者,现在再从社会角度来驳斥他。在一个人格健全的社会
,每个人都需要得到尊重,不仅程序员,包括看门的老大爷都需要尊重。但很多低级繁
琐的事情还要人来完成。如果作者想做高级的事,让别人做低级繁琐的事情,作者就需
要证明自己。他觉得 Linus Torvalds没啥, 他也deserve同样的尊重,现在问题来了,
Linus Torvalds给的linux是free的unix,买一份unix要几百块钱,如果一个公司1000
台机器,那么就是几十万。如果他能提供几十万给这个公司,那么我支持这个公司的人
都应该像尊重Linus Torvalds那样尊重作者。
问题是,他做到了吗?也许以后会。如果那样的话,我建议作者以后再发表本文。
的。
【在 i****k 的大作中提到】
: 我只能说你们面对侮辱已经麻木了。不过你们总可以在某个地方秀出优越感找回平衡的。
要的具体的尊重巴(不完全):
- 解释高级意图,不要使用低级命令
- 不要期望新人向自己学习
- 不要自以为聪明,不要评判别人的智商和能力
- 让一个程序员修补另外一个程序员的BUG,不但是效率低下,而且是不尊重程序员个
人价值的作法,应该尽量避免。
- 不要嚷着要别人写测试
- 高水平程序员由于经常能够另辟蹊径,一个就可以抵好几个甚至几十个普通程序员。
他们处理的问题比常人的困难很多,费脑力多很多,当然他们需要更好的休息,保养,
娱乐
- 一个尊重程序员的公司文化,就应该把程序员作为运动健将,把程序员的代码放在尊
贵的地位。
他所有的意思是,自己是“高水平程序员”, “可以抵好几个甚至几十个普通程序员
”。所以对待他需要更多的尊重,比如不可以“使用低级命令”,不要期望他向自己学
习,不要评判他的智商和能力,不要嚷着要他写测试。
现在我来驳斥这些论调巴:
他开篇说要尊重程序员,但又分为“高水平程序员”和“普通程序员”,那么尊重他这
样的“高水平程序员”,以他的作法,算不算不尊重“普通程序员”?如果不能尊重“
普通程序员”,他的真实立意和文章标题是不是矛盾呢?
下面再说他那些具体尊重程序员,或者尊重“高水平程序员”的具体条目,总而言之是
把程序员的代码放在尊贵的地位。问题是,不管是普通程序员还是“高水平程序员”,
你的程序是不是尊贵在公司里要看市场价值,你不能用学术价值来衡量。这里有很多管
理概念,一个组织只有在市场成功,程序才有市场价值,程序才有可能有尊贵的地位,
比如作者瞧不起的UNIX的程序,人家没什么了不起,你瞧不起可以自己再写一遍嘛。你
既然用人家的,就得承认人家的价值。如果公司想在市场成功,基本程序之外的很多东
西是必须的,比如维护,管理效率,这些都决定了程序需要测试,程序需要作者以外的
人来修改。
最后,我们暂且认同他的观点,即程序员分高级普通的,待遇也不同。现在问题来了,
凭什么作者就是高级程序员呢?他在他具体工作范围是专家,可是在他所在的公司是不是
啊?很显然,他离开的公司,学校的研究团队,人家继续运作阿。那么推广一下,如果
新人程序员来了,不管你过去在自己领域多么牛鼻,你要承认在新的领域,你需要向别
人学习,包括很多低级命令,包括写测试,包括修改别人的程序。
前面是从计算机领域来驳斥作者,现在再从社会角度来驳斥他。在一个人格健全的社会
,每个人都需要得到尊重,不仅程序员,包括看门的老大爷都需要尊重。但很多低级繁
琐的事情还要人来完成。如果作者想做高级的事,让别人做低级繁琐的事情,作者就需
要证明自己。他觉得 Linus Torvalds没啥, 他也deserve同样的尊重,现在问题来了,
Linus Torvalds给的linux是free的unix,买一份unix要几百块钱,如果一个公司1000
台机器,那么就是几十万。如果他能提供几十万给这个公司,那么我支持这个公司的人
都应该像尊重Linus Torvalds那样尊重作者。
问题是,他做到了吗?也许以后会。如果那样的话,我建议作者以后再发表本文。
的。
【在 i****k 的大作中提到】
: 我只能说你们面对侮辱已经麻木了。不过你们总可以在某个地方秀出优越感找回平衡的。
m*a
46 楼
我们这里一堆CS Phd搞research的,光论编程,还有什么工具使用什么的恐怕还不如本
科毕业的一般码工,所以每人配两个普通码工专门实现他们的想法,没人敢嘲笑他们。
【在 b**********s 的大作中提到】
: 作为程序员,我也希望得到别人的尊重。但要看怎么个具体的尊重了。我们来看看作者
: 要的具体的尊重巴(不完全):
: - 解释高级意图,不要使用低级命令
: - 不要期望新人向自己学习
: - 不要自以为聪明,不要评判别人的智商和能力
: - 让一个程序员修补另外一个程序员的BUG,不但是效率低下,而且是不尊重程序员个
: 人价值的作法,应该尽量避免。
: - 不要嚷着要别人写测试
: - 高水平程序员由于经常能够另辟蹊径,一个就可以抵好几个甚至几十个普通程序员。
: 他们处理的问题比常人的困难很多,费脑力多很多,当然他们需要更好的休息,保养,
科毕业的一般码工,所以每人配两个普通码工专门实现他们的想法,没人敢嘲笑他们。
【在 b**********s 的大作中提到】
: 作为程序员,我也希望得到别人的尊重。但要看怎么个具体的尊重了。我们来看看作者
: 要的具体的尊重巴(不完全):
: - 解释高级意图,不要使用低级命令
: - 不要期望新人向自己学习
: - 不要自以为聪明,不要评判别人的智商和能力
: - 让一个程序员修补另外一个程序员的BUG,不但是效率低下,而且是不尊重程序员个
: 人价值的作法,应该尽量避免。
: - 不要嚷着要别人写测试
: - 高水平程序员由于经常能够另辟蹊径,一个就可以抵好几个甚至几十个普通程序员。
: 他们处理的问题比常人的困难很多,费脑力多很多,当然他们需要更好的休息,保养,
m*a
47 楼
你的这些经验就是文章里说的表面知识,别人稍微花点时间
就可以搞明白的,你还当个宝,反过来你没个几年功夫,王垠做的东西你看
都看不懂。
就一个生产线上插插元件的工人的还沾沾自喜自己懂规范,元件插的又快又准,觉得自
己牛逼哄哄,看不起那些掌握核心技术,可以设计生产线和工艺流程的人,
这两年IT泡沫,需要大量熟练工人拿现成元件搭东西去骗钱,过两年recession来了,
潮退了自然会发现who is naked.
【在 g*****g 的大作中提到】
: 叫你写测试是规范,让你先rebase再merge也是规范。这些规范本来是一个有点经验的
: 程序员都知道的,这逼就是年纪不小,经验很少。至于什么Ctrl+X,无非是下意识的,
: 没有人会觉得你不懂怎么删掉一行。把这个上纲上线就是自卑到太敏感的表现。
就可以搞明白的,你还当个宝,反过来你没个几年功夫,王垠做的东西你看
都看不懂。
就一个生产线上插插元件的工人的还沾沾自喜自己懂规范,元件插的又快又准,觉得自
己牛逼哄哄,看不起那些掌握核心技术,可以设计生产线和工艺流程的人,
这两年IT泡沫,需要大量熟练工人拿现成元件搭东西去骗钱,过两年recession来了,
潮退了自然会发现who is naked.
【在 g*****g 的大作中提到】
: 叫你写测试是规范,让你先rebase再merge也是规范。这些规范本来是一个有点经验的
: 程序员都知道的,这逼就是年纪不小,经验很少。至于什么Ctrl+X,无非是下意识的,
: 没有人会觉得你不懂怎么删掉一行。把这个上纲上线就是自卑到太敏感的表现。
d*k
49 楼
b*s
51 楼
你说的那些CS phd的东西,对于数学而言,也是表面知识不是精髓。
至于谁是naked,市场说了算。现在CSphd的supply不少,demand不高,这
也是为什么王这类的人觉得自己是高级程序员但得不到高级程序员的尊重的原因。解放
前大学生就很牛逼,现在博士都是满大街的。
【在 m****a 的大作中提到】
: 你的这些经验就是文章里说的表面知识,别人稍微花点时间
: 就可以搞明白的,你还当个宝,反过来你没个几年功夫,王垠做的东西你看
: 都看不懂。
: 就一个生产线上插插元件的工人的还沾沾自喜自己懂规范,元件插的又快又准,觉得自
: 己牛逼哄哄,看不起那些掌握核心技术,可以设计生产线和工艺流程的人,
: 这两年IT泡沫,需要大量熟练工人拿现成元件搭东西去骗钱,过两年recession来了,
: 潮退了自然会发现who is naked.
至于谁是naked,市场说了算。现在CSphd的supply不少,demand不高,这
也是为什么王这类的人觉得自己是高级程序员但得不到高级程序员的尊重的原因。解放
前大学生就很牛逼,现在博士都是满大街的。
【在 m****a 的大作中提到】
: 你的这些经验就是文章里说的表面知识,别人稍微花点时间
: 就可以搞明白的,你还当个宝,反过来你没个几年功夫,王垠做的东西你看
: 都看不懂。
: 就一个生产线上插插元件的工人的还沾沾自喜自己懂规范,元件插的又快又准,觉得自
: 己牛逼哄哄,看不起那些掌握核心技术,可以设计生产线和工艺流程的人,
: 这两年IT泡沫,需要大量熟练工人拿现成元件搭东西去骗钱,过两年recession来了,
: 潮退了自然会发现who is naked.
m*a
53 楼
Grok 里面python那部分也是他写的
http://digest.definite.name/wang-yin-googles-story.html
“本来这系统能做出来就不错了,一个组员却一直催着我写 test。她根本不明白,一
个程序并不是写了测试就会是个好程序。这个程序经过我多次的大规模修改甚至推翻重
来,即使一早写了测试,那些测试也会很快作废。这种大公司给人灌输的“test-
driven”编程方式,在这种创造性的程序设计里是根本就是行不通的。要写出这样一个
系统,必须全神贯注,深入到语言的本质。而去写测试,往往会打乱原来的思路,所以
测试应该是最后完成之后才写的。当我最后完成这个系统,可以大规模的处理 Python
代码的时候,却听见从她的桌上传来一声沉闷的咆哮:“WRITE–THE–TESTS—”这真
的非常 Googley!”
这段google的经历我深有同感,google有些组里颇有些傻B根本不知道
别人在做什么,只知道让人写test,
【在 S**I 的大作中提到】
: 丫做出了什么东东可以配得上“掌握核心技术,可以设计生产线和工艺流程”的名头?
: 你列出来让大家瞻仰瞻仰。
http://digest.definite.name/wang-yin-googles-story.html
“本来这系统能做出来就不错了,一个组员却一直催着我写 test。她根本不明白,一
个程序并不是写了测试就会是个好程序。这个程序经过我多次的大规模修改甚至推翻重
来,即使一早写了测试,那些测试也会很快作废。这种大公司给人灌输的“test-
driven”编程方式,在这种创造性的程序设计里是根本就是行不通的。要写出这样一个
系统,必须全神贯注,深入到语言的本质。而去写测试,往往会打乱原来的思路,所以
测试应该是最后完成之后才写的。当我最后完成这个系统,可以大规模的处理 Python
代码的时候,却听见从她的桌上传来一声沉闷的咆哮:“WRITE–THE–TESTS—”这真
的非常 Googley!”
这段google的经历我深有同感,google有些组里颇有些傻B根本不知道
别人在做什么,只知道让人写test,
【在 S**I 的大作中提到】
: 丫做出了什么东东可以配得上“掌握核心技术,可以设计生产线和工艺流程”的名头?
: 你列出来让大家瞻仰瞻仰。
S*I
54 楼
这就叫“掌握核心技术,可以设计生产线和工艺流程”的话,你的标准也忒低了。按这
个标准,俺组里的同事一大半都算是“掌握核心技术,可以设计生产线和工艺流程”。
Python
【在 m****a 的大作中提到】
: Grok 里面python那部分也是他写的
: http://digest.definite.name/wang-yin-googles-story.html
: “本来这系统能做出来就不错了,一个组员却一直催着我写 test。她根本不明白,一
: 个程序并不是写了测试就会是个好程序。这个程序经过我多次的大规模修改甚至推翻重
: 来,即使一早写了测试,那些测试也会很快作废。这种大公司给人灌输的“test-
: driven”编程方式,在这种创造性的程序设计里是根本就是行不通的。要写出这样一个
: 系统,必须全神贯注,深入到语言的本质。而去写测试,往往会打乱原来的思路,所以
: 测试应该是最后完成之后才写的。当我最后完成这个系统,可以大规模的处理 Python
: 代码的时候,却听见从她的桌上传来一声沉闷的咆哮:“WRITE–THE–TESTS—”这真
: 的非常 Googley!”
个标准,俺组里的同事一大半都算是“掌握核心技术,可以设计生产线和工艺流程”。
Python
【在 m****a 的大作中提到】
: Grok 里面python那部分也是他写的
: http://digest.definite.name/wang-yin-googles-story.html
: “本来这系统能做出来就不错了,一个组员却一直催着我写 test。她根本不明白,一
: 个程序并不是写了测试就会是个好程序。这个程序经过我多次的大规模修改甚至推翻重
: 来,即使一早写了测试,那些测试也会很快作废。这种大公司给人灌输的“test-
: driven”编程方式,在这种创造性的程序设计里是根本就是行不通的。要写出这样一个
: 系统,必须全神贯注,深入到语言的本质。而去写测试,往往会打乱原来的思路,所以
: 测试应该是最后完成之后才写的。当我最后完成这个系统,可以大规模的处理 Python
: 代码的时候,却听见从她的桌上传来一声沉闷的咆哮:“WRITE–THE–TESTS—”这真
: 的非常 Googley!”
s*e
58 楼
这哥们怎么这么能写啊?
g*g
59 楼
他跟我一样做码农,那些程序语言的东西根本用不上,顶屁用。本质上就跟我说我围棋
随便灭他,我下的棋他看不懂一样,都是事实,so what? 就他这实力还没本事到我面
前装逼。我老人家09年recession最糟糕的时候都能异地想跳就跳,他上次失业可是到
处求爷爷告奶奶。
【在 m****a 的大作中提到】
: 你的这些经验就是文章里说的表面知识,别人稍微花点时间
: 就可以搞明白的,你还当个宝,反过来你没个几年功夫,王垠做的东西你看
: 都看不懂。
: 就一个生产线上插插元件的工人的还沾沾自喜自己懂规范,元件插的又快又准,觉得自
: 己牛逼哄哄,看不起那些掌握核心技术,可以设计生产线和工艺流程的人,
: 这两年IT泡沫,需要大量熟练工人拿现成元件搭东西去骗钱,过两年recession来了,
: 潮退了自然会发现who is naked.
随便灭他,我下的棋他看不懂一样,都是事实,so what? 就他这实力还没本事到我面
前装逼。我老人家09年recession最糟糕的时候都能异地想跳就跳,他上次失业可是到
处求爷爷告奶奶。
【在 m****a 的大作中提到】
: 你的这些经验就是文章里说的表面知识,别人稍微花点时间
: 就可以搞明白的,你还当个宝,反过来你没个几年功夫,王垠做的东西你看
: 都看不懂。
: 就一个生产线上插插元件的工人的还沾沾自喜自己懂规范,元件插的又快又准,觉得自
: 己牛逼哄哄,看不起那些掌握核心技术,可以设计生产线和工艺流程的人,
: 这两年IT泡沫,需要大量熟练工人拿现成元件搭东西去骗钱,过两年recession来了,
: 潮退了自然会发现who is naked.
k*4
62 楼
如果你让高水平的程序员太忙了,一刻都不停着,有趣有挑战性的事情做完了就让他们
做一些低级
无聊的事情,他们悟出这个道理之后,就会故意放慢速度,有时候明明很快做完了也会
说没做完。
有一腚的道理
做一些低级
无聊的事情,他们悟出这个道理之后,就会故意放慢速度,有时候明明很快做完了也会
说没做完。
有一腚的道理
h*a
64 楼
b*s
66 楼
he is not result driven
just that simple
just that simple
c*z
68 楼
哥们有点意思,有点像mike church
h*r
70 楼
why this is important at all? care to give a thoughtful reason?
【在 B********r 的大作中提到】
: 别开玩笑了。 我们公司有个哥们写scala compiler的,也没一天到晚抱怨写个unit
: test就要了他的命
: 连 git 等 SCM都不会用,还真搞不懂你丫怎么工作到现在,复制黏贴?dropbox?用眼
: 睛看?
: 就像打篮球连运球都不会,你丫怪队友不给你一路卡位还抱着你上篮?
: 我也讨厌那种对人指指点点的dickhead,但是自己要有作为engineer的自觉,不会就虚
: 心点学,成天哇哇叫跟tmd没断奶似的烦不烦??
g*e
73 楼
这位王姓小哥这么吊。。。
不应该混工业界的,应该走科研路线。工业是business,大家要合作,不断launch新东
西,才能推动团队前进。
lift is too short to spend it working and doing business with people who
stress us out.
如果你是超级大牛,不断出货,大家也就忍了,但这哥们也没有真正铺开让大家使用的
东西,个人信用还是没有建立起来啊。
其实,一切的痛苦和不满都来自于个人实力的不到位,期望大过能力。
不应该混工业界的,应该走科研路线。工业是business,大家要合作,不断launch新东
西,才能推动团队前进。
lift is too short to spend it working and doing business with people who
stress us out.
如果你是超级大牛,不断出货,大家也就忍了,但这哥们也没有真正铺开让大家使用的
东西,个人信用还是没有建立起来啊。
其实,一切的痛苦和不满都来自于个人实力的不到位,期望大过能力。
h*2
75 楼
没人不尊重科学家,牛人。
问题是王垠他算吗。
问题是王垠他算吗。
c*r
79 楼
有谁给个摘要?又x又长
【在 r**m 的大作中提到】
: http://www.yinwang.org/blog-cn/2015/03/03/how-to-respect-a-prog
: 怎样尊重一个程序员
: 得知一位久违的同学来到了旧金山湾区,然而我见到他时,这人正处于一生中最痛苦的
: 时期。他告诉我,自己任职的公司在他加入之前和之后,判若两人。录取的时候公司对
: 他说,我们对你在实习期间的表现和学术背景非常满意,你不用面试,甚至不用毕业拿
: 学位,直接就可以加入我们公司成为正式员工。然而短短一年后的今天,这位同学已经
: 完全感觉不到公司对自己技能的尊重。Manager让他做一些乱七八糟没技术含量的事情
: ,还抱怨说他做事太慢,并且在他的evaluation上很是写了一笔。在人格尊严和工作安
: 全感的双重打击之下,这位同学压力非常大,周末经常偷偷地加班,仍然无法让
: manager满意。
【在 r**m 的大作中提到】
: http://www.yinwang.org/blog-cn/2015/03/03/how-to-respect-a-prog
: 怎样尊重一个程序员
: 得知一位久违的同学来到了旧金山湾区,然而我见到他时,这人正处于一生中最痛苦的
: 时期。他告诉我,自己任职的公司在他加入之前和之后,判若两人。录取的时候公司对
: 他说,我们对你在实习期间的表现和学术背景非常满意,你不用面试,甚至不用毕业拿
: 学位,直接就可以加入我们公司成为正式员工。然而短短一年后的今天,这位同学已经
: 完全感觉不到公司对自己技能的尊重。Manager让他做一些乱七八糟没技术含量的事情
: ,还抱怨说他做事太慢,并且在他的evaluation上很是写了一笔。在人格尊严和工作安
: 全感的双重打击之下,这位同学压力非常大,周末经常偷偷地加班,仍然无法让
: manager满意。
c*a
80 楼
尊重别人很重要,就事论事更重要。
结论是很简单的,不仅仅是程序员需要被尊重,其实哪个打工的都需要吧?难道千老不
是更需要。大家不是不尊重王垠的结论,关键这个结论屁用没有啊。我现在说个结论1+
1=2,你打算反驳吗?
从这个作者的说法里,我其实看到他呼唤的是别人要尊重他这个高级程序员(掌握了某
些精髓知识的人)?真没看出他打算尊重别人---可能是我的错觉?
我觉得,天才和伪似天才的2B的人之间最大的区别就是,把一个人克隆几个放到一起,
前者能够合作发挥出更大能力,后者会自己打起来:)
你想象一下几个王垠如果在一个组里会怎么样?:)画面很美...
【在 i****k 的大作中提到】
: 你们太因人废言了。。。。。
: 他所说的尊重别人是多么重要的一件事。
: 别人不尊重你,你也不去尊重你后面的人,久而久之,你们已经不知道什么是尊重了。
: 你们只要一看见王垠这个作者,就表示出各种不屑,认为他的所作所为配不上别人尊重
: 他,这本身就是王垠所指出来的你们身上的严重问题。
:
: system
结论是很简单的,不仅仅是程序员需要被尊重,其实哪个打工的都需要吧?难道千老不
是更需要。大家不是不尊重王垠的结论,关键这个结论屁用没有啊。我现在说个结论1+
1=2,你打算反驳吗?
从这个作者的说法里,我其实看到他呼唤的是别人要尊重他这个高级程序员(掌握了某
些精髓知识的人)?真没看出他打算尊重别人---可能是我的错觉?
我觉得,天才和伪似天才的2B的人之间最大的区别就是,把一个人克隆几个放到一起,
前者能够合作发挥出更大能力,后者会自己打起来:)
你想象一下几个王垠如果在一个组里会怎么样?:)画面很美...
【在 i****k 的大作中提到】
: 你们太因人废言了。。。。。
: 他所说的尊重别人是多么重要的一件事。
: 别人不尊重你,你也不去尊重你后面的人,久而久之,你们已经不知道什么是尊重了。
: 你们只要一看见王垠这个作者,就表示出各种不屑,认为他的所作所为配不上别人尊重
: 他,这本身就是王垠所指出来的你们身上的严重问题。
:
: system
g*g
81 楼
不能跟人合作的天才是存在的,但人先有货,不在乎别人咋看他。这哥们就是个纯二逼
而已。
1+
【在 c*****a 的大作中提到】
: 尊重别人很重要,就事论事更重要。
: 结论是很简单的,不仅仅是程序员需要被尊重,其实哪个打工的都需要吧?难道千老不
: 是更需要。大家不是不尊重王垠的结论,关键这个结论屁用没有啊。我现在说个结论1+
: 1=2,你打算反驳吗?
: 从这个作者的说法里,我其实看到他呼唤的是别人要尊重他这个高级程序员(掌握了某
: 些精髓知识的人)?真没看出他打算尊重别人---可能是我的错觉?
: 我觉得,天才和伪似天才的2B的人之间最大的区别就是,把一个人克隆几个放到一起,
: 前者能够合作发挥出更大能力,后者会自己打起来:)
: 你想象一下几个王垠如果在一个组里会怎么样?:)画面很美...
而已。
1+
【在 c*****a 的大作中提到】
: 尊重别人很重要,就事论事更重要。
: 结论是很简单的,不仅仅是程序员需要被尊重,其实哪个打工的都需要吧?难道千老不
: 是更需要。大家不是不尊重王垠的结论,关键这个结论屁用没有啊。我现在说个结论1+
: 1=2,你打算反驳吗?
: 从这个作者的说法里,我其实看到他呼唤的是别人要尊重他这个高级程序员(掌握了某
: 些精髓知识的人)?真没看出他打算尊重别人---可能是我的错觉?
: 我觉得,天才和伪似天才的2B的人之间最大的区别就是,把一个人克隆几个放到一起,
: 前者能够合作发挥出更大能力,后者会自己打起来:)
: 你想象一下几个王垠如果在一个组里会怎么样?:)画面很美...
相关阅读
什么叫有经验的android/ios/fullstack/frontend.......码工VS下有Lib(C++)如何调试?王垠又要回国了Perl Q: how to convert integer to MAC addresswdong开始转型娱乐业了是不是我看错了,Kaggle上可做的题一共11题? (转载)小team政治scenario求教各位码工,一个小问题被opengl害惨了!Multi-tenancy Authentication 大家都怎么做?stack overflow 算大型 web app 么?如何run spark scala 代码,不用jar 的情况下?问wdong一个问题,学习openGL从哪儿开始学好Java现成的distributed的lock有哪些?lightroom请科普下双路deep learning维护一个热门视频榜单的apihci想过没有为什么你没有机会面试Harvard毕业的孩子?Re: [bssd] 教小孩functional programming这偏语言分析的文章很好面试要求上机做题的,你们去不去面?