大家在寻找的高级程序员到底是什么样子的?

你好,我是Z哥。

这篇文章主题很简单,就是一个很常见的话题“什么是高级程序员?”。

文章稍微长了些,但是很容易阅读。

我们的中国文化,对“面子”看的特别重,所以你会发现身边到处都是高级XXX,听着倍儿有面子,程序员也不例外。

但是你真要问每个人,你认为的高级XXX是什么样子的。估计每个人都有不同的回答。

我还记得在我刚开始从事编程工作的时候,对坐在边上不远的那位我心目中的高级程序员的印象是:

工作至少有6、7年以上,能写一个用起来很方便、看起来很牛逼、但是不太容易让初级人员看懂的框架。

前两天,我把这个问题丢到群里,大家给出的答案中,占比最高的是以下几个。

  • 有 N 年以上编程经验(大部分都说5年以上)

  • 有出版过技术图书

  • 对某领域内对常用框架原理有了解,并且实际使用超过2年

  • 可以随时随地快速写出常见的一些算法

  • 至少封装过一个被全局使用的开发框架

  • 写出来的代码,阅读起来很好理解

  • 能带领其他人员成功完成项目



你看,这件事对大家来说就是常说的,“一千个人眼中有一千个哈姆雷特”。

不过这也正常,毕竟像初级、中级、高级这种高度抽象的词汇,想要得到一个可描述的定义与人交流,必然需要夹杂着个人的主观因素。

但是很多行业都在这么进行分类,自然有它的道理和好处。

我觉得其中最大的一个好处恰好是「主观」的附属品——「弹性」

比如,我现在想招一位高级程序员,面试的时候不管是通过还是不通过,我都有理由来解释我对“高级”的定义。如此一来,我对陌生人的判断就有了更大的「弹性」。

这其实是面试官的一种权利,也是长期以来面试者总在面试中处于下峰的原因之一。

事物总是有两面性的,我们在对陌生人弹性的同时,间接的也对内部的人弹性了,会导致内部的一些人才培养出现问题。

比如,你觉得内部的高级程序员不够,希望能在外部招聘的同时,从内部也培养一些出来。但是此时,你又面临了需要定义什么是“高级”的问题。

如果没法定义一个能够达成共识的标准,又如何指导培养的方向呢?只能是一句空话。

长期以往会导致更严重的问题:真正的高级程序员不够,只能让中级程序员顶上。顶替的时间长了,会让一些中级程序员误以为自己已经达到了高级水平

在我平时的面试中,这样的案例屡见不鲜。网上流传的工作10年 = 1年重复10次的段子是真实存在的。

下面我来聊聊我对「什么是高级程序员」的个人看法,欢迎你和我一起探讨。

不管是什么行业,什么岗位,在这个高度分工协作的现代社会,所需的能力主要分为三个维度。

  • 专业能力

  • 连接能力

  • 领导能力

我对程序员在这三个维度的理解大致是以下这个样子。

640?wx_fmt=png


先卖个关子,文章的最后我会将这三个维度组合起来,你会发现一片新的天地。

根据这三个维度的水平差异,我们对初级程序员、中级程序员、高级程序员做一个简要的描述。

01初级程序员 - 知道有事要做

处在初级阶段的时候,我们的精力大多只会专注在专业能力的提升上。这个时候「领导能力」和「连接能力」是很弱的。

所以,这个时候哪怕你有强烈的好奇心也无法很好的表达出来,大多只能被动的接受工作安排。

在这个时期做事情需要依赖一些教程、文档,只能“依样画葫芦”,几乎不能在不借助外部信息的情况下解决之前从未遇到过的新问题,所以百度、Google就成了他们唯一的选择。

