专注业务是否阻挡了我们获得进入高大上公司的技术牌照"?

对于这个问题来自于一个技术群友的疑惑,我们聊了一些在IT行业发展的问题,希望我能够对这个问题说说自己的看法,发个文章出来。于是拟定了这么一个题目。对于这个问题而言,很多工作不太久的人会有这样的困惑,当然我所说的是应用层开发的程序员,系统级别开发的人程序员这样的困惑较少。对于程序员而言,能进高大上的公司(比如BAT)就职,不仅仅是对其能力的肯定,并且有一份不错的收入。对于这样的大基数现象,由于供大于求,那么高大上的公司自然就要求很高,最自然就会想到两样东西,第一,基础知识(数据结构和算法等),第二,架构.(高并发,分布式缓存等).那么就对很多程序员造成了压力,因为平时程序员工作很忙,常常接触的是业务实现,大部分程序员本来就对这些基础东西或则架构要么掌握得模糊,要么使用得少。当然有非常大的难度。

基于上面的情况是不是做业务,专业务对我们进入高大上公司是阻碍作用呢?是不是我们业务剥夺了我们的技术“牌照”,让我们无法驾驶职业成长这趟快车呢?一团一团的迷惑困扰着我们,阻止我们前进的步伐,我始终觉得程序员的时间很宝贵,特备是学习的时间。所以越早走出谜团或则困惑,会带来非常大的效率提升.自然机会和薪资也进步不少.于是我想从几个方面说说一些情况.然后提出我的观点.

1.是否到了你职业的终点

如果你薪资已经达到你的预期水平,并且很难突破,这个时候应该是你找一个“靠谱”公司的停下来的沉淀的信号,如果你不想承担过多的挑战,比如创业。那么基本上可以断定,你可以好好专研公司的业务,通过的经验改进公司的业务流程,精简流程,为企业创收,那么这个时候业务才是你的主要矛盾,当然技术可以用于“怡情”,取决于你的兴趣和精力。这个时候就没有必要过多的关注技术,因为你已经快进入“准备退休”的班车,不需要过多的”牌照“。已经失去意义了。因为你不会因为风险而"挪窝"。

2.“偶遇”超级靠谱的领导

对于大部分人而言,一生有四次机会,第一,就是出生的时候,但是你没有选择的权利,第二,就是偶遇“白富美”,这样的机会对于大部分人来说等于虚设,因为没有帅的“吸银力”.第三,就是能遇到一个牛逼的人(靠谱的人)带你一起进步。这样的一定珍惜,因为什么人生几匹机遇马的事情我不相信,这样的事情太随机太偶然,其几乎为0来形容。所以我只相信我写的代码。这样对于第三种而言,我们工作假如遇到的时候,他需要你做业务,你就把主要精力放在业务上,他要你做技术
,你就是把主要精力放在技术上。这种才是配合他的需要,这个时候非常考验一个人的眼力,如果看错,那么你必须换下家,如果做出判断觉得靠谱,那么就不要多想,勇敢向前冲.当然这个时候你就和所谓的高大上公司失之交臂(当前不在高大上公司),但是没有必要,因为你就是在走向的另一个方式的高大上.第四次,就是给自己一个肯定自己的机会,这个时候你就是你的靠谱领导。然后重复第三种情况.

3.如果你是一个超级技术狂

对于这样的技术爱好者,痴迷者,那么你毫无疑问你应该追求你的技术服务于业务,因为技术就是你的生命,应该珍爱对技术的执着,那是你的全部,也是我们所倡导的,我们佩服的牛人。因为整个行业需要这样的人提供我们思考方式,更高性能框架,更好的用户体验。高大上的企业很喜欢这样的人,因为高大上的企业承载了比较大的社会责任,需要技术工具去支撑去改变。本人而言,很喜欢这样的人。这个时候技术是服务于业务的,主要精力是技术问题.

4.如果你定位的是非技术岗位

