狗家3升5的职场老油条摊牌了：Junior到Senior的一些职场经验

大半年前在地里发了一篇“狗家3.5年 3升5 成为TL后considering跑路”的帖子取得了很多的鼓励。这次把其间观察到的一些职场小经验总结一下。

声明：这篇文章的目的不是要你卷，是要帮助提升思维维度。四两拨千斤，花最少的力获得最大的收益。毕竟有时候 ，慢慢来比较快。

1. 早日摆脱学生思维
. From 1point 3acres bbs
由于当学生太久，思维模式和行为方式不自觉地会沿用在校园环境中熟悉的那一套。

典型的学生思维：

1. 把工作任务当作业：做的好不好没关系，能完成就行；做的快不快不重要，ddl之前提交就行
2. 任务交上去这事就算完结了，立刻就能得到一个明确的评分，且不影响做下一个任务
3. 眼里没活，总要别人来布置任务。

学校的课程和学期，结束了就结束了，不会再有机会修改，且造成的影响，也不过是成绩单上的一个数字。但是职场是持续的、长线的。你给别人的印象，别人对你的信任都是不断累积的。把小事做漂亮，老板就愿意给你scope更大更重要的项目。

更重要的是，作业有着标准的答案和打分机制：对了就是对了，错了就是错了，该得多少分就是多少分。职场却全然没有标准答案，靠的更多是同事老板心中的那把天平。由于每个人都会存在有意无意的bias，可能你啥也没做，天平已经朝某一边倾斜。

因此，你大可以在standup上糊弄大家，可以在代码review中别人提一句你改一句，可以在会议上一句话也不说。没人会站出来跟你说这样不对，但心里已经默默打上了标签。

既然人心中的天平和尺度是看不见的，我们能做的只有以过往成果做基石来谋求职业生涯的发展。

在学校中的年级甚至学位的获取是由时间推动的，只要不出大错等时间到了自动就拿到了。

职场中的能力、影响力、级别和薪水，是需要自己积极主动去推动的，不出大错仅仅能够让自己原地踏步而已。

2. 代码Review不仅仅是个流程

代码review不仅仅是提交代码前的一项流程。从团队的角度看，代码review保证了项目的代码质量和统一规范，从个人角度看，代码review几乎是建立peer之间信任的最好方式。（注意peer间的信任和manager的信任不太一样）。

切记要避免以下几个red flag行为：

1. 缺乏主观能动性：同样的问题一再犯错
    1. 案例一：Reviewer建议按照特定的变量命名方式，改了他指出来的变量，但没有改其他文件的变量。于是下一轮reviewer再一次指出这个问题。
    2. 案例二：Reviewer建议方法参数和返回值使用immutable类型，只改了若干个方法，没有将其应用到所有适用的地方。

2. 敷衍交差：提交review的代码甚至都没有通过测试
    1. 按照comment修改好代码后立刻发起下一轮review，却没能保证这些改动通过了所有的test和静态代码检查。导致Reviewer不敢放心给你approve，需要再等一轮review来确认，费时费力。

3. 急于求成：没有弄清楚任务要解决的底层问题就匆匆写代码
    1. 案例一：某个senior同事在bug里提了一个可能可行的方向，等自己实现的时候，没有throughout地弄清楚要解决的底层问题和这个方向是否正确，就匆匆按照他所说的开始写代码。等发请review了才被别人指出这个解决思路根本不work、不optimal、甚至会带来tech debt，最后只能推翻重来
    2. 案例二：研究了一下bug后觉得发现了root cause于是开始编码，写完发现原始的问题并没有得到解决。更好的办法是先validate这个所谓的root cause是否正确。

4. 欠缺沟通：遇到依赖和冲突没有主动跟进
    1. 案例：一次outage复盘之后产生了好几个Action Items，其中若干的item之间互相勾连，但是分别由两人负责独立完成。期间没有沟通，最后发现交集部分的问题被两人各自用两种不同的方式解决。两种解决方法都没有问题，但我们只需要一种。如果提前沟通好两个item之间的boundary，那么就避免了无用功

3. 警惕战术勤奋，战略懒惰

典型表现：遇到comfortable zone以外的内容不迎难而上，依赖于立刻就寻求他人帮助