你可以在你的身边观察一下,如果经常有以下这些场景出现,大多是初级程序员的表现。

  • 很难提出正确的问题,大多会直接问别人这个功能应该怎么做。如果你清楚地向他解释,他就会完全按你说的去做,甚至你写的示例代码都会copy过去。因为在他们的世界里,只有编译成功和编译失败,任务完成和任务未完成。

  • 经常犯错误,所以会预留过多“弹性时间”,以便有时间在到期日之前重做。所以总会抱怨“没时间”。

  • 对与自己有工作交集的人员的职能没有认识。比如,对测试人员总是充满敌意的,因为他们发现了错误,“阻碍”了自己完成工作。

  • 还没注意养成一些好习惯,比如习惯性的提炼重复代码、编写风格一致的代码、自测等等。

很遗憾,看似很初级的阶段,并不只是刚踏入工作的程序员所属,在实际工作中,也有不少工作多年的人还处在这个阶段。

02中级程序员 - 知道如何做某事

对人群按照单一维度进行划分,大多数时候都是符合正态分布的,这里也不例外。中级程序员是我们身边最多的,包括那些不得不穿上高级程序员马甲的中级程序员。

在这个阶段,有些中级程序员开始具备了一定的「连接能力」,但并不是所有人,主要看是不是拥有了「共同体意识」。

在专业能力上,中级程序员已经明白了一定的「整体与局部」的概念,但仍然看不到整个“森林”,大多局限在某个模块、流程上。比如,他们会想“这是做敏捷的正确方式吗?”,但不会考虑“这对整个团队、整个公司会产生什么实际的影响?”。

他们开始注重代码质量,因为担心低质量的代码会影响他们视野中的“整体”。

但是对于质量的理解还是比较单一。比如,这个时候你会经常听到他们把「性能」挂在嘴边,在他们心目中「性能」的地位是至高无上的,总是想着你这个方案和我的方案哪个性能更好。

同样可以观察一下周围,中级的开发大多数会这样做事。

  • 针对一个问题,可以提出多个方案,但是无法做出准确的决策。一旦更权威的人给出了他的选择,中级程序员就会不假思索的按照建议执行。

  • 可以看出代码中的一些设计模式,但是自己写代码的时候除了单例和工厂,其它的几乎想不到。

  • 在讨论一些时髦的框架和技术的时候总能聊上几句,但是追问这个框架或者技术有什么缺点,基本说不上来。甚至,草率的在项目中运用上这些时髦的框架和技术,最终导致线上问题频发,不得不让高级程序员来收拾残局。

  • 能够对自己完成任务所需的时间有准确的评估,但是评估他人的时间不会因人而异,也会以自己作为标准来评估。

  • 对与自己有工作交集的人员的职能有了一定的认识。比如,会主动寻求测试的配合,帮助自己交付更高质量的项目。

其实这个阶段是最危险的阶段,因为最可怕的不是无知,而是一知半解。心理学中的邓宁-克鲁格效应(The Dunning-Kruger Effect)讲述的就是这个问题。

两位社会心理学家在1999年做的4项研究,证实了下面的这个曲线的存在。

640?wx_fmt=jpeg

在这种状态下,人最容易高估自己,这也是很多导致产生很多“假高级程序员”的原因所在。

03高级程序员 - 知道必须做些什么

高级程序员在「专业能力」、「连接能力」、「领导能力」这三个维度都有所建树。因为他们不但可以把从1到100的事情做得很好,也有能力带领其它人完成0到1的事情。

根据我身边所接触的程序员群体来看,我所认为的高级程序员,他们明白没有什么是完美的,相反,问题、缺点和风险总是存在的。

他们的决策总是站在为了整体的「平衡」角度去考虑,而不是技术的酷炫或者外界流传的所谓“正确的”技术。

他们会更多的关心那些不显而易见的东西,如可维护性,可扩展性,易阅读,易调试等等。

高级程序员就好比社会中的成年人,他们踩过足够多的坑,也填过足够多的坑,已经认清了现实的残酷,寻求适合而不是完美。周到、务实、简单,是他们做事的时候强烈散发出的“味道”。

