编程开发中99%的研发者都踩过的误区

目录
  • 01
  • 02
  • 03
  • 04
  • 05
  • 06
  • 07
  • 08

意识不到误区的存在最为离谱;

01

生活中,职场上,游戏里,都少不了正面对喷过:意识太差;

在个人的认知中意识即思维,意识太差即思维中存在的误区比较多;

每个人或多或少都存在思维上的误区;

思维影响行为;

行为效应会带来很多显而易见的问题;

问题多了自然就是各种鸡飞狗跳;

思维误区作为成长的第一大阻力,认清误区并尽快走出,直接决定成长的速度;

误区最妖娆的地方,在于会让人有自我认同的决心,坚定的相信自己思维的正确性;

想要快速的走出误区,就要时常反思,不断提高认知;

最为关键的是,要学会下意识思考自己是否存在思维层面的认知问题;

02

如果从历经的误区中选出一个拔尖的来,【无法敏锐感知并适应变化】首当其冲;

误区形成的根本原因在于:当前的思维模式,可能不适合变化之后的新阶段;

变化,可能是上行,可能是下行;还不排除来回摇摆;

把握变化中的机会;

如果向好就顺势而为,如果变差就沉着应对;

缺乏适应能力就会陷入被动,受到变化带来的冲击和影响;

在变化中机会和困境都是并存的;

反应迟钝就容易错失机会,反应敏捷也容易抓住机会;

自己在变;

随着工作的经历,技术和业务能力都在潜移默化的进阶;

这样自己对职场的预期也会随之提高,环境对个人的要求也在不断刷新;

如果没有感知到自己的变化,根据环境的要求做出相应的调策略;

那么就会出现个人能力不符合环境要求的情况,双方都会产生不符预期的落差感;

这是职场中典型的现象,可能觉得自己能力不差,却没有升职加薪的机会;

那就应该深入的思考:自己的能力和产出是否匹配;

环境在变;

环境在不断变化的直接影响,就是近两年的裁员热潮了;

在毫无心里建设的情况下,团队成员走人,业务方向反转,早已见多不怪;

当然了,也可能环境没有巨变,只是自己主动或被动的换个环境;

适应新的环境,核心在于是否意识到环境的要求;

符合要求就争取做的更好,不符合就要及时调整自己的策略和方向,快速适应当前环境的期望;

在技术领域的新手期,大部分开发都坚定的认为只要技术能力足够好,职场就会一帆风顺;

然而在现实中,纯技术路线上岸的人寥寥无几,这就是市场的选择,供需关系带来的直接最终结果;

总结的说,对自己的能力和所处的环境有透彻的认知;

在角色和环境变化中不断的调整自己的思路,避免双向的预期落差过大;

03

作为一个有着多年搬砖经验的码农;

很清楚在职场中,不同阶段的围城现象和摇摆心理,进而会形成不同阶段的思维误区;

工作中时常会在【技术、业务、管理几条线的围城】中摇摆不定;

实际上把这几个概念划线隔开,就已经踩到误区里了,交集空间很大,只是被选择性忽略了;

新手期,坚定的认同技术能力就是职场的一切解法;

这在初期并不是错误的想法,只是不太全面;

发展期,有了一定的技术沉淀,也有了一定的业务思维;

但是侧重积累业务还是沉淀技术,举棋不定还来回拉扯,甚至一度迷茫;

成熟期,可以有条不紊的应对各种事务,最终也理解业务和技术的相辅相成;

技术的沉淀可以更好的解决业务需求,业务思维可以更好的驱动技术更新;

再后来,就会产生技术和管理的摇摆心态,堪称职场心病;

担心做技术写代码久了失去市场竞争力,走管理路线又怕转型失败两头添堵;

到最终,在技术能力和业务思维的双重加持下;

并且做人和做事都没有明显问题的话,职场环境最终会推动你走向管理的路线上;

对于职场中大部分普通玩家来说;

五年后的职场需要机会,更需要把握机会和适应变化的能力;

互联网行业里,职场的围城现象极其普遍;

总能听闻不同的角色说过,如果再给一次选择的机会再也不选这个职业,自黑吐槽又相互羡慕;

但始终在各自的轨迹上持续前行;

04

对于研发这个角色来说,绕不开的两大核心能力;

就是互联网行业中经常说到的【技术深度和业务高度】两个范畴;

对于技术和业务这两大能力,很考验应对的策略,而不是做选择的决心;

技术和业务作为职场中的核心能力缺一不可,这里不讨论单方面的天赋异禀;

首先要深刻的理解两大能力的各自特点;

这里站在个人的经验和认知上,并且清醒而深刻的把自己定义为职场中的普通玩家;

技术,难度高于业务,复杂度低于业务;

