2. I will value flexibility over repetition
Just because it worked last time doesn't mean it's the only way to do it this time. And did it really work as well last time as it could have? Has absolutely nothing changed -- neither the options available, the staff available, nor the expertise of the staff -- that might make an option viable now that wasn't viable earlier? Try to keep an open mind when team members raise new methods that haven't been tried. And even when the decision is made to reject a certain idea for this iteration of a project, don't be too quick to dismiss it if the same idea is proposed the next time.
3. I will weigh all the considerations before arriving at a decision
Be particularly wary of qualitative adjectives, such as "faster," "smaller," "easier," "more scalable," and "more robust" when arguing in favor of tools. Like synthetic benchmarks, they seldom tell the whole story. It may be true that the best-written C++ code will outperform the best-written Java code at the same task. But are the C++ programmers on your team really the best in the business? Does performance outweigh other considerations, such as code maintainability or ease of memory management? For some projects, time to market might be the most important factor; in those cases, the "best" tool for the job might simply be the one that gets it done fastest. Make sure you understand your project's priorities before you argue in favor of any tool.
4. I will recognize the deficiencies of my tools, even ones I prefer
I have yet to see a language, method, or process that is equally good at everything. For example, C might be the only language that makes sense for a project like the Linux kernel, but it's lousy for text processing. Agile methods might work wonders in small groups but fall apart at enterprise-wide scale. Foolish programmers are those who agitate for a specific tool again and again simply because it's the one they understand best; wise programmers are those who are willing to set aside their favorite methods when, deep down, they know they aren't ideally suited to the task at hand.
5. I will not make the perfect the enemy of the good
We've all seen terrible code, and we've all seen the completely wrong tool bent to a task it was never meant to handle. These are the worst-case scenarios. Other times, however, a less-than-optimal solution that achieves the objective is preferable to an ideal solution that's too difficult to implement in the time allotted. It's important that experienced developers raise concerns when they recognize problem areas, but once those issues have been aired, it's time to set the debate aside and focus on the goal. Some fights are better left for another day.
6. I will admit my mistakes, rather than compound them
We're all wrong some of the time. We all put our feet in our mouths some of the time. No matter how experienced you are, no matter how sure you are of your footing, sooner or later you'll probably meet someone who understands a problem or tool better than you do. These moments aren't defeats. They are opportunities. To be a good advocate, you should not only be self-assured enough to argue passionately for your position, but also self-aware enough to recognize a lesson worth learning.
Failing that, you can always go home and bicker on a message board -- and good luck to you.
This article, "My manifesto: Only an idiot would disagree," originally appeared at InfoWorld.com. Read more of Neil McAllister's Fatal Exception blog and follow the latest news in programming at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.