10x程序员工作法
郑晔
火币网首席架构师,前ThoughtWorks首席咨询师 ,TGO鲲鹏会会员
立即订阅
7975 人已学习
课程目录
已完结 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程序员工作法
登录|注册

38 | 新入职一家公司,怎么快速进入工作状态?

郑晔 2019-04-12
经过前面几个模块的学习,我们分别领略了各个原则在不同场景下的应用,相信你对于这些原则的理解也上了一个台阶。但实际工作并不会清晰地告诉你,到底该运用哪个原则来解决问题。
所以,在接下来的三讲中,我挑选了程序员职业生涯中三个非常经典的场景,与你一起看看怎么在实际的工作中运用好已经学习到的这些原则。
在综合运用这个模块的第一讲,我们就来谈谈,当你加入一家新公司时,应该怎么做。
IT 行业快速发展,无数的机会涌现了出来,程序员频繁流动是这个行业的一个典型特征。频繁换工作,无论是对公司,还是对个人都是成本很高的一件事。所以,在加入一个新公司时,怎么让自己快速融入,尽快发挥价值,是摆在我们面前的一个重要问题。
以行业标准来看,我换工作的速度是很低的,但因为之前工作的原因,我需要到不同的公司与不同的人合作,每到一个新公司,工作的内容就是全新的,就如同换了一个新工作一般。因为合作周期有限,我不可能像普通员工入职新公司一样,花几个月时间慢慢熟悉,只能在尽可能短的时间内,快速上手,而且还要提出自己的新想法。
那我是怎么做的呢?其实,我就是运用这个专栏里提到的各种方法解决这个问题。下面我就来分享一下具体的做法。

运用思考框架

