Communicating with Programmers

Not really. I mean, we usually just beep and whirr at each other because the data transfer and encoding is more efficient, but our human analog languages work just fine.

...

OK, but seriously, just be flexible and clear in requirements and questions. The worst case answer to "I want to be able to do _____" is "that will take more resources than current computing can handle". You don't need to know programming languages unless you'll be writing/reading code. Having clear and relaxed conversations with your programming person/crew will tell you why certain things are or are not possible. Otherwise you'll just need to trust them when they say "you can keep two of these ideas, but all three won't work well together". I don't think I've ever been in a situation where I wished the other person knew a little more about programming, it's kind of part of the package as a code-writing team member to translate spoken and high-level requirements into specific pieces of code and design.

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.

Perfect. Well that answers my question. Can't imagine an answer I like more than "no work necessary" or "don't use words you don't know" or "English", haha.
I haven't had any miscommunications with any programmers I've worked with, by the way, but I was anticipating it would eventually occur. Guess not, good to hear.

Thanks, all.

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.

From my experience, English and Japanese are the most efficient means of communicating to programmers. Next would be French, but last would be Thai. Generally even Thai people prefer to use English and read English books instead of Thai books when it comes to programming (too many of their words are literal descriptions—for example, their word for “traffic” (?????) literally means “car stuck”, so you can’t use it to describe Internet traffic unless you want to say, “Internet cars stuck”). I have heard Chinese is somewhere in the middle but I have no personal experience with that.

In the world of game creation, each discipline has terms unique to itself. Artists know what “bevel” means while musicians know what “accompagnato” means.
While it is true that the world of programming is the most “sectioned off” from the masses and the most bewildering to outsiders, all people from all professions know what words have meaning only to them and what words have meaning to the rest of the world.

In other words, programmers know how to communicate as well as you do.
Just as you know a few words from the world of art, programmers know at least a few words from the world of design (in fact, many programmers are designers in sheep’s wool).
Generally there should not be a problem unless you, the programmer, or both of you have a problem with communication in general, in which case that is another issue.


L. Spiro

Well yes, English. Beyond that, your knowledge in technical aspects is the only ticket to loosen out that tension.

Most frustrating communications I ever encountered with artists, or graphics designers, or UI designers, is that they don't usually understand the enormous task necessary to implement their artwork. Adding just one layer in Photoshop could equal to 10K lines of code with rigorous testing depending on what you are asking for.

This is an example that I run into just recently.

UI Designer created an assets for some product. It is obvious in the spec he created that the locations of every single thing is hardcoded in pixels. 10 pixels between button A and B, 23 pixels between button C and D, font size 12, etc. That's not going to work when you create a product on which the environment can be of any resolutions -- yet somehow he didn't get this and continue to give specs in pixels.

You artists have the benefit of working on a constrained environment. Your canvas has fixed width and height. You can fine tune each pixel or voxels or polygons, and paint brush imperfections. Programmers work on open-ended environments, in which he has to abide to the principle of generality. One code fits all. The code has to run on every single hardware combination with every single resolution on every single machine out there. So, we tend to approach problems as a whole, and fix the whole thing in one shot.

This introduces something that we all programmers hate, special cases. Special cases like "Can we bold the letter R right in the middle of that text, and then have the letter Z flash red every 10 seconds, and have the whole thing spin around, and only to do this when the hero died from the backstab wound, but in every other case, the text must flash blue-green and spin on the z-axis, because I think that'd be cool?" will drive programmers nuts.

Unfortunately there's nothing you can do to understand us except putting yourself in our shoes (learn coding) and see it from our perspectives. I have had the most pleasant experience working with artists who also happen to have done coding themselves.

You artists have the benefit of working on a constrained environment.

That was actually the basis of my concern, so I'm glad you mentioned it. I can look at a picture, an animation, scenery, whatever, in a game and get a pretty accurate idea of how the visual aspect was completed and the time and tools it took to do so, but I won't know if there are 10 or 10,000 lines of programming behind it. The good idea fairy must be a pain in the ass for programmers.

Again, thank you all for the continued assistance.

You should have a solid understanding of math. It will help you more than you realize.

Just make sure you know that something that may seem simple to you is not as simple in practice. They will probably tell you if you are asking for something that is too complex

I particularly agree with SoTL.

Beyond that, clarity. Some things are very simple, or well understood in the industry. You won't know which things. In that case let them get on with it. If you want something more custom, it gets tricky. Some programmers you'll tell to do something and they'll just start. Sometimes that's a danger sign that they're making lots of assumptions. Or you'll tell a programmer what you want. They'll ask you to explain in more detail. You will. They'll look puzzled and ask for more detail, etc etc. For example, if you say you want a character to act cute:

Artist: Make the character act cute.
Programmer: What do you mean by cute? Big eyes and cute noises?
Artist: No, ACT cute.
Programmer: You have some animations you want me to play?
Artist: Well yes... but no. Like very happy but easily scared.
Programmer: Scared of which things? I can set up a system so you can tag which things it's scared of...
Artist: That's going to take an awfully long time tagging things... any other ideas?
Programmer: Er, scared of enemy characters and fast-moving objects? But we'd need to decide HOW FAST is FAST and if there are any exceptions. Also we'd need to add a sight system so it knows which enemies to be scared of... unless it's psychic? Psychic would be easier, just all enemies onscreen or within radius X. Hmm, but maybe disable this in cut scenes or things could get pretty trippy.

etc etc. Programmers have to (or at least should) consider all use cases, which is why the job can be difficult and pedantic. ;)

this thread has moved from form of communication to content of communication. it also has indifferently talked about artist <-> programmer talk and director <-> programmer talk.
I hope just mentionning it will allow people to order all of that.

NaturalNines, thank you for asking. At least you inquire about it. I wish more people would see this thread as many great points were raised.

Feature Creep. Oh man, Feature Creep. "Wouldn't it be fun/nice/good if it did this?" Sure, but I didn't agree to that - You're piling straw on the camel's back, and sometimes what you're asking is just the last (and latest) one.

I'm using "you" in the general form of "the projects' client".

I want to point out that it can also be beneficial to have only one person through which the majority of communication with the programmers takes place. It doesn't have to be an unbreakable rule but when you have one person who deals with the programmers most often, they will tend to get to know each others needs and methods better. Also, it's a good way to filter out a lot of the 'noise' that would otherwise be sent to the programmers directly and that issue that one end user thinks is critically urgent is properly classified as the medium priority item that it really is.