1.5 从程序员到工程师

简介: 1.5 从程序员到工程师

程序员和工程师这两个词,经常出现在我们的视线里,我接触过的很多人也会把这两个词等同起来看待。包括看到的招聘广告里面,大部分招聘的title是工程师,即使我们入职后,公司给我们的职位名称也是叫,java工程师,C++工程师,Qt工程师等,这些信息使我们常常会将工程师和程序员这两者混为一谈。

但在我看来,工程师和程序员是两个完全不同的概念,程序员是代码实现者,而工程师所负责的内容或考虑的事情都是从整个软件工程角度出发的,所以两者是有本质的区别的。工程师就比如建造一座大楼的总工程师、水电工程师、测量工程师、土木工程师等等,而程序员就是建造这栋房子的泥瓦工,水电工等。

在我去过的一些公司,和他们技术交流后,其实他们只是程序员,他们只熟悉自己负责的部分,对于系统从哪里来,整体都有哪些部分,产品的定位及发展基本是属于真空地带,所以本节我就讲讲我对工程师的理解。


工程师应具备的四大技能

1 会写方案

有人曾问过我,如何能快速提高自己的技术,增加自己的经验,达到架构师的水平。我给他三个字“写方案”。通过写方案,能够让你想清楚事情的来龙去脉,整理现阶段所拥有的资源,梳理自己的思路,从系统的角度出发去思考问题。

当方案写出来后,一定要把所有相关人员聚集在一起进行评审,否则写的方案就是没用的,不够全面的,只会陷在自己的思维框架里出不来。让其他不同背景,不同思维,不同需求的人参与进来,这会让你的方案更全面。

既然方案要评审,那你写出来的方案一定是清晰易懂的,能让不了解该背景的人能够快速理解,这样写的方案才算过关。别人无法快速理解的方案是失败的,说明自己就没有把事情想清楚。想让人快速理解你的意图,绘制流程图,导图等图形方式是必不可少的,所谓一图胜千言说的就是这个。所以我们要提高自己的绘图能力。

当你经历过至少50个方案后,我相信你的设计能力已经超过其他人数倍了。看待问题的角度会有自己的思维体系和认知论,能够以系统认知的方法来认识和解决问题,此时你会产生一种因使用系统方法解决问题而带来的一种兴奋感,而不是直接拍脑袋做决定的那种焦虑感。

说起方案怎么写,我一般看一个方案就会看他的前三个标题,好的方案要包含以下三个标题,从这三个标题里面,我能够快速掌握本方案的核心诉求及解决方法,能够把这三个方面写清楚的,方案已经至少成功一半了。

1)背景

2)问题

3)目标

所谓背景,就是要将当前的业务情况进行说明,将这件事情所处的环境进行简要概括。就像物理中水的沸点100℃,前提是要在1标准大气压下才成立的。而脱离了1标准大气压这个前提条件,沸点100℃是不成立的。所以这里所说的背景就是要将这个前提说清楚,这样我们定义的问题才会成立,才是有意义的。

所谓问题,你要将目前遇到的问题通通都列出来,然后进行分类,哪些是主要问题,哪些是次要问题,哪些是紧急问题,哪些是长远问题,在识别清楚问题之后,才能对症下药,才能有行之有效的办法解决问题。所以我们对于问题空间的定义一定要清晰明了,否则方案的方向就是错的。对于相关的问题,一定要有相关的数据支撑,有详细的统计分析,这样我们才能有效识别真正的问题是什么。

所谓目标,是我们做了方案后,要达成的一个目标,有了这个所有评审的人才知道努力的方向,思考的方向,否则大家坐在一起就是你一句我一句没有重点,最后评审会开完没有任何收获,大家又产生了更多新的问题,这些问题导致方案编写者抓不住重点,往往还需要花费更多的时间和精力来重新整理方案。

对于大的方案,往往要经历3轮左右的评审才能够进行落地,好的方案能够帮助开发者屏蔽掉不确定性,大家可以目标一致的朝着某个方向进行落地开发,所以我们一定要谨记,前期方案一定要认真评审设计,所谓好事多磨。我看到过太多的草草出个方案,然后快速进入开发阶段的团队了。一旦出现问题,那就是大问题。

对于工程师,要明确懂得设计与执行的投入是完全不对等的。设计可以很快推翻进行再设计,而到了执行阶段,想要推翻重来那代价就是巨大的。有的项目甚至需要花费以年为计时单位的时间来重新设计臃肿的旧框架,更有甚者由于前期的设计问题,最终导致公司破产。新老客户的迁移也是个痛苦的过程。


2 系统思维,经济实用

工程师在考虑一件事情时,从不会忽视这件事情所带来的损耗或经济效益,他会有一个确定的方案来支撑他的想法,他的思考是全面系统的。

