Skip to content

四火的唠叨

一个纯正程序员的啰嗦

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

多面手程序员

Posted on 12/29/201210/01/2024 by 四火

1 先来看看这样的场景:

  • “没有美工做的高保真页面,我怎么来开发呢?我没有审美,也不会用 PS 作图啊。”
  • “正交测试这种技巧,是测试工程师应该掌握的,开发不需要了解。”
  • “目前进度的瓶颈在产品经理那里,他还没有给我澄清需求。难道要一个写代码的去给客户整理需求么?”
  • “我是 C++程序员,我是做底层开发的啊,这种页面样式的问题我怎么可能懂?”
  • “这是维优人员关注的线上数据,他应该把日志、错误现象全部备齐了再提交问题给开发。”
  • “这是他的模块,把问题提给他来处理。”
  • ……

这些是我下面要反驳的一些做法,你有没有中枪的?

事实上,我已经在很多篇文章里(比如这篇文章)阐述了这样的观点:程序员要多能。很多情况下,优秀的程序员一个人就可以搞定一切。

但是如果我直接把我的观点扔上来,可能不会遭到很多的质疑。我们的教育一直都讲究 “做一行,爱一行”,明确哪些事是自己应该管的,哪些事是别人的,切勿指手画脚。因此,即便有的人暂时赞同了我的看法,却只似雁过留痕而已,在实际学习工作中,依然不容易扭转这样的观念。

所以我摆出这样的几个场景,有异议、有争论是好事。

程序员替代不了美工吗?

有人反驳我,说:“如果程序员可以替代美工,可以替代 UI 设计师,那还要专门设置这些职位干什么?”

说得好。程序员当然可以做美工的工作,但是程序员不能取代他们,这里至少有两个原因:

  1. 多数程序员并不具备美工的专业技巧和丰富的 UI 经验,换言之,无法如他们那样精通界面设计;
  2. 出色的美工需要有非常优秀的审美,这需要审美天赋,也是大多数程序员不具备的。

但是——

  • 程序员可以用 PS 切图吗?可以。
  • 程序员可以设计 CSS 和 HTML 界面吗?可以。
  • 程序员可以设计 UI 吗?当然可以,而且往往清晰、简洁,组件复用性好。

美工,只是一个特例而已。你可以把它套到各种相关工种名称上,比如测试。有这样一篇文章 《我们需要专职的 QA 吗?》,答案当然可以不是非黑即白的,可这需要放下成见,我想,你会有自己的思考。

请不要忽视工具的威力

工具的威力有多大?想想 Bootstrap,可以让一个对 CSS 和 JavaScript 只是略懂的人,就可以做出非常简洁美观的界面来;再比如这篇文章,谁说程序员不能做运维?当工具足够强大,运维并没有那么困难。

在工具降低重复劳动和降低门槛的时候,真正精通的专家都去开发工具了。正所谓 “授之以鱼,不如授之以渔”,但这句话有个特例,如果对方是程序员,那么这两者都不用,还是给他开发一个自动捕鱼工具吧。

小团队和简单流程

小团队也好,简单流程也好,就是要让沟通成本尽可能小,容易保持对话交流这种高效的方式。在享受这样的好处的时候,“专才” 可以吸引你的眼球,但是 “通才” 却是一个必不可少的要求。

对一支创业团队来说尤为如此。小团队让一个创意可以快速得到实施,但是你没有太多钱和精力,谁负责宣传?谁负责约见客户?谁负责上线?谁负责响应投诉?……你需要多面手而不是技能单一的专家。

一专多能

多面手并不阻碍你成为某一领域的专家。深度和广度往往是相伴而行的,很难想象一名优秀的 DBA 不懂操作系统底层的知识;也不可能见到出色的 “前端工程师” 却只会写 JavaScript 客户端脚本语言。毕竟问题不可能非常单纯,总是牵一发而动全身的,唯有了解的东西多了,才能够去更好地认识自己最擅长和熟知的领域。

事实上,一专多能已经成为了潮流。在足球领域,现代足球的发展造就了多样化的角色,为这些角色使用了独立的词语,以前锋为例,就有 Poacher(抢点型)、Trequartista(9 号半)和 Target Man(站桩中锋)等等。

多走一步

我的同事在定位问题的时候,如果发现不是我们自己的问题,而是别的产品引发的问题(由别的团队维护),都已经形成这样的习惯:尝试花少量的代价去定位一下问题的所在。这其中,我们经常会去阅读对方的产品的代码。有人觉得不可思议,你去读别的产品的代码?其实听起来恐怖,可多数情况下做起来却没有那么困难。至少,你可以把你的调查分析结果给目标团队,了解别的产品和阅读别的产品的代码,对于扩大视野还是有助益的。

