
How to Pick Your Battles on a Software Team - philk10
https://spin.atomicobject.com/2016/06/21/pick-battles-software-team/#.V2k-lErouZc.hackernews
======
whack
I 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 person in the team
expected to voice suggestions and concerns whenever they see them. In a team
where people aren't constantly trying to jockey for position, where people are
open to discussions without getting caught up in their egos, having people
bring up suggestions freely is of great benefit to the team and the project.

Maybe the real question that needs to be asked isn't how to "pick your
battles", but rather, how to build an organization where people can contribute
suggestions and concerns, without getting themselves dragged into a battle.

~~~
nilved
> I 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.

This is true, but practical. Most people will never work on a functional team.

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

~~~
jacquesm
> 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 can choose to (1) accept this and be of help as good as I
can or (2) revisit every decision already made and to argue about them.

My attitude is to choose (1) wholeheartedly because that's much more useful
than (2) _even_ if I might be right about some of those decisions.

If a choice is an existential one (as in, the company depends critically on
the right choice in the longer term) then by all means, spend a great deal of
time on the decision. But don't turn each and every choice into a 'my way or
your way' discussion. It's pointless, it takes up way too much time and in the
end _a_ way is usually far more important than _the_ way.

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

~~~
jacquesm
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 that 'work / life balance' is precisely there, because
teamwork costs energy and spending time away from each other is as important
as spending time together, and there is more to life than code.

A couple of years ago I spent some time re-factoring a huge code-base that had
totally gone off the rails. The guy that ran the project and I clashed quite
badly when it came to the code and our approach to it (but since he asked me
to help it was fairly clear that he was out of his depth from a programming
perspective). When I got there there was no version control, the code was a
giant hairball and literally nothing worked.

We spent the better part of two years untangling the mess and at each and
every turn he'd dig in and make progress just about impossible. I tried very
hard to keep my cool in all this and to just resort to _facts_ rather than ego
and I think that's the only reason that we did not end up in an actual fight.

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.

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

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

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

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

~~~
AlexCoventry
_Getting to Yes_ is a far, far better book than _How to Win Friends_ , with a
much more nuanced and broadly useful perspective.

------
dbcurtis
The article strikes me as immature responses to immature behavior from others.
It's a How-To for creating a caustic environment.

Try this:

    
    
      def leadership():
        while true:
          have_clear_goals()
          articulate_goals_clearly()
    

There is other stuff to good management, sure. But this will go a long way.

The section on "when someone makes it personal" really irks me. It should
never be personal in a healthy organization. You can vigorously debate the
design, the implementation, or any other issue, while keeping the focus on the
issue. It never needs to be personal. If it ever gets personal, a manager must
step in and immediately squash that and make it clear "That's not how we
debate things here. Personal attacks are unacceptable. Focus on the issues."

But, really. Just have clear goals, then most decisions will make themselves.
Debates can be settled by measuring alternatives against the goals. If, when
measured against the goals, there is no clearly winning solution, then which
one you pick probably doesn't matter, so everyone should stop wasting energy
on decisions that don't matter and focus on the ones that do.

~~~
ryanmarsh
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 signal fitness and interpret fitness signals from others. If leadership
does not pound these into the organization from their unique vantage point
then the system will adopt its own in the vacuum. Rarely does such a scenario
turn out optimal for all participants (for reasons beyond the scope of this
comment).

~~~
dbcurtis
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 your mind
whatsoever what he wanted and when he wanted it. 2) He then asked you if you
had everything you needed to get the job done. And then he listened to what
you said until he was certain that he understood, and got you what you needed
or adjusted the plan.

When you think about it, failure to do those two things as a commando officer
means having to write unpleasant letters to parents.

I mentioned this to another friend, also ex-commando (Royal Navy Special Ops
Diver "We taught the SEALs how to do it.") He told me he often spent days
thinking about exactly the right words to articulate the goal to his unit.

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

------
arielweisberg
People (and I include myself) are lazy and will present that laziness via
technical arguments and pretending not to understand/remember what you are
saying. It's the steady string of previously debunked straw-man arguments or
orthogonal unrelated objections that is the tell tale signal. If you keep
pushing you are just burning relationship currency.