可以根据下面的这些场景来看看你身边有多少“有味道”的高级程序员?

  • 与初级和中级程序员不同,他们抛出问题不是为了正确的做事,而是做正确的事。他们会询问为什么要这样做以及你想要实现什么。当你告诉他们目标是什么后,他们或许会通过暗示这种方式是错误的而另一种更好来做出一些修正;当然,更重要的是还会提供论据说服你。

  • 因为提前明确了做事的目标,所以在动手做一件事的过程中,他会在关键细节思考有没有更好的方法,甚至是那些不在之前的讨论范围的新尝试。

  • 他可以轻松地承认他不知道什么,并且向你请教。同时也可以轻松地向他人讲清楚他所知道的事情。

  • 他们理解合作的人员的职能的作用,不但知道什么时候向谁寻求帮助,还知道自己如何更好的帮助他们。

  • 困难的事交给他们很放心,因为他们擅长的不是某种技术,而是解决问题的能力。他们总能解决那些之前从未遇到过的新问题,哪怕它们很困难。

那么,怎么做有助于我们成为高级程序员呢?

01关注技术之余还要关注业务

为什么把它放第一点,因为我觉得这点最重要,是其它项的基础,也最容易做到。但是很多程序员不愿意去做。

一定要搞清楚业务目标,不搞清楚不开工。相信我,只要是一位合格的leader,一定会不厌其烦的和你说清楚的。

然后要习惯基于业务目标去分析可能会面临的技术挑战。比如,多少流量,涉及哪些用户角色和功能,复杂度有多大等等。

再带着下面的「不可能三角」去寻找合适的技术框架、解决方案。尽可能的寻求最优的平衡,而不是走极端。

640?wx_fmt=png

如果拿捏不准,可以将多个方案各自的优缺点罗列出来,向Leader寻求建议。

02“设计”代码而不是“写”代码

一般人可能拿到需求,就开始写代码了,写着写着由于页面功能越来越多,感觉代码越来越复杂,自己都会觉得难以维护了。

虽说要做好设计离不开大量的实战经验的积累。但是还是有些方法可以让塑造这个能力的过程更快一些。比如,

  1. 首先就是前面提到的第一点,多关注业务。不了解业务,你啥都设计不出来。或者把马设计成了驴……

  2. 如果某个功能的开发/修改,以“天”为工时单位,一定要先画图。具体画什么图,可以参考我之前写的文章:。

  3. 搞明白每个设计模式的特点和适用场景,注意,不需要把代码怎么写背下来。只要你每次写代码之前扫一眼设计模式的列表,看看有没有适用的。如果有的话,再去“依样画葫芦”按照设计模式去实现,经过时间的积累,慢慢地,你真正掌握的设计模式就越来越多了。这有助于锻炼你的设计能力。

03“接”需求之前会先“砍”需求

要做这点还得依赖于第一点,否则,你提出的“砍”需求建议大多是不会被采纳的。

很多人在听需求讲解的时候,思考的是,这个功能能不能实现、怎么实现、难不难。大多数的提问也是基于这个思路展开的。

可能也会提出“砍”需求的问题,但是理由大多是这个实现起来太麻烦了,这个没法实现之类。

其实只要你时刻保持着“做这个需求的目的是什么”这个问题去思考,“砍”需求会变成一件更容易成功,而且自然而然的事情。

04解决一类问题而不是一个问题

很多人觉得,每天看到bug清完就万事大吉了。哪怕同一个问题在生产环境出现多次,最多也就说一句“不会吧,怎么又出问题了”。

这种对待问题的方式只会让你越来越忙,因为你的解决问题效率与投入的时间多少是成同比变化的。

我们要习惯于解决掉一个bug之后,想一下能否通过什么方式找到现有代码中的同类问题,并把它们处理掉。

甚至是考虑有没有什么办法能够一劳永逸的避免此类问题再次发生,比如封装一个SDK或者写一个组件,尽可能用一种低侵入的通用方式将问题扼杀在摇篮里。不但让自己轻松了,也造福了大家。

