For our startup here in Costa Mesa, it helps to practice an "us" mentality. Simply put, we make an effort to detach our own personal desires, interests, and ideas in order to serve what's best for the entire team.

"Its not about you, it's not about me, it's about us..." -Ajahn Brahm

I think differences in opinion often turn into little grudge matches between developers or even regular people for that matter, because we often attach our own self validation to them.

When we tweak our perspective just a bit, and focus on this concept of "us", we tend to make better decisions sometimes finding new innovative solutions by the combination of multiple opinions.

A nice and easy decision making assessment we like to use consists of four simple checkpoints (Adopted from another Ajahn Brahm teaching)

A good decision must consist of...

1. Benefits to every party involved

2. No influence from things like anger or resentment

3. Information that has been gathered, analyzed, and assessed prior.

4. Influence of fear from uncertain elements (ie future forecasts or long-term risks.. we are developers not fortune tellers after all)

Note- At this point we are a small team of developers and are always iterating our process. I always appreciate any feedback or suggestions out there!

That makes a good interview question, one I've both asked and been asked. The only acceptable answer is: 'Well, we go down to the local bar/pub and hash it out over a beer.'

The idea is not to be the only person with the "right" answers. The beer part is more for comic relief, but it shows that one is willing to sit down with someone in a casual setting and iron out any differences. Hard to be mad at someone you're breaking bread / having a drink with.

Edit: well, maybe not the "only" acceptable answer... ;)

Can you imagine what would happen if a company commissioned an artwork and recruited a team of artists because they wanted it done on a tight timeline? Well, if you're employed as a software engineer, you don't have to use your imagination because this is your daily reality.

With this in mind, I only ever do side projects by myself, because programming is my art and I create my artwork alone.

This depends on the organisation, the team itself, the team-lead, the level of leadership vs direction that are in play. In an ideal world, it should function like the Beatles... "whoever had the best song idea is the one we used" but more often than not you will find a somewhat curtailed level of design autonomy when it comes to software development...

Of course this leads to the gripes, disagreements, factions forming, enemy-of-my-enemy, work to rule, I'm outta here scenarios depending on the gravity of the situation. Professionally we all like to think we're right, yet sometimes we'll do things and implement choices we believe thoroughly wrong because the decision is out of our hands or budget, or you simply no longer care enough to put up a fight. Moral high-horsing about walkouts are fine in print, not so fine when you've houses, cars, kids to pay for etc...

As a manager, I try not to stamp out all friction, some can be very good, productive, educational and motivating actually, it's a case by case scenario. Naturally, anything serious or detrimental must be handled and delicately, but difference of opinion and a little loose rope to see how it pans out needn't be a bad thing.

I'd rather have a team 'burdened' by respectful disagreements than a group of sheep waiting to have orders barked at them. A handy 'fire-blanket' I've used before is to take a losing idea, explore the merit of it and see where else we could use it assuming it's not a useless idea.

I always take in what others say, doesn't mean I follow it. Sometimes it is just an opinion or way they would like and not necessarily something that works for you. If it works don't fix it is my way of thinking about it. Unless you know it could be improved or done better then you should always try to do that.