How to Pick Your Battles on a Software Team

I don't think you're going to get a satisfactory answer from HN but I'll try.

It's probably easiest to start with your manager and talk over these problems. Consider how your manager works:

Is he a data kind of guy? Show him how writing tests reduces bugs in the future and speeds development time. How will your changes allow you to ship more features or fix more bugs in the future?

Is he trying to make everybody on the team happy? Ok, see if you can get a few of the more senior people together on the team and talk over the problem in meeting and get everyone to agree on an incremental plan moving forward.

Is your team the kind that tends to hang out together after work? Go out with them once a week, see if you can bring this up in the group casually.

Maybe your boss thinks everything is fine and will only listen if you make more noise? Go into his office and be more direct about the problems you're having.

This also applies to the rest of the team. Consider that they may not see the problems with the project in the same way as you. That's not a bad or good thing, it's just that all people are different. You sound like you're frustrated because it's clear from the facts that there are not enough tests and your team's processes are not being followed. The rest of the team might think that "good enough" is all that is required, and adding more work (even if it reduces workload down the road) isn't a "nice" thing to do.

> I rarely learn from them and they don't want to do things better, they only want to work to raise money.

This is an opportunity for you to learn from them! It's just in areas that you may not be thinking about.

I'm not going to pick any battle. Because I don't believe that is the way forward. I'll inform and I'll produce but I will not confront or invest my ego into which path is chosen. And in the position that I'm in right now I will simply produce.

That's because this is the best way to contribute to a team effort that is already underway. If and when my expertise is required for something I'm quite sure the other team members will know how to reach me.

The hardest battles I've had are dealing with legacy code. The majority of teams want to improve the overall code base and correct past mistakes, but you can never fix everything right now. Deciding when to let the nasty thing lie and when to pay the cost of fixing something is a tough decision to make. Fixing costs are large and immediate but the cost of leaving a problem area is spread unknown across the future. Couple that with fixes that don't actually provide system value except for standardization and you can have all sorts of fun arguments.

This may be redundant with what others have said at this point, but I think this article is wrong-headed: it perpetuates the idea that you will/should have winners and losers.

The biggest barrier I've found to helping improve an idea is that input is perceived as an attack on the author. And, far too often, engineers will say something like "that approach isn't the right one, this one is", effectively substituting their own solution wholesale for the original.

If a team is ever going to be greater than the sum of its members, it must produce output that is better than any single member could produce on their own. That only happens when you move away from "your approach/my approach" to something like "here's a specific concern I have with the existing approach - how would folks suggest we address it? (here's one possibility)"

>If you feel the direction a project is going in is not to your liking you can always quit.

Sorry but that is terrible advice. Most people would be out of a job with that kind of attitude.

>But leave the war and associated terminology and attitude out of it.

Nobody brought it in in the first place. The terminology was in quotes, to explicitly indicate that its not used in the dictionary meaning of the term.

> A good team member knows how to make their objections heard without engaging in confrontational tactics and will be able to present their reasoning in non-confrontational fact driven terms. And is able to accept that they do not always get what they want.

Sure, that looks excellent on paper, but I have found that it doesn't work with actual humans who are actually very _human_ with all of the associated (incl. negative) traits that humans have in varying amounts including pride, pettiness, jealousy, egotism and others. It has very hard to pickup on those because not everyone will display these traits overtly. They will mask it under other rationalizations or explanations or "objective arguments", or what have you. Many people are just sensitive like that. You can try telling them that their work needs fixing in the most gentle, objective way possible, but all they will hear is "XYZ thinks I suck".

>If that happens too frequently then maybe ask to be transfered to another team or maybe leave for another company.

Wow. Much of your comment reads like this to me - "This what a good team looks like, if you aren't on one, find another team or quit your job"