Skip to content

四火的唠叨

一个纯正程序员的啰嗦

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

程序员懂业务有多重要?

Posted on 07/09/201810/01/2024 by 四火

Image result for complex程序员懂业务有多重要?印象中我从来都说,“很重要” 这句没有营养的废话。在许多项目中,业务才是真正驱使价值兑现(冠冕堂皇的说法,基本上意思就是 “赚钱”)的法宝,而技术实际上有诸多选择,选择某一项并无太大区别。可是,老实说,下意识地,在技术和业务难以两全其美的时候,我还是倾向于选择那些从技术角度更有趣,但是业务上显得没 “那么” 重要的项目。我不讳认这一点,但是随着这些年的经验积累,或者说经历的项目的洗礼,业务的分量已经越来越大了。

在华为的时候,我做过一些杂七杂八的项目,其中最大的一个项目是一个大型的电信门户网站,由于我参与的是基线版本的研发,定制业务少,变态需求少,扩展性、性能、可维护性这些技术层面的因素考虑更多,因而总体来看,还可以说是一个技术比重明显大过业务的项目。

来到亚马逊,换过几个 team,第一个呆的时间比较长的 team 是 Demand Forecasting(销量预测),由于团队比较成熟,组织结构无论是人员上还是代码上,解耦都做得还可以,因而我更关心的是数据的 ETL 过程、schema、版本、可视化等等这些通用而并不耦合业务逻辑的东西。我们当然有业务方面的需求,但是这个 team 的核心还是在数据上面,大量的机器学习内容,不太可能内建太多的业务逻辑,主要影响销量预测还是数据本身。但是这个团队中,我接触了不少领域知识,这是一个比较大的变化,而这部分和预测算法,以及机器学习相关的领域知识,不同于某些典型的纯业务范畴的领域知识(比如说许多医疗领域、金融领域等等),可以说是技术和业务之间的灰色地带——既有技术的部分,也有业务的部分。

接着是 Contribution Profit 这个组,计算成本和盈利。从架构和系统上和大数据更深入地打交道,却基本上没有了机器学习的内容。主要原因在于,成本和盈利情况的计算,并不,或者说基本上不需要机器学习的技术,主要还是一些复杂的统计量化的方法,包括一大堆逻辑纷繁的公式。所以从业务和技术的角度上看,每天既要从系统上和元数据角度去解决那些大数据计算存储方面的问题,又要深挖业务逻辑,尝试去理解一些数值的缘由。加上我们的工具不足够出色,许多本来应该由数据分析师(Data Analyst)来做的工作,被迫转嫁到了程序员工程师的头上。这个角度看,业务逻辑的比重已经非常大了。当时我们组的同事也可以大致上分成两部分,一部分擅长业务,一部分擅长技术。

现在来到 Oracle,在 Storekeeper 组每天的工作包含了云设备(包括 instance 等等)管理,我最初的理解是,应该说工程师主要的贡献应该是提供不同种类的工具,让 Data Center 的技术人员去使用它们来管理。但是,和上面一条的情况类似,工具不足够好用,加之我们算是一个相对比较年轻的团队,还有很多相对混乱的地方,有大量的业务问题需要工程师介入以后才能解决。比方说某些数据的修改,由于工具的缺乏,这些现场的技术人员只能给工程师开 ticket,然后由工程师去更新数据。毫无疑问,这里存在大量的业务逻辑需要厘清,每当新需求分析的时候,通常比技术层面难度更高的是以沟通和梳理业务为主的部分,去和许许多多不同的用户聊,去现场了解情况,去和不同的 team 谈,从而逐步理清思路,了解问题,给出可行的解决方案。我觉得这些事情在一个足够成熟的团队中,是很难遇到的,即是机遇,亦是挑战,很难一刀切谈好坏。

老实说,曾经业务的东西从打心眼里是远不如技术受到我的重视的,再加上我换了那么多领域,我一直觉得只有技术的东西才是持久的,业务的东西却一直在变。但是这样的观点也在慢慢改变。一个是我留意到,有一些同事能够专注于某一领域(比如说 billing 系统,做了几年,换了几个团队,甚至公司,却一直研究账单系统;再比如和我现在打交道的一位 TPM,在亚马逊、微软干过,现在来到 Oracle,都在云计算的最底层处理涉及硬件和设备的需求,考虑到本来云计算就没多少年,在这一块领域,她可以说是非常罕见的老江湖了),这一旦在进一步职业选择的时候,如果选择到了相同的领域,无疑是在经验上有很大优势的。这也促使我在这一次求职的时候所说,希望在几年后的三十五岁的时候,明确一个大致上希望精进的方向。也许未来的新业务难以预测(比如哪怕就在五年前有谁能知道区块链居然能火成这样?),但是有一个大致熟知的领域为根基去伸展枝叶,会比一直没有清晰的门路强。当然,我不觉得之前的各个业务领域的积累是浪费,毕竟,眼界不只取决于深度,还取决于广度。

程序员工程师,毕竟主要做的是工程,不是研究。和生活更紧密,和实际问题更贴近,因而有大量的非技术问题和知识需要把握。入职以后,今年给自己的一个小目标,就是想提高包括沟通和业务理解在内的软实力,一定程度上也是我的短板。业务本身兴许未来能用到,更多的可能是用不到,但是对于业务和技术两条腿走路的多数程序员来说,瘸了哪一条都显得受限许多。

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

×Scan to share with WeChat

你可能也喜欢看:

  1. 再议单例模式和静态类
  2. 不要让业务牵着鼻子走
  3. 从 DCL 的对象安全发布谈起
  4. JavaScript 实现继承的几种方式
  5. 系统设计的典型分层和涉及的知识点

1 thought on “程序员懂业务有多重要?”

  1. Jesse says:
    09/03/2018 at 8:36 AM

    技术为业务提供服务,业务促进技术的变更,互相成就。

    Reply

Leave a Reply to Jesse 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 框架源码解析
  • “ 你不适合做程序员”
  • 画圆画方的故事

近期评论

  • Ticket: TRANSACTION 1.922915 BTC. Go to withdrawal >> https://yandex.com/poll/enter/BXidu5Ewa8hnAFoFznqSi9?hs=20bd550f65c6e03103876b28cabc4da6& on 倔强的程序员
  • 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 资源链接
© 2025 四火的唠叨 | Powered by Minimalist Blog WordPress Theme