Skip to content

四火的唠叨

一个纯正程序员的啰嗦

Menu
  • 所有文章
  • About Me
  • 关于四火
  • 旅行映像
  • 独立游戏
  • 资源链接
Menu

观点的碰撞

Posted on 12/03/201206/23/2019 by 四火

argue 几周前我写了一篇文章,《对几个软件开发传统观点的质疑和反驳》,微博上、独立域名的博客上,还有 ITEye 网站上,都有一些评论的朋友给了我许多事实和观点。我觉得这些评论,似乎都有理由,无所谓对错,这些是有价值和有意义的文字。相较于那些“ 顶”、“ 支持”、“SB”、“ 沙发”…… 纯灌水或者是没什么意义的信息垃圾,这些文字要显得珍贵得多。

最近看了两本软件和创业方面的书,我的世界观总在不断小范围地崩塌和建立。现在愈发觉得,到底何谓对错,到底何为黑白,我是不是受到中国传统教育毒害太深了,到现在才慢慢缓过劲来?

我想到一些有意思的争论:

1、先寻找优秀的程序员还是先准备优秀的产品设计?

先准备优秀的产品概念、设计和理念,再去寻找合适的人,这样的公司稳重、成熟,能做出优秀的产品;还有的先去寻找最优秀的程序员,把这撮人聚到一起再去考虑做什么,这样的公司大部分都死了,但是活下来的都是极其伟大。

具体地说,有的公司为项目寻找合适的人,我想大多数公司都是这样做的;有的公司寻找最棒的人,他们的项目有许多都是由这些最棒的人发起的。很不幸的是我是后一种观点的支持者,尽管这种观点经常被骂成“ 不合逻辑”。

2、你是要做工程商人吗?

我记得我毕业找工作的时候一位面试官和我说,“ 我们不需要最优秀的人,我们只寻找最合适的人”,三年后,我参与做一个产品的时候,一位老程序员说,“ 做‘ 最好’ 的产品,就有意义吗?我们都是工程商人,我们做‘ 合适’ 的产品”。

有哲理?还是扯淡?我曾经那么坚信赚钱是这些软件商人的第一要务,可是后来我才逐渐感到,还有一种被称为“ 梦想” 的东西在他们之中的少数人身上闪光。人是有感情、有追求的动物,程序员不是理智的法官,程序员要做一个狂野的画家。

所以我大概不适合创业,理想主义者总会在妥协和坚持两边摇摆和斗争,他们中的许多最终会死在惨白的现实下。

3、用户是上帝?

程序员应该首先去关心用户的需求和体验吗?如果用户不喜欢,你那些再华丽的技术又有何用? 是啊,多么正确的话。好吧,换个角度,产品经理是老大,他们是这个星球上最清楚用户想要什么的人……

看看有多少产品经理掌握话最大语权的公司吧,可是另一种声音说,这样的产品经理请滚蛋。程序员首先要用自己做的产品,征服自己,其次才是用户。用户其实也不清楚自己到底想要什么。所以,大部分时候请忽略他们。记录用户的需求?拉倒吧,“ 用户真正的需求根本不用记录。真正有意义的需求,客户会一次又一次地跟在你屁股后面提出来。你根本就不可能忘记。你的客户就是你的记事本。”

用户不但不是上帝,而且大多数用户对你的产品来说,他们什么都不是。你,或者你的团队,才是产品的上帝。用户只是会抱怨会牢骚会骂死你的不负责任的凡人而已。

4、工程师文化有多棒?这样的公司才能做出伟大的软件产品吗?

你可以给我举出 Google、Facebook 或者 37Signal 的例子。好吧,你真睿智,但是这个世界并不是那么简单的。

首先,这个世界上大部分软件公司采用工程师文化的模式来运作的话,都会死得很惨。

其次,这个世界上大部分号称工程师文化的软件公司,都只是号称号称而已。

最后,这个世界上大部分成功和伟大的软件公司,都不是工程师文化的。

以牛逼哄哄的苹果公司为例,在我看来,苹果就是一个人的公司,如果这个人很牛,公司就会很牛,如果这个人水了,公司就要完蛋了。苹果的工程师并不会觉得生活有多美好,死在他们手里的项目,莫名其妙被叫停的项目太多太多,只有一个人掌握生杀大权,那个人曾经是乔布斯。现在乔布斯死了,要么苹果不再是一个人的公司,要么苹果就快完蛋了。

5、团队合作有多重要?

团队合作至上。不错。

甚至有人说,有人说:最厉害的人不是自己解决问题的人,而是能让那些能解决问题的人死心塌地为那个人努力干活并最终解决问题的人。

好吧,又一句像绕口令一样的至理名言,又一个未来的哲学家,我服了你了。

