职场求生攻略
臧萌
PayPal 数据处理组技术负责人,《Java 入门 1 2 3》作者
11259 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 34 讲
结束语 (1讲)
职场求生攻略
15
15
1.0x
00:00/00:00
登录|注册

04丨主观能动性:为什么程序员,需要发挥主观能动性?

其实关于这个主题,我也仔细想过,是放在生存发展篇合适,还是放在职业素养篇合适。最终还是觉得,作为程序员,发挥主观能动性应该算是一个基本的职业素养。
很多时候,只要我们勤勤恳恳,认真负责地做好老大交代的任务,就算是一个合格甚至优秀的员工了。但是程序员这份工作,如果只是做到这一点,最多算是合格。由于软件开发的特殊性,一个任务完成的界限是非常模糊的,而且会根据具体的情况而变化。那么这时候,就要求程序员发挥自己的主观能动性,才能把事情做成,能够交付,而不仅仅字面意义上的“完成工作”。
你可能会想,说得这么玄乎,是真的么?我们来看两个例子。

数据清理和数据标准化背后的要求

在一个数据处理和分析的项目中,有两个功能是对订单数据进行数据清理(data cleaning)和数据标准化(data normalization)。
我首先简单介绍一下数据清理和数据标准化。我们要知道,来自不同的订单数据源的数据质量是不一样的。有的会缺失重要的信息,比如说购买者的 ID、商品详情、订单时间等等。过滤掉这种缺失信息的不合格的数据,这就是数据清理。
数据标准化则是对数据中的数据格式进行标准化转换。比如有的时间用毫秒表示,有的用秒数表示,有的用不同的格式“2020 年 5 月 15 日 15 点 30 分 15 秒”“2020-3-15 15:34:45”,有的甚至用不同时区的时间。再比如对于苹果这个品牌,有的数据用“Apple”表示,有的用“苹果”表示,有的用“苹果(Apple)”表示等等。那么数据标准化的任务就是要将这些数据转换成统一的格式。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

