I am right and you're wrong.

Aka: Living in a yin / yang (black n white) bubble.

If you're unable to adapt because the only perspective that matters is your own small little universe, then you shouldn't be a dev.

As a dev, you'll have to accept that you cannot know it all. There will be smarter people and there will be things that you won't understand.

It's okay to be wrong. It's okay to not know it all.

Amazon had a principle, "leaders are right, a lot." If you didn't come with data to back your decisions, you didn't stick around. I'm perfectly okay with that practice, largely eliminates tyranny of the majority.

@SortOfTested how did it work, there? Did you just not ask or were they very open to explain their points?

@SortOfTested Tell us more

@piratefox @zemaitis
On the new feature side, every task you work on started with a design document. That design document presented the case for and strategy of your implementation.

You would have the opportunity to get it vetted by an unaffiliated team of peers and principal engineers, which was time that could be used to refine the idea. You then present it to your team for general agreement on the design and spot checking. You'd run a few drafts and then get the buy in.

On the failure side, when an issue occurred, you were expected to be able to produce data showing the root cause analysis for that failure and propose a resolution. If you couldn't produce that data, and you had no idea (completely byzantine), you would likely be scrutinized as a team, and as an individual when performance review time came around.

In any case, you are required to present your case in a self-explanatory fashion to peers, who are also skilled engineers. It's tough but fair.

@SortOfTested interesting process, thanks for sharing! :D