How to Pick Your Battles on a Software Team

In fact, I think that 'work / life balance' is precisely there, because teamwork costs energy and spending time away from each other is as important as spending time together, and there is more to life than code.

A couple of years ago I spent some time re-factoring a huge code-base that had totally gone off the rails. The guy that ran the project and I clashed quite badly when it came to the code and our approach to it (but since he asked me to help it was fairly clear that he was out of his depth from a programming perspective). When I got there there was no version control, the code was a giant hairball and literally nothing worked.

We spent the better part of two years untangling the mess and at each and every turn he'd dig in and make progress just about impossible. I tried very hard to keep my cool in all this and to just resort to facts rather than ego and I think that's the only reason that we did not end up in an actual fight.

Being a team player can be super hard, especially when everything is phrased in terms of 'your way or my way'. It eats up a huge amount of energy that could be used more productively and it tends to make it hard to leave the job without taking it home every day.

Try this:

  def leadership():
    while true:
      have_clear_goals()
      articulate_goals_clearly()

The section on "when someone makes it personal" really irks me. It should never be personal in a healthy organization. You can vigorously debate the design, the implementation, or any other issue, while keeping the focus on the issue. It never needs to be personal. If it ever gets personal, a manager must step in and immediately squash that and make it clear "That's not how we debate things here. Personal attacks are unacceptable. Focus on the issues."

But, really. Just have clear goals, then most decisions will make themselves. Debates can be settled by measuring alternatives against the goals. If, when measured against the goals, there is no clearly winning solution, then which one you pick probably doesn't matter, so everyone should stop wasting energy on decisions that don't matter and focus on the ones that do.

Not I'm not project manager, I'm single remote dev. My manager try to the other devs write test, but they said to him that is impossible or too complex. So at that time I spend 2 days and I wrote the test and I wrote a long email with links, howtos, benefits, etc.. Nowadays they still say that it's too complex and no value added. My manager can't say test in all places: they complain about it and I tried the #2 but it didn't work.

#2 worked well with the vagrant box, at first days was too complex, now they loved.. but with test and pep8 code style is a long battle. I think that I'm trying to change how they use to work, and they don't want to change how they work.

I always use to explain that, as a friend, is good for all, but I can't get it.

#1 Yes, me too, but when you reviewed 18 PR in 2 days without good code indention, half of them didn't work and 70% was mark as resolved in the task-manager I need to run a marathon every morning to keep away my frustration. Maybe was that last week I was on holidays and these days I only fixed problems.

If you have an environment where everyone is just getting along and there's no conflict at all over major decisions, either no work is getting done, or the observer is blissfully ignorant of the conflict going on. Part of being a "highly functioning team" is that people pick their battles and don't bicker over unimportant things. "Battle" doesn't mean a screaming match -- just a disagreement that needs to be resolved in one way or another.

If you look at really poisonous workplaces, you'll usually find that there's alot of micro-management/supervisory control over all decisions, and the minions adapt by fighting over bullshit to "look good" in front of the micro-manager and ultimately get their way. Also, bike shedding (aka Parkinson's law of triviality) is a handy technique for concealing bad news.

I have observed at least 100 teams over the last 5 years. At any given time I'm coaching 4-10 teams. Every six months or so I get new teams.

The number one problem I see is a lack of clear consistent communication of leadership's intent and values.

Disclaimer: I might be hypersensitive to this because of my military experience.

Complex adaptive systems of humans are always searching for systems with which to signal fitness and interpret fitness signals from others. If leadership does not pound these into the organization from their unique vantage point then the system will adopt its own in the vacuum. Rarely does such a scenario turn out optimal for all participants (for reasons beyond the scope of this comment).