10x程序员工作法
郑晔
火币网首席架构师,前ThoughtWorks首席咨询师 ,TGO鲲鹏会会员
立即订阅
7942 人已学习
课程目录
已完结 56 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 程序员解决的问题,大多不是程序问题
免费
思考框架 (1讲)
01 | 10x程序员是如何思考的?
以终为始 (11讲)
02 | 以终为始:如何让你的努力不白费?
03 | DoD的价值:你完成了工作,为什么他们还不满意?
04 | 接到需求任务,你要先做哪件事?
05 | 持续集成:集成本身就是写代码的一个环节
06 | 精益创业:产品经理不靠谱,你该怎么办?
07 | 解决了很多技术问题,为什么你依然在“坑”里?
08 | 为什么说做事之前要先进行推演?
09 | 你的工作可以用数字衡量吗?
10 | 迭代0: 启动开发之前,你应该准备什么?
答疑解惑 | 如何管理你的上级?
划重点 | 关于“以终为始”,你要记住的9句话
任务分解 (11讲)
11 | 向埃隆·马斯克学习任务分解
12 | 测试也是程序员的事吗?
13 | 先写测试,就是测试驱动开发吗?
14 | 大师级程序员的工作秘笈
15 | 一起练习:手把手带你分解任务
16 | 为什么你的测试不够好?
17 | 程序员也可以“砍”需求吗?
18 | 需求管理:太多人给你安排任务,怎么办?
19 | 如何用最小的代价做产品?
答疑解惑 | 如何分解一个你不了解的技术任务?
划重点 | 关于“任务分解”,你要重点掌握哪些事?
沟通反馈 (12讲)
20 | 为什么世界和你的理解不一样
21 | 你的代码为谁而写?
22 | 轻量级沟通:你总是在开会吗?
23 | 可视化:一种更为直观的沟通方式
24 | 快速反馈:为什么你们公司总是做不好持续集成?
25 | 开发中的问题一再出现,应该怎么办?
26 | 作为程序员,你也应该聆听用户声音
用户故事 | 站在前人的肩膀上,领取属于你的高效工作秘籍
27 | 尽早暴露问题: 为什么被指责的总是你?
28 | 结构化:写文档也是一种学习方式
答疑解惑 | 持续集成,一条贯穿诸多实践的主线
划重点 | 一次关于“沟通反馈”主题内容的复盘
自动化 (12讲)
加餐 | 你真的了解重构吗?
29 | “懒惰”应该是所有程序员的骄傲
30 | 一个好的项目自动化应该是什么样子的?
31 | 程序员怎么学习运维知识?
32 | 持续交付:有持续集成就够了吗?
33 | 如何做好验收测试?
34 | 你的代码是怎么变混乱的?
35 | 总是在说MVC分层架构,但你真的理解分层吗?
36 | 为什么总有人觉得5万块钱可以做一个淘宝?
37 | 先做好DDD再谈微服务吧,那只是一种部署形式
答疑解惑 | 持续集成、持续交付,然后呢?
划重点 | “自动化”主题的重点内容回顾汇总
综合运用 (7讲)
38 | 新入职一家公司,怎么快速进入工作状态?
39 | 面对遗留系统,你应该这样做
40 | 我们应该如何保持竞争力?
答疑解惑 | 如何在实际工作中推行新观念?
划重点 | “综合运用”主题内容的全盘回顾
总复习 | 重新审视“最佳实践”
总复习 | 重新来“看书”
结束语 (1讲)
结束语 | 少做事,才能更有效地工作
10x程序员工作法
登录|注册

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

郑晔 2019-01-09
在前面的内容中,我给你介绍了几个体现“以终为始”原则的实践,包括怎样界定工作是否完成的 DoD、怎样判定需求是否完成的验收标准、还有怎样验证产品经理给出的产品特性是否合理的精益创业理念。
了解了这些内容,可能你会想:我为什么要关心这些啊?我是程序员啊!难道我不应该安安静静地写程序吗?为什么要操心其他人的工作做得好坏?如果我管了那么多事,我还是不是一个程序员,到底哪里才是我的“终”呢?
今天这一讲,我们就来聊聊这个让许多人困惑的问题。因为只有要跳出程序员的角色看问题,工作才会变得更加高效。

“独善其身”不是好事

在需要与人协作的今天,独善其身可不一定是好的做法。我先给你讲一个发生在我身边的故事。
有一次,我的团队要开发一个数据服务层,准备作为一个基础设施提供给核心业务系统。开发没多久,一个团队成员和我说,他的工作进展不顺利,卡在了一个重要问题上,他想不明白该如何在多个实例之间分配 ID。
我听完之后,有些疑惑,为什么要考虑这个和功能无关的问题呢?他解释说,因为我们的系统需要保证消息的连续性,所以他设计了消息 ID,这样下游系统可以就通过消息 ID 识别出是否有消息丢失。
这是没错的,但我奇怪的是,他为什么要在多个实例之间协调呢?他给出的理由是,这么做,是出于考虑应对将来有多实例并发场景的出现。然而事实是,我们当下的需求应对的是单实例的情况。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《10x程序员工作法》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(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
收起评论
24
返回
顶部