05/06 发表评论

摘要:如果你是程序员,是否有类似这样的困惑——“天天写业务代码的程序员,怎么成为技术大牛,开始写技术代码?” 阿里资深无线开发专家李运华梳理了自己的思考和理解,希望帮助程序员同学少走弯路。2980字的纯干货,阅读时间需要9分钟。

image.png | left | 748x748

成为大牛:梦想很美好,现实却很残酷

不管是开发、测试、运维,每个技术人员心里多多少少都有一个成为技术大牛的梦。毕竟“梦想总是要有的,万一实现了呢”?

但很多阿里的新人,工作后就会发现,梦想是成为大牛,但做的事情看起来跟大牛都不沾边。
比如,程序员说“天天写业务代码还加班,如何才能成为技术大牛”,测试说“每天都有执行不完的测试用例”,运维说“扛机器接网线敲shell命令,这不是我想要的运维人生”。

我也是一位程序员,所以我希望通过以下基于程序开发的一些例子,用我的经验给大家一些参考。

典型误区1:拜大牛为师

有人认为想成为技术大牛最简单直接、快速有效的方式是“拜团队技术大牛为师”,让他们平时给你开小灶,给你分配一些有难度的任务。
我是反对这种方法的。

大牛很忙,不太可能单独给你开小灶,更不可能每天都给你开1个小时的小灶。而且一个团队里面,如果大牛经常开小灶,难免会引起其他团队成员的疑惑,我个人认为如果团队里的大牛真正有心,多给团队培训最好,但准备一场培训很耗费时间。

因为第一个原因,所以一般要找大牛,都是带着问题去请教或者探讨。因为回答或者探讨问题无需太多的时间,更多的是靠经验和积累,这种情况下大牛们都是很乐意的。

然而也要特别注意:如果经常问那些书本或者google能够很容易查到的知识,大牛们也会很不耐烦的,毕竟时间宝贵。

经常有网友问我诸如“jvm的-Xmn参数如何配置”这类问题,我都是直接回答“请直接去google”,因为这样的问题实在是太多了,如果自己不去系统学习,每个都要问是非常浪费自己和别人的时间的。
对于大部分人来说,要想成为技术大牛,首先还是要明白“主要靠自己”这个道理,不要期望有个像武功师傅一样的大牛手把手一步一步地教你。

适当的时候可以通过请教大牛或者和大牛探讨来提升自己,但大部分时间还是自己系统性、有针对性的提升。

image.png | center | 617x414

典型误区2:业务代码一样很牛逼

业务代码中的技术是每个程序员的基础,但只是掌握了这些技巧,并不能成为技术大牛。

就像游戏中升级打怪一样,开始打小怪,经验值很高,越到后面经验值越少,打小怪已经不能提升经验值了。这个时候就需要打一些更高级的怪,刷一些有挑战的副本了,没看到哪个游戏只要一直打小怪就能升到顶级的。

成为技术大牛的路也是类似的,你要不断的提升自己的水平,然后面临更大的挑战,通过应对这些挑战从而使自己水平更上一级,然后如此往复,最终达到技术大牛甚至业界大牛的境界。

写业务代码只是这个打怪升级路上的一个挑战而已,而且我认为是比较初级的一个挑战。
所以我认为:业务代码都写不好的程序员肯定无法成为技术大牛,但只把业务代码写好的程序员也还不能成为技术大牛。

典型误区3:上班太忙,没时间学习

很多人认为自己没有成为技术大牛并不是自己不聪明,也不是自己不努力,而是中国的这个环境下,技术人员加班都太多了,导致自己没有额外的时间进行学习。 

这个理由有一定的客观性,毕竟和欧美相比,我们的加班确实要多一些,但这个因素只是一个需要克服的问题,并不是不可逾越的鸿沟,毕竟我们身边还是有那么多的大牛也是在中国这个环境成长起来的。

阿里巴巴西溪园区的樱花

几个误区导致这种看法的形成

