Ask HN: How to avoid arguing over trivialities?
1 comments
Have coding standards. This way, you only have to argue about these kinds of tedious issues once.
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.
"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.
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.
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.
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.