Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to Pick Your Battles on a Software Team

spin.atomicobject.com

Post reply on HN
Print view View original

131–140 of 141 posts

Re: How to Pick Your Battles on a Software Team

#131

Post by RangerScience »

I have a question, that bothers me a lot:

When someone says "there's a better way to do it", aren't they actually saying "[I think that] there's a better way to do it"?

I think I understand that saying, simply, "I don't like the way this is done" isn't helpful, but I don't see how it's necessarily "personal", or rather, that any critique can be anything other than personal. Anything you say is expressing a thing you think. How can it be otherwise?

I have definitely fought hard-lost battles, and everyone came out the worse for them... but it's still hard for me to understand why they happen, because anything you express is, by definition, something you think is true. Leaving out the words, it seems to me, just makes your expression less genuine.

Re: How to Pick Your Battles on a Software Team

#132

Post by ryanmarsh »

dbcurtis wrote: post #114
ryanmarsh wrote: post #69

Earlier quoted context omitted.

This! 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 si…

It is interesting that you mention military experience. The best manager I ever worked for had been an Israeli commando officer during the military service portion of his life. (If you remember the rescue at Entebbe, he was in the "Plan B" unit that was staged and ready to go in without the element of surprise should Plan A fail. Happily, Plan A worked.) So what made him a great manager? 1) You never had any doubt in…

You nailed it.

Here's the mission, what do you need for the mission, and if all else fails here's my intent.

People think the military is full of mindless robots but in reality that's just how you're treated during indoctrination. Combat leaders must enable their people to thrive in chaos.

Re: How to Pick Your Battles on a Software Team

#133

Post by r00fus »

jacquesm wrote: post #33
samlikescode wrote: post #26

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.

I disagree with this logic. Teams are great if their functionality ratio (functional/dysfunctional) is high and the results are good.

Teams change/vary over time, and therefore you need to have some aggregated evaluation of overall effectiveness.

Re: How to Pick Your Battles on a Software Team

#134

Post by jeanettehead17 »

RangerScience wrote: post #131

I have a question, that bothers me a lot: When someone says "there's a better way to do it", aren't they actually saying "[I think that] there's a better way to do it"? I think I understand that saying, simply, "I don't like the way this is done" isn't helpful, but I don't see how it's necessarily "personal", or rather, that any critique can be anything other than personal. Anything you say is expressing a thing you…

Author here. I like to say 'this way would be better because...' as much as possible. Providing a business case to back up your claim makes it less personal. Receiving feedback is never fun, but IMO it's easier to weather when there's a reason for that feedback being given that's more than someone else's opinion.

Also having coding guidelines/linters is important from transitioning the conversation from 'I think it should be this way' to 'our coding standards say it should be this way' and removing some ego from the conversation.

Re: How to Pick Your Battles on a Software Team

#135

Post by DougWebb »

dasmoth wrote: post #113
jacquesm wrote: post #52

Earlier 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?

I'd say it depends on just how much of a 'not team player' you are. If you want to be completely independent, developing small mobile apps, mods for games, Wordpress/Bootstrap themes, and projects like that where you can work for yourself and by yourself might be ok. If you want to code alone, but you can handle having a customer having the final say on any decision they care about, you can become an independent consultant/contractor. Next rung up on the teamwork ladder would be your typical open-source or small-business projects, where you work by yourself most of the time but your work needs to be reviewed and sometimes changed, and others will typically have the final say on decisions.

