Live data from Hacker News

How to Pick Your Battles on a Software Team

spin.atomicobject.com

91–100 of 141 posts

Re: How to Pick Your Battles on a Software Team

#91

Earlier quoted context omitted.

I think it's not clear if he is the project manager or not. If he has a project manager, then we have to ask why he isn't helping focus the team. Or are they are product a team that is expected to organize themselves. I agree strongly with #1. #2 I think it might be good to approach it by asking more questions. If people say it is hard, ask how can we achieve the goal of writing more tests without it being a burden?…

Hey, 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…

I didn't realize it was remote. I think that changes things, since it's difficult to nail the relationship-building part as a remote worker. I think communication is going to be the biggest challenge, particularly if different people don't speak English as their first language.

An email with links and explanations might just fly over the head of a lot of people. One approach I used when working remotely is making short videos, or walking people through things using something like TeamViewer.

Re: How to Pick Your Battles on a Software Team

#92

Earlier quoted context omitted.

> How about some good old consensus? My concern with consensus, is that most teams are comprised of a single or two senior people supported with a larger number of less senior people. If consensus is the protocol-de-jour, your service/product/offering suffers in the mid-to-long term (as well as alienation of the senior people whom you want driving).

> If consensus is the protocol-du-jour, your service/product/offering suffers in the mid-to-long term (as well as alienation of the senior people whom you want driving). I don't believe that is true. Junior people are only junior people if you treat them like that. If you are the lead dev and you work together with people junior to you (in experience, possibly not in years) then the fastest way to get them to grow is…

I think he's talking about the support aspect. When a group decision is made, the actions taken are often not a group effort. If the group decided to do X but most of the people capable of acting wanted to do Y, you're going to have problems.

Nothing makes me bristle more than having to clean up after mistake that I warned the team not to make in the first place.

Re: How to Pick Your Battles on a Software Team

#93

Earlier quoted context omitted.

Your "(1)" is, by the very definition of the concept, "picking your battles." This is because you aren't pushing issues. The whole article is about making a way more important, but also recognizing that valid concerns deserve to be addressed. Balance.

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 m…

So you don't report bugs?

Re: How to Pick Your Battles on a Software Team

#94
post #13
post #3

Earlier quoted context omitted.

I fully agree. When working on a team, you have to think about the future not only the current moment. If every time you have a disagreement it results in a win-lose situation I can guarantee you the mood among the your team will go down quite rapidly. I would suggest 'Getting to yes' by Bruce Patton, Roger Fisher, and William Ury on this matter of negotiation.

I don't know this book - thanks for the advice. I would recommend "How to win friends and influence people", which gives also good advice and a lot of hints.

Getting to Yes is a far, far better book than How to Win Friends, with a much more nuanced and broadly useful perspective.

Re: How to Pick Your Battles on a Software Team

#95

Earlier quoted context omitted.

"Not every battle is going to be a winning one, and understanding when to challenge a teammate and when to hold back is a skill that can only be developed with practice. The battles I’ve lost by not being prepared, the battles I’ve lost by picking on something trivial, and the battles I should have started—but didn’t—are what inspired this blog post." "The more stressful a situation is, the more I find pragmatism is…

Think of it as a mindset. OP is still sketching things in these terms and has not moved beyond it. That is where the problem lies. Not in not being prepared, by arguing about something trivial or by battles that were not started but did not. As soon as you start phrasing things in these terms everybody loses .

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.

Re: How to Pick Your Battles on a Software Team

#96
I've been thinking about the word "ideology" lately. What does it mean?

My grandfather was imprisoned by the Nazis and later fought for a Trotskist partisan militia. He hated "communists." According to him (as far as I understood), the defining feature of "communist" was fanaticism. The communists at that time, fighting Nazi & Fascist occupations or orchestrating revolutions under their ideological flag were ideological devotees. We remember Nazism and the madness that took a hold of Germany but I think we forget the context. Other ideologies of the period were less of an evil archetype, but not less devoted ideologically. Often they were just as bloody, if not in the same cold way. The communists that played the archetype role in my grandfather's experience (I assume his comrades, but IDK) must have been very fanatical. "A communist is someone who would sacrifice his mother for the cause" was how he'd describe it. This didn't (as far as I know) have much to do with what we might call "socialist" policy now. This wasn't an opinion about economics or social policy.

