组里senior太多是好事还是坏事？？

这个问题憋在楼主心里很久了 一直很想知道作为一个junior engineer 在一个满是senior甚至更高level的engineer的组里是好事还是坏事？
我现在在的组 除了我T3基本上都是T5起 平均工龄5 years +  甚至还有一些工龄10年+的大佬

想到的好处就是peer pressure会小一点？ 可以跟老人学东西？
坏的地方有很多啊 比如得不到好的项目和信任，impact少，做一下边边角角的东西。 被老年人们忽略？开会听不懂的挫败感？


考虑过转向产品组， 如果去newgrads junior很多的组， 做得项目会快很多， 好上手（因为senior多的组一般系统都比较复杂 + 难)，但是peer pressure又会很大 一堆t3等着升4... 但是个人做很多项目应该会有很大的满足感的吧
.--
之前男朋友在前公司的第一个组就是因为组里有很多E8（funding member) 项目被压着 新人不被信任 后来换组了

我在前司的组里也是用了很久的时间融入 （因为组里都是做了五年+的老人  很难插上手新的项目）

现在这个组又不是年轻人多的产品组  所以有点迷茫 求大家指点迷津 还是说infra的组就是会这样 那么问题也可能是 年轻人如何在infra team survive？



补充内容 (2019-1-19 06:12):
来补充两点吧

之前提到男朋友在的第一个组很多E8 而这些E8 都是自尊心极强的白人 整个open source的funding  member 连老板都要看他们脸色行事的 其实很明显了 不是一个好组


补充内容 (2019-1-19 06:15):
我的前司 高达90%的印度人比例 作为组里唯一的女程序员 非常的不被重视 印度老板思想里觉得女性差不多做点小活就行了 不需要take很大的responsiblity 即是年底的pf给的是exceed 自己却因为学的太少郁闷的很

补充内容 (2019-1-19 06:18):
新组 国人白人一半一半 华人老板很supportive 一周两次的1o1 积极的给我找不太复杂又有价值的task  老板本身也刚来半年 感觉还在ramp up阶段 组里的人都比较独立强大 没有team lunch 工作各司其职

本文被选为01/17/2019全站置顶文章之一。

本文被提升为今日话题：凡是在置顶有效期内参与讨论，提供言之有物、切中主题的高质量回复，最低奖励20大米，干货越多奖励越多。
欢迎大家参与，对于“干货”回答，请加分、请顶上去。
说明：给别人加分不会扣除你的积分。

只能说各有利弊吧 而且取决于你有多么junior。我工作没多久也算是两种都经历过了，以下讲讲我的经历和感受：