If you dig in for every single little thing your going to be the bad guy org
wide because people don't have enough context in most development workflows
and aren't going to put in the effort to understand the technical or timeline
issues at stake. You will just be the one who makes a fuss all the time. I've
watch some solid people get pushed out due to this.

As long as the harm is minimal I'll point it out and let it slide if the
objections go off the rails even if the cost to do it right/better is less
than the value realized from doing it right/better. Discussion isn't free.
When the cost of dragging the discussion out is commensurate to the harm or
value realized then that is when I will tax both myself and others involved in
the discussion to address it.

This is one reason to have these discussions before code is written and people
are invested in not having to make changes. If you are brutal and break things
down into small chunks delivered regularly the latitude for things to go
sideways is reduced and discussion is more productive.

~~~
jacquesm
> Discussion isn't free.

Exactly, that's the key insight to have. Making the discussions more important
than the project is a pretty good way to derail anything, there has to be some
sense of proportionality.

------
jacquesm
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
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. If that
happens too frequently then maybe ask to be transfered to another team or
maybe leave for another company.

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

I've had someone in our little group at TT who would approach each and every
little item like a battle and I was very glad when he moved on, it's fairly
easy to destroy an otherwise winning team when someone starts to treat the
process of software development as something that can be won or lost.

There is work to be done, and if we do it well we _all_ win, and if we mess up
then we _all_ lose.

~~~
ksk
>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"

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

I agree, and I've had to learn this the hard way after leaving 4-5 separate
gigs that went fine for several months until someone new came on, or until an
issue came to a head, etc. As software engineers, we have a lot of mobility
and it's almost _too_ easy to throw in the towel and move on; in any career,
there are going to be conflicts, and you have to learn to confront and
neutralize them in a positive way that _doesn 't_ involve the departure of
yourself or the person with whom you're conflicting. "I'll quit" is too often
the go-to and can stifle the development of individual professional conflict
resolution skills. That option should stay off the table practically up until
the point of complete collapse.

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

Right on again. This is another thing that I had to learn in the crucible
after years of reading idealistic navel-gazing in trade outlets and message
boards. There was a time I believed that while it required being highly
selective, you could get a team together that would hold these values and
function without pettiness. I now believe that's not really possible long-term
and we must accept the petty and political nature of man as a fact of life
(and we should be aware of this nature within ourselves as well, instead of
naively claiming that we are above all of it; only regular rigorous self-
analysis can reveal the influence of these natural tendencies). Not only is
that political nature a fact of life, but it is exacerbated and brought to the
forefront by the economic structure and corporate culture that we've developed
in the West (which is not to say those things are necessarily bad).

I'd really like to see more content about coping with the reality of what we
have in the real world, instead of the fantastic idealistic drivel that makes
some tech writers popular.

------
samlikescode
I think this is a really great article. It's unfortunate that people see a
word like "battle" and assume that it is meant aggressively. It is just a
theme for highlighting the reality that developers and designers disagree all
the time. When you work with intelligent individuals who are passionate about
what they are doing, there are going to be strong opinions. These situations
can get intense, and it is exceedingly difficult when the other party thinks
less of your opinion - like because you're a girl. Solid article on a tough
topic.

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

------
grandalf
Most of the tensions described in the article are things that I believe can be
modeled in terms of debts. It depends on which kinds of debt your team
willingly takes on. Most teams take on at least one or two types routinely, no
matter how religiously they avoid the others:

Technical Debt:

\- build it fast by any means necessary

\- use whatever pre-packaged library exists, and duct tape it into your
existing system.

Analytics Debt:

\- build it without any prior UX experimentation on the design.

\- build it without any way to measure key interactions

\- have no data about the status quo before you build something new, this will
insure that your new feature is a success because the before numbers are
unknown.

Marketing Debt:

\- build it without knowing whether users want it (or what they want)

\- build it without talking to users about their problems.

Spec Debt:

\- build it without creating a detailed spec, leaving many important decisions
up to the developer, who may not know the full reasoning for what she is
building.