程序员需要发挥主观能动性,理解用户未说出的需求,为用户着想,交付用户想要的东西。发挥主观能动性的代价是会用掉更多的时间,因此需要注意时间管理。在发挥主观能动性时,程序员要注意不要“夹带私货”,即不要因个人喜好而影响项目进度。程序员的职业已经远远延伸到了写代码之外,需要理解需求背后的用户意图,理解用户的问题。程序员有责任和义务发挥自己的主观能动性,达成最终的作战目标。读者需要思考自己在工作中是否有发挥主观能动性的习惯,以及有哪些场景可以发挥主观能动性。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《职场求生攻略》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(25)

  • 最新
  • 精选
  • 勇闯天涯
    主观能动性背后是一个程序员强烈的责任感和追求完美的洁癖,但同时,交付进度的压力下又不得不折中,所以实际工作中,我经常会在折中前想好扩展,实在来不及,我会单独拉版本处理,在后面合并到主版本时再重构,努力保持代码的没有坏味道。有时觉得很辛苦甚至很累,但责任感和对自身的高要求,让我努力保持着积极主动的态度

    作者回复: ✅✅,公司能收获利益,自己能收获成长。 echo一下刚刚一个同学提到的点。这个也和之前说的交流有关系。自己对问题的理解和解决方式有了新的想法时,应该先跟需求方确认自己的想法是否对,做出来是否有价值。这样,对自己发挥主观能动性,是一个巨大的正反馈。如果只是自己的理解,做出来用户不买账,那反而是一个对发挥主观能动性的打击。

    2020-05-25
    13
  • sugar
    看在这篇我也有个感触,想补充一下。在如今大厂工作的同学,做技术岗很多人都是在晋升/面试时才意识到一个问题:自己此前工作中做的都是60分及格的东西,也就是做业务、根据需求实现功能,平时确实能把工作应付了,但在这种节骨眼上,需要把自己工作中的亮点、闪光点拿出来,特别是大厂技术晋升,个个拿出来的ppt材料都是比赛“造火箭”,做业务实现需求所产出的那些东西,在此时的材料里真的是毫无竞争力。老师提到的主观能动性,可能有点过于正能量了....乍一听有种“资本家压榨剩余劳动力”的托词的感觉,毕竟国内圈子里现在是996已经是敏感字眼了。但文章里读到夹带私货这四个字,讲的就非常接地气~ 确实是这样啊 哈哈

    作者回复: 谈谈自己的一点感触和想法。 为什么“工作中做的都是60分及格的东西”不能作为晋升的强有力的理由呢?因为公司知道,想突破就要创新,只是完成手头的工作,那么公司只能平稳,无法突破。长此以往,公司就越来越平庸了,甚至可能被淘汰。 我觉得,公司并不是不知道那些所谓的创新有水分。很多人其实贡献并不比那些矜矜业业做着60分工作的人更多。但是公司为了未来的发展,也必须要传递出这么一种信息:想要自己向上,必须能帮助公司向上。10个创新中,能又一个有用,就已经是赚到了。 很多人都是脚踏实地干活,忘记了抬头看天。但是说句刺耳的话,脚踏实地干活的人好找,能抬头看天发现一片新天地的人不好找。所以公司也更愿意鼓励大家抬头看天,让有这种特质的人升的更高,进而公司能有突破性的发展的可能性。 很多踏踏实实干活的60分员工,都会有这么一个顿悟的过程,发现这么玩不行,“老老实实”干活在公司看来那就是“不思进取”。 从风险和收益的角度来说,脚踏实地的干活,投入和产出都是可以遇见的。而创新的风险更大,收益更大一点,也是合理的。 而且这个也是我们程序员的精神追求的一部分。整天做一摸一样的东西,不无聊么。我们程序员不是要改变世界的么,整天做一样的东西,怎么改变世界?(鸡汤有点浓了哈哈哈哈) 回归现实,想要多收获,就要多付出。这个逻辑是不会改变的。但是多付出了,也不一定会有多收获,这个确实也是事实。多付出的是什么,公司是不是重视你多付出的这部分,就看自己的拿捏了。 至于夹带私货嘛,哈哈哈哈哈,程序员最懂程序员哈。

    2020-06-04
    12
  • 6点无痛早起学习的和尚
    对比工作,就像谈恋爱一样, 发挥主观能动性对比恋爱中如何在节日里制造原定之外的surprised, 但是要考虑一个问题也就是说这个surprised对方是不是会肯定喜欢, 同时也要考虑到制造这个surprised的时间,精力成本。

    作者回复: 嗯呐,发挥主观能动性,不是发挥黄教主霸气的“我不要你觉得,我要我觉得” 更多的时候是: 多听多问:吃透需求,了解问题本质 多想:思考在现有的架构下,有没有更好的方式解决问题,做出来之后能否解决用户的问题 多说:有了想法之后,要拿方案跟用户多交流,让自己思考的成果,得到用户的认可,形成正反馈 女孩肯跟喜欢惊喜。客户一般不喜欢。或者说,客户的心思不一定比女孩的心思更好猜哦。

    2020-05-26
    7
  • 一道阳光
    最近做了一个优化,之前代码逻辑臃肿,复杂,还有隐藏的bug(很难发现),所以我进行了优化,用sql语句替换点代码逻辑,不仅能减少性能开销,解决bug,而且代码大段的删除变得整洁,但是sql语句可能判断的条件判断变得复杂,不利于维护,所以针对sql语句我写了一个笔记,后面交接的人维护起来也更容易上手。

    作者回复: 大赞👍,记得总结并跟大家分享自己的工作,一方面可以让大家了解相关的改进,另一方面也让大家了解自己的贡献

    2020-05-25
    4
    7
  • lisimmy
    老师好,看了这篇文章,我有很多感想。 文章提到: 如果一个程序员做事情永远只知道按照需求中写的做,不多考虑一分,实际上就是自己的失职。 如果我们多考虑了(比如实现了可扩展、松散耦合等等), 也跟需求方交流了,按期完成了一个堪称完美的可交付物。皆大欢喜了吗? 问题来了, 由于自己做的太好了,以至于这个需求从开发到上线,一点问题没有,长期下去,同事或者领导眼里觉得你手上事情太少。 反倒是那些没有主管能动性的, 天天有人来找(为什么?需求有问题,考虑不全面, 但开发人员还是按需求去实现了,没有多考虑),结果这些人天天忙的焦头烂额的,工作周报上写的满满的,解决了什么什么问题,修复了什么什么缺陷,一月下来,名下的需求和缺陷在Redmine上能翻好几页。 而那些主动的人呢? Redmine上,3-5个条目,一页都不到。周报上再怎么写,领导眼里也觉得这是个大闲人。 公司恰好是以git代码量和Redmine条目衡量每个人的工作量。 我心里就想: 以数量衡量工作量,不看质量的吗? 那么我可以明知道需求有问题的情况下,就按需求做, 到时候有问题提缺陷, 我也可以把周报写的漂漂亮亮的,git上满满的代码,Redmine上好几页的条目。 需求定的有问题,需求方就有错吗?我们不主动,我们就不合格吗? 这时候我们去适应环境,做一个职场“老油条”,更加顺风顺水。

    作者回复: 我觉得有一点你说的很对,就是要去适应环境。就你说的例子来看,如果管理者比较看中量化指标,比如Redmine条目,甚至代码行数,那么在开始就把事情做的很好,确实吃亏的可能性比较大。 换言之,这些管理者还是在以传统的、量化的输出来衡量软件工程师的贡献,比如写了多少代码,完成多少task,fix了多少bug。这种机制/环境,就不太鼓励软件工程师去发挥自己的主观能动性。 比如说,代码写的好,不一定行数多(行数应该少才对),bug fix的多,不代表贡献就大,可能只是前期埋的坑太多。而且每个bug的解决方式也不一样,fix一个bug可以搞出n个bug,这样可以一直搞,没完没了。 按照代码量衡量工作量已经是被行业所抛弃的方式。这是把写代码当成体力活的一种行为,长此以往肯定会有不好的价值导向。 当然,每个公司的实际情况都不一样,我不觉得你们公司的管理人员不知道这一点,可能只是公司的实际情况不允许更精细化的管理。实际情况包括管理者的风格水平以及IC的风格水平,这就凸显出自己是否适合公司这个问题了。 现在我们跳出你现在公司的情况,来理解一下你提出的问题。就Windows操作系统来说,98,2000,xp,win7,win10这一路走来,除了vista被人骂,win10倍强制升级之外,别的操作系统都还是不错的。2000,xp和win7更是堪称经典,但是微软也没有止步开发下一代操作系统。用惯了win7,肯定是回不去xp了。所以还是那句话,只要需求在发展,肯定没有一直完美的系统。 其次,从个人发展的角度看问题。发挥主观能动性,也是让自己解决更难更有挑战的问题,锻炼自己解决问题的能力。对自己来说,是一个投资。这个投资用到的是公司的资源(周边资源,问题本身等等)和自己的时间与能力,前者只能依托公司才能获得。发挥主观能动性,可以更好的利用这个资源来提升自己。毕竟,你也不打算在一个用task和代码量来衡量自己贡献的公司一直“老油条”下去吧。

    2020-08-05
    2
    6
  • LDxy
    发挥主观能动性是可以把产品做得更好,但其中花的功夫可能只有我自己知道。别人拿到产品一看可能觉得就应该是这样的,不知道我在其中做了很多需求上没写的额外工作。我需不需要把自己做的这些发挥主观能动性的额外工作说出来呢?

    作者回复: 说,必须说,而且要先说再做。想做的东西,先跟需求方交流,看自己理解的对不对,想做的东西对他们来说有没有价值。

    2020-05-25
    2
    6
  • J.Smile
    又是一节深有感触的课。 刚入职新企业没多久,老大给了一个任务,对一个网站开源项目进行调研,然后进行改造以契合公司内部业务。经过和一个同事一起调研,发觉这个开源项目并不好用,issue很少,star也很少。但老大还是比较乐观,坚持用这个。所以,开始对其改造,整个过程我觉得挺难受的,思前想后考虑各种因素,每当遇到一个问题我都找老大确认,这样以来可能给老大的感觉不是主动,而是我自己没有思考。 不过最后,还是确认了最终的方案,尽管并不完美。——这里引用课里一句话“比起功能的完美,在规定的时间内实现基本功能,才是优先级更高的事情。” 回顾整个过程,我觉得最难受的就是自己的完美方案构想,跟老大的想法在刚开始的时候脱节了。自己拿一个完美的标准去衡量了老大的标准,直到在最终方案确认时我才发现,老大并不是非得要那个理想的,完美的东西。他要的一个最低标准只不过是解决当前公司内部存在的问题。如果我一开始知道这点,可能不会那么觉得那么难受了😣!

    作者回复: 可以一步步做到完美,开始就追求完美,从经理的角度来说,风险太大,投入产出比也低。

    2020-08-02
    3
  • 安迪密恩
    如果客户验收标准和工作量都很高,而时间压的很短的时候,即使原本我有心做好,也不愿意去做了。

    作者回复: 无解的马儿跑马儿不吃草问题。 先完成,再完善。

    2020-06-05
    2
  • FelixFly
    主要提倡的思想是多想多沟通,有想法提供出来大家一起讨论,不要闷头干。但现实中大都是推磨子,推一圈转一圈,这样就比较尴尬

    作者回复: 每个组里,都有想混的,也都有想做得更好的,多跟与自己想法一致的人交流。

    2020-05-26
    2
  • 松鼠工作室
    大佬你好,我司现状是有专门的产品去对接客户的需求,而不是我们研发直接对接客户需求,我想问这么几个问题 1. 直接对接客户需求和有专门产品对接客户需求这两个方式谁好谁坏?如果加了中间产品对接的角色,那么势必会导致信息失真,有可能客户说的a,产品理解并转成了b,然后我们理解实现变成了c,那么a->c就有一定的偏差?如何纠正这个偏差呢? 2. 在有客户经理和产品经理的角色介入下,如何也能按照本章讲的发挥我们主观能动性呢? 3. 本章讲的核心内容都是完成的基础上,然后再多想多思考,然后完成好的的基础一步步迭代变成完美的东西,可是我们项目基本做的都是一锤子买卖,实际上并没有很大的程度的可持续交付,虽然在之后的用户使用的过程中,总会产生一些不大不小问题,我们采取的策略都是客服尽量安抚,安抚过去了这事就算了事了,安抚不过去,才考虑如何处理,如果问题不大,比如数据问题,那就改数据等等这些不痛不痒的解决行为,我想请问我在这种场景下,如何做到多想多思考,多为用户解决问题呢? 还请大佬解答,谢谢!

    作者回复: 1)产品经理有自己的一套技能栈,开发直接对接需求,可能会比较适合简单直接的需求。如果是一个完整的产品,需求繁多,这时候没有产品经理作为总控,会乱套的。简单的东西,直接最好,复杂的东西,就需要引入层级。就好像访问数据库,如果只有一个表,一个表只有五个列,那可能真没必要用DAL,但是如果有几百个表,每个表都好几百列,表和表之间还有各种各样的关系,那DAL才更有价值。 至于需求失真,那就是产品的责任了。产品有责任理解和总结客户的需求,并将需求无误的传达下去。 至于你提到的A->B->C这种情况,肯定是存在的。但是就需求方来说,可能有A1到A10,如果让开发去问搞需求,没准能得到10个有差异的版本。所以,是逮住自己的产品经理问比较省事儿,还是逮住甲方Ax问比较省事儿呢。至少,产品经理是背负着搞清需求的责任的。而甲方的Ax,可以信口开河,一天一个样。 2)和3)其实是类似的问题。这是一个在公司只做项目的这种大氛围下,如何成长的问题。这种情况下,程序员不能/无需让客户收获更多,毕竟需求是他们说了算的。做的多真的不等于做得好。 这时候可以从另一个角度出发。从自己的成长出发。其实程序员成长的一个核心,就是不要重复自己。可以考虑如何避免写重复的代码,如果避免写重复的模块。是不是有可能把重复的代码抽出来,做成工具库,是不是有可能把重复的模块抽出来,做成公司内部的通用模块。如果相似的项目再过来,是不少可以用更少的时间完成。

    2022-04-16
    1
收起评论
显示
设置
留言
25
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部