表面上看，虽然问了很多基础的问题，似乎很勤奋好学是个好苗子，但其实仔细阅读文档或资料就能系统性地习得那些知识技能，节省大家的时间。久而久之，大家会相信你是一个可以独立分析和解决问题的人，老板会更倾向让你尝试更大scope的事情。如若不然，时间长了大家会觉得你是个不上进的**，什么东西都要别人嚼碎了喂到你嘴边。

除此之外，还可以放大职场雷达的辐射范围，警惕与peer的差距，学习peer的优点。不要局限自己一亩三分地。多观察同事们在做什么， 怎么做的，哪里做得好可以偷师。具体而言：

1. 同事代码是否用了新奇的编程语言技巧可以提升代码效率和readability
2. 同事是否有一些脚本或命令行将繁琐的事情(如测试或查数据库)自动化
3. 同事的设计文档中提到的设计模式、新技术概念、最佳实践是我不知道的

除了项目deadline外，职场中一般不会有人催促你个人的成长。但出于对自己负责的态度，需要有时间的紧迫感：

1. 入职3个月了，组里的产品、roadmap和运作流程是否已经熟悉？
2. 入职半年了，组里用的tech stack我是否全部都接触学习过基本用法了？
3. 作为IC参与过好几个项目开发，已经熟悉项目的启停流程了，我是否可以尝试去主导lead项目了？
4. 在项目中已经解决过好几次相同的问题了（如Error Handling，Scalability，Monitoring），是否可以总结一下通用的思路在组内（或更大的org）形成固定的流程/best practice。使得自己从一个纯IC转变成为组里set technical direction的leader？
5. 跟同事讨论问题总觉得自己词不达意，是不是可以跟manager或TL讨论一下如何提升沟通能力？或者找一些相关的training和coach机会？
6. 入职一两年了，技术和人事的积累是否达到可以带intern或作为新人的mentor的程度？

4. 不要畏惧所谓的脏活累活，先思考有没有附加价值

所谓脏活累活，是指那些没有什么技术含量的纯体力活（比如整理文档、检查和清理backlog）、又或者是为别人先前犯下的错误兜底的任务。因为没有什么技术含量，做完也不会产生什么impact，因此没人愿意去做。

我们当然应该尽量避免这样的事情，但遇到的时候也需要审慎地思考一下其背后会否带来附加价值。

我所在的组里，前TL不但技术好，而且对组里各方面业务和技术细节都很熟悉。他跟我差不多时间进的组，同样的时间里他怎么会了解掌握地这么快？我暗地研究调查了一番，发现他其实有在长期地维护组里的各种文档并将其归纳整理到小组的网站上。这些事情虽然繁杂又不会带来引人注目的成果，但他却凭此把触角伸向了组里事务的各方各面，极大地增加了domain knowledge的广度。

这件事他甚至都没有写到perf里，但是背后带来的间接价值显然远超任务本身。由于熟悉各种技术细节，老板在开会时问到的一些细节问题，他都能快速回答。在老板心中坐实了domain expert的地位，并最终放心将TL一职托付给他。

5. 技术之外，关注人事的脉动

- 同事做的项目，是怎么拿到的？单纯因为他比较空闲所以老板分配给他，还是因为他有某方面的优势，还是他主动讨要来的？
- 大组今年要做哪些项目，我所分配的项目是否是高优先级。
    - 如果不是，我有没有可能参与到高优先级的项目里？
    - 某个项目的某个模块我很感兴趣，对我的技术或职业发展(人脉)很有帮助，我是否要跟老板主动提出来？
- 组里有谁会在近期尝试升职，他做的项目必然是属于比较重要的项目。我有没有可能参与合作，一方面参与到重要项目，另一方面提前积累自己升职的人脉（这个同事在升职后可以在我尝试升职的时候帮我写feedback）？

6. 成为insider，创造机会参与决策

我从其他同事身上学到的一个以前认为并没有那么重要的经验是，不要放过刷脸的机会，尽可能地参与大大小小的决策过程，让自己从旁观者变成组织的insider。终极目的在于让大佬们认为你对这些事情是有knowledge的，当需要将其escalate为更大scope的事情是，大佬们会想到你。

所谓的刷脸，未必一定要在会议中没话找话，其实在日常工作的群聊中积极参与讨论问题就足够。具体而言，当别人发出了一个问题

