Sign in to follow this  
NaturalNines

Communicating with Programmers

Recommended Posts

[quote name='alvaro' timestamp='1349288853' post='4986480']
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.
[/quote]

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.

Share this post


Link to post
Share on other sites
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. Edited by NaturalNines

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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 [i]are[/i] 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

Share this post


Link to post
Share on other sites
[quote name='alnite' timestamp='1349313395' post='4986618']
You artists have the benefit of working on a constrained environment.
[/quote]
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.

Share this post


Link to post
Share on other sites
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:

[b]Artist:[/b] Make the character act cute.
[b]Programmer:[/b] What do you mean by cute? Big eyes and cute noises?
[b]Artist:[/b] No, ACT cute.
[b]Programmer: [/b]You have some animations you want me to play?
[b]Artist: [/b]Well yes... but no. Like very happy but easily scared.
[b]Programmer:[/b] Scared of which things? I can set up a system so you can tag which things it's scared of...
[b]Artist: [/b]That's going to take an awfully long time tagging things... any other ideas?
[b]Programmer:[/b] 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. ;)

Share this post


Link to post
Share on other sites
[img]http://4.bp.blogspot.com/-wacMl1rl7tY/UC5CHob7nkI/AAAAAAAAASo/tz3-ia5oxPc/s400/Toystory-Kaj_ErlingFacebook120817.jpg[/img]

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. Edited by UltimaX

Share this post


Link to post
Share on other sites
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". Edited by Narf the Mouse

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
trying to learn how to program as an artist is actually rather hard... its' just a very different way of thinking and approaching a problem.

i studied/degreed in art, and later decided to pick up programming (sadly started with assembly, and now many years later working with C#).. so i think i can completely relate to the OP.

the odd thing about all of this, as a profession... i did NEITHER as a whole, i became a technical manager (the middle man of IT.. you know, sorta like the guy in this scene from "office space": [media]http://youtu.be/mGS2tKQhdhY[/media] ...)

does it hurt to understand how a part of your projects workflow functions to do what they do?  nope.  is it necessary to do it as well as they do? nope.  but i think it can help to understand.

I honestly believe artists and programmers are very similar... creative, complex, and abstract thinkers.

so, to begin programming?  I would say to NOT pick any particular language, but rather learn the concepts to build a good understanding.

Simon Allardice did a couple great training videos on Lynda.com that I took and found to be excellent starting places, "Foundations of Programming: Fundamentals, and Object-Oriented Design".   They are mostly language independent, but show a few examples of concepts in different languages to show syntax differences, etc...

then i would say, pick a language that YOU want to learn.

Share this post


Link to post
Share on other sites
As a programmer I fear that people might not understand me more than I might not understand them. But my brain tends to compartmentalize everything so I might seem like I don't have a clue what you're talking about sometimes.

"Whats the progress on it?"
"What what ? What it ? What is this it? "
"The thing we were talking about 5 minutes ago"
"Oh right, I reckon I've figured out how to do it, will tell you if I succeed"

Generally if a programmer ever says something you don't understand; make them explain it, jargon isn't jargon, it's a concept that has a name.

Share this post


Link to post
Share on other sites
Generally speaking I think the bigger concern is the other way around. As a programmer who has spent many a day dealing with artists, the biggest barriers to communication have been when I didn't understand the content creation process well enough and was unable to effectively communicate the necessary constraints or requirements, or fully understand the implications of such from their perspective.

So I got myself a subscription to Digital Tutors and spent a couple of months learning what I could about developing game assets with Max, Maya, ZBrush and MotionBuilder, and typically now I spend at least a couple days a month doing the same, and the communication has become much, much easier.

This is probably not something that every programmer will be able to or want to do, but as somebody else mentioned, there should be one guy on the programming team that can act as liasion between the technical and artistic sides, and it would be a good idea for that person to have a reasonable understanding of the content creation process.

Share this post


Link to post
Share on other sites
Prefer talking often, to talking longer.
Prefer sketching small isolated ideas, to excessive feature planning.
Don't always talk at the same desk. Alternate!
'Knowledge transfer': The programmer needs to understand your problems, you need to understand theirs. (alternating helps to see it from both viewpoints)
A pint after work usually solves the very worst problems.

Share this post


Link to post
Share on other sites
[quote name='RobTheBloke' timestamp='1349818856' post='4988503']A pint after work usually solves the very worst problems.
[/quote]definitely, unless you've both had a bad day and are lookin' for Trouble (capital T style).ha!

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this