05遵循KISS原则,写尽可能简单的代码

KISS 原则:保持简单,愚蠢(Keep it simple, stupid)。

不单单是程序员,任何化繁为简的能力才是一个人功力深厚的体现,没有之一

越简单,越接近本质。就好比,有的人要用长篇大论才能讲明白一件事,而有的人只要做一个形象的比喻你就懂了。

这个「简单」指的是整体的简单,而不是通过局部的复杂让另一个局部简单。比如,为了上层的使用更加傻瓜化,底层封装的代码错综复杂、晦涩难懂,这并不是真正的“简单”。

如果你自认为已经是一个中级或者高级程序员了,那么你回头去看看自己还是初级程序员那会写的代码,就会很容易发现一些显得冗余的代码。

第二点提到的——「“设计”代码而不是“写”代码」对做好这点有很大的帮助。

06选择忍受某些问题

在人工智能还不能代替我们coding之前,我们永远要亲自面对无穷无尽的、这样那样的问题。

然而,任何事物都有两面性的,一个方案在解决一个老问题的同时,总会带来新的问题。所以,我们一定要意识到,忍受某些问题是必然的。

那些你现在看起来很傻逼的设计,可能就是当时的人做出的妥协。

所以,既然如此,你更应该考虑的是,当前的这个问题现在到底有没有必要解决?值不值得,为什么之前没去解决?它是不是你当前所有待解决问题列表中优先级最高的?

07打造自己的“T型”专业技能

可能很多人都听过“T型人才”的概念,我们程序员在专业技能的打造上也适合用这种模型。

但是对于“先竖再横”还是“先横再竖”可能不同的人有不同的看法。

我的观点是,大多数情况下,先竖再横。特别是某个技术、领域发展的越成熟,越应该如此

因为很多事物的本质是一样的,所以对某一个领域达到非常深入,洞察到一些本质的东西之后,对其它相邻的领域有触类旁通的效果。可以加速自己在「广度」上的扩展。

不过,「广度」也不是说蜻蜓点水,只知道最表象的“它是什么”。我认为比较合适的程度是,可以不用清楚某个技术具体的使用方式,但得知道它可以解决哪些问题,以及使用成本和潜在的风险,我将这些信息概括为“它怎么样”

08构建自驱动的“闭环”

很多人都知道闭环的概念,但是它的重要性和价值往往被低估。因为人总是短视的,“聚沙成塔”之类的方式总是不受待见。

常规的搭建一个闭环的过程大多是这样的。

640?wx_fmt=png


这里所说的自驱动的“闭环”是这样的。

640?wx_fmt=png

如何才能变成这样呢?只要做一件事,尽可能多的对外输出自己的知识

举个我自己的例子,我在2015年那会在项目中开始引入领域驱动设计,并且不断的在内部进行分享它的好处,慢慢地越来越多的项目开始往这个方向走。

因为前期的不断分享,所以在组织内部,别人对我的人设多了一个“DDD专家”的标签,那么大家遇到有关DDD的问题就会来和我一起探讨。

越到后面,我已经不用自己主动去寻找这个领域的知识去学习了,因为接收到的外部反馈已经足够多了,它们能够倒逼我往前走。并且这些反馈都是实际的真实场景,此时的信息获取和学习自然能达到「学以致用」的效果。

说实话,有不少人并不是这么想的,他们想的恰恰相反:“为什么每个人都在问我问题!你自己去学习吧!”。

所以,当你遇到其他人来请教你的时候,如果恰巧这是你所关注的领域,那么应该去拥抱这个问题而不是排斥它。因为你是团队里最权威的人,这是你构建自驱动“闭环”的好机会。错过这一回,下一回不知道得等多久。

前面文章里说到,我会将「专业技能」、「连接外部的能力」、「领导力」三个维度组合起来给你看。就是下面这个样子。

640?wx_fmt=png


你会发现这里面包含了程序员在进阶后的几个常见岗位。

