04丨主观能动性：为什么程序员，需要发挥主观能动性？
数据清理和数据标准化背后的要求
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
程序员需要发挥主观能动性，理解用户未说出的需求，为用户着想，交付用户想要的东西。发挥主观能动性的代价是会用掉更多的时间，因此需要注意时间管理。在发挥主观能动性时，程序员要注意不要“夹带私货”，即不要因个人喜好而影响项目进度。程序员的职业已经远远延伸到了写代码之外，需要理解需求背后的用户意图，理解用户的问题。程序员有责任和义务发挥自己的主观能动性，达成最终的作战目标。读者需要思考自己在工作中是否有发挥主观能动性的习惯，以及有哪些场景可以发挥主观能动性。
《职场求生攻略》，新⼈⾸单¥59
全部留言(25)
- 最新
- 精选
勇闯天涯主观能动性背后是一个程序员强烈的责任感和追求完美的洁癖，但同时，交付进度的压力下又不得不折中，所以实际工作中，我经常会在折中前想好扩展，实在来不及，我会单独拉版本处理，在后面合并到主版本时再重构，努力保持代码的没有坏味道。有时觉得很辛苦甚至很累，但责任感和对自身的高要求，让我努力保持着积极主动的态度作者回复: ✅✅，公司能收获利益，自己能收获成长。 echo一下刚刚一个同学提到的点。这个也和之前说的交流有关系。自己对问题的理解和解决方式有了新的想法时，应该先跟需求方确认自己的想法是否对，做出来是否有价值。这样，对自己发挥主观能动性，是一个巨大的正反馈。如果只是自己的理解，做出来用户不买账，那反而是一个对发挥主观能动性的打击。
2020-05-2513
sugar看在这篇我也有个感触，想补充一下。在如今大厂工作的同学，做技术岗很多人都是在晋升/面试时才意识到一个问题：自己此前工作中做的都是60分及格的东西，也就是做业务、根据需求实现功能，平时确实能把工作应付了，但在这种节骨眼上，需要把自己工作中的亮点、闪光点拿出来，特别是大厂技术晋升，个个拿出来的ppt材料都是比赛“造火箭”，做业务实现需求所产出的那些东西，在此时的材料里真的是毫无竞争力。老师提到的主观能动性，可能有点过于正能量了....乍一听有种“资本家压榨剩余劳动力”的托词的感觉，毕竟国内圈子里现在是996已经是敏感字眼了。但文章里读到夹带私货这四个字，讲的就非常接地气～ 确实是这样啊 哈哈作者回复: 谈谈自己的一点感触和想法。 为什么“工作中做的都是60分及格的东西”不能作为晋升的强有力的理由呢？因为公司知道，想突破就要创新，只是完成手头的工作，那么公司只能平稳，无法突破。长此以往，公司就越来越平庸了，甚至可能被淘汰。 我觉得，公司并不是不知道那些所谓的创新有水分。很多人其实贡献并不比那些矜矜业业做着60分工作的人更多。但是公司为了未来的发展，也必须要传递出这么一种信息：想要自己向上，必须能帮助公司向上。10个创新中，能又一个有用，就已经是赚到了。 很多人都是脚踏实地干活，忘记了抬头看天。但是说句刺耳的话，脚踏实地干活的人好找，能抬头看天发现一片新天地的人不好找。所以公司也更愿意鼓励大家抬头看天，让有这种特质的人升的更高，进而公司能有突破性的发展的可能性。 很多踏踏实实干活的60分员工，都会有这么一个顿悟的过程，发现这么玩不行，“老老实实”干活在公司看来那就是“不思进取”。 从风险和收益的角度来说，脚踏实地的干活，投入和产出都是可以遇见的。而创新的风险更大，收益更大一点，也是合理的。 而且这个也是我们程序员的精神追求的一部分。整天做一摸一样的东西，不无聊么。我们程序员不是要改变世界的么，整天做一样的东西，怎么改变世界？（鸡汤有点浓了哈哈哈哈） 回归现实，想要多收获，就要多付出。这个逻辑是不会改变的。但是多付出了，也不一定会有多收获，这个确实也是事实。多付出的是什么，公司是不是重视你多付出的这部分，就看自己的拿捏了。 至于夹带私货嘛，哈哈哈哈哈，程序员最懂程序员哈。
2020-06-0412
6点无痛早起学习的和尚
对比工作，就像谈恋爱一样， 发挥主观能动性对比恋爱中如何在节日里制造原定之外的surprised， 但是要考虑一个问题也就是说这个surprised对方是不是会肯定喜欢， 同时也要考虑到制造这个surprised的时间，精力成本。作者回复: 嗯呐，发挥主观能动性，不是发挥黄教主霸气的“我不要你觉得，我要我觉得” 更多的时候是： 多听多问：吃透需求，了解问题本质 多想：思考在现有的架构下，有没有更好的方式解决问题，做出来之后能否解决用户的问题 多说：有了想法之后，要拿方案跟用户多交流，让自己思考的成果，得到用户的认可，形成正反馈 女孩肯跟喜欢惊喜。客户一般不喜欢。或者说，客户的心思不一定比女孩的心思更好猜哦。
2020-05-267
一道阳光最近做了一个优化，之前代码逻辑臃肿，复杂，还有隐藏的bug（很难发现），所以我进行了优化，用sql语句替换点代码逻辑，不仅能减少性能开销，解决bug，而且代码大段的删除变得整洁，但是sql语句可能判断的条件判断变得复杂，不利于维护，所以针对sql语句我写了一个笔记，后面交接的人维护起来也更容易上手。作者回复: 大赞👍，记得总结并跟大家分享自己的工作，一方面可以让大家了解相关的改进，另一方面也让大家了解自己的贡献
2020-05-2547
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-0526
LDxy发挥主观能动性是可以把产品做得更好，但其中花的功夫可能只有我自己知道。别人拿到产品一看可能觉得就应该是这样的，不知道我在其中做了很多需求上没写的额外工作。我需不需要把自己做的这些发挥主观能动性的额外工作说出来呢？作者回复: 说，必须说，而且要先说再做。想做的东西，先跟需求方交流，看自己理解的对不对，想做的东西对他们来说有没有价值。
2020-05-2526
J.Smile又是一节深有感触的课。 刚入职新企业没多久，老大给了一个任务，对一个网站开源项目进行调研，然后进行改造以契合公司内部业务。经过和一个同事一起调研，发觉这个开源项目并不好用，issue很少，star也很少。但老大还是比较乐观，坚持用这个。所以，开始对其改造，整个过程我觉得挺难受的，思前想后考虑各种因素，每当遇到一个问题我都找老大确认，这样以来可能给老大的感觉不是主动，而是我自己没有思考。 不过最后，还是确认了最终的方案，尽管并不完美。——这里引用课里一句话“比起功能的完美，在规定的时间内实现基本功能，才是优先级更高的事情。” 回顾整个过程，我觉得最难受的就是自己的完美方案构想，跟老大的想法在刚开始的时候脱节了。自己拿一个完美的标准去衡量了老大的标准，直到在最终方案确认时我才发现，老大并不是非得要那个理想的，完美的东西。他要的一个最低标准只不过是解决当前公司内部存在的问题。如果我一开始知道这点，可能不会那么觉得那么难受了😣！作者回复: 可以一步步做到完美，开始就追求完美，从经理的角度来说，风险太大，投入产出比也低。
2020-08-023
安迪密恩如果客户验收标准和工作量都很高，而时间压的很短的时候，即使原本我有心做好，也不愿意去做了。作者回复: 无解的马儿跑马儿不吃草问题。 先完成，再完善。
2020-06-052
FelixFly主要提倡的思想是多想多沟通，有想法提供出来大家一起讨论，不要闷头干。但现实中大都是推磨子，推一圈转一圈，这样就比较尴尬作者回复: 每个组里，都有想混的，也都有想做得更好的，多跟与自己想法一致的人交流。
2020-05-262
松鼠工作室大佬你好，我司现状是有专门的产品去对接客户的需求，而不是我们研发直接对接客户需求，我想问这么几个问题 1. 直接对接客户需求和有专门产品对接客户需求这两个方式谁好谁坏？如果加了中间产品对接的角色，那么势必会导致信息失真，有可能客户说的a,产品理解并转成了b，然后我们理解实现变成了c，那么a->c就有一定的偏差？如何纠正这个偏差呢？ 2. 在有客户经理和产品经理的角色介入下，如何也能按照本章讲的发挥我们主观能动性呢？ 3. 本章讲的核心内容都是完成的基础上，然后再多想多思考，然后完成好的的基础一步步迭代变成完美的东西，可是我们项目基本做的都是一锤子买卖，实际上并没有很大的程度的可持续交付，虽然在之后的用户使用的过程中，总会产生一些不大不小问题，我们采取的策略都是客服尽量安抚，安抚过去了这事就算了事了，安抚不过去，才考虑如何处理，如果问题不大，比如数据问题，那就改数据等等这些不痛不痒的解决行为，我想请问我在这种场景下，如何做到多想多思考，多为用户解决问题呢？ 还请大佬解答，谢谢！作者回复: 1）产品经理有自己的一套技能栈，开发直接对接需求，可能会比较适合简单直接的需求。如果是一个完整的产品，需求繁多，这时候没有产品经理作为总控，会乱套的。简单的东西，直接最好，复杂的东西，就需要引入层级。就好像访问数据库，如果只有一个表，一个表只有五个列，那可能真没必要用DAL，但是如果有几百个表，每个表都好几百列，表和表之间还有各种各样的关系，那DAL才更有价值。 至于需求失真，那就是产品的责任了。产品有责任理解和总结客户的需求，并将需求无误的传达下去。 至于你提到的A->B->C这种情况，肯定是存在的。但是就需求方来说，可能有A1到A10，如果让开发去问搞需求，没准能得到10个有差异的版本。所以，是逮住自己的产品经理问比较省事儿，还是逮住甲方Ax问比较省事儿呢。至少，产品经理是背负着搞清需求的责任的。而甲方的Ax，可以信口开河，一天一个样。 2）和3）其实是类似的问题。这是一个在公司只做项目的这种大氛围下，如何成长的问题。这种情况下，程序员不能/无需让客户收获更多，毕竟需求是他们说了算的。做的多真的不等于做得好。 这时候可以从另一个角度出发。从自己的成长出发。其实程序员成长的一个核心，就是不要重复自己。可以考虑如何避免写重复的代码，如果避免写重复的模块。是不是有可能把重复的代码抽出来，做成工具库，是不是有可能把重复的模块抽出来，做成公司内部的通用模块。如果相似的项目再过来，是不少可以用更少的时间完成。
2022-04-161