How to handle being on a small team where half the devs are principal engineers?
Posted by dijkstras_disciple@reddit | ExperiencedDevs | View on Reddit | 122 comments
I'm currently a mid level software engineer and worked at a couple places prior to my current work place. All my previous teams usually had 1 lead that had final say and laid down conventions.
Current team has 3 principal engineers out of 6 devs and each one of them refuses to adhere to the conventions set by the other principal engineers. When I'm doing PRs, they suggest a lot of conflicting code practices that makes it difficult for me to adhere to one convention.
I personally don't have any strong opinions on which convention to use, but rather prefer for folks to pick one and stick with it.
I've tried to bring this up before but at the time folks felt it was too draconian to enforce.
Any ideas how to go about this without stepping on one of the principals? Also would welcome any advice on how to be successful on a team like this. Thanks!
drakgremlin@reddit
Configure a linter with the rules you know everyone follows. If they complain all them to update the linter. Otherwise raise it up to whoever is in charge you're bogged down because they can't reach consensus.
RelativeYouth@reddit
I’ve so desperately wanted to dable in a linter for our team at work. Is it worth the startup effort?
hgtunafish@reddit
Linters have really started to become faster across several programming ecosystems in recent years thanks to new tools being written in languages like Go and Rust. Ruff in the Python ecosystem and Biome in the JavaScript ecosystem are two standouts.
Ok_Category_9608@reddit
Yes. If style issues aren’t in the linter they get acked. Any stupid little argument about line lengths/whatever happens in one place and is enforced uniformly.
BomberRURP@reddit
That’s one of those things that will pay off for sure.
noharamnofoul@reddit
One of the first things I do at a new job is configure a code workspace, precommit hook, formatter and linter. I refuse to work at a company who doesn’t have these basic ergonomics down, it’s literally the easiest thing to setup, just pick a setting and move on who gives a fuck. I’m a team lead now so we also have a lint formatt typecheck unit test build deploy integration test pipeline that runs on all PRs and I don’t review your code until those all pass.
FatStoic@reddit
The startup effort is almost nil. Any decent linter can be configured to ignore current linting issues and only error on new violations.
Doable in a morning.
elgrovetech@reddit
The startup effort is not the actual setup but the politics of getting it implemented and deciding on the config.
If you get lucky, and everyone on your team is like me - I don't care what the standard is as long as there is one and only one - then it might be easy. Lots of SWEs are opinionated and think their code is art. Good luck with them.
FatStoic@reddit
Bring a copy of "disagree and commit" to the meeting and force the issue by basically saying "any reasonable standard will always be better than no standard"
djsquaretube@reddit
Yes, it will save time and energy in the long run
gillygilstrap@reddit
It also makes the code in every file read the same way.
It’s so nice to have things consistent
wayruner@reddit
This is something I would have expected a good principal to have done already in a situation like this. Sounds like title inflation to me
MathmoKiwi@reddit
This is an evil genius move if you can pull it off! Because then if a principal updates the linter with a rules that conflicts with what another principal wants, then they will have to battle out an agreement, not you!
supyonamesjosh@reddit
This is the best option. You don’t fight about convention in a pr. You decide ahead of time and if there isn’t agreement there is no convention
BoysenberryLanky6112@reddit
That's insane, I used to work at a tech company with \~250 employees and we had a total of 2 principal engineers across the entire company, one backend and one frontend. One team having more than one principal engineer is insane, typically you expect each team to have 1 or 0 staff engineers, and then there's one principal engineer across a large number of teams essentially setting the strategy for the larger org.
As for your immediate situation without leaving, I'd probably try to first work with the 3 non-principals and come up with the consensus view. Odds are you're not the only one who feels this way, and it's worth having chats with them. I'd also have a chat with your manager. It's tough to walk the line, because you don't want the principal engineers to feel like you're going over their head and "tattling" on them, but you need to point out that you're getting conflicting standards and that you need to understand how to decide how to do your work. Make sure you have specific examples. This is assuming you don't feel comfortable having that chat with the principal engineers, as it seems you've already done that and received push back.
At the end of the day it sounds like you're in an extremely poorly constructed team, and it should absolutely not be on a mid level dev to sort out that kind of problem. This is a management failure, and that's why I'd start with making sure management is aware of it and give them room to solve the problem. But honestly I wouldn't hold my breath, any company that is putting 3 principal engineers on a team is probably one that is not going to prioritize making the developer experience better here. I'd probably start looking for another job unless you see a path towards this getting better, as this sounds absolutely infuriating.
GuessNope@reddit
Sorry but no. The dysfunctional anomaly here is 250 people "working" on one project and only two experienced people among of them.
For a project of that scale to have a snowball's chance in hell of working out you need \~24 leads and 3 managers.
PedanticProgarmer@reddit
In my company, principals are lower levels, below tech leads and architects. Silly and outdated.
It’s hard to start this conversation with the management, because I then I would have to explain why I care about the title on my resume ;)
BoysenberryLanky6112@reddit
Title is irrelevant, I've never put my official title on my resume, the resume title should match your responsibilities. I guess I took OP since they mentioned they worked at big tech at actually referring to principal with its typical usage, which is the level after staff which is the level after senior, both promotions which are extremely hard to get. It's typically a role that is someone who guides the tech for the entire large org (company for smaller companies, VP-level org for large companies) and sets org-wide standards. The idea there would be 3 of those on a single team of 6 is just batshit insane.
farazon@reddit
Doesn't changing your title cause issues with background checks? Wouldn't the hiring manager be confused if e.g. they hear back from HR that you were employed as X when your resume says Y?
I'm particularly curious because while my manager brands us as "SWE in observability", for organisational reasons, we have SRE titles with the observability team being in the SRE org alongside other teams such as platform.
I'd definitely feel more comfortable putting myself down as SWE on my resume since that describes the work I do a lot better.
BoysenberryLanky6112@reddit
I hear this a lot on reddit, but I'm pretty sure background checks don't even get whether you were employed they just check criminal records and such. There's no national job registry, and I don't think companies are telling external firms whether or not someone worked there or not. Now I have had job applications that required a contact info from either a former supervisor or just hr person, and presumably that stage is what they would confirm you worked there and maybe ask your title? But it's super common practice to put on your resume a job title aligned with what you actually did rather than your official company job title. No company would refuse to hire you if you had swe on your resume but when they asked your manager your title they said "computer software developer 2" or something like that. The only way that would look bad is if you said you were for example a cto and it turned out you were an swe, or if you said you were an swe and you were actually just it support, blatant stuff like that where you're actually trying to mislead them.
behusbwj@reddit
It’s more common in tooling teams, where the “principals” are more like subject matter experts. For example, the core developers of Linux are all principal level, even if they work on the same code. It’s like a minor version of distinguished engineer at some big tech companies when there isn’t another title that fits right or pays enough for the level of
card-board-board@reddit
I work as a principal at a company with 4 principals and about 18 total engineers. The reason is that we survived the layoffs and the Jr and mid-levels (and PMs and EMs and CTO) did not survive the layoffs. We are principals not staffs because the previous CTO's ladder went associate, engineer (no modifier), senior, principal, distinguished, associate fellow and engineering fellow. Just for context that it might not be title inflation it might just be that the company axed the headcount and kept the team members they knew they needed to keep things running and also had our weird ladder.
I've argued with my other principal colleagues about architecture and conventions but not with any amount of heat and always in meetings with just us.
PurepointDog@reddit
Yeaaaa, there's a reason you needed 250 ppl to do your work. Let me tell you, it's nice working on teams with only a few people who each pull their weight
JarateKing@reddit
You can have smaller teams within bigger companies.
I'm actually not aware of any company of more than a handful of people not divide into teams, even outlier managerless flat hierarchy companies seem to naturally end up with informal teams.
BoysenberryLanky6112@reddit
Principal isn't about how good you are or how you pull your weight, it's a specific title that means you're essentially leading many different teams and providing technical direction to them. Your description of a team would just be all seniors, seniors are expected to pull their weight and contribute without too much direction. And the 250 includes all the different services the company delivers, product people, project management, HR, sales, executives, plenty of non-tech people as well as tech people across many different products we offered. The OP even specified they're at big tech so likely their company has hundreds of thousands of employees.
GuessNope@reddit
Time for a skip-level management meeting.
mystmane@reddit
Vote amongst the other plebs who you want to support as supreme principal, swear fealty to them and then force the other two principals into submission by weight of numbers
jlbqi@reddit
This is the way
ummaycoc@reddit
No, they elect a Super Nintendo engineer.
Spinach-Eater@reddit
This is the way.
There shouldn't be three "principal" engineers looking over the same PR. Management hasn't picked their ~~winner~~ leader so its up to you. That or look for new work.
Mysterious-Rent7233@reddit
I hope you're kidding.
The problems outlined do not seem sufficient to "look for new work."
He didn't say the team is toxic. They just don't adhere to common coding standards. It's not great but not sufficient to look for new work.
labab99@reddit
It’s the go-to solution to just about every problem I’ve seen described on this sub, no matter how minuscule.
Spinach-Eater@reddit
Basically everyone acknowledges this is a management problem. If the mid level is willing to start taking on leadership responsibilities by organising their peers then that's great.
But with a management vacuum and if they had no desire to take that on I'd consider other options. Doesn't mean quit today.
UsernameMustBe1and10@reddit
Wait, trial by code combat is not a standard?
thefoojoo2@reddit
No, have to project to the astral plane https://youtu.be/FDoH15ylAeo?si=tKAE659EKEmPup9j
PaxUnDomus@reddit
That's a duel request
Careful_Ad_9077@reddit
Also, buy a small guillotine.
PothosEchoNiner@reddit
This doesn’t seem like it should be good advice but it is.
DigmonsDrill@reddit
It's a three-person union.
Do it, OP.
oupablo@reddit
This seems like the prime opportunity to hold a series of games to crown a champion.
Cahnis@reddit
Prince Principal if you will
ok_throwaway161@reddit
What a waste of principal's time, assembling them on the same team and asking them to do code reviews.
b1e@reddit
Something tells me principal doesn’t carry the same weight at OP’s company
dijkstras_disciple@reddit (OP)
Yep you can probably deduce which company it is by the amount of principals
PangolinZestyclose30@reddit
I worked in a team with several principals and some staffs (big tech), and they were indeed at that level. It was a specialized database technology which required a lot of skills.
But I think it's rather an exception than the norm. The fact they can't agree on basics like code conventions suggests it's not one of these exceptions.
ielts_pract@reddit
Can you give an example of this specific skill
PangolinZestyclose30@reddit
I think the actual skill was "can go very deep on any required topic". In this case (from what I understood, I didn't stay long), it was about extreme concurrency, despite working in a high level language, understanding of what's going on in the hardware (CPU, memory, storage) and layers in-between (specifically filesystem). Application of a lot of CS algorithms.
VeryAmaze@reddit
At one point in my team we had 2 staff(and one of the staff was friends with one of the architects and kept cc'ing them into the loop), 2 seniors, and an extremely gifted intern(and we were recruiting a staff and a senior). Design reviews were spicy!!!! No one nit picked code conversations tho, ain't nobody care bout that as long as it's readable 😆.
PragmaticBoredom@reddit
At least it’s not a banking company where everyone gets a VP title.
1000Ditto@reddit
leadership in an mnc is be like: team lead, manager, senior manager, director, senior director, avp, vp, svp, executive, senior executive etc etc
bwainfweeze@reddit
Do you remember the good 'ol days when Microsoft had hundreds of VPs?
DuneScimitar@reddit
I wish I was principle enough to know what company has a principle problem!
ohmyashleyy@reddit
My title is principal but it’s really a staff role. But even then 3/6 staffs on a team is still a lot.
reboog711@reddit
I personally don't see a lot of consistency in titles and job descriptions in higher level roles across the industry.
In your mind, What is the difference between staff and principal positions?
ohmyashleyy@reddit
A staff engineer generally works across multiple teams. So if a team is made up of multiple staff engineers, they’re also usually solving other problems too.
A principal, in my experience, is usually at least one level above that. So they’re working across many more teams solve larger architectural problems.
I haven’t worked at a FAANG, but at my previous tier 2 company, we had Staff, Staff 2, and Senior Staff all before principal so there really were very few Principal engineers.
reboog711@reddit
I don't feel there is any consistency across the industry. I've spoken to people where staff is above principal at their employer, for example.
At my employer, for example:
A "Lead Software Engineer" is one level above senior. Sometimes they oversee multiple teams. Sometimes they work on a single team. Industry wide sometimes people refere to "lead" as the Engineering Manager, as opposed to an IC position.
A "Principal Engineer" is one level above that. Usually they oversee a department. Sometimes they oversee larger orgs, which would be multiple departments of multiple teams each.
And a "Senior Principal" is one level above that. Usually they are always at the org level.
No staff position.
ohmyashleyy@reddit
Our “Lead” title is effectively senior. Our company calls the level below that senior in some countries and software engineer II in others - I’m not sure why they haven’t the discrepancy yet, but it’s a mid-level role for sure. We have a lot less levels than bigger companies though.
I agree, there’s definitely not consistency across the industry (my company doesn’t even have a staff role) but I thought the term “staff engineer” was pretty well understood, at least in the last 10 years or so. There’s multiple books on Amazon about the Staff Engineer role.
reboog711@reddit
I would argue that "Staff Engineer" is not a well understood term. At least not yet. There is industry wide inconsistency in titles, responsibilities, and career ladders.
PedanticProgarmer@reddit
I am observing an adjacent team with 4 principals and these guys are just seniors with average skills. Titles mean nothing.
Prestigious-Cook9031@reddit
Lol, the principals at OP's are just senior who got some titles they heard about. Typical title inflation. And obviously the seniors lacking communication skills which confirms my assumption.
stevefuzz@reddit
Lol ctrl-shift-i argument over. If someone wanted to argue spaces vs tabs, id literally say, whatever Silicon Valley (show) decided. I have no space for any of that bs.
Nyefan@reddit
Sounds like serious title inflation - I don't know a principal who is so married to a particular style or convention to argue for any longer than it takes to write down the style guide. It's such a boring conversation to have compared to figuring out how many of the 10,000 things you'd like to do that you can accomplish with the 5 spoons, one spool of twine, and a pitchfork that management will give you.
kaevne@reddit
Is this msft? I’ve only ever seen this at msft where 2/3 of the lvl 65s are overleveled seniors who definitely are not staff-level engineers.
dijkstras_disciple@reddit (OP)
Yep I'm also in a very top heavy org where each team has 2+ principals so tons of competition to make impact
sqPIdt37xCHo0BKbwups@reddit
3 principals per team is too much. More generally, most of SWE teams are overstaffed and can be culled without loss of quality. Ditto for most of "product" roles.
TheRealJamesHoffa@reddit
Sounds like none of them are principal engineers if they’re all “principal engineers” and none of them have authority.
quipumsg@reddit
In our villages there is a curse prayer, which goes like this
"May everyone in your family be an elder—(where no one listens, and conflict becomes the only conversation.)"
Cool-League9903@reddit
notmsndotcom@reddit
lol wut. You should have like one staff+ per couple engineering teams.
BomberRURP@reddit
What is it about our industry that attracts those kinds of people, ugh.
Have a team meeting, get everyone to agree on some standard, and stick to it.
At such a level I would expect them to have already do this a long time ago. And I would expect that even if they individually didn’t like part of the standard they’d still stick to it because code understandability, consistency, etc are way more important than “I WANT to do it this way”.
LogicRaven_@reddit
3 principles in one team sounds like title inflation.
But regardless of titles, the team needs to agree on common practices.
You could try getting them in the same room and record the agreements. Or if that is not possible, then start a doc with X team coding standards, put in some of the comments you received, then let the discussion begin (make sure you have enough popcorn).
If they can't agree, talk with the manager.
dijkstras_disciple@reddit (OP)
Unfortunately the title inflation is required to get into that next pay range. I would say the principal pay here is equivalent to most senior software engineers at FAANG
Agent_03@reddit
Going to guess either Microsoft or Oracle?
WanderingLethe@reddit
So it's just an experience based title. Have a meeting with the team and talk about the issue you see. And don't see those principals as your superior, just have a talk with six equal developers.
tallgeeseR@reddit
Tried this approach in a mid size tech company where my team had 20 engineers, unfortunately even our limited-technical EM trying to run away, did not want to get involved. Eventually conflict resolution responsibility was pushed down to senior/mid level engineer: let say you're a senior/mid level engineer who leading a project and the project is impacted by conflict among principal engineers (principal not responsible for project delivery). Then as the project's lead you're responsible to solve the conflict rather than expecting EM to handle it. Quite an energy draining duty :(
beachcode@reddit
Your project will have the best coding standards documentation there is :-)
masterJ@reddit
Looking to move to a new team with better dynamics is the best use of your time and energy here. The only answer on a team like this is to leave. You do not have the organizational leverage to be effective or direct them, and if you are looking for promotion, there will be a lot of resistance to it since the team is already so heavy with senior+ devs.
merry_go_byebye@reddit
Haha sounds like Microsoft alright
lazy_londor@reddit
Yeah, this definitely sounds like Microsoft, where Principal is equal to Staff at other companies. Anyone that stays an individual contributor long enough without being laid off will end up as a Principal Engineer.
arkestra@reddit
It really doesn’t sound like they are actually what most people would call “Principal Engineers”. I say that partly because there are 3 of them on a team of 6, but mostly because people who were truly at Principal Engineer level would proactively reach agreement/consensus in this kind of situation. As you say, it doesn’t matter which side of the road you drive on, the important thing is that everyone picks the same side and gets on with it!
OP you sound like the grownup in the room here. Maybe they should bust them down a couple of ranks and promote you instead :)
perdovim@reddit
This isn't a problem of too many principals, it's about the team knowing how to function.
One of the most productive teams I was on was virtually all principal level people. They all respected each other and got along great.
I suspect you'd have them butting heads irregardless of what their title is. That's the problem that needs fixing...
behusbwj@reddit
Do i know what team you’re on..? 😂 if it has something to do with programming language development, yes they are known to be incredibly opinionated about style.
RageBlue@reddit
Easy there Patrick Bateman
yall_gotta_move@reddit
I had this exact situation on my very first team. Messy politics aside, THIS IS A GIFT. Do everything you can to learn from them while you are here. I guarantee you'll miss it when you move on to a new team.
Disagreements don't have to be conflict. Usually people are just working with different constraints in mind, nobody has the full picture, etc.
If you get conflicting reviews, here's what you do: "Thanks for the feedback @ P1 . This seems to contradict what @ P2 suggested above, can you explain where your reasoning diverges?"
Then sit back and read what they have to say. Learn their technical perspectives and learn how they compromise, and remember nobody gets to Principal level without learning how to compromise and build consensus at some point.
That doesn't mean you're obligated to be the go-between though -- that's inefficient. Just tag them both directly and let them settle it between each other so you're not wasting time. Ask good clarifying questions so that you show involvement and make sure you understand each perspective, then work on another PR while they settle their design disagreements.
If it's stalling out too long, invite them both to a call to speed up the process of identifying where the disconnect lies. They'll show up because they care -- they wouldn't be arguing back and forth about your PR if they didn't.
If it takes so long that your manager gets concerned, simply point to the discussion threads and say that your leads can't agree on a path forward. If things get to a point where nobody is willing to compromise, then that's a problem for management to solve anyway.
If your manager is useless and wants to hold you accountable for velocity without providing political help, ask for a title increase so that you don't get overruled as easily.
trcrtps@reddit
The only possible resolution is to find the biggest Principal Engineer in the room and knock him out. This asserts dominance. If you think of a badass catchphrase (think "I am the captain now") you may be made the new Principal on the spot.
Skittilybop@reddit
Why does the largest principal dev not simply eat the other principal devs?
sweetno@reddit
Become the 4th principal engineer just to show them how ridiculous they are.
PragmaticBoredom@reddit
Why aim so low? Gotta get to Distinguished Principal Staff Engineer to really flex on them.
PothosEchoNiner@reddit
It might take 5 of them for that
dijkstras_disciple@reddit (OP)
That's the dream haha
NotNormo@reddit
They argue about conventions? This is why there's usually a tech lead. To make the final decision on that stuff.
dijkstras_disciple@reddit (OP)
They don't necessarily argue, but rather they all have their own flavor and style and tries to influence the PR in their particular direction
Steinrikur@reddit
That's where you argue for them coming up with a coding standard. Refuse any flavor and style changes until they agree on a standard to use.
guico33@reddit
My thoughts exactly. What does it matter everyone is a principal engineer. This is just a seniority title. The person in charge should get the final say on those matters.
ashultz@reddit
I don't know who you're working with but they sure as hell aren't principal engineers.
hobbycollector@reddit
A. SPOILER: they're not. B. You'll end up with all the grunt work. Use AI.
BanaTibor@reddit
Lock them in a room and do not let them out till they do not come up with common guidelines which all of them accept. :D
Or make the team vote a lead and follow that guy.
Torch99999@reddit
That brings back repressed memories of a startup I worked at where the dev team consisted of a VP, 6 Product Managers, 9 Architects, and 3 engineers.
Temporary-Daikon2411@reddit
I would love to get hired at that startup, I'd know exactly what to do
xabrol@reddit
They don't sound like principal engineers to me. They sound like they were tenored into the roles instead of earning them. Principals in title only basically, not necessarily skilled, and highly likely at a much lower salary than actual principal engineers.
morswinb@reddit
Reminds me of my first startup job that got merged into other company next door.
Suddenly a team of 10 young just back/front end devs got mixed with a team of 10 Senior Architect Principal Engineers Voodoo Masters.
I left.
Temporary-Daikon2411@reddit
let me guess, salty old Java dogs vs nimble young JS/Python cats?
xabrol@reddit
Yeah, its an unpopular opinion, but technically... The Job hoppers are usually the talented ones. Now if it it's like 8 months here, 4 months there, etc yeah they're a flight risk and probably are just getting put on pips and hopping. But when you see 2.5 years here, 3 years there, 4 years over here, 2 years there, etc... They're likely highly skilled and talented. They stay at a job long enough to prove themselves, so likely didn't get fired, and more likely left for all the reasons I posted above.
Ime it's a good experience range to look for on new hires, people with between 2 and 5 years at many jobs, then don't do any of those things above to keep them.
bwainfweeze@reddit
I worked at a place like this. If I had been asked, I'd have said that I would never have promoted either of the principals on the team past staff engineer.
They new tons and tons of facts, but they were both weak on theory and abysmal on leadership.
dijkstras_disciple@reddit (OP)
Your third paragraph made me chuckle because that was one of the comments 😅
Temporary-Daikon2411@reddit
Yet another consequence of the deflation of "Senior Engineer" leading to the over-use of "Principal"
No company should have so many "Principals" that there are three on a team.
Big tech look in the mirror.
ScottORLY@reddit
“ain’t no such thing as ‘staff’ at a 2 person shop”
andymaclean19@reddit
By definition ‘principal engineer’ means ‘most important engineer’. Having three in the same project is weird, are they just using it as a mark of seniority and/or pay scale thing rather than it actually being a job function with responsibilities?
wlynncork@reddit
I have never met a good principal engineer. Become a senior engineer in 1 field and get those on your team
przemo_li@reddit
Meeting with all 3. Leave them PR, ask for definite feedback.
They refuse, go to Manager or Managers (but single meeting).
PR must container actual contradictions, layout those down, play stubborn stupid. Demand solution.
If it's as ridiculous as you say this should bring it to boiling point
Lothy_@reddit
Can you say bun fight? Because that’s what it sounds like. No way there’s enough job scope for half of the team to merit the Principal job title.
Buttleston@reddit
I know several large successful companies with less than 3 principal devs in the whole org
bwainfweeze@reddit
Three legitimate Principals on one project better be designing a new realtime system, or something with massive security constraints.
Schedule_Left@reddit
Usually, there should be one top dog. Like a lead engineer or engineering manager who has the final say. Having multiple talking heads is a setup for conflict. What you gotta do is just direct blame. "Well principle 2 told me to do it this way, maybe you both can talk it out".
pardoman@reddit
Clearly, you need to come up with your own set of conventions.
Now for real, this is clearly a situation where the “disagree and commit “process needs to be followed, but it requires having a decision maker to take ownership of this aspect of your team’s development process.
Practically what you can do is bring this up to your manager and have them mandate the process to be updated.
Finally, enforcement should be mostly done through tooling if possible.
twisterase@reddit
If there were a good venue to discuss this, like a retro or team meeting, I would say something like: given that we want to deliver our features promptly, and so we want code reviews to go smoothly, what should we do about cases where we're receiving conflicting suggestions on code reviews?
This approach might bring out some more workable ideas, because it ties the issue back to the team's common goal of delivering features promptly and doesn't point fingers at anyone.
MissinqLink@reddit
You need to elect a team captain that gets to make final decisions. Otherwise you’ll all be fighting in some way or another.
fllr@reddit
Get out of the fight. When the PR is out, say you’ll implement whatever is decided and get out of the way. Let them fight it out.
ParticularAsk3656@reddit
My advice is to leave this team. I am the highest leveled engineer on my team and I do not act unilaterally. I seek opinions of the seniors, listen to them, and we establish the best path forward even when we disagree. Being wed to your own opinion is a recipe for disaster and when everyone is doing it, your team will fail.
David_AnkiDroid@reddit
Sounds like hell
Set up a linter, or start a code conventions doc and redirect a subset of feedback to additions to the conventions.
Sell it as: "I'm receiving conflicting advice, and want to be sure I'm doing things right in future".
dhir89765@reddit
Be very clear on whose approval is actually required to ship a PR, and who you just want to consult for helpful advice. You can use the RACI framework for this and ask your manager if you are not sure who to put in each box.
Ideally you are only working with one senior person per project (but it can be different people on different projects), and then you can follow whatever review comments that person leaves in your PR.
For very nitty conventions (like code formatting), you can outsource these arguments to an automated linter. But in your position I'd avoid suggesting changes to team processes, because it sounds like your team has too many opinionated people as is.
Rae_1988@reddit
get a new job?