

Ask HN: How to avoid arguing over trivialities? - aminuit

I work on a team with 8 or 9 people who all have different specialties, but from time to time we experience a lot of overlap, especially when it comes to crunch time on a big project.  Invariably we end up making a big deal over some small issue, be it version control conventions, variable naming schemes, or tabs vs. spaces.  In other words, we're at loggerheads over some issue where reaching an agreement is more important than whatever the agreement is.<p>What do you do speed things along without pissing off your coworkers?  We have non-technical but otherwise awesome management, and no official technical leadership.  We like it that way.  I think we all have an appreciation for the egalitarianism within the group, but sometimes it can be an impediment.
======
comatose_kid
Have coding standards. This way, you only have to argue about these kinds of
tedious issues once.

~~~
aminuit
I see where my examples were largely limited to coding conventions, but the
point was that when we are free to work on our own we all have our preferences
for everything. And we all do our own thing when it only involves only
ourselves. Here is another for instance that is somewhat less trivial (I'm a
C++ guy):

"Why should I have to use use this boost::shared_ptr for everything? This
class clearly has ownership of this data. I'll take care of everything in the
destructor. If you need a copy, make a _copy_. I'll write you a deep copy
function if you want."

"But I don't want to make a copy. It's inefficient and I find it unnecessary.
Just use boost::shared_ptr for everything and it will all be ok"

... for code that will probably not be used anywhere in a performance-critical
section of the code but it's hard to know in advance.

~~~
inerte
Just have a method. Any method. Democracy is nice. If more people agree on
something than the rest, it's the way it'll be done.

And somedays you have to tell people to suck it up. "Oh, two spaces
indentation in Python is how Google does it? Well, it's not how we're doing
here".

When it's allowed to break the rules? When the method you choose allows it.
For example, breaking code convention is a no-no under whatever. But
boost::shared_ptr? What everyone else on the team thinks? What does your
"method" says? That performance is more important than readbility?

If you have a prima donna developer who doesn't accept his peer decisions,
then you have a bigger problem than just silly arguments. You've built the
wrong team :p

Smart people love being corrected, most of the time. They're in it for the
learning, not to display their awesomeness.

