实习生职场生存手册-用编程的思维去工作
实习生职场生存手册-用编程的思维去工作
本文旨在介绍计算机专业的学生如何把熟悉的编程思维复用到陌生的职场工作中, 用专业知识去形象地理解工作中的问题和规则. 从而更快更好地实现从学生到职场人的过渡.
简单介绍下我个人的经历:
大二进入为之工作室, 边学 Java 边做项目
大二暑假有一份短暂的实验室经历, 由于当时技术和工作能力的欠缺最终还是离开了, 但是在各方面都颇有收获
大三在准备面试的过程中完善个人知识体系, 在大三寒假进入正大集团供应链部门实习, 在大三暑假进入到美团交易系统平台实习. 技术和工作方法都得到了锻炼和检验.
也许本文在职场人看来颇有一种"初中生教育小学生"的喜感, 但是考虑到大量不善言辞的本专业学生在初入职场时都面临着许多困难, 我认为分享一些我的实习经历和思考仍然是有价值的.
用接口的思维去请教问题
你是否有过这样的经历: 你遇到了一个问题, 自己尝试无果, 决定请教同事. 因为害怕占用他过多时间而被厌烦, 所以你刚到他面前就开始嘴像机关枪一样描述你遇到这个问题的经历, 等你认为你用最快的速度给他传递完所有信息后, 他被你一顿输出得一脸懵逼.
这个做法有 3 个问题:
害怕麻烦同事, 害怕被同事厌烦. 所以想快一点请教完回到自己的工位, 语速就特别快.
要输出的信息太多而且没有重点(就像日志一样从头到尾机械地记录发生的所有事情), 再加上语速快, 那个信息密度没有正常人能反应的过来.
急躁, 这个势头会让人感到不安, 即使你的问题本身并不是什么紧要的事情.
我们在学习面向对象编程的时候都接触过一个概念叫"封装", 意思是一个类对外暴露的功能要尽可能简洁, 对外隐藏实现细节, 这个原则的一个典型例子就是接口(java 中的 interface), 调用者只需要知道接口中的方法能做什么就可以, 并不需要关心具体的实现方法.
在请教问题的这个场景里, 你可以认为你和同事是两个互不熟悉的类, 他不需要也不应该了解你的具体情况, 他只需要了解必要信息, 然后经过思考给出一个他的方案, 至于具体怎么把这个方案落实到一行一行的代码上, 是你要做的事.
以上 3 个问题的解决方案:
"害怕麻烦同事", 这其实只是一个认知问题, 我的观察结果是: 只要你提的问题是经过自己思考和自己尝试的, 客气一点, 一般人都不会厌烦.
而且通过加快语速并不能让你的问题更快的解决, 让你们之间的信息传递质量更高才是重点.
输出信息要简洁, 有结构, 便于对方理解. 我常用的模板:
x哥, 有个问题想请教一下你(引起注意, 给对方暂停手头工作的时间, 可以理解为操作系统切换线程时"保存现场"的操作)
(等对方暂停完手头工作) 我在做 xx 需求时遇到了问题, 我想实现 xx (目的)
但是 xx (问题)
我尝试用 xx 去解决, 但是因为 xx 没有成功(自己的思考和尝试)
其实上面这几句话即使慢慢地说完也花不了 1 分钟, 不会耽误多少时间. 语速放慢可以让你思路更清晰, 对方理解起来也容易.
还有一个隐藏的好处: 放慢语速会让你显得更沉稳, 而不像一个毛手毛脚的新手. 谈吐上的改变会带动思维的改变, 你会发现自己在思考和行事的过程中也变沉稳了.
程序的可观测性很重要, 人也是
规模稍微大一点的应用都会有可观测性的要求, 我们要能知道 qps 指标, 异常日志, 内存占用情况...以便于及时发现问题或寻找优化点.
人也一样, mt(mentor 导师)其实是希望能及时了解你的工作进度的, 以便安排相关的其他事项, 或者对你的异常状况有一个心理预期(比如延期了怎么兜底).
在美团, 我每天都要写日报汇报给 mt, 从日报模板来看, 他们关心的内容可以用以下结构来描述:
我在做 xx 任务
这个任务的进度
下一个里程碑
预期交付时间
有无潜在风险, 如何消除
千万不要因为害怕打扰 mt 而不敢汇报, 他不是国家元首, 不会因为每天花几分钟听你汇报就耽误什么重要会议.
及时汇报对于你来说也是有好处的:
你可以让 mt 对你的工作付出更加印象深刻
用于审视自己每天的工作状态, 能及时发现问题并处理
及时抛异常
如果用编程的思维去理解一个任务的认领-交付的过程的话, 可以把自己当成是一个方法(函数), 把你的 mt 当成方法的调用者. 他传入参数, 等待你执行完返回一个结果.
如果能正常返回当然是最好的, 可是如果有异常情况呢? 比如任务无法按时交付, 或者遇到了一个自己无法解决的问题, 或者对 mt 给的信息有疑问...
在 java 中, 你应该抛出一个异常, 让调用者知晓这件事情并处理. 千万不能把异常私自用 try catch 吞掉还不处理.
在工作中也一样, 有异常情况/风险及时向上汇报是基本原则. 有异常情况很正常, 不要担心这会给 mt 留下不靠谱的坏印象, 有异常情况不汇报才是大忌.
保证通信质量
一个人可以理解为一个微服务, 在自己内存中的信息传递是高效而准确的, 而一旦涉及到人跟人之间的交流(rpc), 就很容易出现误解/丢失的情况. 因此就需要一些手段来保证通信质量. 比如复述和确认.
比如 mt 交给了你一个任务, 描述了任务目标, 大致实现思路, 和 ddl. 你要用自己的语言去复述一遍你的理解, 得到对方的确认以保证自己正确理解了.
还要大致思考一下做的过程中还有哪些不确定的事情, 并要求 mt 补充必要信息.
下面是还有一些值得记录的方法论, 和编程思维并没有太大关系.
有主持, 有议程, 有跟进
可能是受从小到大的各种思想教育主题班会/水课的影响, 我们已经习惯了在一个会议中走神/沉默. 但是在工作中, 每一次会议都是有目的的, 它要求信息的有效传递.
标题中的三点是美团会议室里的提示, 是保证会议质量的简单而有效的措施.
有主持: 会议必须有一个主持人, 他要知道本次会议的议程和目的, 负责提出议题, 调动参会人员, 推进议程, 记录 todo list.
有议程: 可以理解为要有进度条, 主持人要知道本次会议要讨论的所有问题, 并控制进度, 当发现讨论偏离议题或者在某一个议题上停留太久时, 要及时纠正.
有跟进: 会议中要明确相关人员后续的职责, 也就是要有 todo list. 会议不仅是为了同步信息, 还要指导后续的行动.
很多问题的本质都是人的问题
这句话出自我之前接触到的一位架构师, 他是一个稳重和蔼, 而且很有思想的中年男人.
这句话可以理解为: 良好的私人关系有助于解决很多本来很棘手的问题.
比如你的产品提出了一个不合理的需求, 如果你和他的关系并不好, 为了避免有"对人不对事"之嫌, 你可能就硬着头皮给做出来了, 而且在以后的开发中, 你还要持续地为这个不合理需求的复杂性买单.
但如果你们的关系还不错, 你们就可以真正从客观角度出发去讨论这个事情, 你可以陈述这个需求在技术上的代价, 并站在他的角度去分析产品上的得失. 寻求一个更合理的解决办法.
再比如, 你有一些问题要找一个人确认, 如果你们关系好的话, 即使问再多次也不会担心被厌烦. 反之这个过程可能就没那么顺畅.
有目的
我的 mt 作为小组的 team leader, 经常主持和各个部门沟通的会议. 我问他是如何锻炼这种统筹全局的能力的, 他的回答很简单: "要明确目的, 一切围绕目的推进"
我在涉及到这种跨部门的沟通时就比较头疼, 因为我进入到了一个陌生的领域, 当遇到一个问题时, 我把握不好"是自己解决还是找他们解决"的边界. 可能为了解决一个小问题陷进去很长时间, 偏离了目的.
而如果我的行为时刻围绕目的, 就能清楚哪些事情该自己去推(调度人员, 传递信息), 哪些事情该叫别人去做(其他部门的技术细节).
快速了解业务代码
先请负责同事讲一遍主要业务逻辑, 然后再去看代码, 这样有重点有结构.
如果自己从头开始看代码, 可能会因为一些废弃的/不重要的设计而困惑好久.
遇到 bug 时
不要盲目地改代码试图"碰"出正确结果。应该想明白原因，设计好改造方案，明确测试指标(例如期望得到什么样的结果)。慢慢来，会很快.
优化数据库操作
对于一个耗时的数据库操作, 有以下优化思路:
使用批处理, 降低数据库交互次数(最优, 既可以减轻 db 压力, 又可以减少网络通信耗时. 但是代码形式稍微复杂一些, 需要写好注释)
将一些数据库操作转为内存操作(例如复杂的筛选/排序/计算)
多线程处理(适用于批处理改造困难的代码)
git 避免冲突
如果你的分支距离创建已经有很长一段时间了, 和主干分支的差异肯定会越来越大. 为了避免在合并代码时遇到太多冲突, 可以在合并之前先 merge 一下最新的主干分支. 当然, merge 完记得做好测试, 防止他人的新代码影响了你的代码逻辑.
