June 6, 2003
We’ve had an array of wonderful comments in the two previous posts on artist programmers. (I just added a lengthy comment with a bunch of new links.)
Another facet of this debate: What happens when artists and programmers collaborate? The issues are more than just the potential cultural divide of freaks vs. geeks, but also the (perhaps unpleasant) issue of artistic credit. I’ve heard more than one story of a team of people working on a new media art piece “led” by a “primary” artist, who effectively takes all of the credit for the piece, when those who did the actual programming deserve at least as much credit for the success of the work. Sound familiar?
Some articles on the topic of artist – programmer collaborations:
From a post in the “code and content” list
“i’ve seen a number of collaborations that didn’t work out because the Content side and the Code side had little or no experience with one another’s fields or cultures. also, often the “content” people (artists, activists, etc.) seem to initiate and approach the collaboration from the position of “giving orders to the hired gun.”
From a recent discussion on the “biome” list
“though i think the term collaboration is another debate… there is hiring someone to do something for you as directed then there is collaborating with someone to collectively discuss and realise the possibilites i dont think one is better than the other they are just different however i think they get confused alot and ‘collaborative’ relationships break down and people get dissatisfied / power issues come into play / it is difficult if you dont know where you stand”
“I agree this ignorance always results in snobbery – one collaborates with a coder because one can’t write code or doesn’t have the hardware… Who is excercising the creativity in these situations?
A Gamasutra article “The Psychology of Artists and Programmers”
“I think there is often a disconnect at two levels: One is an important difference in goals for artists and programmers, and another is the garden-variety difficulty in communicating with which all team members must cope.”
From an essay “Thoughts from a Girl Making Boys Games in a Man’s World: Relationships”
“Unfortunately, not all programmer-artist relationships are good. In bad ones, the programmer or artist shuts down any dialogue, thinking that they have all the answers by themselves. … Something else I’ve discovered is that programmers really hate it when artists do ugly stuff with what they consider to be beautiful code”
A Brown-RISD course, “Interdisciplinary Scientific Visualization”,
“The 16 students in the class are working in artist/programmer pairs”
From a game development article “Questions Artists should ask Programmers”
“Artists want the game they are working on to look good and be fun to play. Programmers want the game they are working on to be fun to play and look good. Each team looks at the challenges from different perspectives, but the goals are the same.”
Just posted as I’m writing my post: Phoebe addresses artist – programmer collaboration in her recent comment.
June 6th, 2003 at 4:43 pm
…i think maybe (and this may contradict much of what i posted previously) that much of this discussion is based on art and programming being distinct areas…but is there not artistic programming? what about perl poetry? the code poems jim andrews mentioned, the brilliant work of mez and alan sondheim? would be interested in hearing from those who don’t see a distinction between the two fields…
June 6th, 2003 at 5:48 pm
Do we know the names of the stone-masons who cut the block for Michelangelo’s David and managed to get it down from the mountain in one piece? At the time that was an incredible achievement of engineering, and probably as demanding as Michelangelo’s work.
It’s not fair, but in collaborations some get more glory than others, even if they didn’t really do the hard, backbreaking work. But without them, the work might never have been started in the first place. So who is the artist? It’s not easy to know, it might all be from Ruben’s workshop.
June 6th, 2003 at 6:25 pm
In some of the recent work I’ve done in collaboration with the film industry, the issue of credit was very important. Interestingly, those folks seemed to have worked out the credit assignment problem quite well for the products of their work that fell into traditional media types (movies) with understood roles (executive producer, director, line producer, actor), and had almost no interest in how credit was assigned for the products that were new to them (interactive software prototypes, conference publications).
For example, the academic role of Principle Investigator (PI) shows up in the scrolling film credits somewhere between key grip and food services, figuratively speaking. However, none of these film industry collaborators were even mentioned when the principle investigators published a conference paper on the work. In each case, the collaborators got the credit they wanted in the communities they were targeting. Perhaps that is the point, that credit only makes a difference in relation to the audiences that you care about.
June 7th, 2003 at 7:25 am
i think it’s interesting to look at the specialization (and credit) found in the film industry… it’s one model of reference (although in my experience, the role of producer is vastly different in these two industries, in film – you’re the boss… in new media, you’re middle-management… roughly) but i digress…
i’ve found a range of possible collaborations, from client-developer (where you’re hiring, or being hired) and so you work to give the client what they want… to in-house teams working together on a project (so most often the leads get the credit… to a group who shares an idea and works together fairly equally…
what’s really relevant about this discussion is that while is it valuable to develop some degree of programming knowledge, and that we should work on some sequence that gets students this exposure… i’d say it’s even more valuable to teach students how to work in a group with others (because if they get a job in the industry, they’re going to be working with people on teams…
when i was at a publishing house in a position where i was making hiring decisions… favorable decisions swung less around if you were an artist/musician/writer/etc.. who could program… and more around if you had a documented, and positive, history of working on teams
which brings me to a point applicable to all forms of collaboration… for it to be most successful for all involved, a major key becomes detailed documentation and clear communication… being able to articulate your ideas in writing (no matter what your skills) is crucial to working together with others… it helps to minimize confusion, clarify credit, and keeps collaborative projects focused around the agreed upon goals…
i think as new media educators, we would be remiss in not helping students learn about issues of project management, such as documentation, deliverables… it’s a flexible framework that can help a gropu work together… and that’s what can be really cool about a good collaboration.. is making something above and beyond the abilities of any one person in the group, but from the synthesis of the group’s collaborative effort…
June 8th, 2003 at 10:33 pm
I agree with the sentiments in the above comments, but there’s a particular point about this whole issue I’d like to emphasize. What I’m saying may already be obvious to the participants in this discussion, but I’m not sure it’s obvious to all non-programmer new media artists.
Some interactive work to date has been strong on concept, and relatively simple on the programming-side of things, which is perfectly fine. In such cases, if a non-programmer artist / designer collaborates with a programmer, perhaps the artist considers the programmer essentially a technician. That may be accurate for works with relatively simple mechanisms or interactivity. But as non-programmer artists try to make works that go further with interactivity and/or generativity, the programmer necessarily becomes less of a technician and more of a fellow artist. Why? The more complex an artwork’s interactivity becomes, the more the decisions made during programming will impact and define the essence of the experience. High-level direction of a programmer isn’t enough to maintain total authorship; as complexity increases, there are too many devils in the details. In such works, a lot of artistic decision making happens during coding.
Seems obvious, but I wonder if some artists disagree with that – instead believing that the concept is primary, and even for complex works, it’s enough to give high level direction to the programmers, who some how remain technicians in the artist’s eyes.
Of course, in any collaboration, some people get more credit than others, and I suppose this will remain unavoidable in any project, interactive or otherwise. For example, with movies, there is a tendency to look to the director, and perhaps the actors, as the primary author(s), when in reality the writer, producer, cinematographer, etc. often have equally important authorship roles. If you asked the director, they’d probably be quick to agree / admit (and truly believe) that the creation of the film was very much a collaboration.
The bottom line I’m trying to say is, that as we push to create more deeply interactive / generative work, artists will either need to fully share artistic credit with the programmers they collaborate with, or become programmers themselves.