How to Pick Your Battles on a Software Team

I wanted to like this article, but I feel that it focuses too much on "winning" and "losing" - building software is (mostly) a creative task, and (I think that) treating it like a series of wins and losses can be a dangerous mentality to start off with.

Finding a creative equilibrium between two ideas is the key to forming the right amount of "creative abrasion", but walking away from every discussion feeling like you won or lost is not going to get you there.

If you're arguing about smaller or inconsequential things like tabs vs. spaces or other stylistic items, you need to spend some time and document guidelines, which should be enforced equally on everyone. This saves tons of time down the line, and eliminates a lot (but, of course, not all) of these problems.

I agree -- there was also a very "product v. engineering" vibe to it also. Maybe my company is different from most they see, but we don't have product doing code reviews for developers. The place tension can arise seems to be more around the fact that product always wants to move faster and engineering expresses that they can't always do that. I don't think either side is right all the time, but the way the article starts with "Winning battle = product giving into engineering", "losing battle = product being pushed into a better decision by engineering" screams to me of a lack of understanding that in a good organization each party has the best possible information for making decisions that represent the interests of the company from different perspectives, and these meetings are to figure out how those interests align or conflict and sort them out.

True, but some of this rang true since, in the past, there were certain people I felt like I was competing with. Over time, of course, that gets toxic and bad for business, something which needs a long-term solution.

I agree with other commenters that this is simply too combative an approach. I've personally have had better luck with negotiation and redirection.

I will say, I kinda burned out with product managers that don't understand technical requirements. Or product managers that lacked vision. I'm at a point where I'm pretty much done programmer other people's (uninspired) ideas (and am fortunate enough to be in a situation that allows me this freedom). There's a huge productivity difference when I'm working on a piece of software that I'm passionate about vs an app that consider misguided.

Either I completely misunderstood the article, or ...

I also had a similar feeling, and I think it's more productive to focus on results and goals, rather than "winning" or "losing". Nobody wants to be a loser.

Further, I don't like the term battle, as it has a negative connotation, and this is exactly what you need to control or even to get rid of in a team: battle, win/lose, blood, emotions, arguments.

In general I find the article pretty superficial and somewhat biased. In a real work environment you might have the best idea ever that might lead the product/company towards success, however, in front of you there is a senior dev/team lead to convince, and he is defensive and negative (and who knows, maybe he is having a bad moment in his life). How do you "win" this "battle"? By rationally "showing the numbers"? If we were all robots, this approach would possibly work, but in a team of 5 people there are 5 animals with 1) emotions, 2) personal problems, 3) different personalities, with ambitions, etc etc.