Programmers are human beings, and it's best to talk to them in clear English, or whatever other human language you both speak.

As a programmer, I often wish non-programmers would understand and use diagrams and plots, because they are effective ways to communicate things that are hard to put down in words.

Sometimes, to me, it's better that people that are not involved on programming do not really understand how things work on the background, because that makes it easier for them to just try to express as clearly as possible what they are looking to achieve, instead of over complicating things or trying to explain HOW would they like to achieve it, which happens sometimes when people have a little technical knowledge.

So, I believe that improving you communication skills, as a human being, is the most important thing to look after to improve teamwork, much more than to be able to draw a couple of diagrams. This is the way I see it.

Flowcharts, diagrams, and mockup pictures can often provide better detail than words can.

If you're trying to communicate the general flow of a smaller idea, sometimes pseudo-code written in structured English can help - if you know how. Don't just start using it on the spot, because it takes a bit of understanding of the structure of a programming language, and knowing what we need to hear.

Overall, as the others have pointed out, speaking plainly is best, then you're likely using a language both of you have been proficient in for years. For technical terms, be absolutely sure of them: If the word doesn't mean what you think it does, you're going to get pretty far apart on the end result. Don't try to "reach out" and use a word you've heard two or three times, thinking it's what we want to hear.

(You know this isn't targeted at you specifically, just speaking in general about the problems we've all run into!)

Programmers are human beings, and it's best to talk to them in clear English, or whatever other human language you both speak.

As a programmer, I often wish non-programmers would understand and use diagrams and plots, because they are effective ways to communicate things that are hard to put down in words.

I'd agree with alavaro. What I would add to that is this - as programmers, we also have a responsibility here. We need to communicate well not just with the creative team, but with management, other members of a team, (possibly) clients, etc.

Just prefix all your english sentences with the words "see out", and us C++ programmers will suddenly comprehend you better.

A little scripting might be beneficial to you, but just speak english and ask questions when we say something you don't understand.

The two things I would like non-programmers to know is:
A) The size of the feature does not equal the amount of work. A "small" feature does not mean a "small" amount of work. It could be a huge amount of work.
This rule is called "A small matter of programming", and is misunderstood so much that we have a term for it.

B) Unlike a painting, an entirely visual art form, where you can visually see the work progressing, 90% of the work programmers do cannot be seen or understood by non-programmers (not without us explaining what we did). We can spend days working on something that doesn't make a single visible change to the project - but that does not mean that we aren't working, or that we are behind schedule. Likewise, when the visible changes come, they can suddenly come so fast and so frequently that the the visible side of the project changes dramatically overnight.
This is tipping point of a rapid change from non-visible progress to visible progress is sometimes called a "Black triangle moment". Computer programs are like icebergs - only 10% of the program is above the surface of the water.

Alot of programmers are creative individuals. Just because our skillset (programming) may seem entirely scientific in nature, it is very much a creative process as well (similar to architectural engineering - a mix of creative and scientific skills).

Also understand that many programmers, like mules, have a terrific sense of humor. We also love making references to obscure literature, movies, or historical events - we (or at least I) sometimes play it straight hoping other people don't get the reference.
If you also have a sense of humor, even if it differs from the individual humors of each programmer on your team, it can be a great way to relate to each other and break up the mood.

or is this goal achievable through knowledge of programming jargon alone?

I spent 20mins moaning about this earlier; if you do not have a solid grasp on what something means do not try to use it.

I work as a rendering programmer, which means I have to interact with artists a fair amount, and while I might well shout and swear about them from time to time due to frustrations about the way they do things (like large amounts of polys under the ground which you'll never see...) the thing which annoys me the most is when they hear a new term and suddenly start trying to use it everywhere; I've taken to assuming they are using the term incorrectly (until I know otherwise) because if I take them at their word I find it slows down my bug fixing etc.

(QA are the second biggest offenders here; so many bug reports of 'z-fighting' or 'light probe issue' when the problem wasn't either of those things!)

I guess the best way to ask is: has there ever been something you wished a creative member of your team knew, be it a language, program, whatever, that may have facilitated development or at least communication?
[/quote]

Frankly; english.
If it helps then a rough drawing/sketches.

If you are talking to a rendering programmer then assume we have a working knowledge of things such as vertices, uv channels etc which at least matches your own but don't try and frame things only in the context of the 3DMax and Maya because not all of us know about the program.

One thing that is important is, if you want a programmer to do something, make sure it is something that's possible. Think it through to the end.

I worked on a project once on a system for a boarding house where beds were assigned to patients. Sometimes patients would check in before other patients would check out, and they would be assigned the same room. The customer wanted to have a report which would show all of the patients in the rooms. They wanted it to show the patient that was already checked in to the room some times, and in others they wanted to know the patients that were newly checked into the room at other times. They didn't want to see both names at once, and they couldn't provide me with a reasonable explanation of when they would want to see which. They just wanted the computer to mystically understand what their intention is when they went to open that report. They didn't want additional options or controls or reporting options because that was too complicated.

In the end I wasn't able to implement it as they wanted because what they wanted was only half-conceived, the rest was just magic. They needed to either compromise on the amount of information they were willing to put in to the system, or in the amount of information they were willing to be served by the system, but they couldn't expect the system to magically determine what was in their mind.