At the company I work for we have just started mob programming, where the team of three that I am a part of all write the code for our project together at one keyboard, and we only proceed if we all agree on the path forward.
It has been commented that we always take my path, and not a path put forward by anyone else and I agree, I think we do. This is something I want to change but I also don't want to put code that I think is bad into production, so I don't just want to concede when I'm not convinced the other person is correct.
For example someone might say:
let's make a method that does A and B, and I might say: Why don't we make a method that does A and a method that makes B? That way each method does only one thing, which is often considered better.
and usually everyone will agree and we will take that approach. The problem is that while we all agree the code is now better we have once again gone down my suggestion and I have 'shot down' someone else's suggestion. This is leading to some resentment from the other members of the team as even my manager has commented that some have said we always do it 'my way'.
Is there some approach I can take where I can guide the team towards a better solution without it looking like it's all my ideas and none of theirs, without sacrificing code quality?
Not relevant to the question, but there is some discussion about mob programming so I will leave a short snippet that convinced the team to experiment with it:
this is an evolutionary step beyond the Extreme Programming [EXT] concept of pair programming. We strive to accentuate and amplify concepts such as face-to-face and side-by-side communication, team alignment, collaboration, whole team involvement, continuous code review, and the "self-organizing-team", to name a few.
Note that I do not want this to be a question discussing the pros and cons of mob programming, substitute mob programming for pair programming or even code review and the question should still remain roughly the same.