这是关于一个具有极高智商但却极端个人主义的程序员的故事,这种类型的程序员我们都知道，也都不喜欢。我们可以不用这样的人吗？
有一些我曾经共事过的程序员，他们极其的聪明，但也极端的古怪离奇。
“古怪离奇”也许用来形容一个事件或一个观点更合适。也许称这类型的人为书呆子更合适。但不管怎样，我的印象中，大多数时候，他们并不会带来太大的麻烦。
并不是他们的脑瓜不灵。很多时候，这些“优秀”的程序员往往是团队中最有能力的。他们的智商和解决问题的能力都是其他人无法企及的。
很多时候，他们是公司里能够解决那些将会让公司损失百万美元问题的唯一的人。当然，大多数情况是因为最初他们参与了开发设计或给了最初的指导。
如果是他们自己故意制造了这将要到来的灾难，我一定都不会吃惊，这样一来他们就能成为救世的英雄。
不幸的是，在众多的IT企业文化中，英雄崇拜是普遍现象。一个明显不合群的程序员但却会被经理们高捧在众人之上。
管理者们需要在意这样的程序员吗？我曾在以前的文章里谈到过这样恃才放旷的程序员，比如Tyler——无视规定，破坏团队建设。是的，我相信管理者绝对应该重视他们，因为他们会影响到团队其他人员，影响到整个团队，他们会给团队带来长久的不确定的风险。
可问题是，管理者们喜欢依赖于这样的有才华的程序员，把他们当作中流砥柱。
我以前也这样过，现在想起来内心有愧。你很容易陷入这种境地，你会因此悔断肠子，因为他们会让你丢掉工作。
这些年来，我曾和很多种这样极富挑战型性格的人共事过。我这里选一个有代表性的例子：我向你保证，乔希绝对是一个真实存在的人；但我给他起了另外一个名，以免他发癫到我家来找我。
我第一次见到他是在我新上任第一天处理一个危机的时候。乔希在我之前很多年就来了这个公司。我们的团队的任务是解决公司的软件产品中的各种问题。
我们当时都在会议室里，免提电话里传来客户的咆哮。他已经受够我们的产品环境中的一个迟迟不能解决的问题，威胁要取消订单。
于是我把乔希叫了进来，他就是产生这个问题的程序的开发者——更像是个主谋。一般情况下，没有人会把乔希带到客户面前，因为他的外表，怎么说呢，让人想起Charlie Brown卡通中邋遢的Pigpen。
我知道这不是可视电话(也不会传导气味)，所以应该没问题。而且毫无意外，乔希一个小时内就解决了这个问题。客户得到了安抚，我也松了口气，避免了在我的管理下丢失客户。
我问技术支持小组的技术负责人，问什么乔希一个小时解决了这个问题，而我们的团队花了两天时间都解决不了？回答让我震惊。
他说“我昨天问了乔希，向他求助，但他笑我。他说如果我们没有能力解决这个问题，那我就不配待在这里。”
我的这个技术负责人继续解释说，尽管他翻遍了所有产生错误的程序代码，问题实在让人费解，他查不出问题出在哪。我问程序的文档在哪，他转着眼珠，不自然的傻笑，“什么文档？”
先对乔希的背景做一下介绍。他有时会穿印有挑衅性标语的T恤。上班时你有时会找不到他，甚至好几天。
不止一次我身边的女同事说他在她们面前说脏话。然而，他仍然在这个公司里，而且是拿的薪水最高的程序员。
我决定跟乔希聊一聊。当走进他的办公室时(他是唯一一个有私人办公室的程序员)，我感觉需要拿着一个手电筒，因为太黑了。更像是个洞穴，而不是办公室。
宁愿找个衣服夹夹住我的鼻子。
我记不清确切的说了哪些话，但过程大概是这样的。
“你好，乔希”，我说，声音尽量轻松高兴。
静悄悄。
乔希依旧狂暴的敲着他的键盘。我继续说，“嗯，乔希，我能占用你一分钟时间谈谈客户发现的那个问题吗？”
他没有停下来，嘴动了一下，“你说。”
“我想说的是谢谢你解决了那个问题，但我也知道，昨天我的团队向你求助时，你不肯帮他们。”
乔希，注意力并没有从键盘上移开，支吾了一句“怎了？”
“我想知道，你为什么不肯帮他们？”
“我很忙，”他爱理不理的说。
“我知道，但如果你能帮一下….”
他打断我，语气中带着轻蔑的说“帮他，让我去向那个白痴去解释如何做他的工作？我写我的代码。我的代码好用。over。”
我不知道这次谈话怎么结束的，而且，这不太像是一次谈话。我决定找乔希的经理谈一谈。
我一提起这个话题，他的经理噌的站起来去关上了她办公室的门。
她说，“小心，你应该放弃这个念头。这是乔希。他喜怒无常，如果我不全力支持他，他随时都会拍屁股走人。他写代码的速度比团队里任何一个人都快。”
我试图向她解释，乔希应该融进团队中，写的程序也应该有文档。她的回答是，有能力的程序员都不需要文档。
“代码”就是文档。她根本无视整个“团队”的抱怨。
随后她笑了，说，“我直说吧，如果没了乔希，我们就不能按时完成下一次的发布，我也就不能坐在这里了。over。”
一天内两次“over”。可是，这事儿没这么就over了。当有更多的客户方面的问题出现后，CEO出面并强行解决了这个问题。
你猜在CEO和乔希的谈话后发生了什么？第二天他没来上班。他走时甚至没有拿走留在办公室里的东西。
他就这样….失踪了。
跟着他走的还有他掌握的对那些复杂(杰出)的代码的理解。一大群优秀的和“水平一般”的程序员最终把这留下的烂摊子整理清楚，但公司为此耗费了大量的时间和金钱。
我们可以称乔希这样的程序员为怪胎，疯子，或蛮不讲理，可毫无疑问，他们的智商是高人一等的。但是，如果你一直任着他们这样下去，他们迟早会成为你公司，团队或事业上的定时炸弹。
红果果的污蔑，高手跟性格怪异没啥相关性
程序复杂度无从得知，文中乔希的人品问题也不谈了
写无注释且别人难于读懂的代码，说明coder第一课没有学好
你的逻辑有问题. 原文作者没有假设高手必然就是性格怪癖的, 当然没有什么相关性. 你没有碰到这样的人并不能说明这样的人不存在, 天马行空才华横溢的程序员有相当多都是自学成才, 不是人人都被国内的教育填鸭过的.
天马行空才华横溢的程序员有的是,但是软件开发是团队活动,不懂协作的人对团队绝对是毁灭性的.更何况软件使用相当一段时间是需要维护的,没有文档,直接增加维护的成本,这对企业所有者和管理者来说,这是绝对不可以接受的
不属于自己的工作，人家凭什么告诉你？就一点知识，你知道人家背后付出了多少？热于分享的人，我们感激他。不想分享的人，也应该体谅。都懂了，你想想自己的工资还会那么高么？自己那么多的付出不就是打了水漂？这也就是为什么有专利的原因。
乔希是很好的程序员，但是没法相处。。。
悲剧了。。。
这样的人适合去做开源软件的开发，特别是kernel那样的。山外有山，人外有人。会有Linus那样的大神压住他们的
脱离了贡献谈负面影响的都是臭流氓！
像乔希这样的人才，确实是一柄利剑，同时也是双刃的。如何妥善地使用，是个令人头痛的问题。
1,只要不是有意留下的bug，乔希工作上的错误只在于沟通。这种人认为和他一样的办事能力（任何方面都行）是和他平等相处的必要条件，参考“谢尔顿”。作者的工作中沟通估计会超过50%，显然他并不是很善于处理这类事。
2.作者希望乔希能按作者的风格办事，融入作者的团队，基于逻辑和上面提到的乔希的相处原则，这是不合理的。文中最认同作者的只有主题：一个有效的管理手段比一个高手来的重要。
3.没说这哥们儿走了以后是不是就没或者少了这类问题（客户XX）了，只说解决了遗留问题。当然大家都懂。
为什么要埋怨乔希捏？
他说了，“让我去向那个白痴去解释如何做他的工作？”
为什么他会说白痴呢？我想是因为别人真的技术不够强
不能理解乔希的思想，如果管理人员够厉害，
我觉得文章中说的绝对不是问题。。。
实在搞不懂楼主用这个个案想说明什么
类似乔希的人我遇过，我觉得本文的作者显然不够聪明。
怎样做才够聪明呢
团队的意义就是要组合不同特点的人，他已经有了很大的优点，为什么还要强求他有很好的沟通能力呢？公司应该既使用这样的人，同时也要做好他随时离开的准备，这是使用天才必须付出的代价。
有性格啥！团队好就多付出点，所在团队不是很好就少做点！
写的代码一个团队的人都看不懂的程序员？好吧。
作者这样做很白痴，失去乔希，虽然解决他留下来的麻烦，但是也失去一个太才人的创意和成功，后者才是最重要的。。
另外这些麻烦其实可以乔希存在的时候解决的，只是那群同事太庸才了，代码就是最好的注释，其他人搞不懂只能证明其他同事能力不足。。。
作者这样做很白痴，失去乔希，虽然解决他留下来的麻烦，但是也失去一个天才的创意和成果，后者才是最重要的。。
另外这些麻烦其实可以乔希存在的时候解决的，后来解决也证明他的代码也是可读的，只是那群同事太庸才了，乔希在的时候太依赖他了。
别人笑他太疯癫，我笑它人看不穿
三个臭皮匠赛过诸葛亮，再聪明有能力没有融入团队只会边缘化，这类怪才适合单干。
如果说乔希的代码可读性差，那的确问题就大了。无论他多么聪明。
你甚至可以教会一个白痴写可读性差的代码，但只有高手才能写出可读性好的代码。
代码的可读性是评判代码优劣的唯一标准。
可读性是于写的人来说的，对于怪才来说，理解力就不同，可读性自然也就不同了。
企业应该用他的长处，尽量包容他的短处，没有完美的人，如果让我选择，10个中规中矩的人，都比不上一个天才。中规中矩的人在招聘上一抓一大把，天才就无处可寻了。