在模块划分上亦如此,不要把模块的责任划分得那么清晰,谁都有查看、修改代码的权利和义务。

多走一步还表现在团队中非设计编码的其它事务上,程序员应当尝试做各种各样的事情。比如招聘——招来的人是要和你每天在一起工作的好伙伴、好基友,这是事关你切身利益的大事,如果让别人去决定你的团队要安插什么样的人,这谈何合理呢?

有的人甚爱搞科研,这些人叫做研究员、科学家;有的人擅长做工程,这些人才是工程师。做工程就是要解决实际的问题,于是你不可避免地接触到形形色色的领域和现象。SDE 不只是 Software Development Engineer,同时更是 Someone Do Everything。

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

×Scan to share with WeChat

你可能也喜欢看:

  1. JavaScript 使用 for 循环时出现的问题
  2. Function Invocation Patterns
  3. 几道容易出错的 JavaScript 题目
  4. 为中国的程序员说几句
  5. 关于国内程序员到美国工作

7 thoughts on “多面手程序员”

  1. somex says:
    10/15/2013 at 7:42 PM

    唉,说的倒是挺对的。不过当初,俺参加技术面的时候,面试官看到我简历上写着“web 开发一条龙服务:前端,后端,测试,存储,调优“ 的时候,有些嘲讽的和旁边的人说” 哇,高手啊“,当时那个囧啊~~~~

    Reply
  2. Anonymous says:
    06/04/2013 at 5:33 PM

    深度和广度往往是相伴而行的,很难想象一名优秀的 DBA 不懂操作系统底层的知识;也不。。。。。。非常非常赞同。

    Reply
  3. yjin says:
    04/23/2013 at 1:02 PM

    "SDE 不只是 Software Development Engineer,同时更是 Someone Do Everything"
    I could not agree more.

    Reply
  4. cokecoffe says:
    03/08/2013 at 3:54 PM

    各有利弊,小团队方式多面程序员很容易就能发展为产品经理。
    而大公司的程序员可能一辈子是程序员,但是很可能发展一个技术大牛。

    Reply
  5. 求源 says:
    03/07/2013 at 2:46 PM

    我就想做这样的一个程序员,专而自信,多而勤勉!刚毕业半年,目前小公司滴干活!欢迎各位同行多多指教

    Reply
  6. 冯大宝 says:
    01/23/2013 at 6:56 AM

    其实每个人都可以设计产品的,这里面当然包括程序员,也包括美工。由于我们公司规模比较小,所有的网站页面设计都是由我和一个美工共同设计完成的。和用户沟通需求也是我们。基本上我们两个人配合可以完成任何网站了。但缺点就是我们只能接一些小公司的网站,遇到大网站,复杂系统,高并发,就马上感觉技术上不足了。
    其实程序员需不需要是多面手,这完全取决于公司规模的大小。
    大公司培养的一般是一些专精人才,而小公司培养的都是多面手。要是小公司和大公司都待过的话,就很容易培养出一专多能了……

    Reply
  7. 有课 says:
    01/22/2013 at 6:47 PM

    最后一条不能认同。可以尝试去修改,可以向模块负责人提交修改,但是最后还是得让人家来决定怎么改

    Reply

Leave a Reply to somex Cancel reply

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

订阅·联系

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

Amazon Google Groovy Hadoop Haskell Java JavaScript LeetCode Oracle Python 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)
  • Big Data and Machine Learning (5)
  • 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 框架源码解析
  • “ 你不适合做程序员”
  • 画圆画方的故事

近期评论

  • + 1.943624 BTC.NEXT - https://graph.org/Ticket--58146-05-02?hs=9a9c6f8dfe3cdbe0074006e3e640b19b& on 所有文章
  • Anonymous on 闲聊投资:亲自体验和护城河
  • 四火 on 关于近期求职的近况和思考
  • YC on 关于近期求职的近况和思考
  • mafulong on 常见分布式基础设施系统设计图解(四):分布式工作流系统
  • 四火 on 常见分布式基础设施系统设计图解(八):分布式键值存储系统
  • Anonymous on 我裸辞了
  • https://umlcn.com on 资源链接
  • Anonymous on 我裸辞了
  • Dylan on 我裸辞了
© 2025 四火的唠叨 | Powered by Minimalist Blog WordPress Theme