我们公司前一阵来了一个架构师,他对技术有着很深的理解,在看了我们前端所暴露的一些问题后,他制订了一套升级方案。在评审过后,我能看出他技术的确不错,但在他的方案里面,缺少了一项,那就是确定的经济成本。方案中没有相关数据做支撑,只是笼统的说某个框架升级后会提升编译速度,统一各个前端的编码习惯,有更多丰富的库来使用,bug会比以前变少,总之一堆说这个框架怎么怎么好的结论。而这些都是很模糊的概念,没有相关的数据和测算方法。那这就会让公司领导摸不着头脑,给他很大的恐慌感,他并不懂技术,而所有前端底层都要进行替换,付出的成本是巨大的。试想,领导怎会同意这样的做法,怎会分配足够的资源。如果最后没做好,前端架构师可以一拍屁股走人,而老板就是血亏,甚者导致公司破产。所以要有一个确定的经济效益,这样我们才能取得老板的信任,保证项目顺利进行。

百度原产品副总裁曾提出这样的公式:

用户价值=新体验-旧体验-替换成本

从这个公式里面我们可以得出这样的结论

1)最大化新产品体验

2)最小化旧产品体验

3)最小化替换成本

同样,工程师在做一件事情,也是要考虑这三个方面的,在实际中很多人会忽略考虑替换成本,这是一项大忌。举个例子,微信做即时通信,其实功能很简单,有很多公司也可以做,如强大的阿里也想做即时通信,之前过年支付宝互相加好友活动想撬走一部分用户,阿里砸了那么多钱,最终还是失败告终。究其原因是微信用户所有的人脉,圈子都在微信,你想要把它的用户抢过来,就要帮助用户减少这些切换成本,而实际上是无人能做到的。再比如,现在的华为手机免费提供的云盘服务,它就是要将我们的照片,个人文件都存下来放在云端,如果我们哪天想换其它品牌的手机,那对不起,你的切换成本将非常高,需要把云端的文件全部迁移走,最终你只能妥协,还是继续使用华为手机。

所以工程师在做一件事情时,一定会从系统,从经济,从价值的角度去思考问题,而不是简单的升级技术。

有时候,我们可能会遇到一个较大的项目,跨度周期比较长,存在很大的不确定性,这个时候我们就需要一套快速验证的方案或计划,我们把这个快速验证方案叫做mvp版本(Minimum Viable Product–最简化可实行产品),砍掉无用的功能,仅保留最小可用功能,能够快速投放市场,取得用户的验证,即时反馈。这样才能让我们以最小的成本得到市场快速响应,以方便我们调整方案计划,做出实用的产品。而不是我们直接闭门不出,闷头造车,自以为已经做出了伟大的产品,而实际却无人问津。

当做出mvp版本后,我们就会有最佳实践,将现有的成果和模式进行快速复制,例如旧系统的升级与迁移就需要这种快速复制的能力。


3 高效沟通

一名合格的工程师,不会埋头苦干拉车不看路的。除了干好自身的工作外,要通过各种方式增强与上下级之间的沟通,工作协同。在我们开发中,很多人性格都比较内向。不愿意开口讲话,甚至还有很多人认为大声讲话会影响到周围同事办公,这其实都是错误的观念。我所推崇的是,高效沟通,效率优先。

以下是提供几种沟通方法,优先级从高到低:

1)能当面讲的就直接讲,胜过在通信软件里面拼命打字。我比较反感虽然座位很近,但仍然使用钉钉微信这些通信工具进行讨论问题的做法,一个问题往往要持续很久才能得到解决,同时打字也是一件很累的事情,这会耗费不少的精力。对于沟通这件事情,我就很喜欢销售的作风,他们一有事情就会直接跑到我跟前,两三句就可以把事情讲清楚,节省了彼此的时间和精力;

2)通过电话或会议,有些沟通不能够当面进行的,最好的方式就是进行电话沟通,如果涉及到多人,我们可以直接进行电话会议进行沟通。让主要负责人对本次电话会议作主持,这会大大提高沟通效率,否则你只会夹在中间左右为难;

3)通过通讯软件,微信钉钉等,这种方式的沟通,我不太推荐,但却是我们日常最主要的沟通方式,如果是一些不太紧急的事情,可以使用这种方式,或是你想留下一些证据或留言,也可以使用这种方式;

4)邮件沟通,对于和外部或外部门的沟通,需要你将某件事情确定下来,作为一个里程碑式的记录,应该以正式的邮件进行沟通。邮件是一个比较正式的沟通方式,便于后期的对证和查阅,凡是需要和外部的合作,经过几轮沟通后,最后都要以邮件的形式把这件事情确定下来,分清责任,这件事不能怕麻烦要多做,如果不做只是口头上的答复你会后悔的。


4 向贵人请教