当你通过几年技术的沉淀,想做管理,或则需求方面的专家的时候,这个时候你应该更多的关注业务,因为那是你的兴趣,你的职业导向,这个时候技术对你而言,只是实现你想法的"工具",而不太关心性能,扩展性等等。这样选择的人,多半都是已经的技术高手过渡过去的。并且就职于比较好的单位。基本上是不会考虑跳槽,对于少部分而言,工作在小企业
不太稳定的时候,又想搞业务,那么你一定要需要时间来沉淀你的技术,进入高大上的企业才做你想做的业务。也就是过度。

5.如果你的职业理想是一个架构师

对于这样的你,这样的职业定位,你都应该技术和业务都要熟悉,二者之间的差距不能太大。光有技术没有业务,可能会设计不合理,不易于操作。光有业务无技术,那么你的想象可能难以实现,二者之间都是相辅相成的.那么前期要技术和业务耦合在一起,开始的时候是技术占大多数,随着工作经验的增加,两者差距会越来越小。达到一定的阀值的时候,业务和技术会出现相对的平衡.

对于以上现象而言,我认为都是属于“Y字形”的发展,需要积累一定的技术经验,然后在在走不同的路线,往往前期都有积累比较扎实的技术,然后在选择别的方向,总的来说,在你没有进入一个高大上的公司之前,太多关注业务忽略技术的话,可能你就失去了一些进入高大上公司的机会,所以开始技术是可以带你到一定的高度(高大上公司),然后才是职业其他的发展.也就是基础决定高度.程序员的发展是一个阶段性的过程,很多都是水到渠成的事情,我们现在应该做的是积累好技术,在做业务的时候多关心我们的技术一些。这样你才有拿到牌照进去高大上的公司,你做业务可以,做技术也可以,因为相对而言,高大上的公司业务稳定,也就是你的职业相对稳定.不是的话直接做业务风险很大。因为你随时可能离开现有平台.但是后期业务对我们更好的做好技术起到了推进的作用,设计更好的系统。总的来说,太多时间关注业务的话,完全忽略技术的深度话,基本上在你羽翼未丰之前就是一种障碍.

专注业务是否阻挡了我们获得进入高大上公司的技术牌照"?

时间: 2024-10-13 14:53:35

专注业务是否阻挡了我们获得进入高大上公司的技术牌照"?的相关文章

业务一直是老司机,是时候该让技术开车了。

1.技术领导者的思维,需要从以支持各部门为中心转变为以客户为中心: 2.技术领导力需要从研发的能力进化为整合的能力: 3.技术领导者需要有更高的视野,要将眼光从仅聚焦某部门或职能,提高到连接企业各部门: 4.技术领导者角色的升级,需要从关注交付.实施和执行升级为以商业战略为导向. 我对技术领导者最核心的需求是增长,真正的技术领导者必须要能支持公司业务的增长. 技术领导者要时时清醒地牢记技术创新的目的还是应用落地,产生价值. 在实际操作中,创新要围绕着公司愿景.使命和目标,给公司专注领域.核心业务

开源|宜信开源专注业务逻辑的轻量级服务框架nextsystem4

宜信于2019年3月29日正式开源nextsystem4(以下简称"NS4")系列模块. 此次开源的NS4系列模块是围绕当前支付系统笨重.代码耦合度高.维护成本高而产生的分布式业务系统解决方案.NS4系列框架允许创建复杂的流程/业务流,对于业务服务节点的实现可串联,可分布式.其精简.轻量,实现了"脱容器"(不依赖tomcat.jetty等容器)独立运行.NS4系列框架的设计理念是将业务和逻辑进行分离,开发人员只需通过简单的配置和业务实现就可以实现逻辑复杂.性能高效.

vue+koa+sequlize 搭建使程序员专注业务代码开发框架---项目结构思考(一)

好久没进行日常积累了.最近闲着没事写了一个自己业务开发框架,感觉有一些收获,对于webpack.koa等等都有了一些新的认识,总的来说还是挺有收获的,今天开始分享一下自己的经验,和记录其中踩到的坑. 由于我希望将代码之后代码中具有以下几种特点 client和server进行分离,不包含耦合成分. server使用script标签的形式进行引用前端的代码. 前端的页面不能只有一个入口,多入口的形式可以减少业务的耦合.增加代码的可维护性. 前后端交互的数据不应该只是使用ajax请求进行请求,应该在一

王概凯-架构漫谈之你理清技术、业务和架构之间的关系了吗