1. （作为新人）虽然你不是特别了解问题的答案，但可以巧妙地参与提问。例如我们所做的assumption是什么、它是否valid，我之前有看到的个类似的情况是不是和这个问题有关联，这么做会不会影响其他某个模块
2. （作为老人）你对这问题的context颇为熟悉，那就要借机建立你的authority。例如这个问题的constraint在于A、B、C；这个方案我之前有考虑，pros和cons分别是…；要解决这个问题，需要先解决另一个问题

当讨论出了结论，可以主动表达自己愿意接下这活（当然也要量力而行）并跟进到尾。如此一来，leadership，collaboration，independence全都有所体现，可谓一鱼三吃。

当然，上述行为中要避免尬聊尬问。把问题带偏或纠结某个细节不放可能适得其反。实在没有任何context不如安静地做个旁观者。

补充内容 (2023-02-21 12:01 +8:00):
发帖的本意是想指出并规避一些意识层面的坑，提供一些思路帮助有需要的朋友更快地适应职场。这么点粗浅的小技巧就能算作“卷”了？你们可能对真正的内卷一无所知（狗头）

楼主是在狗家工作不错，但另外这些方法论适用所有科技公司吧？个别朋友抓着狗家升职性价比高不高批判一番duck不必，毕竟没有人逼着你要在狗家升职（摊手）

匿名用户 发表于 2023-2-20 16:13
还真难说。。 mgr要管组里所有人的”吃喝拉撒“挺累心的。。 反正起码🐶有不少混到一定级别不想着 ...

因为你在狗，之前的狗想pip一个人很难。FG是少数关心entry level ic利益的公司，所以em既要manage up也要manage down。你换成纯manage up文化的公司试试，遇到不听话的不能干活的，直接一套pip送走。高级别ic遇到特别难的tech issue只能自己死磕，总不能靠pip解决吧。

相位疯脸 发表于 2023-2-20 01:36
说得很好，但是对很多人来说多付出这些换来升职涨的那点工资并不划算，留在自己舒适区rest and vest才是性 ...

一边有人说升职涨的那点工资并不划算，一边有人说为什么Senior Leadership华人不够多。
CEO都是一级一级升上去的。我琢磨，难道说这些话的是两拨人？

说得很好，但是对很多人来说多付出这些换来升职涨的那点工资并不划算，留在自己舒适区rest and vest才是性价比最高的选择，只不过现在大环境下这种机会越来越难了。

补充内容 (2023-02-20 15:08 +08:00):
个人觉得爬ladder的分界点在于能不能转em，能转em就加入了最底层资本家队伍了，可以利用下属打工的剩余价值扩大自己的impact和scope。如果努力卷只能当高级别ic的话，就涉及到性价比问题了，因为合格的高级别ic赚得真心是辛苦钱。

相位疯脸 发表于 2023-02-19 22:36:05
说得很好，但是对很多人来说多付出这些换来升职涨的那点工资并不划算，留在自己舒适区rest and vest才是性价比最高的选择，只不过现在大环境下这种机会越来越难了。

补充内容 (2023-02-2

兄弟em也是个打工的，和ic没有一丝区别…
你按照这个思维去爬career ladder，怕是要很失望

除了工作，这世界很精彩。工作就是一个8小时换取金钱的交易，8小时以外的时间才是我有价值又丰富多彩不亦乐乎的人生。工作差不多干的不拉垮就得了。大厂干不了，可以去中厂，中厂不行了，去银行，银行不行了，去政府。我从程序员这份工作中感受不到意义:我们的产品带来的影响是-对普通用户来说没带来啥太多的的便利，对公司而言可以裁掉很多客服人员，让公司和它们的高管们更富得流油。为了一份除了钱以外不能提供任何额外价值的工作，我只愿意最小投入达到保住工作的结果

收藏了，含恨没有早点读到

這有點東C

好贴，让我完全打消了卷级别的想法。

非常好的总结，赞一下

Mark学习下，感谢楼主分享

小亩_fe3h5ky 发表于 2023-02-19 23:49:29
. 1point3acres.com 兄弟em也是个打工的，和ic没有一丝区别…
你按照这个思维去爬career ladder，怕是要很失望

如果真像你说的这样，那meta让很多em转同级别ic应该大家都无所谓才对。事实上很多em根本不想转，人都是用脚投票的，同级别ic和em哪个好混哪个更辛苦不是显而易见吗。

看完之后不想升了。