不过,我觉得,单兵作战能力极强的精英团队,也许争吵不易控制,可比平庸的和谐之队产出强多了。有争论、甚至争吵,至少都是思考的表现,出发点大多是正面的,只要对事不对人就好了。指望大家都客客气气地陈述事实、然后安安静静地讲道理?那么这堆人都是圣贤,或者就是机器人而已。追求这样的和谐团队?去死吧。另外,我一直觉得,原型、demo,还有框架基础,甚至产品第一稿,就是该由一两个人完成的。

程序员都讨厌开会,因为“ 会议中总难免轮到一个低能人士发言,于是大家的时间都被浪费在他们的扯淡上”;结对编程也不总是那么受欢迎的,结对的两个人水平差异太大了不行、性格过于冲突了不行、沟通能力不够强还是不行…… 如果团队合作的感觉那么美好,为什么不三个人、四个人一起写一段代码,在不说谎话的代码面前培养培养复杂的感情?

很简单,团队合作也是需要成本的。在产品初创的时候,团队的人越多,越做不出伟大的产品来。

6、辩证法?可有时候,我们只需要一个观点,一个明确的观点而已。

这个世界上只有两种编程语言,一种是被骂的,一种是没人用的。

这个世界上只有两种设计,一种是简单的设计,一种是烂设计。

这个世界上只有两种人,一种是说话偏激的,一种是说废话的。

好吧,我来具体说明一下。我问某牛逼的架构师,我应该把这些数据存放到数据库里还是文件里?牛逼的架构师回答我说,如果放到数据库里有 1、2、3 三条好处,也会带来 4、5、6 三条坏处;但是如果放到文件里,则存在 a、b、c 三条优点,以及 d、e、f 三条缺点。请考虑,这回答太完美了,没有什么漏洞可以找。所有的问题他都可以给你横陈利弊,当然,做最后决定的人是你。

所以无论你做什么决定,最后如果有什么问题那都是你的问题,他的方案条理清晰、思路明确,怎么可能有问题?当然,如果事情办得妥妥的,功劳当然是他的,因为他把事情都给你分析清楚了,你不就是一个傻帽的执行者而已嘛。

你放心,我不会这样说:该死的唯物辩证法。那是找骂。

我只会说,告诉我一大堆理由也可以,但是请给我一个明确的答案。

“Java 太垃圾了”、“ 我就是痛恨注解”、“ 微软的东西是屎”…… 这些人的观点太过鲜明,而且 2B 青年充斥在思考着之中,以至于大多数人都接受不了。不过,如果理坚词硬的话,这些敢说的人,相对于那些不想得罪任何人的人,还是挺可爱的。

7、更多时候,相较于知识渊博的人,我们需要一个执行者,一个做实事的人。

其实这样的人知识广泛、学识渊博,而且具备丰富的经验。他们最喜欢的挂在嘴上的话是:“ 我当年做 XXX 的时候……”。

“ 这个问题很简单,只要使用 ABC 技术,或者 DEF 框架,一整合、一实现、一配置,就搞定了。” 程序员的工作在他们眼中卑微而渺小,事情总是那么容易解决。就像程序员估计项目进度一样,事实却很难估得准。

遇到困难的时候,他们则跳出来说:“ 这个烂东西,一开始方向就是错的,如果用 XYZ 技术,三下两下就搞定了”。于是,这个东西设计开发骨干的你躺枪了。而且,死得很难看。

牛人都如此言简意赅,那么喜欢指点江山吗?

下次,你应该这样反驳他:你说得对,既然你看来很容易就能搞定了,那你来做吧,我一边歇着去。

好了,我说完了。

文章未经特殊标明皆为本人原创,未经许可不得用于任何商业用途,转载请保持完整性并注明来源链接 《四火的唠叨》

×Scan to share with WeChat

你可能也喜欢看:

  1. 思考、学习新技术的原则和方式
  2. 编程语言学习和使用的观点
  3. 换个角度思考问题
  4. 谈谈 Ops(二):流程和人
  5. 层次

8 thoughts on “观点的碰撞”

  1. mikewootc says:
    02/06/2013 at 10:01 AM

    " 所以我大概不适合创业,理想主义者总会在妥协和坚持两边摇摆和斗争,他们中的许多最终会死在惨白的现实下。"
    不太同意这种说法, 理想主义者可以创业. 在摇摆和斗争中找到平衡, 在现实中寻求理想, 最终就能实现理想.

    Reply
  2. jim says:
    01/24/2013 at 6:05 PM

    补充一句,赞博主一个。从文字里可以看出博主是个非常喜欢思考分析的人。

    Reply
  3. jim says:
    01/24/2013 at 6:03 PM

    “ 最近看了两本软件和创业方面的书,我的世界观总在不断小范围地崩塌和建立。”
    估计这句话会一直伴随你,若干年后你可以再看看自己现在的文字,或许有更多感悟。呵呵

    Reply
  4. Probe says:
    12/12/2012 at 10:55 PM

    “ 最近看了两本软件和创业方面的书” 是哪两本呢?
    博主之前有篇文章提过《Rework》。而“ 用户是上帝” “ 团队合作” 这两个部分有点像《Getting Real》里的观点。也许不是这些,是《软件随想录》《精益创业》?
    也许

    Reply
    1. 四火 says:
      12/14/2012 at 8:45 PM

      这两本书就在你说的其中 :)

      Reply
  5. 独酌逸醉 says:
    12/07/2012 at 1:52 PM

    有些偏激,但是很对我胃口。获益匪浅!

    Reply
  6. G says:
    12/06/2012 at 10:32 AM

    我在想一个问题:为什么您的文章有些话要用不同的颜色亮出来?

    Reply
  7. Anonymous says:
    12/04/2012 at 6:48 PM

    好

    Reply