想单纯的从技术领域突围,不但要有持续研究的定力,更需要适当的天赋加持;

普通玩家所能达到的技术深度是有限的;

业务,难度低于技术,复杂度高于技术;

无法否认业务是公司运营的核心;

在基本的供需关系中,业务可以变相的理解为价值,作为公司的核心竞争力和生存的基础支撑;

不论是技术型公司还是业务型公司;

业务虽然复杂,但是业务能力的沉淀是有迹可循的;

具备相应的业务思维,借鉴一些方法 论的指引,在实践中用心总结,业务高度的门槛比技术低很多;

所以从相对综合的角度来看;

技术积累到一定的深度,必然会遇到难以突破的天花板;

但是如果业务达到一定的高度之后,普通玩家的职场发挥空间就会越来越大;

05

如果单从技术角度来看;

很多开发都持续纠结过【技术深度还是广度】的问题,毕竟两全其美才能皆大欢喜;

在互联网技术发展的初期,兼具技术深度和广度的大神级人物确实不少;

但是对于当下的研发技术栈来说;

想单人通关前端、后端、数据端,建议想想就好,不能认真;

当前的主流趋势,技术面在纵向上层层分离,业务侧在横向上有诸多拆分,形成统筹协作的机制;

回到这个问题的本身上来;

对于技术这条路如何选择才最合理?先积累深度还是广度要视情况而定;

在没有环境的压力下;

可以稍微偏向技术的基础深度,在广度上要做到不影响业务的正常研发就行;

至于技术能力最终能深到什么程度,看个人的天赋和觉悟了;

当存在环境的压力时;

如果身处业务型的团队;

为了解决各种复杂的需求规则,要善于利用不同的组件解决不同维度的问题;

自然需要有技术广度的视野;

如果身处技术型的团队;

以分布式系统的中间件服务为例,需要给各种业务场景提供可复用的解决方案;

自然依赖于技术深度的积累;

所以对于技术层面的成长路径来说;

基于当下的主流技术栈和基础能力要求,可以先构建一个路线框架;

例如:分布式架构,数据服务,基础技术等,然后野蛮生长;

06

如果单从业务角度来看;

研发人员【不重视业务能力】行不行,堪称思维误区中的天花板;

更是团队协作的核心矛盾点;

研发时常和产品互相拉扯;

指责对方没有业务思维,或者考虑问题只站位自身的角度,不顾对方的难处;

开发时常和测试来回拉扯;

指责对方无法理解业务,开发认为测试只会点页面不懂业务路径,测试觉得开发想当然歪曲业务需求;

回到这个现象的根本上找原因,互联网公司的团队都在围绕业务流程做协作;

很容易偏向一个误区,【站在自己的角度认为团队的其他角色不懂业务】;

然而实际上,业务作为团队协作的核心目标与方向;

从不同角色自身出发思考业务,明显存在角度上的问题,即站位落差;

如果不在相同的站位上去思考问题,自然很难形成相对统一的共识;

先站位业务角度;

明白在业务发展的过程中什么维度的事项是最高的优先级;

在业务实现中需要以怎样的协作方式去应对;

业务的不同阶段,对于不同团队和不同角色来说要求都不一样;

再站位自身角度;

从业务的视角判断自己的技术能力,或者反思在认知上是否存在偏差;

如果能力跟不业务的变化节奏,就要及时的调整策略,补足技术或认知方面的缺陷;

即便站位相同,也可能因为角色自身的利益而产生冲突;

此时还是需要基于业务利益,调整不同角色间的需求和利益,追求相对平衡平稳;

所以再回到【技术深度和业务高度】这个话题上来看;

对于普通玩家来说,如果缺失其中一个方面的能力;

都会直接压缩职场的发挥空间;

07

除去技术和业务能力的沉淀之外,在职场中还存在一个影响重大的因素;

如何选择【适合自己的团队或者业务线】,这个因素很容易被忽略;

大团队中,分业务线分组作业是普遍的模式;

小团队中,单人单挑业务线是常见的现象;

在刚进入公司的团队时,如果有选择的空间;

可以根据自己的能力或者发展方向,选择符合预期的团队或者业务线;

成熟的业务线;

各种应用层的产品或者系统能力的建设都已经进入平稳期,主要的工作内容可能就是维稳和缓慢迭代;

初期的业务线;

虽然能够给成员更多的发挥空间,但是从真实现象来看;

突然性的业务中断,并打包送走的情况时有发生;

所以不论自己身处一个怎样的业务或团队中,可以先从自身思考如何快速的适应环境;

如果在一个不错的公司中,可以把握机会去适当的调整自己的工作方向;

08

说到底;

误区本身并不可怕,可怕的是不知道自己持续待在误区中;

