Earlier quoted context omitted.
This. Is. What. The. Article. Is. Telling. People. To. Do.
You either don't understand the word arbitrage or you really didn't read the article.
"move on"
How to Pick Your Battles on a Software Team
121–130 of 141 posts
Re: How to Pick Your Battles on a Software Team
#122I think this article misses the point that somethings are also completely right or completely wrong. For example, using string concatenation to build HTML and SQL. This is, just about always, a very bad idea. If a team is entrenched in doing this, it's not going to be a "winning battle" to undo it. You're going to anger the devs by changing all their code or making them use new libraries or whatever, but this is the…
What if the captain is the one who says you have to use string concatenation for HTML and SQL?
Then you either get off the plane or die with him.
Re: How to Pick Your Battles on a Software Team
#123I think this article misses the point that somethings are also completely right or completely wrong. For example, using string concatenation to build HTML and SQL. This is, just about always, a very bad idea. If a team is entrenched in doing this, it's not going to be a "winning battle" to undo it. You're going to anger the devs by changing all their code or making them use new libraries or whatever, but this is the…
"but this is the way it needs to be done." Actually, I'd disagree. It doesn't need to be done that way and this is a good example of a battle you're likely to lose that won't really cost you anything (other than some unpleasantness hand crafting SQL queries). I'd argue that even with significant opposition, any battle that needs to be won can. "I don't think we should store all the user passwords in plaintext on the…
On the contrary, if you're working with people that dense, it's very unlikely that you'll make any progress on technical grounds. It's hard even among intelligent people.
The reality is that most people do not make value judgments based on objective criteria of any kind. This is true even among technical people, who rapidly build religious precepts around their nearly-arbitrarily-chosen pet technologies and then discard anyone who doesn't present with the tokens and signs of their adopted technical religion, regardless of that person's true technical ability.
People make judgments based on the amount of personal trust and goodwill they have toward the person making the argument. That's the natural status. With a lot of exercise, people can partially limit the effects of this impulse, but very few train at this in any significant way.
The moral of the story is that the way to win arguments is to be well-liked. It's a popularity contest. If you want people to let you do what you want, you have to make them like you. The objective merits of whatever you're arguing about are practically irrelevant.
Re: How to Pick Your Battles on a Software Team
#124Earlier quoted context omitted.
I'm starting to understand your position a little better. You're against someone being open when they disagree with something, whether or not their position is valid? That's a little ridiculous. Being Taoist in withdrawal from conflict is one thing, but being a responsible member of a group is another.
You keep putting words in my mouth, the parent comment is a classic strawman and I refuse to be drawn out into a debate at this level. Good luck.
My observer take is that you two (and perhaps others) seem to disagree on the definition of the word "disagreement" (haha).
Jacques appears to take a view that disagreement (or "picking battles") is tantamount to a fist fight, which obviously should be avoided. But, I think the OP and others discussing here rather think of of it as merely a difference of opinion, to be noted and moved past. In that sense, "avoiding disagreement" is not helpful because they are not noted, but buried.
Re: How to Pick Your Battles on a Software Team
#125Earlier quoted context omitted.
There are team players and there are solists, it's rare to find people that can be both. If you feel that 'software is art', that 'you are going to have problems with ego' then probably your view is that of the solist, and likely not of someone who would be happy in a team unless they get to call the shots and impose their will on others. Good teams simply follow the leader and take their paycheck. Great teams cause…
Any thoughts on where the best opportunities for those you'd describe as solists (not a term I've heard before -- I initially read it as "soloist") currently lie?
Trouble shooter, smaller projects where the output is very well defined (for instance: tuning and optimization), indie games.
Re: How to Pick Your Battles on a Software Team
#126I agree with the author's advice, but a part of me can't help but feel that "picking your battles" is a sign of a poorly functional team. The entire premise behind "picking your battles" is that battles are expensive, and hence, you can't afford to fight every battle. But in a highly functioning team, bringing up suggestions and points for discussion shouldn't be expensive. It should be natural and fluid, with every…
The key is not to think of an organization in military terms, hence my opinion here: https://news.ycombinator.com/item?id=11919593
Re: How to Pick Your Battles on a Software Team
#127Earlier quoted context omitted.
Completely different context, but still a creative team, look at musical groups like the Ramones, Fleetwood Mac, many others who could hardly stand to be in the same room together offstage but still managed to make some great music. Dysfunctional groups can still do great things.
The Ramones did almost all their great music before Joey and Johnny stopped talking. Before that it was a bit of a madhouse, but they got a ton done. Which I guess confirms your point.
It definitely casts the lie to "culture fit." You don't have to be lunch buddies to do good work together.
Re: How to Pick Your Battles on a Software Team
#128This 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 th…
I think the article is looking for winners and losers in the wrong place. There will inevitably be winning and losing companies . People that put more energy into making sure that they, personally, win over other people in the organization are not focused on making sure the company wins. Asking "How do I win?" is a very different question from asking "How do we make the company win?".
The Iron Law of Institutions:
Re: How to Pick Your Battles on a Software Team
#129There's nothing caustic about self-censoring when your view isn't worth the headaches it might give others. In terms of development, you have to respect the views of your teammates and the effect of your position on overall workflow. Edit: for clarity, there's basically one guy here who's made it some sort of vendetta to object to the entire concept of a "battle," as though using that word for a disagreement is the i…
It may be a cultural thing.
Re: How to Pick Your Battles on a Software Team
#130I agree with the author's advice, but a part of me can't help but feel that "picking your battles" is a sign of a poorly functional team. The entire premise behind "picking your battles" is that battles are expensive, and hence, you can't afford to fight every battle. But in a highly functioning team, bringing up suggestions and points for discussion shouldn't be expensive. It should be natural and fluid, with every…
I think that's what the author defines as a "winning" battle. Notice that "winning" and "losing" in the article are NOT "my idea won" and "my idea lost", but rather... "bringing this up netted improvement" and "bringing this up netted bad feelings".