New team structure at work. Six of us. It’s a mixture of seasoned devs and new guys (me). An (subjective) objection is made about something I created. Should I push back or let the senior devs have their way?

If there's really no functional or architectural disadvantage to their way, I'd say let them win this one. There's no use rocking the boat for no reason.

@spongessuck In fact their solution was what I wanted. I let it go. I just don’t want to set a precedent of being walked on every time forever. I also don’t want to become the obnoxious asshole of the group. Idk how to handle it. Hence the question. 😔

@broseph I feel like if you can't make a good point to push back with, you'll just seem defensive or insecure and you won't come off the way you want.

Not enough information to make a call.

Things in the “whatever” category:
Dark mode
Tabs/spaces
Brackets/braces on new lines

Things in the “let’s talk about this” category:
Mixing SQL in your app code vs stored procedures with business logic in the db
Using stuff less than a year old in production vs being one of those companies that prove out new stuff in production
Really any tech stack choices, doubly so if you have call/pager rotations
VM/Cloud vs Physical/On Prem (four way battle)

Things in the “I die on this mountain” category:

Things in “this company is stupid” category (you can’t change culture buddy):
Burning money in the parking lot via waterfall/agilefall
Not defining/poorly defined roles/responsibilities/workflows (RACI there I said it) between support, operations, development, business, QA, BA, PM, sales, infrastructure, etc.

If you don't state your opinion, you'll never have that conversation where you either learn something or they do. But yeah, don't sweat the petty things, and don't pet the sweaty things.

Assuming it's really subjective, ask them where was their opinion when you were writing the code. Where was their support, advice and objection. You got a ticket, you closed it, end of story.