You say "best opportunities". If you're looking to earn a good living, that's hard to do solo. Very few people are good at all of the tasks that go into software development (and I'm including the non-development tasks, like sales and marketing of both the product and your development skills here). Also very few people manage to create a runaway viral hit on a small application (like Flappy Bird), where your solo work can earn enough so that you don't need to worry about making a good living on the other solo projects you choose to work on. For most developers, learning to work on teams with others is a crucial development skill.

Re: How to Pick Your Battles on a Software Team

#136

Post by zb »

jacquesm wrote: post #19

How about some good old consensus? Battles are not the way to go, regardless of the stakes. If you feel the direction a project is going in is not to your liking you can always quit. As soon as you start phrasing things in terms of battles, winning, losing and so on you're going to end up very frustrated and potentially toxic to the rest of the team. A good team member knows how to make their objections heard without…

Jacques, please stop.

The article is unfortunately ambiguous. It's pretty clear from the comments here that there are two different camps in terms of how people interpreted it.

However, it's quite clear to me that the author defines 'winning' as reaching a consensus on one person or the other's point of view, and 'losing' as battling to a stalemate or having one person impose their solution on the other. It's about the team winning or losing (or, to put it in other words, "if we do it well we all win, and if we mess up then we all lose"). 'Picking your battles' is an English idiom that means avoiding confrontations.

It's a little light on specifics, but it's not terrible advice. In fact, it's the exact same advice you are trying to impart here.

Even if you don't agree with that interpretation, I think it behooves you as a HN-famous person to at least consider the more charitable interpretation before publicly branding the author as someone whose "advice could quickly turn a functional team into a non-functional one."

Please consider re-reading the article with a view to trying to understand how other people may have interpreted it, and the author may have intended it, differently. Failing that, at least take some of your own advice and give up your scorched-earth battle to the death with the author and every commenter who read it differently. We're all losing right now.

Re: How to Pick Your Battles on a Software Team

#137

Post by eikenberry »

dasmoth wrote: post #113
jacquesm wrote: post #52

Earlier 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?

One possible opportunity for a 'solist' could be so-called DevOps positions. They are often structured more as a group of loosely cooperating people working on independent tasks. You will get a lot more say in HOW you do things vs a traditional software development team. You will of course have to deal with doing Operations like work in addition to the development (how much vary a lot based on the company/job).

This is where I've ended up due after many years as a software developer at start-ups because you can land a more stable job that pays better while not being driven crazy by micro-management.

Re: How to Pick Your Battles on a Software Team

#138

Post by boundring »

zb wrote: post #136
jacquesm wrote: post #19

How about some good old consensus? Battles are not the way to go, regardless of the stakes. If you feel the direction a project is going in is not to your liking you can always quit. As soon as you start phrasing things in terms of battles, winning, losing and so on you're going to end up very frustrated and potentially toxic to the rest of the team. A good team member knows how to make their objections heard without…

Jacques, please stop. The article is unfortunately ambiguous. It's pretty clear from the comments here that there are two different camps in terms of how people interpreted it. However, it's quite clear to me that the author defines 'winning' as reaching a consensus on one person or the other 's point of view, and 'losing' as battling to a stalemate or having one person impose their solution on the other. It's about…

You put the mood into words quite elegantly. I just couldn't find a way to explain it so thoroughly...

It's terrible when this happens in person, such a painful way to agree and yet become separate.

I don't think we all lose, though. I think these situations result in someone hurting themself more than they realize. I've been there, but I failed to frame things properly.

In person, it's about being as honest as possible, if quiet when there's a complicated issue. Being honest, you can learn in-situ when issues arise, which is very much what Jaquesm supported.

I've felt terrible seeing great engineers leave meetings upset over minor issues.

Re: How to Pick Your Battles on a Software Team

#139

Post by lsc »

jacquesm wrote: post #61
ams6110 wrote: post #51

Earlier 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.

I don't actually think it is all that different. The point you are inadvertently making is that when it mattered (on stage and while practicing) they were performing well as a team. That they didn't like each other outside of that didn't matter much, just like I don't need to personally like my colleagues in some IT project and that I don't need to hang out or spend time with them outside of work. In fact, I think th…

>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.

The hardest person I had to work with was someone who was super picky about using the right words for all social situations. If you referred to something as "your way" They would make a rather large deal of it. Most of the time, I was just trying to identify one of the two choices.

I mean, uh, the person in question was certainly worth working with, in spite of their social issues, and certainly, learning less confrontational language, you know, language less likely to set off other people is a worthwhile goal, but my point is just that if you spend too much time concentrating on the connotations of the words, rather than on the denotations, well, you can become pretty difficult to deal with for anyone who isn't used to walking on your particular brand of eggshells. Yeah, if you are good enough, we'll deal with it, but don't pretend that making a big deal out of connotations rather than denotations makes you easier to work with. It's quite the opposite.

I mean, I totally agree that minimizing ego should be a goal... but I also think it's disingenuous to pretend we don't have ego at all. We all have ego. It sucks. but it is. lying about it won't help. Acknowledging it and trying to move past it might.

Re: How to Pick Your Battles on a Software Team

#140

Post by gedrap »

Comments on this thread gave me loads of food for thoughts and I missed the thread to comment on it, so decided to write a short post: https://medium.com/@GedRap/when-working-with-other-people-yo...

tldr: We would like to think that all disagreements can be solved by rational reasoning, comparing alternatives and coming up with the best plan of action together. In an ideal world, yes, that would be the case. True, there are teams with perfect chemistry, aligned attitudes and views, no interpersonal friction, etc, but these teams are rare. It is naive to expect that every team to be perfect. We are not robots, and we are not working on some conveyor of code, moving from one to ticket to another, coldly and indifferently. Placing yourself into a position of other person, trying to understand their sometimes irrational motivations, and combining it with assuming the best intentions will go a long long way.

Post reply on HN