本文是漫谈架构专栏的第九篇,作者 Kevin 以钻木取火为切入点,深入介绍了技术.业务和架构之间的关系.正如作者所说,技术总是在人类解决对业务的要求不断提高的情况下产生,目的也是为了获取更大更好的利益. 某天和朋友吃饭正好聊到这个话题.作为架构师或者做技术的人,在开发软件时, 我们基本上就是在扮演上帝的角色:我们不但要创建出一个个的程序,还要让这些程序能够脱离我们在硬件上独立运行,以便为这个程序所服务的群体提供服务.当这个程序出现问题甚至 bug 的时候,我们还得扮演牧师的角色去修复这些问题.这

IBM成甩手掌柜 倒贴15亿美元出售芯片制造业务

大数据在线报道:根据路透社最新消息,IBM公司今天正式宣布以支付15亿美元的方式将芯片制造业务出售给芯片代工企业GlobalFoundries公司,IBM公司还将获得价值2亿美元的资产.在经历数月反复谈判之后,IBM终于将长期处于亏损状态的芯片制造业务转手给GlobalFoundries,这也是继出售X86服务器产品线之后,IBM出售的另外一项重要的业务. GlobalFoundries接盘 今年伊始,IBM公司即着手寻找芯片制造业务的买家.根据知情人士透露,IBM芯片业务一直处于亏损状态,在I

云智慧悄然“变身”业务运维,到底发生了什么?

最近,关注APM领域的客户以及业内人士发现,国内APM领导者云智慧的业务方向已经悄然发生了变化,这就是业务运维,该解决方案已成为其主打产品. 因监控宝而立足,于2014年.2016年陆续推出透视宝.压测宝的云智慧,此次的"变身"显得非常低调.对此,云智慧北京分公司总经理张雅娴的解释为"目前已经有几个大的案例在陆续落地,不过云智慧不是一家喜欢大张旗鼓做市场宣传的公司,我们希望为行业客户扎扎实实的做些事情." 那么,云智慧为什么要做业务运维?业务运维有什么特点和价值?业

架构漫谈(九):理清技术、业务和架构的关系

某天和朋友吃饭正好聊到这个话题.作为架构师或者做技术的人,在开发软件时,我们基本上就是在扮演上帝的角色:我们不但要创建出一个个的程序,还要让这些程序能够脱离我们在硬件上独立运行,以便为这个程序所服务的群体提供服务.当这个程序出现问题甚至bug的时候,我们还得扮演牧师的角色去修复这些问题.这不正是一个程序的社会吗? 和人类社会的演变何其相似!那么我们自然也能够拿人类演变的历史来指导软件开发工作,以避免再经历一次像人类演变发展那么痛苦的过程了.由此我们也可以看出,架构师和程序员们都在扮演着多么重要的

业务软件的本质,超越CRUD

经常写业务软件的开发会吐槽crud没有技术含量,想学新技术,但是学完新技术会发现又进入了crud的循环(学完mq发现只会发送和接收消息,学完redis发现只会读写缓存,学完zookeeper发现只会操作node节点).这种现象产生的原因是什么的?因为关注点一直是逻辑,而不是存储.而一项技术的底层和原理无非逻辑与存储.一个业务软件本质由两个部分组成:业务数据+业务逻辑,这有点像是面向过程=数据结构+算法,这道出了软件开发本质.业务数据层本质就是数据存储,storage,从组成形式来说,分为内存和磁

提升业务价值 创见卓越用户体验 ——APM应用与整合分享

提升业务价值 创见卓越用户体验 --APM应用与整合分享 本文整理自GOPS2016全球运维大会 上海站 APM专场杭州数云运维总监罗兴峰的演讲. 我的分享和前面几位的出发点不太一样,我实际上是APM的用户,前面大家的思路都是如何实现,在腾讯这边他们也是APM的用户,只不过最终自己来解决问题.我自己并不是做互联网技术的公司,我们是一个做业务型的公司,但是我是业务型公司里面的运维,我要保证我们的公司能够很好卖业务的时候才选择了技术. 我今天来的时候碰到了一个情况,和我今天讲的这个事情其实有关系.来