Anyway... in a software context, the word ideology gets thrown around, often in a derogatory way. It's surprisingly hard to define it. I think a lot of the conflict points (losing battles) alluded to here are likely to have at least one person pissed off at the other's stupid ideology.

"Agile" is the obvious one to bring up. This is mostly because it has a name, it's been successful enough to have beeen bastardized and tortured many times and it has a manifesto. But there are a lot of things like that.

I haven't come up with a good definition, but I think a good chunk of it has to do with this: Ideology is contextual. When you're argueing for 'X' ideologically, you can't explain your reasons without going into a lot of abstract preamble. This is annoying to the people who disagree with the background reasoning and to those that have never looked into it. To them it sounds like you're saying "just because." Ideological bullshit.

In a political context, one might be a libertarian. This has implications about the legal status of recreational ketamine, minimum wages, building codes, school funding and the approval process for new pharmaceuticals. It all ties in logically to the Libertarian perspective. But, if a libertarian is trying to be centrist, pragmatic, get elected or convince others to make laws then they have a choice. They can be "ideological" and talk about non-coercion or emergence or whatever forms the base of their ideological position. This then becomes about the ideology, not the specific thing. Or, they can talk about the specific thing, the law or policy. They can point to some study on minimum wages and unemployment or innovation and regulation in the pharmaceutical sector or whatever. This often feels contrived. That study isn't what convinced the idealist, the ideology convinced him.

I don't know how this gets solved. I do think that it's important to keep a record though. what ideology do I subscribe to. Realize that when you disagree for ideological reasons, that you are entering tricky territory.

As a side note, common ideologies are great for cooperation.

Re: How to Pick Your Battles on a Software Team

#97
post #49

Earlier quoted context omitted.

> How about some good old consensus? How about it? What do you do when there is no consensus, because people genuinely, honestly disagree? Sometimes consensus is impossible.

Arbitrage. And then you move on .

This. Is. What. The. Article. Is. Telling. People. To. Do.

Re: How to Pick Your Battles on a Software Team

#98

Earlier quoted context omitted.

Even a great team can be dysfunctional. It's crazy to pretend like a software team will not have disagreements from time-to-time.

> Even a great team can be dysfunctional. By definition it can't. > It's crazy to pretend like a software team will not have disagreements from time-to-time. Sure you can have disagreements. So then you all present your arguments figure out which way forward is the best with as little ego thrown in as possible and move on. Right now I'm involved on the side with a project where a ton of decisions have already made. I…

> > Even a great team can be dysfunctional.

> By definition it can't.

Only if you assume that dysfunction is either a steady state and does not fluctuate, or that there exists two binary states of function and dysfunction, and nothing in between, or both.

If either of those are true, then it's possible to be on a great team (which is itself relative), and still either have aspects that are dysfunctional, or periods where it goes into dysfunction.

> Sure you can have disagreements. So then you all present your arguments figure out which way forward is the best with as little ego thrown in as possible and move on.

Sometimes, when that decision keeps coming back to bite you, and possibly you in particular, you feel the need to keep bringing it up, so others know it's an ongoing problem. That can be seen by others as someone not letting a decision go.

Does that engineering choice that resulted in a somewhat frail system keep coming back to bite you? Congratulations, now you're presented with keeping your mouth shut and just fixing it every time it breaks, or speaking up when it breaks so that people know it's a continual problem, and risk others thinking you are just complaining more, and promoting team dysfunction, or some happy medium, but where is that medium?

Re: How to Pick Your Battles on a Software Team

#99
post #51

Earlier quoted context omitted.

> Even a great team can be dysfunctional. By definition it can't. > It's crazy to pretend like a software team will not have disagreements from time-to-time. Sure you can have disagreements. So then you all present your arguments figure out which way forward is the best with as little ego thrown in as possible and move on. Right now I'm involved on the side with a project where a ton of decisions have already made. I…

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.

Re: How to Pick Your Battles on a Software Team

#100

Earlier quoted context omitted.

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 m…

So you don't report bugs?

I think we're done. Your categorical un-charitable interpretation of my comments and persistent use of straw-men in this thread make be believe that further interaction with you is un-productive.

I'm not sure what you intend to gain with misinterpreting what I wrote but it makes no sense to me. Enjoy HN.

Post reply on HN