1、上班做的都是重复工作,要想提升必须自己额外去学习
形成这个误区的主要原因还是在于认为“写业务代码是没有技术含量的”,而我现在上班就是写业务代码,所以我在工作中不能提升。

2、学习需要大段的连续时间
很多人以为要学习就要像学校上课一样,给你一整天时间来上课才算学习,而我们平时加班又比较多,周末累的只想睡懒觉,或者只想去看看电影打打游戏来放松,所以就没有时间学习了。

实际上的做法正好相反:首先我们应该在工作中学习和提升,因为学以致用或者有实例参考,学习的效果是最好的;其次工作后学习不需要大段时间,而是要挤出时间,利用时间碎片来学习。

正确的做法1:Do More

做的更多,做的比你主管安排给你的任务更多。要想有机会,首先你得从人群中冒出来,要想冒出来,你就必须做到与众不同,要做到与众不同,你就要做得更多!

怎么做得更多呢?

1、熟悉更多业务
不管是不是你负责的;熟悉更多代码,不管是不是你写的,多熟悉业务有很多好处。

2、熟悉端到端
“系统性”、“全局性”、“综合性”这些字眼看起来比较虚,但其实都是技术大牛的必备的素质,要达到这样的境界,必须去熟悉更多系统、业务、代码。

3、自学
一般在比较成熟的团队,由于框架或者组件已经进行了大量的封装,写业务代码所用到的技术确实也比较少,但我们要明白“唯一不变的只有变化”,框架有可能要改进,组件可能要替换,或者你换了一家公司,新公司既没有组件也没有框架,要你从头开始来做。

这些都是机会,也是挑战,而机会和挑战只会分配给有准备的人,所以这种情况下我们更加需要自学更多东西,因为真正等到要用的时候再来学已经没有时间了。

正确的做法2:Do Better

要知道这个世界上没有完美的东西,你负责的系统和业务,总有不合理和可以改进的地方,这些“不合理”和“可改进”的地方,都是更高级别的怪物,打完后能够增加更多的经验值。

识别出这些地方,并且给出解决方案,然后向主管提出,一次不行两次,多提几次,只要有一次落地了,这就是你的机会。

只要你去想,其实总能发现可以改进的地方的;如果你觉得系统哪里都没有改进的地方,那就说明你的水平还不够,可以多学习相关技术,多看看业界其它优秀公司怎么做。

image.png | center | 610x426

正确的做法3:Do Exercise

在做职业等级沟通的时候,发现有很多同学确实也在尝试Do more、Do better,但在执行的过程中,几乎每个人都遇到同一个问题:光看不用效果很差,怎么办?

分享一下个人的经验,其实就是3个词:learning、trying、teaching!

1、Learning
这个是第一阶段,看书、google、看视频、看别人的博客都可以,但要注意一点是“系统化”,特别是一些基础性的东西。

2、Trying
这个步骤就是解答前面提到的很多同学的疑惑的关键点,形象来说就是“自己动手丰衣足食”,也就是自己去尝试搭建一些模拟环境,自己写一些测试程序。还有很多方法,这里就不一一列举,简单来说,就是要将学到的东西真正试试,才能理解更加深刻。

3、Teaching
一般来说,经过Learning和Trying,能掌握70%左右,但要真正掌握,我觉得一定要做到能够跟别人讲清楚。因为在讲的时候,我们既需要将一个知识点系统化,也需要考虑各种细节,这会促使我们进一步思考和学习。
同时,讲出来后看或者听的人可以有不同的理解,或者有新的补充,这相当于继续完善了整个知识技能体系。

总结:热情和兴趣才是决定性作用

成为技术大牛梦想虽然很美好,但是要付出很多,不管是Do more还是Do better还是Do exercise,都需要花费时间和精力。这个过程中可能很苦逼,也可能很枯燥。
这些其实都是方法论,但真正起决定作用的,其实还是我们对技术的热情和兴趣。

原文:https://yuque.com/alidoc/dry/tgq1bw

发表评论

回到顶端