在变化中具备一定的反思能力,并借鉴一些参考经验或者方法 论指引;

察觉自己处在误区时,及时的调整自己并走出来就行;

当然并不能排除是从一个误区直接进入另一个误区;

但是误区踩多了,自然会产生认知上面的积累,会具备一定的反思和洞察能力;

很推崇的一个思路;

在飞速变化的当下,只能走一步,停下来看一看,想一想,再走下一步;

如果偏航,就在合适的位置掉头;

以上就是编程开发中99%的研发者都踩过的误区的详细内容,更多关于编程开发踩坑误区的资料请关注我们其它相关文章!

(0)

相关推荐

  • iOS schem与Universal Link 调试时踩坑解决记录

    目录 简介 AppDelegate和SceneDelegate 问题:在iOS13以上冷启动的时候不会走代理函数! 如果你用了Scheme方式: iOS13之前会走这个代理函数 iOS13之后会走 如果你用了Universal Link方式: iOS13之前会走这个代理函数 iOS13之后会走 总结 简介 scheme和Universal Link是在iOS中两种可以在网页中点击回跳到自己预定的APP的两种方式.至于这两种方式需要怎么配置,这里就不做详细的介绍了.网上的文章一搜一大堆.今天主要是

  • 示例解析java设计模式七大原则接口隔离原则及优化

    目录 1.什么是接口隔离原则? 2.对应代码 3.改进代码 4.接口隔离原则总结 1.什么是接口隔离原则? 客户端不应该依赖它不需要的接口,即一个类对另一个类的依赖应该建立在最小的接口范围上. 2.对应代码 上面这张图呢,就违反了接口隔离原则.它对应的代码如下: package com.szh.principle.segregation; /** * */ interface Interface1 { void operation1(); void operation2(); void oper

  • vue3不能使用history.pushState修改url参数踩坑

    目录 前言 问题 追根溯源 解决 前言 在重构我的 vue-use-sync-url(辅助将数据和 url 参数进行同步的工具库)时,遇到了一个使用 window.history.pushState 来修改地址栏的 url 参数的 bug,准确来说是 vue-router 的 bug,下面就来讲讲具体是怎么回事. 问题 场景如下,有一个输入框里面输入了内容,点击搜索按钮使用 window.history.pushState 将数据同步到 url 参数上.然后再点击 go about 按钮跳转到别

  • Android界面一键变灰开发深色适配模式编程示例

    目录 深色主题工具类 background_color公用背景色 values/colors.xml 的代码 values-night/colors.xml 的代码 Android 界面一键变灰 java kotlin 深色主题工具类 package com.example.kotlindemo.utils import android.content.Context import android.content.res.Configuration import androidx.appcomp

  • Storybook 7.0 Beta Vue3踩坑解决记录

    目录 故事背景 坑一: 坑二: 坑三: 总结 故事背景 基于 Vue + Vite + TS 结合 pnpm 的一个 monorepo 项目的组件库文档编写,起初个人是比较倾向于直接使用全家桶系列的 VitePress.无奈公司中其他库文档均使用 Storybook,并且已经升级到最新版本. 好吧,到这里就基本知道了自己要做什么了. 由于之前也没有接触过这个玩意儿,就去看着官网一步步操作去了.坑也就在这里了,谁知道版本上去了,文档却没有做出相应的调整.然后就有了后续一系列的问题.Storyboo

  • 编程开发中99%的研发者都踩过的误区

    目录 01 02 03 04 05 06 07 08 意识不到误区的存在最为离谱: 01 生活中,职场上,游戏里,都少不了正面对喷过:意识太差: 在个人的认知中意识即思维,意识太差即思维中存在的误区比较多: 每个人或多或少都存在思维上的误区: 思维影响行为: 行为效应会带来很多显而易见的问题: 问题多了自然就是各种鸡飞狗跳: 思维误区作为成长的第一大阻力,认清误区并尽快走出,直接决定成长的速度: 误区最妖娆的地方,在于会让人有自我认同的决心,坚定的相信自己思维的正确性: 想要快速的走出误区,就要

  • javascript编程开发中取色器及封装$函数用法示例

    本文实例讲述了javascript编程开发中取色器及封装$函数用法.分享给大家供大家参考,具体如下: 1.封装$函数 function $(str){ //如果传入的是'#' 则选择id标签 //如果传入的是'.' 则选择所有的类名标签 //如果传入的既不是'#也不是'.' 选择复合标签 //判断传入的值 if(typeof str !='string'){ console.log('传入的参数有误!'); return null; } //获取参数的第一个字母 var firstChar=st

  • Android编程开发中ListView的常见用法分析

    本文实例讲述了Android编程开发中ListView的常见用法.分享给大家供大家参考,具体如下: 一.ListView的使用步骤 ListView的使用通常有以下三个要素: (1)ListView中每个条目的布局; (2)填充进入ListView中的内容; (3)将内容与页面进行整合的Adapter. 因此,使用ListView也通常有以下三个步骤: (1)创建ListView条目的布局文件(或使用Android SDK提供的布局); (2)创建填充进入ListView中的内容,如字符串.图片

  • Android编程开发中的正则匹配操作示例

    本文实例讲述了Android编程开发中的正则匹配操作.分享给大家供大家参考,具体如下: 在Android开发中,可能也会遇到一下输入框的合法性验证,这时候最常用的就应该是正则表达式去做一些匹配了,下面就常用的正则匹配做一下介绍 1. 手机号码的验证 根据实际开发于2009年9月7日最新统计: 中国电信发布中国3G号码段:中国联通185,186;中国移动188,187;中国电信189,180共6个号段. 移动:134.135.136.137.138.139.150.151.157(TD).158.

  • JavaScript编程开发中的五个实用小技巧

    真是五个很quick的小提示: 只在<form>元素上使用submit事件 如果要在form中绑定事件处理程序时,应该只在<form>元素上绑定submit事件,而不是给提交按钮绑定click事件. March:这个方式固然很好,但是,公司开发时使用了Web Flow,一个页面就一个大form,而里面可能有若干个提交按钮,所以不得不把部分事件处理程序绑定在了提交按钮的click事件上. 可点击的都应该是链接 不要给除锚元素(<a>)以外的元素绑定click事件.这一点对

  • Android编程开发ScrollView中ViewPager无法正常滑动问题解决方法

    本文实例讲述了Android编程开发ScrollView中ViewPager无法正常滑动问题解决方法.分享给大家供大家参考,具体如下: 这里主要介绍如何解决ViewPager在ScrollView中滑动经常失效.无法正常滑动问题. 解决方法只需要在接近水平滚动时ScrollView不处理事件而交由其子View(即这里的ViewPager)处理即可,重写ScrollView的onInterceptTouchEvent函数,如下: package cc.newnews.view; import an

  • iOS App开发中扩展RCLabel组件进行基于HTML的文本布局

    iOS系统是一个十分注重用户体验的系统,在iOS系统中,用户交互的方案也十分多,然而要在label中的某部分字体中添加交互行为确实不容易的,如果使用其他类似Button的控件来模拟,文字的排版又将是一个解决十分困难的问题.这个问题的由来是项目中的一个界面中有一些广告位标签,而这些广告位的标签却是嵌在文本中的,当用户点击文字标签的位置时,会跳转到响应的广告页. CoreText框架和一些第三方库可以解决这个问题,但直接使用CoreText十分复杂,第三方库多注重于富文本的排版,对类似文字超链接的支

  • iOS应用开发中使用Auto Layout来适配不同屏幕尺寸

    简介 Auto Layout 是苹果在 Xcode 5 (iOS 6) 中新引入的布局方式,旨在解决 3.5 寸和 4 寸屏幕的适配问题.屏幕适配工作在 iPhone 6 及 plus 发布以后变得更加重要,而且以往的"笨办法"的工作量大幅增加,所以很多人开始学习使用 Auto Layout 技术. 初体验 0. 开发环境 本系列文章的开发环境为: OS X 10.10.3 Xcode Version 6.3.1 (6D1002) 1. 新建应用 新建一个 Single View Ap

  • iOS应用开发中视图控件UIWindow的基本使用教程

    一.简单介绍 iPhone应用程序通常只有一个窗口,表示为一个UIWindow类的实例.应用程序在启动时(或者从nib文件进行装载)创建这个窗口,并往窗口中加入一或多个视图并显示出来.之后我们很少需要再次引用它.UIWindow对象是所有UIView的根,管理和协调的应用程序的显示.一般应用程序只有一个UIWindow对象,即使有多个UIWindow对象,也只有一个UIWindow可以接受到用户的触屏事件. 在IOS中,UIWindow对象并没有像windows应用程序中常见的关闭框或标题栏这样

  • iOS应用开发中使用设计模式中的观察者模式的实例

    在软件开发中,无论是那种高级语言中总会伴随着一些最为常用的设计模式,即便就如iOS开发中与我们打交道最多的无非就是单例模式.观察者模式和工厂模式了,当然了其他的设置模式也同样存在在编程的很多地方.下面就就让我们简单的了解下观察者模式吧! 观察者模式本质上时一种发布-订阅模型,用以消除具有不同行为的对象之间的耦合,通过这一模式,不同对象可以协同工作,同时它们也可以被复用于其他地方Observer从Subject订阅通知,ConcreteObserver实现重现ObServer并将其重载其updat

随机推荐