Part of being a programmer should be communicating clearly to your peers. Your peers can be other programmers, managers, and even clients. If you can't speak in terms they can understand, you're not being helpful, and especially, you're not being very effective.
When the other party can't clearly understand what you're saying, they are more likely to misinterpret it. That misunderstanding will probably return in the form of demands that are unrealistic, impossible, or, in your opinion, just plain stupid. Since you can't explain clearly why these requests are unrealistic, impossible, or some diplomatic euphemism for "stupid", then no matter what you say, they think you're making a big deal out of nothing. You're upset at their requests, and they're upset at your nonsensical complaining.
The classic "rift" in tech companies seems to between sales/marketing and the technical department, usually programmers and engineers. They are, from a psychological perspective, about as incompatible as you can get.
When "sales and marketing" people talk to "the techies", they speak their own "sales and marketing" language, and not surprisingly, the reverse is true. In order to be effective, both sides must make an effort to bridge that gap, and one of the easiest ways to do this is to use plain language. If both sides refuse to compromise, you might as well have one group speaking Swedish and the other Korean. Nothing is going to be communicated except vague notions of what the problems and requirements are, and both sides feel abused.
In line with your "number one programmers motto", think of that in terms of the collective, not on an individual level. If Party A communicates something to Party B in 10 seconds, but it takes Party B five minutes to figure out what Party A really said, is that productive? If Party A instead took 30 seconds to give a full explanation, then it would end there. It's about conserving effort on a broader scale. | [reply] |