\- have a print designer do the UX, so that many subtle areas of interaction,
animation, and behavior are unspecified.

Mental Model Debt:

\- build it without having a hypothesis about why it is helpful and what might
need to be changed next. This helps your engineers make choices that speed up
this feature but add significant complexity for the next step.

\- do not worry about the statistical significance of numbers. Just focus on
the direction the numbers are going and be sure your CEO knows how smart you
are.

Credibility Debt:

\- Don't acknowledge things that have gone wrong (with planning or execution)
before. The pretense of infallibility is helpful to creating resentment and
mistrust among different divisions of your team.

Kool Aid Debt:

\- Whatever you do, be sure it is "agile" or "scrum" because then you have
done everything right and you didn't need to worry about any of the above
forms of debt.

------
heartsucker
I 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 way it needs to be done.

I agree that approach matters, but let's not call it "battle skills," how
about "not being a dick to your coworkers" and "interpersonal skills."

If software development teams really are teams, take it from sports. Sometimes
the captain needs to say "this is the playbook we're using, end of story" and
everyone needs to trust that they're captain for a reason.

~~~
sleepychu
"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 server."

~~~
heartsucker
Please read about SQL injection[0]. Not using a library that escapes your
strings is how Bobby Tables[1] ruins your production database.

[0] -
[https://en.wikipedia.org/wiki/SQL_injection#Incorrectly_filt...](https://en.wikipedia.org/wiki/SQL_injection#Incorrectly_filtered_escape_characters)

[1] - [https://xkcd.com/327/](https://xkcd.com/327/)

~~~
sleepychu
Love that XKCD :-)

Maybe I misunderstood what you had in mind when you wrote string concatenation
but concatenating untrusted raw strings and using a library to construct SQL
queries are not the only two ways to produce a SQL query.

------
alarge
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)"

~~~
dbcurtis
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?".

~~~
rhizome
The Iron Law of Institutions:

[http://rationalwiki.org/wiki/Iron_law_of_institutions](http://rationalwiki.org/wiki/Iron_law_of_institutions)

------
makecheck
Your experience/talent should dictate _how much_ you press on an issue, and
you should do it professionally regardless (e.g. no yelling, and listen to
people; calmly state your point of view).

Over the years I have encountered people arguing passionately about things
that, as it turns out, they did not fully understand. It is fine to not
understand things but if you’re new to a language/team, you should be saying
things like “shouldn’t we do X?” or “I read on [site] that X is better”, and
not act like you have found the One True Way to do everything.

Ultimately, you need to communicate some experience/example showing why it is
important to do X, or you must be in a position of authority where you can say
that you choose X because there is no clear decision among the alternatives.

------
eloycoto
I'm in the middle of this problem and not sure If I'm doing something wrong.

In the next month we are going to launch a new product, I'm full stack dev and
I'm bit frustrated with my colleagues. I did all the devops and all
developers(5) has his vagrant per branch, each vagrant box is deployed in one
box so they can show to another colleague without trouble (I built a server
with the subdomain with the $TASK-ID.subdomain) and the workflow is correct
for all of them and they are happy. To deploy to staging/prod we have a full
terraform + consul so we're in a happy place.

In terms of code this is painful, they didn't make any test, I made around 50
test 1 month ago to show to them how to make test, but in one month, only one
test was added in the project. In terms of the code-review they complain about
good indention, and each time that they made a Pull-Request (pep8 and
pyflakes) is not passed, and they use to complain about it. They use to mark
task as resolved before code got merged, things to weird that I can't explain.

I tried to explain why things need to change, I made a workflow in plantuml
and they are complaining that it's too difficult. I'm the only one that made
commits in the docs folder.

Nowadays I'm thinking to switch to another company, but I'm happy with my
manager (He is too honest), but the team is killing me, and I don't feel
comfortable with them, I rarely learn from them and they don't want to do
things better, they only want to work to raise money.

This is a dead battle? Or can I fix this?

~~~
jacquesm
You can fix it but it will take time and you will need to be _very_ patient.

(1) let go of your frustration, it is not helping you, if you can't GOTO 3.

(2) pick the _best_ of your colleagues and try to lift him/her up to your
level with _arguments_ , not with force (this will take time and oceans of
patience)

(3) if that does not work, start looking for other employment, no matter how
much you like your boss

(4) if it _does_ work, then now you have a buddy, who already knows your
method works, rinse and repeat at (2) until you've either had enough of it or
you find that you now have a well oiled team.

Good luck! (You'll need it, this is not an easy thing to do). And if you
manage to make this work you are management material yourself.

~~~
TheCowboy
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? Maybe OP is perceived as pushy if he's not the manager, or
he doesn't allow for enough input on how the process evolves if he is the
manager.

~~~
eloycoto
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 but it didn't work.

#2 worked well with the vagrant box, at first days was too complex, now they
loved.. but with test and pep8 code style is a long battle. I think that I'm
trying to change how they use to work, and they don't want to change how they
work.

I always use to explain that, as a friend, is good for all, but I can't get
it.

#1 Yes, me too, but when you reviewed 18 PR in 2 days without good code
indention, half of them didn't work and 70% was mark as resolved in the task-
manager I need to run a marathon every morning to keep away my frustration.
Maybe was that last week I was on holidays and these days I only fixed
problems.

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

------
haihaibye
Interesting article, I like the focus on interdeveloper relationships.
Software is a team sport, there should be more articles on this underserved
area. We probably have more text dedicated to tabs vs spaces.

------
boundring
There'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 issue. There's no such thing as a "perfect"
team, but it seems his idea of that involves consensus.

Consensus is an abstract, reality is defined by multiple viewpoints.

~~~
mixmastamyk
It may be a cultural thing.

------
jcadam
At my current job we have a prima-donna software engineer who wins 90%+ of all
battles simply because he throws a giant tantrum whenever a disagreement comes
up. People (including the boss) usually just give in to shut him up.

It's to the point people won't critique his work because he gets defensive and
throws a giant hissy-fit if you suggest his explosion-at-the-pattern-factory
nightmare of a module isn't just the most awesome piece of code ever created.

------
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...](https://medium.com/@GedRap/when-working-with-other-people-you-will-
have-battles-d03b04bb6705#.8ezmi3llb)

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.

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

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

~~~
RangerScience
I am all on-board with reasons with critique. I guess I'm asking about the
difference between: "I think this is good/bad because..." and "This is
good/bad because...."

The latter one is just dropping words; it's still a think you think, whether
you acknowledge that or not.

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

~~~
dclowd9901
This is something you have to decide organizationally. For our part as a
frontend team, we've decided when we implement a new feature, it won't be in
our old framework. Ever. We've built a way to integrate React into our old
world areas of our code. Furthermore, the portion of the old world code that
this new React code interacts with will also be converted into React. This
way, our code has a sort of 100%+1% movement toward the new framework.

The point is, you need to figure this out as a group and then just implement
it as a rule. It can't happen during the code review.

------
delecti
Most of Amazon's corporate principles are a bunch of management buzz words,
but situations to apply one of them pop up fairly often in design discussions.
"Disagree and Commit"

You're not always going to think that the design the team settled on is the
perfect, but if you've laid all your evidence on the table and the team goes
the other way, then you go the other way.

------
gwbas1c
Honestly, if there are that many battles in a developer's day, it's a sign of
mismanagement. Some bad company leaders think that the right thing to do is
constantly have people negotiate over silly details.

~~~
jacquesm
> Honestly, if there are that many battles in a developer's day, it's a sign
> of mismanagement.

Or a bad hire.

~~~
dbcurtis
Maybe. The article outlines some behaviors that a good manager would
immediately squash. Most people will conform themselves to the prevailing
culture. When bad behavior is confronted honestly, squarely, and articulately
by a manager, the offender usually conforms to the healthier cultural norms as
articulated by the manager. Only if the bad behavior is confronted and still
persists can you call it a truly bad hire. In which case it should be dealt
with. No amount of productivity justifies being a jack-ass.

------
pascal1usa
At our company code reviews are my way or the highway. Raising objections only
gets you negative feedback. It's mostly for coding style, spaces, variable
names.

------
poorman
I wish I could tag people in hacker news articles.

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