可以对号入座一下:D

好了,我们总结一下。

这篇我先和你聊了一下在大家眼中高级程序员是什么样子,发现没有特别统一的标准,都是模糊的。这也体现在了几个现实的场景中,比如招聘高级程序员、培养高级程序员上。

其次,我对初级、中级、高级程序员的特点分别阐述了自己的观点。

然后,给出了一些帮助大家往高级程序员靠拢的实践思路。

希望对你有所启发。

最后,用Martin Fowler的一句话作为结尾:“任何傻瓜都能写计算机能理解的代码,优秀的程序员编写人类能够理解的代码。”

Any fool can write code that a computer can understand. Good programmers write code that humans can understand

Martin Fowler

希望看到这篇文章的每个程序员最终都能成为头发茂盛的码农:D

640?wx_fmt=jpeg

原创不易,如果你觉得这篇文章还不错,就「在看」或者「分享」一下吧。鼓励我的创作 :)

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/313605.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

优秀的程序员是那种过单行线马路都要往两边看的人

最近一周帮我以前一个同事推荐工作,顺便了解下行情,我这个同事我感觉还行,技术不说有多好,但是往年绝对不至于简历筛选时被刷掉那种,最先开始推给了一个我比较信任的HR手里,她兼职猎头,推给这个…

【为自己相亲】单身小姐姐你在哪里,我是书豪,我在等你

笔者简介Introduction书豪:【人工智能爱好者社区】公众号负责人《R数据科学实战:工具详解与案例分析》书籍作者。 你没看错这是书豪在给自己寻觅良缘如果你有,或者身边的朋友有兴趣请与我联系基本信息 出生日期:1995年5月身高&am…

知道的越多,越感觉自己渺小

作者:猛哥,关注技术和人文发展的程序员,架构师社区合伙人芝诺说:“人的知识就像一个圆,圆圈外是未知的,圆圈内是已知的,你知道的越多,你的圆圈就会越大。圆的周长也就越大&#xff0…

.NET Core 3.0 System.Text.Json 和 Newtonsoft.Json 行为不一致问题及解决办法

行为不一致.NET Core 3.0 新出了个内置的 JSON 库, 全名叫做尼古拉斯 System.Text.Json - 性能更高占用内存更少这都不是事...对我来说, 很多或大或小的项目能少个第三方依赖项, 还能规避多个依赖项的依赖 Newtonsoft.Json 版本不一致的问题, 是件极美的事情.但是, 结果总不是不…

Java9 新特性

在介绍 java9 之前,我们先来看看java成立到现在的所有版本。 1990年初,最初被命名为Oak;1995年5月23日,Java语言诞生;1996年1月,第一个JDK-JDK1.0诞生;1996年4月,10个最主要的操作系…

深入探究Kubernetes - 初识容器

♥2019年8月28星期三第47篇原创引言最近Kubernetes比较火,新技术快速火起来,一定有它强大的优势,Hr反馈,招聘时会Kubernetes的很少,风口上的Kubernetes一起学学?扫盲贴,参考《Kubernetes进阶实践…

Java11 新特性

Java 11新特性的详细解释。JDK 11已经于 2018年9月25日正式发布,那么Java 11主要包含哪些新特性呢? JDK 11是Java SE 11平台版本11的开源参考实现,由JSR 384在Java Community Process中指定。 阿里巴巴是中国唯一的JCP委员会成员公司&#x…

福爆 | 博客升级 .NET Core 3.0 又踩一坑

点击上方蓝字关注“汪宇杰博客”导语昨天刚发了一篇《生产大爆炸发生问题的是已经被删除的博客文章,正常情况下,这些不存在的文章会直接显示自定义的404页面,但实际上产生了500异常。日志如下:2019-09-26 00:11:50.8405|RD00155DB…

Sping5——响应式编程

