07 | 解决了很多技术问题，为什么你依然在“坑”里？

精选留言(24)

• 

  SA

  我在项目中也多次遇到过通过扩大上下文而解决问题的情况，比如有一次客户提了一个定期从我方系统提取数据同步给某外围系统的需求，开发过程中我们发现提数逻辑涉及关联一张上亿多数据的大表，查询性能很差，技术层面无论如何是无法解决的，最后我们从需求层面出发，着手绕过这个坎，经过分析，发现关联这张大表的作用主要就是为了过滤掉一些脏数据，再结合客户最终的使用场景分析，发现其实由外围系统进行此项过滤会更容易，最后我们说服了客户和友商，不仅很好的绕过了这个坎，也成功实现了该需求；类似的案例还有很多，技术解决不了的问题就通过非技术手段解决，这个案例中开发人员搞了几天一直没能解决，后来报了进度风险，最后版本经理想到从需求层面绕过去，这或许就是他们两个角色的上下文不同的区别吧

  作者回复: 赞！

  2019-01-09

  

   15
• 

  虢国技匠

  打卡
  扩大工作上下文，跳出程序员思维
  醍醐灌顶，受教！

  2019-01-09

  

   12
• 

  ZackZzzzzz

  之前一个项目，需要调用三方的API拿到客户购买历史，通过和上下游服务交涉，明白购买历史只对于会计计算有用，而会计允许一定范围误差，确认不调用三方API的结果在误差范围之内，结果就是节约了大概4s的API延迟

  作者回复: 赞！

  2019-01-09

  

   9
• 

  Vackine

  听了这么多第一次留言。还是研究生，马上毕业，听了之后，感觉对自己以后职业的发展有了更清楚的想法认识和计划。事物发展的过程都是由点到面不断往外扩充的，要想成长也是如此，从最开始看到的点，前后上下文的联系，以及思维的转变，才是成长更近一步的表现。老师讲的非常棒，跟下去之后对自己之后毕业入职一定会有很大的帮助!🤗

  作者回复: 真羡慕你在没开始工作之前就了解了这些！

  2019-01-09

  

   9
• 

  大彬

  我很喜欢上下不同这个描述。我曾经以为，具有主管的能力就够了，后来发现这还不够，缺少主管这个位置的视野和背景，就是上下文这个词。我们组的主管，是上级主管兼任的，我想，我是不是能够成为组的主管？有次主管有事没来，让我按他说的，给其他同事安排工作，等他回来后，跟他汇报，发现是有差距的，并且有些工作还得他出面协调。为什么我做的不够好，为什么我现在做不了这个组的主管。一个星期的时间，我认识到，能力是一方面，上下文也是一方面，我缺少他知道到的信息，这也会影响决策的方方面面，从此，开始不断拓展自己的能力圈。

  作者回复: 你已经具备了向前一步的基础，赞！

  2019-01-09

  

   7
• 

  Alexdown

  还没满足当前需求，就以可扩展性之名考虑后需求，纠结着想要一次性写出完美的代码，没错就是我本人了！
  
  老师的那位同事真是幸运能遇到您！
  
  我一直在纠结着，实现一个功能可能有ABC三中方式，当量级上来后C更容易扩展成D满足后续需求，AB较难或需推倒
  有两个纠结点:
  可能只有AB，根本没C自己在那里瞎转空耗
  意识到了有ABC，但纠结着无法做出选择，因为抱着那位同事的心态想一次搞定完美解决，可惜能力不够不知道C能扩展成D
  
  希望听听老师的建议，谢谢

  作者回复: 别纠结，先实现，等问题真的出现了，再说怎么去优化，很有可能的情况是，你想多了。多了解一些上下文，你才有能力判断自己是否想多了。

  2019-01-10

  

   4
• 

  此方彼方Francis

  老板也曾经跟我聊过跳出程序员思维这个事情，会说到控制成本啊、具备一些产品思维啊这些方面，但是由于个人愚钝，总觉得这个概念很模糊，自己没什么比较明确的提升办法。
  看到这篇文章让我有点豁然开朗的感觉，以后起码我可以从扩展上下文这个方面入手，在这个过程中应该能有不少收获。
  感觉买的很值，感谢！

  2019-01-10

  

   2
• 

  butterfly

  如何扩大自己的上下文呢？ 有没有什么最佳实践呢

  2019-05-21

  

   1