向贵人请教,这是一个非常重要的技能或提升自己的方式。在职场上你如果能遇到一个贵人,他能够给你一些指点,这甚至能够顶的上你几年的努力。想要遇到贵人,并不是完全的自己等待这样的机遇,而是要主动去出击寻找。甚至可以在论坛,线下活动中多去和这些人接触聊天,这样才能得到指点。你要给这样的人足够的尊敬,完全原地等待或是永远想白嫖是不可取的,想要得到持续的指点,维护好你和他的关系是非常必要的,适时的请他喝个咖啡,吃顿饭都是很不错的选择,要记住天下永远不会有免费的晚餐,这对谁都一样。


说了这么多,最后总结一下,程序员想要升级到工程师,就需要进行系统性的思维来思考问题,要考虑到经济效益,切换成本,用户迁移,系统稳定,数据测量,风险评估等诸多方面的内容,然后将这些思考落实到方案中,通过方案的前三问就可以讲清事实,然后请贵人评审,多和他人能够进行良好高效的沟通,这样你才会快速的成长起来,才会突破自己的瓶颈,让自己的视野更宽广。

所以如果你只沉迷技术,请多考虑一下其它方面。当我们以工程的视角去看待事情时,程序员和工程师这样的概念其实已经不重要了,而重要的是思维方式的升级,让我们更加全面的去思考解决问题。


最后就是要靠自己去行动起来,光看是永远不会有效果的。


我的公众号会专门更新一些独家干货文章,您可千万不要错过哦

微信号:小豆君编程分享 (关注后,可加入小豆君交流群进行学习交流,也可以和小豆君一对一进行专业咨询哦)

头条号:小豆君编程分享

相关文章
|
11月前
|
Oracle Java 关系型数据库
程序员做开发工作必须要考证么?
众所周知,随着信息技术的迅速发展,程序员已经成为现代社会中不可或缺的一部分。与此同时,关于程序员需要考证的话题也越来越受到关注,以及现在互联网行业内卷严重,催生了程序员继续学习的渠道。随着行业寒冬的影响,互联网行业的程序员竞争越来越激烈,也让程序员再次审视了考证提高自身竞争力的设想。那么本文就来简单探讨一下程序员是否需要考证,以及衡量程序员能力的方式是什么?
148 2
程序员做开发工作必须要考证么?
|
11月前
|
前端开发 JavaScript 算法
程序员必须掌握的技术
程序员必须掌握的技术
57 1
|
程序员
你可能没发现你只是程序员不是工程师
你可能没发现你只是程序员不是工程师
91 0
你可能没发现你只是程序员不是工程师
|
新零售 人工智能 达摩院
写在程序员日,为什么程序员都喜欢去阿里?
在连接成为所有企业战略以及用技术改变未来的今天,程序员越发重要。企业们要有对于当前及未来的社会责任,程序员则有未来实现万物互联时代的担当。一个企业是否真正重视技术,从其对程序员渴求度即可见一斑。因此,从近两年程序员的流动走向,基本上能看出企业对于技术的重视以及战略的转型。
132 0
写在程序员日,为什么程序员都喜欢去阿里?
|
架构师 程序员 测试技术
程序员加入新团队,必须知道的 20 道问题!
不同的软件开发团队做事的风格也完全不同。即使在同一家公司内,许多可变因素也会导致团队之间出现分歧。作为一名软件工程师,每当与新同事合作或开发新软件时,通常都会觉得非常兴奋。但在加入新的开发团队时,我们需要思考一系列的问题。
|
Java 程序员 API
程序员的遮羞布:这个需求技术上无法实现
程序员的遮羞布:这个需求技术上无法实现
98 0
|
分布式计算 算法 NoSQL
如果说程序员的硬通货是技术,那么软技能是什么?
程序员往往一心扑在编程技术上面,学习编程语言,算法,网络,自己子领域相关的知识等等。这非常正确,也是作为coder的核心竞争力所在,姑且称之为“硬技能”吧。 对于有一个程序员来说除了日常码代码之外,其实也需要很多编程之外的软件能,非专业上面的技能可以更好的展现你的情商,与人合作的能力等。
|
存储 算法 安全
2020年程序员/工程师必看的三本编程书籍
因为新冠肺炎疫情,很多同学都宅在家中,所以有大把的时间进行学习和充电。作为程序员或工程师的你,想要在代码方面更精进一步的话,应该看哪些书?
3671 0
2020年程序员/工程师必看的三本编程书籍
|
人工智能 安全 物联网
程序员:除了技术,还有什么更重要?
本文分享崮德老师关于危机感、结构化思考、演讲力及商业化思考方面的经验心得,希望能带给大家一些启发。
|
程序员
程序员最常见的技术性误区
සරසවි සිසුන්ගේ සැබෑ නායකත්වය හමුවේ අබියෝගයට
626 0