刚毕业的时候加入的是个senior远超于junior的infra team，大概是6个超大牛（principal及以上级别）、3-4个senior、1个SDE2和1个可怜的new grad(我）。缺点就是三个字：压力大，大到晚上睡不好觉，因为我无论如何努力都远不及我的teammates，经常担心我的manager会有buyer's regret后悔收了我。优点当然就是能从不同人学到非常多的东西，不仅是coding技术上的更是工作上沟通为人处世方面的。我觉得作为team里面唯一的junior不要一上来就想加入核心feature，而是要从bug一点点入手。主动去问大牛们他们手里的bug那个你可以help investigate+fix。一般他们会非常开心把bug甩给你。改bug是个很好熟悉系统的方式，主动帮senior load balance也会让老板更加了解+信任你。我是大概做边边角角和改bug将近三个月后才开始参与feature的，都是senior们的design我来implement这样。我觉的只要会主动要work，在senior多的组才impact大。因为项目选择多且都是非常核心的项目（每写的任何一行code都有可能take down整个service。。），而且没有人会和你抢东西做。

大概工作一年多后我们组因为牛人太多被分成了两个组然后新招了些SDE2级别的人，不过依旧senior多。分成两组代表我们team own的core features变少了，on-call时候负责的东西少了，相对压力变小了，整个team room氛围感觉更放松了。但是同样的可以让我随意问问题或者bounce idea的人也少了。

又大概半年后组里先后走了两个大牛，其中离开的一个大牛是我很好的朋友对我帮助非常大，可以说是我工作以来最敬佩的一个人。（知道消息的时候我是真的在办公室当着其他teammates的面哭成了狗，丢死人了。。）大牛把手下很core的feature ownership留给了我，工作压力突破顶峰。现在我们team大概senior/junior一半一半把（我依旧level最低也是没救了哎。。。）。优点就是责任变重了，慢慢开始lead小project了，更敢在design meeting上发表自己观点了。不好不坏的就是一些琐碎的事情比如需要回复的email，参加的design meeting，review的pull request都变多了。缺点就是学到东西少了，感觉大家（尤其是junior间）多的是埋头做自己分配的的工作反而knowledge sharing少了。。

我也来提供一个data point。感觉这个就像围城墙里的面的人想出来，墙外面的人想进来。

我一开始入职的时候我们组只有两个人，连manager都还在招，这个时候的team刚刚建立，虽然有了自己own的东西，但是很多不明确，这种时候根本不可能去做一些大的系统的活只能干一些边边角角的小feature。后来manager入职了之后，会觉得你是这个team的founding member然后给你分派一些大的活。而且还会招一些新的SDE，这样你还可能mentor新人。有点事可以做一些很大的project并且写一些design。缺点就是没有一个经验成熟的senior的话可能会在design上有所欠缺。具体到component的设计，scope，resource等等。一个有经验的senior可以很好的define不同team的界限，掌握整个的project的进度并且进行有效的push back。这点很重要，有些时候的push back是必须的，不然就陷入了无穷无尽的自己team承担很多活。以上都是当你在没有经验去lead一个project的时候会遇见的坑。但是反过来，当你和一个senior合作的时候，你的impact一定会在这个senior之下。这个时候就会感觉到自己可有可无。

我个人的意见是楼主想明白自己现在追求的是什么，并且学习和掌握怎样增加自己的visibility。举个例子，如果现在target升职，在很多Senior的情况下就比较困难，因为自己的impact可能并不会很大。但是如果想要学习就好好利用这个机会学习一切的关于tech和soft skill的东西。同时也需要让你的manger知道你的想法，主动积极的去争取一些项目。当你在一个组里的时候，可以主动写一些proposal出来来说服你的老板这个会给整个团队带来什么。一旦你的项目被采纳来lead这个项目的人就应该是你了。我觉得不管在任何一个组成的团队里，你要展现的都是你对整个团队的影响，大到所有的design，小到所有的featur task，CR你都可以用自己的理解来comment。满满的有了新的想法就可以起飞了！

我觉得取决于senior是怎样的人，以及team的人跟project之间的比例。
提供一个data point：
我入职的时候是4，组里两个senior都是e7 tl。刚入职的时候两个人轮流带我，有问题的时候帮着debug，有质疑的时候回答很谦虚，performance review的时感觉比我自己还希望我promote。我之后又有若干4-5 join，都是这个待遇。
当然这个data point一半是运气，两个senior都是人好的大神。另外一半我觉得是team增长的需求，如果own很大scope却没有足够多人，那来了新人不会想着信不信任，想的都是赶紧教上手了可以新人自己own一块，还能帮着带更新的人。

我在senior多的infra组和junior多的产品组都呆过，也经历过一个组从基本全junior成长到senior人满为患的过程。前面大家已经把两方面的优缺点都总结的差不多了，很多人提到senior多的环境容易学东西，也有人说要自己有机会上手才能涨经验。我从自身经历聊聊这两种情况下的到底能学到什么吧。
首先，我们这里不讨论书本上能学到的知识，这里包括但不限于各种CS基础知识，OS，网络，语言，算法，常见open source system架构。这些知识有大量的公开课，教材，文档可以自学。我记得看到过有人写在google工作的好处，是可以直接在内部IM上问golang commitee的人初级问题。这就是典型的浪费学习机会，也是浪费彼此的时间。
那在一个全是senior的环境下能学什么呢？我理解主要是两方面：
第一是解决复杂技术问题的方法论。这里的复杂问题可以是各种奇怪debug过程，系统重构，或者是梳理一个一团乱码的项目。我接触到的最senior的工程师，往往是team里最被信任能够解决困难的问题的人。而我在观察他们解决这类问题的过程时，能明显感觉到他们会对技术问题有各种各样的抽象，也就是所谓的"solve the problem at a different level"。这种抽象能力和方式和每个人的知识结构和经验有直接关系。在一个全是senior的组里，你可以接触到很多人很多年形成的知识体系，那还等什么呢？
第二是设计经验，或者说是提前预测问题的能力。设计一个系统，或者做任何一个技术决定的时候，一个工程师能提前考虑到多少不同的因素和潜在的问题，是system design能力的直接体现。设计一个直接能上线的系统容易，但设计一个能survive若干次需求和人员变动的系统，是需要踩很多坑才能锻炼出来的能力。
现在轮到junior挑大梁了，我觉得这种情况下最能学到的是各种软能力。如何push一个cross team的项目，什么问题该什么时间和什么人用什么顺序communicate，谁有资格做什么样的决定，如何说服别人一个技术上分歧。这些问题在项目里有senior的时候往往被解决好了，只有当你自己挑大梁的时候才能锻炼。
写了这么多好像都很抽象，没什么具体的例子。不过这个回帖已经够长了，下次新开一帖展开聊聊。

我觉得主要是infra项目的特性（模块高耦合，代码质量要求高）决定了新人难做事情，和senior数量没有太多关系

如果一个infra组全是junior的话，可能出现的就是一两个有相关背景的人完成了核心部分80%的代码，剩下的人打酱油或者做相对垂直的附加工具..

如果组里都是senior的话，其实很多人会拥有重写整个系统的能力，所以反而分工上相对均衡，但这种情况下junior就更难找到切入点了。

所以一个比较geek的解决方案是先提升“演员的自我修养”，把自家组系统的核心部分（数万到十万行代码量级）业余时间自己重写一遍.. 重写的过程中应该会积累很多对系统架构、模块抽象、性能特性、性能瓶颈方面的认识，这之后才比较容易提升在组里的影响力。

不过这也只是我粗浅的认识.. 我并没有很多业界经验，但就我之前做过的一些DB/大数据项目来看是这样的，三五十万行代码不是那么好着手的，很多人都只是浅尝辄止。我比较好地掌握一个DB系统的架构是在重写了大概10万行C++代码之后.. 所以拿到一个新系统，能潜下心来庖丁解牛吃透大部分模块并且end-to-end地重写整个系统，我觉得是在infra领域具有竞争力的一个相对硬指标。

magicsets 发表于 2019-1-17 11:03
我觉得主要是infra项目的特性（模块高耦合，代码质量要求高）决定了新人难做事情，和senior数量没有太多关 ...

自己写还是给公司写?

个人觉得senior的人为主对junior不是好事情。理论上可以跟着大佬看学学，但是那样远不如自己做长经验值快。我说工作之余自己再做很多时候太难了，还是把提高能力和工作结合最有效率。

zhuangtuo 发表于 2019-1-17 22:36
自己写还是给公司写?

自己写，当然这里面也有很多可操作性的问题，一是公司项目有保密问题——除非是开源项目否则不应该去参考公司的代码而是要基于对各个模块功能的理解来重造，二是缺乏外部激励难以坚持。

从公司层面肯定是不鼓励重造轮子的，而且重写代码对原代码的owner是一个负面信号，有种拆台的感觉。所以我认为稍大规模的重写要么是自上（boss）而下的安排，要么是你对原代码owner在威望上具有足够的压制力并且有充分理由并付出尽量少代价去做这件事。

这也是公司利益最大化与个人成长的矛盾，infra系统里如果安排一个新人去做一个feature而对系统其他模块有（接口上或者性能上的）影响的话，可能还是要senior自己去花数倍的时间擦屁股 —— 经济学原理中的贸易共赢是不存在的。

不过CS的一个好处就是可以自己搭台自己演戏，顶级的开源项目最初也就是一两个人搭建起来的核心部分。此外根据我的观察，CS领域有一类人自己水平很高也很喜欢带人成长——是真的那种分享型人格、将教会别人新的能力置于需求层次上端的人，不过也是可遇不可求。

magicsets 发表于 2019-1-16 22:03
我觉得主要是infra项目的特性（模块高耦合，代码质量要求高）决定了新人难做事情，和senior数量没有太多关 ...

infra组里全是junior、senior太少，做不好吧？
infra组需要一些经验丰富的人来lead?

分senior本身是什么样的人，我遇到过愿意带人教别人的，就算把一些杂活分给你，但好歹你能接触到project然后渐渐熟悉。也遇到过不想带你玩只想自己做完东西交的，压根不和你分一杯羹，所有credit都是他自己的。

再分老板，一个好的老板应该积极调节组里人的工作分配，遇到那种跪舔senior的只能junior自己吃瘪。

我不做编程，所以只是笼统的说一下。其实这个问题很好，美国传统行业都在养老，而且都是倚老卖老，这种情况就更常见，也想看看大家有什么好见解。

谈谈我的一点想法，我觉得都是Senior组的好处就是没有peer pressure，如果有两个junior的人，就会有比较谁做的好谁做的不好。但是我觉得总体不是好事，毕竟生于忧患死于安乐，junior人多的组升职会快一些，都是senior的组本来就有很多senior，他们都多有几个人在手下，所以提升空间并不高，而且很多脏活累活都会甩给junior。我之前工作的地方组里都是Senior，基本上基础的活都是我做，不过那段时间跟着他们学到不少东西。总体上我觉得Senior的人更愿意去教你很多东西，对于刚入职的人还是件好事，如果该学的都学了而且上升空间不高就可以考虑换个环境了

magicsets 发表于 2019-1-18 06:27
自己写，当然这里面也有很多可操作性的问题，一是公司项目有保密问题——除非是开源项目否则不应该去参考 ...

这个想法当然很好，但我个人觉得对常人而言难以实现，因为不管是新人还是老人都有自己的KPI，重写核心逻辑要花大量时间

好的manager应该是会交给新人写一些小feature的，在写feature的时候就是读code了解架构的时候。不应该觉得自己做的工作不重要，重不重要其实很多时候靠的是吹，而不是真的做了什么极为核心的东西