取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《10x程序员工作法》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(10)

  • 极客不落🐒
    1.我会在权限允许的范围内,时不时的到处翻翻 ftp、内部 wiki 等资源,星星点点构建全貌(业务、技术、团队);

    2.梳理系统数据流。去年很火的电视剧「大江大河」里,宋运辉初入职场的方式就很值得借鉴:先走通全部流程,有个全貌,利用图书馆、师傅等资源再自己动手各个击破并绘制流程图,最终实践检验认知以技术说话融入团队。
    「他就每天只要天气晴朗,绕着设备上上下下、里里外外地跑。一个星期下来,全部流程走通;两个星期不到,原理搞通,仪表能读,普通故障能应付;第三星期开始,他可以开出维修单,但得给师父过目;第四星期起,谁有事请假他可以顶上,坐到仪表盘前抄表看动态做操作。师父说他学得很快。
        第四星期起,没人可以让他顶替时候,他在仪表室后面支起绘图板。先画出工艺流程图,经现场核对无误,又让师父审核后,开始按部就班地根据液体走向,测绘所有设备的零件图、装配图、管段图等。这工作最先做的时候异常艰难,首先是绘图不熟练,很多小毛病,尤其是遇到非标零件,还得到机修工段测绘,一天有时都绘不成一个小小非标件。如果车间技术档案室有图纸还好,可以对照着翻画,可档案室里的图纸残缺不全,前后混乱,想找资料,先得整理资料。资料室中年女管理员乐得有个懂事的孩子来帮她整理,索性暗暗配把钥匙给宋运辉,要是她下班不在的时候,让宋运辉自己偷偷进来关上门寻找资料。
        机修工段的人本来挺烦这个宋运辉,说他一来维修单子多得像雪片,支得他们团团转,有人还趁宋运辉上班时候冲进控制室指桑骂槐,被寻建祥骂了回去,差点还打起来。但后来集中一段维修高峰后,维修单子又少了下去,上面还表扬跑冒滴漏少很多,一工段和机修工段各加一次月奖,可见设备性能好转。再以后遇到维修,他们不能确定要用什么零件,打个内线电话给控制室问宋运辉,一问就清楚。双方关系渐渐变得铁起来。基层有时候很简单,只要拿得出技术,别人就服。 」

    作者回复: 非常赞的补充!

    2019-04-12
    18
  • 西西弗与卡夫卡
    有朋友正在转型,从乙方商业化产品的交付经理转向新公司的产品经理。原本得心应手的思维方式和工作习惯,遇到了巨大挑战。以前只需依据已有产品的功能出解决方案,能做就能做,不能实现就是不能实现,到某个时间交付什么功能很明确,考核是以交付签字为准。现在需要面对各方需求,自己想明白用户真正的问题是什么,最终要交付的价值是什么,没有一个实体的谁来签字,只有不断地迭代。

    借鉴领域驱动设计,可以采用以下方法。简单描述的话,是一个点、一个圈再加一个箭头线,是不是有点像丘比特?

    一个点,指的是用户核心价值。这是最关键的一条,基本上只能靠自己想明白。想,不是闭门造车式的苦思冥想,可以是已有的领域经验,可以从书本中学习,可以是大家的各种吐槽,可以是自己从旁边观察用户的实践,还可以是自己变身为用户的实践。有些人会纠结点想的对不对,迟迟不敢动手。其实一开始想得对不对不是那么重要,关键是要有这点,然后快速到市场上验证,根据反馈再调整。

    一个圈,指的是围绕核心价值划出的范围,即领域驱动设计中的限界上下文。产品经理面临的一个现实是,各种人都会给你提需求,只要他们觉得和你有关,还时不时来问什么时候可以实现。需求轰炸之下很容易焦虑,不光自己焦虑,所有的利益相关者都会焦虑。依据核心价值,框出需求范围,在和各方交流过程中可以有一种确定性,减少焦虑,利于行动。大家(不光是研发团队,也包括其他需求方)就能明白,哪些和当前核心价值密切相关我们优先考虑;哪些与核心价值有关但它不在我们的范围内,属于其他团队需要他们协助;哪些有关系,但目前没想清楚价值大不大并且代价可能很高建议先搁置。范围不是一成不变,它随着时间会发生变动,所以我们不要追求固定,只要保证在某个时间段内,大家一致认同即可。

    一个箭头,指的是实现路径,箭头指向核心目标(核心价值)。目标(核心价值)和范围描绘的是终极,而从现实到终极还有很多路要走,可能的路径还有很多条。我们需要琢磨怎么走更稳当,怎么走代价比较低,路上关键的里程碑是什么。路径对不对其次,重要的是思考过程,可以把关键点需要交付的价值、需要支持的资源等等梳理清楚。

    以上

    作者回复: 多谢补充,非常好的思考!

    2019-04-12
    9
  • 0bug
    了解业务这一步是最难的,要么需要有人给讲,一般都没那么多时间,要么有详细的文档,一般文档都是零碎化的。

    作者回复: 让人讲是最容易的,大部分人没那么忙。

    2019-04-12
    1
    5
  • 高阳路人
    昨天看的这篇文章,今天看《架构整洁之道》,第21章也讲到,团队新成员应该先了解系统用例,而非技术细节和交付方式。互相对应上了。

    作者回复: 合理的东西是相通的

    2019-04-13
    3
  • 风翱
    三年前入职新公司的时候,本来认为是一个小问题,让对应的开发人员看一下代码是怎么处理逻辑就可以了?结果他们回答说不知道,那时还有点生气的说,这个你帮我看一下代码不就可以了嘛!后面才知道他们是属于前端的开发人员(C#)调用了是另外一位副总的服务端接口(C#)。
    2019-04-14
    2
  • 我曾服务于一家影像设备的产品型公司,入职时还在初创阶段,产品尚未投入市场,而我之前的公司则是以信息化软件项目交付为主。最大的不同在于业务上从确定性转向不确定性(后者不但要提供竞争对手的通用功能还要主动探索新特性),另一个是业务的实现方式从重交付转向重设计,设计对产品维护与升级相当重要,这是之前未曾切身体会到的。
    课程中先业务后技术的路径我非常赞同,入职新公司时有全局观,做有心人能加快脱颖而出的速度,从我个人经历来说,如果能更早更快的与一线用户打成一片效果会更好,有机会的话程序员不要局限在自己一亩三分地和职能藩篱,多主动出击,以免一旦做起来脱离有效需求陷入技术细节,增加内部沟通成本和外部发布时间成本。
    2019-04-13
    2
  • 旭东
    产品文档缺失,文档缺失,代码日志也没有,更不说单元测试没有。代码结构混乱,到处都有相同业务的特殊逻辑。原始架构依稀可见但早已面目全非。

    更要命的事产品经理离职,剩下一些只言片语的PRD。和其他兄弟部门的对接报文,只能扣代码😂

    解决:1.先加日志和性能监控
    2.整理流程图(参考代码,PRD以及仅有的几个元老同事口述)
    3.适度重构
    4.重写系统。搞清业务边界,有序整理分类合并业务入口,优化程序处理流程以及性能。

    在此过程还在接新需求
    2019-04-12
    2
  • ownraul
    个人经验是入职到新公司, 一定是先从业务着手, 先从整体架构着手开始, 除非是非常偏重技术的那种公司
    一开始可能会分配一些比较简单具体的Task, 正好也是熟悉系统的一个方式, 但是从业务和整体架构着手, 会使得理解这个Task更加容易一些
    2019-04-17
  • 捞鱼的搬砖奇
    融入同事吧,需要点时间积累
    2019-04-12
  • Lyam📵
    曾有机会负责编写开发团队的“入职须知”,帮助新成员一步步快速进入状态。但一直在“关注点顺序”、“是否还有遗漏”、“哪些信息不急于传递”等问题上纠结。本文是比较全面了!
    2019-04-12
收起评论
10
返回
顶部