查看原文
其他

艰难的这年,程序员的未来在哪里?

程序人生 2020-10-29

The following article is from 大飞码字 Author 大飞码字

作者 | 大飞码字
来源 | 大飞码字(ID:BigFly1024)

大部分技术人,在职业发展的后半段,会触及发展的瓶颈。面对这种瓶颈,大部分人是想通过提高技术来突破。对这个问题,我结合自己的经历说说自己的一些思考。



大学的时候,我特别喜欢编程,用 “痴迷” 来形容也不为过。毕业工作后,也对技术有着近乎偏执的执着,觉得只要技术高到一定水平,就能够搞定所有的事情。

毕业第一年,过得蛮焦虑的,当时压力很大,老担心工作做不好。

不过我有一个好的行为模式:越是担心,越是努力。所以第一年的时候,我看了不少技术书籍,也继续看了不少 linux 内核的源代码,期望通过技术的提高,解决工作问题,最后消除焦虑。

但事与愿违,我的第一个考核拿了一个B,就是那种不好也不差的水平。

我当时很不解,后来我 leader 找我谈话,具体的内容记不清了,但我记得他当时跟我说,不要花太多时间看 linux 的源代码,要多花时间在业务代码上。

我当时听了,觉得 leader 不重视技术,很长的时间里,我一直很反感他说的那段话。



接下来的5年,我一直在基础架构部门,从事底层框架和存储相关的工作,直到14年,我才转调到了业务部门,开始真正意义上接触业务。

而直到这几年,我才慢慢转变了 “纯技术” 思维的想法。

互联网公司,无论国内国外,除了极少数技术驱动的公司,绝大部分的公司都是业务驱动的,或产品,或商业。

这个道理我很早就懂了,也很早就接触到了,但一直没有深刻的思考过,这意味着什么。

我估计很多人都没有思考过,特别是对于工作不满三年的新人。

我想大部分人都会有 “只要技术牛B” 就可以通吃一切的信念!

直到这几年,我才从更高的层次,理解了技术在整个商业体系里面的价值和技术人员的价值。

其实,目前根本就没有所谓的纯技术公司,更加没有纯技术驱动的公司,但是有技术人员主导的公司。

这两者是有着本质的不同的。

技术人员,大部分设想的是,我只要 “技术牛B”, 就可以通吃一切,这是 “纯技术” 的思想,但 “技术人员主导” 跟 “纯技术” 并不是等价的。

正确的理解,应该是技术 + 业务,是的,技术人员除了掌握技术,还要深刻理解业务。

也只有通过对用户,对商业的理解,将技术转化为实际可用的产品的公司,才有可能最后存活下来。而在公司内部,这种人才也是最值钱的。

技术能力不容易培养,需要个人花费很多的时间,精力,甚至还要有一定的天赋,而业务的敏感度,商业思维,一点都不比技术能力来的容易,很多时候比技术能力更难培养。

因为实际的能力都要来自实际项目的历练,无论是技术还是业务,相比成功的技术项目,成功的产品项目其实更少,更加难以获得。

这也是一些知名产品的员工在招聘市场上大受欢迎的原因 --- 因为有过成功的技术经验和业务经验。



这几年招过不少毕业生,也带过不少毕业生,大部分毕业都有对技术的执着,我觉得这个是好事。

不过有些毕业生对技术的执着过了头,太过于抵触 “技术含量低” 的工作,其实这种抵触是相当不利于个人发展的。

除非你未来做学术研究,要不你一定会接触业务,而且不单只是接触业务,你后面还会发现,决定你技术成长快慢的也是业务。

遇到一个高速发展的业务,一个高速扩张的团队,真的是技术人员的福音。

因为发展快,遇到的问题就会特别多,需要解决的问题自然也特别多,这个时候,个人只要能够扛下来,技术能力,综合素质都会有飞快地提升。

微信的早期,就是这么一个项目。在微信取得成功后,我记得当时的技术总监提了一个问题 :“是技术成就了产品,还是产品成就了技术?”

有人可能会对前半句嗤之以鼻,觉得怎么是技术成就了产品?

而实际情况是,当时微信跟米聊抢市场,最终取胜,跟技术是有莫大关系的,因为微信的系统更稳,产品迭代速度更快,这些都跟技术强相关。

因为有了坚固的基础架构,所以系统稳;因为软件层面的复用做的更好,所以迭代更快。(当然这些都是相对当时的米聊,现在回头看,当时也确实存在很多的问题)

产品成就技术,大家可能就更难以理解了。

而实际情况是,微信产品的快速发展,催生出了一些独特的软件开发理念,比如小步快跑,快速试错。这些在现在看来,大家熟知的理念,在当时都是很新颖的。

为了达到又快又稳的产品效果,技术上做了很多的创新和改进。包括业务架构设计的创新,基础软件,如存储系统,RPC框架的创新等,都是业务发展催生出来的产物。

所以说产品成就了技术,也是有道理的。

我觉得答案是:技术和产品互相成就了彼此。

公司如此,产品团队如此,我觉得个人也是如此的。

一开始的新人,都是接任务,按需求做方案,随着技术能力的提升,个人的工作职责,会慢慢从 “怎么做” 过渡到 “做什么”。

你得先会解决问题,当你能够熟练地解决问题后,你就要开始学会 “提出问题”。

真正的技术大拿,一定都是 “提问题” 的高手,而这种提问题的能力,纯有技术是不行的,一定是在技术能力扎实,并深刻理解业务的基础上,才能够提出的。

多年之后,我终于明白了,第一年,我的 leader 跟我说那句话的初衷。我需要学好底层技术,但同时也要花时间在业务逻辑,业务代码上,两者是相得益彰的。


最后


技术人员,早期的时候,花费更多的时间在技术的淬炼,成长上,是正确的,但当技术达到一定的水平,一定要开始关注业务,不要无视甚至抵触业务。

你对业务的理解越深刻,你就越容易看到业务的问题。提出问题,并用自己的技术能力解决问题,才能真正将你的技术能力转变成生产力,你也才会成为真正意义上的技术大拿!

作者:大飞。十年互联网人,资深架构师,技术 leader。


更多精彩推荐

全国程序员工资最新统计来了,平均 14,542 元!

老师,你确定Java注释不会被执行吗?

华为副总裁回应应用删除用户图片;美国拟允许华为参与 5G 标准建设;Firefox 76.0 发布 | 极客头条

蚂蚁金服高要求的领域建模能力,对研发来说到底指什么?

一文看懂主流区块链攻击底层逻辑 | 博文精选

饿了么交易系统5年演化史

你点的每个“在看”,我都认真当成了喜欢

    您可能也对以下帖子感兴趣

    文章有问题?点此查看未经处理的缓存