1、响应式编程基础 1.1、什么是响应式编程? 响应式编程是一种面向数据流和变化传播的编程范式。 使用它可以在编程语言中很方便地表达静态或动态的数据流,而相关的计算模型会自动将变化的值通过数据流进行传播。我们可以使用声明的方式构建应用程序的能…

.NET Core使用NPOI导出复杂Word详解

最近使用NPOI做了个导出Word文档的功能,关于使用.NET Core 导出Word文档的方式有很多。最终我为什么选择了NPOI来实现了这个功能,首先是NPOI是一个开源,免费且容易上手的第三方框架(并且现在已支持.NET Core,GitHub源码…

Spring Boot 2.0新特性

Spring Boot依赖于Spring,而Spring Cloud又依赖于Spring Boot,因此Spring Boot2.0的发布正式整合了Spring5.0的很多特性,同样后面Spring Cloud最新版本的发布也需要整合最新的Spring Boot2.0内容。 一、新版本特性 1.1,基于 Jav…

为了不让代码“作恶”,能否将道德条款纳入开源许可证?

随着特朗普政府反移民政策的执行,成千上万的移民儿童与父母分离,美国移民和海关执法局(ICE)也因此成为众矢之的。所以,当开源开发者 Seth Vargo 发现前东家 —— Chef 公司最近与 ICE 签订了合同后,进行删库…

dump获取与分析

一、dump基本概念 在故障定位(尤其是out of memory)和性能分析的时候,经常会用到一些文件来帮助我们排除代码问题。这些文件记录了JVM运行期间的内存占用、线程执行等情况,这就是我们常说的dump文件。常用的有heap dump和thread dump(也叫ja…

dump分析死锁

1、制造死锁场景 一段死锁程序 public class DeadLock {public static Object lockA new Object();public static Object lockB new Object();public static void main(String[] args) {new ThreadA().start();new ThreadB().start();} }class ThreadA extends Thread {Ove…

用 C# 来守护 Python 进程

背景目前我主要负责的一个项目是一个 C/S 架构的客户端开发,前端主要是通过 WPF 相关技术来实现,后端是通过 Python 来实现,前后端的数据通信则是通过 MQ 的方式来进行处理。由于 Python 进程是需要依赖客户端进程来运行,为了保证…

针对媒体不实报道误导大众--抹黑C#工资垫底

近注意到一些媒体故意抹黑C# 工资垫底,参见 https://www.toutiao.com/i6741889572931633668/:通过搜索引擎搜索《编程语言薪酬排行:Python薪资最高,Java第二,C# 垫底》:早在2018年就出现这样的标题内容,还是CSDN公众号…

程序员你写的代码,被人挖出了黑产

事件经过看了微博上发表转发1000 、点赞1000次的吐槽陕西省的普通话成绩查询网站代码的微博,后来知乎上又有20万的阅读量这个话题的提问。最终结案这并不是真的陕西省普通话成绩查询网的网址,只不过是和官方查询一样的界面,李鬼”网站&#x…

Java垃圾回收日志解析

1.开启垃圾回收日志 在运行一个java程序时可以在命令行中加入相应的JVM垃圾回收参数,获取程序运行时详细的垃圾回收日志信息。以下是一些大概的参数: -XX:PrintGC与-verbose:gc 这两个命令效果都是一样,打印最基本的回收信息 -XX:PrintGCDe…

感谢有你们,架构师修行之路!

感谢有你们转眼马上就十月一了,听说今年的阵势非常强大,菜菜虽然身在北京,但是可能也目睹不了这个激动时刻了。自从2018年年底决定开始写公众号以来,几乎每个周末都在构思文章,撰写文章。关注公众号的老粉丝应该知道&a…

自定义构建基于.net core 的基础镜像

先说一个问题首先记录一个问题,今天在用 Jenkins 构建项目的时候突然出现包源的错误:/usr/share/dotnet/sdk/2.2.104/NuGet.targets(114,5): error : Unable to load the service index for source https: /usr/share/dotnet/sdk/2.2.104/NuGet.targets(…