• 

  春之绿野

  我在做ab两个组的事情，前两天a组的组长跟我说因为他们这边缺人，让我全部做a组的事情，因为没有心理准备，而且我想这边这么缺人，我肯定也没有选择权，问我可能就是个形式，于是我就答应了，其实我不想专做a组的事情。后来还是我领导找的我，我跟他确认我能不能自己选择，还有a组这么缺人怎么办，我领导说这个是可以自由选择的，缺人的话他会让另外一个同事加入或者想其他办法加人。其实在领导的上下文里，这个问题是有很多解决办法的，我还操那么多心，连和更大点的上下文寻求帮助，反馈沟通的意识都没有。而且我发现我做的选择是下意识的根据好多预设的条件做出的，因为是无意识的，也没有去反馈和确认这些预设条件的意识。如果不是领导主动找我，我可能又暗自憋屈去了。沟通好难啊！

  作者回复: 进步就是一点点发生的。

  2019-05-12

  

   1
• 

  新博

  之前自己是一个打杂的程序员。有次负责一个项目的人离职走啦，部门经理让我负责，最后也完成了工作，不仅让自己的技术得到了提升。更重要的自己也学会了与客户的更好的沟通，及时完成项目任务，获得了领导和客户的信任。扩大自己工作的上下文，别把自己局限在一个“程序员”的角色上。

  作者回复: 越走路越宽

  2019-02-24

  

   1
• 

  SA

  郑老师这个观点让我醍醐灌顶，其实日常工作中我们已经不自觉的在受上下文这个底层规律的约束，上下文范围大的人视野会更广，格局会更大，考虑问题自然更周全，上下文小的人很可能只是守着自己的一亩三分地，甚至坐井观天而不自知。

  2019-01-09

  

   1
• 

  arronK

  由于自己的爱好吧，之前也经常学习一些产品经理相关的东西，在做写程序的时候呢，也会经常和产品经理去沟通他们的一些产品需求。我就是经常这样扩大自己的上下文的。
  也应而在和产品对接需求的时候。有很多不必要开发的需求能及早的避免掉，有很多可以更好更优的解决方案的需求能够更早的被提出来。也正是因为如此，我的开发效率也提升很多。

  2019-11-26

  

  
• 

  二康

  扩大自己工作的上下文，别把自己局限在一个“程序员”的角色上。

  2019-10-21

  

  
• 

  蛋炒饭

  曾经跟个身价过百亿的老板创业，idea很前沿的，不到半年二十人左右的团队，砸了小一亿（购买国外专利占大头，负责人都私吞装腰包算一部分），而且团队成员（竟然还有个高中生）技术太垃圾了做的不理想，当时感觉没前途，为了追求技术就跑了😔
  
  这种局面，应该怎么破？
  

  2019-10-14

  

  
• 

  每天一点点

  老师你好，我有个疑问问下你
  就我个人而言，技术有点弱，所以遇到技术问题为了解决它，大部分用的都不是非技术，和你文中案例类似通过方案调整，但是出发点不同，他是因为技术强陷入其中，我却是技术弱避免了局，但是我感觉我进去了另一个更深的局。我一直担心往上进步会因为技术弱影响，我这种如何破局？

  2019-08-26

  

  
• 

  陈斯佳

  其实这也是Efficiency和Effective的主要区别。Efficiency是盯住一点，提高效率，而Effective会站在更大的上下文去思考如何能以最优的方式得到想要的结果

  2019-07-13

  

  
• 

  长期规划

  谢谢郑老师的分享，不局限于自己的工作，扩大工作范围，站在更大的角度思考，了解前后端，产品，甚至市场的工作，了解越深，做决策时才能更优，从局部最优到全局最优。从一颗螺丝钉到一个部件，一台机器，甚至一家工厂，这也是格局的提升。这其中，与其它职能的员工沟通交流是核心，这就突显情商，人际关系的重要性。程序员啊，只埋头干是不行的，不能只低头走路，一定要扩展人际网，才能看的更高更远，决策更优

  2019-06-20

  

  
• 

  simple

  上下文的说法跟能力圈的意思差不多，一个人的精力是有限的，努力让自己的能力圈成为top10的同时，扩大自己的能力圈范围

  2019-05-17

  

  
• 

  蜗牛

  扩大工作上下文，从那些细节开始，途径和方法有哪些？

  2019-04-17

  

  
• 

  111

  扩大自己上下文，不要让自己受限于程序员，其它可能有很多都在用了，可能是从不同角度去解决问题，站到使用者可以提出解决方案，站到领导层又会提出另外解决方案。

  作者回复: 你说得没错，后面会讲到用户视角。

  2019-02-24

  

  