Leave a Reply to G Cancel reply

Your email address will not be published. Required fields are marked *

订阅·联系

四火,啰嗦的程序员一枚,现居西雅图

Amazon Google Groovy Hadoop Haskell Java JavaScript LeetCode Oracle Spark 互联网 亚马逊 前端 华为 历史 同步 团队 图解笔记 基础设施 工作 工作流 工具 工程师 应用系统 异步 微博 思考 技术 数据库 曼联 测试 生活 眼界 程序员 管理 系统设计 缓存 编程范型 美股 英语 西雅图 设计 问题 面向对象 面试

分类

  • Algorithm and Data Structure (30)
  • Concurrency and Asynchronization (6)
  • System Architecture and Design (43)
  • Distributed System (18)
  • Tools Frameworks and Libs (13)
  • Storage and Data Access (8)
  • Front-end Development (33)
  • Programming Languages and Paradigms (55)
  • Testing and Quality Assurance (4)
  • Network and Communication (6)
  • Authentication and Authorization (6)
  • Automation and Operation Excellence (13)
  • Machine Learning and Artificial Intelligence (6)
  • Product Design (7)
  • Hiring and Interviews (14)
  • Project and Team Management (14)
  • Engineering Culture (17)
  • Critical Thinking (25)
  • Career Growth (57)
  • Life Experience and Thoughts (45)

推荐文章

  • 谈谈分布式锁
  • 常见分布式系统设计图解(汇总)
  • 系统设计中的快速估算技巧
  • 从链表存在环的问题说起
  • 技术面试中,什么样的问题才是好问题?
  • 从物理时钟到逻辑时钟
  • 近期面试观摩的一些思考
  • RSA 背后的算法
  • 谈谈 Ops(汇总 + 最终篇):工具和实践
  • 不要让业务牵着鼻子走
  • 倔强的程序员
  • 谈谈微信的信息流
  • 评审的艺术——谈谈现实中的代码评审
  • Blog 安全问题小记
  • 求第 K 个数的问题
  • 一些前端框架的比较(下)——Ember.js 和 React
  • 一些前端框架的比较(上)——GWT、AngularJS 和 Backbone.js
  • 工作流系统的设计
  • Spark 的性能调优
  • “残酷” 的事实
  • 七年工作,几个故事
  • 从 Java 和 JavaScript 来学习 Haskell 和 Groovy(汇总)
  • 一道随机数题目的求解
  • 层次
  • Dynamo 的实现技术和去中心化
  • 也谈谈全栈工程师
  • 多重继承的演变
  • 编程范型:工具的选择
  • GWT 初体验
  • java.util.concurrent 并发包诸类概览
  • 从 DCL 的对象安全发布谈起
  • 不同团队的困惑
  • 不适合 Hadoop 解决的问题
  • 留心那些潜在的系统设计问题
  • 再谈大楼扔鸡蛋的问题
  • 几种华丽无比的开发方式
  • 我眼中的工程师文化
  • 观点的碰撞
  • 谈谈盗版软件问题
  • 对几个软件开发传统观点的质疑和反驳
  • MVC 框架的映射和解耦
  • 编程的未来
  • DAO 的演进
  • 致那些自嘲码农的苦逼程序员
  • Java 多线程发展简史
  • 珍爱生命,远离微博
  • 网站性能优化的三重境界
  • OSCache 框架源码解析
  • “ 你不适合做程序员”
  • 画圆画方的故事

近期评论

  • panshenlian.com on 初涉 ML Workflow 系统:Kubeflow Pipelines、Flyte 和 Metaflow
  • panzhixiang on 关于近期求职的近况和思考
  • Anonymous on 闲聊投资:亲自体验和护城河
  • 四火 on 关于近期求职的近况和思考
  • YC on 关于近期求职的近况和思考
  • mafulong on 常见分布式基础设施系统设计图解(四):分布式工作流系统
  • 四火 on 常见分布式基础设施系统设计图解(八):分布式键值存储系统
  • Anonymous on 我裸辞了
  • https://umlcn.com on 资源链接
  • Anonymous on 我裸辞了
© 2025 四火的唠叨 | Powered by Minimalist Blog WordPress Theme
Menu
  • 所有文章
  • About Me
  • 关于四火
  • 旅行映像
  • 独立游戏
  • 资源链接