Coding Methodologies for New Media Artists


Last week, I hosted Raunak Singh, as a coder-in-residence, at Xenoform Labs. I normally provide artist-in-residencies for new media artists throughout the year, but  Covid torpedoed the program for 2020 and 2021.  I am thrilled to be resuming some sort of programming for 2022 and am now experimenting with different models.

Raunak is a trained software engineer and we collaborated on this blog post, I designed for New Media Artists, working with software code for their own projects.

My background: I am an educator who now teaches code to Design and CS students, and a new media artist, who is proficient with programming code, and for new works, I’m learning new technologies. I used to run my own software company in my early 20s and am self-taught, with an undergrad degree in Political Philosophy and an M.F.A.

The problem is that new media artists need to know how to use a range of technologies in their projects. They may be strong in a single domain (electronics, Java coding, VR, etc), but don’t usually have the engineering experience that makes learning and applying new technologies efficient. These artists often must pivot to new tech as it comes out, in order to be current with their critical discourse.

What methodologies can we learn from software engineering and apply to an art practice, without becoming a full-blown engineer or getting stuck in the technical weeds? After all, artists want to focus on researching the developing the concepts and creating the art. The tech is the means to the end, just a tool.

But first, an introduction to Raunak, in his own words.

Raunak is a software engineer who comes from a civil engineering background. He enjoys working on inter-disciplinary projects that combine different areas of engineering to do interesting things. This has given him a lot of practice in quickly learning and building with new tools.

Raunak has worked with tools ranging from virtual reality, full-stack applications, and machine learning. His most recent work with Xenoform Labs was on NFT Culture Proof, a collaboration with Scott Kildall and Nathaniel Stern and was a large-scale participatory text performance on the Blockchain. Through this project, Raunak exercised his ability to dive into new technologies through learning how to build smart contracts, as well as frontend and backend components that interact with them.


Time is a finite resource

Most of this article is about practical time-management techniques, which has implications in both the short-term (a specific project) and long-term (generally becoming a better builder).

Raunak introduced me to the concept of the Planning Fallacy, one of the many cognitive biases that impact time management. After reading about it, I quickly realized that I’ve often been its victim.

To quote Wikipedia, “The planning fallacy is a phenomenon in which predictions about how much time will be needed to complete a future task display an optimism bias and underestimate the time needed.”

People often (1) think that they can do the task faster than others who have done it before you (2) don’t account for unknown delays or hiccups (3) don’t possess the necessary information for realistic estimates.

Experience will counter this bias and as Raunak points out, most junior engineers overwhelmingly have problems with underestimating the completion times since it’s hard to see future roadblocks since they haven’t experienced them.

So don’t be discouraged when finishing a project takes even 2 or 3 times longer than you initially thought it would take! Even (and especially inexperienced) engineers have this problem. Set expectations — if you know this is the case ahead of time, then stretch out your timeline and then when it does take 3 times longer, for example, get your fancy interactive electronics pushing live data to a website functioning seamlessly, then there are fewer surprises, and, you’re not brimming with frustration halfway through the project.

One thing that we spoke about was to ascertain when to outsource and know when to learn a new tool. With NFT Culture Proof, we hired Raunak to be the lead developer and do all the blockchain coding. It was beyond my level of expertise — I’m an expert coder (at least for an artist), but learning this new tech and properly deploying it was beyond what I could do in the 3-4 month timeframe we had.

Nathaniel and I scoped out this problem early and focused on securing a solid developer. Our first person fell through and she recommended Raunak, who worked out spectacularly well.

The problem with outsourcing work is that you don’t learn new tools. And, the more distance that you have from the actual software coding, the harder it is to (1) make serendipitous discoveries — there are often unintended good outcomes that you discover when you write code (2) maintain your code for future projects or changes (3) implement your vision, since you have to both find and trust someone to do it for you.


Spend 5-10 hours solely on learning the new tool 

This guideline helps  to manage technical debt, which is a concept that Raunak spoke about. The concept here is that there is a cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer. To summarize: when you make a decision for a better short-term outcome at the cost of the long-term.

Spending just 5-10 hours on learning a new tool can result in net gains down the project timeline. An example of this that I’ve seen is learning how to use GitHub, the standard source-code archiving and sharing tool. Just about every coder uses it to manage their projects. I teach it in my Interaction Design class. It’s notoriously confusing.

In about 2-3 hours, newbies can learn how to use this tool. And the more you use it, the easier it gets in terms of workflow. GitHub enables you to backup your projects, revert to older versions and have a cloud-based storage solution. I have about 100 source code repositories, some public, some private for artwork I’ve made, dating back to 2005. I even have an intro to GitHub video here

Too often, I’ve seen new media artists working with custom JavaScript, Arduino code, or something else and they have multiple versions of the project — old semi-working ones with names like “TalkingShell_final_final_3”. It’s a mess of confusion and creates its own sense of anxiety.

The trick here is, as Raunak points out, that when learning a new technology, you don’t know how long everything will take. This makes it hard to make decisions like “should I spend time writing this code that will make this other code easier to write”?

This is why a guideline of 5-10 hours is helpful. In Raunak’s case, with NFT Culture Proof, he learned the basics of Solidity, which is a smart contract coding language for the Polygon blockchain that we used. He spent time with an Udemy course on the topic and then developed the project timeline.

That 5-10 hours can also help you out with the decision to outsource or not. Perhaps it’s going to be something you can bite off with some limited technical knowledge, or maybe you’ll figure out that WTF, this is really hard and beyond what I can do, as I did with any sort of smart contract coding. That time will not be wasted.


What technologies should you use?

Ask a trusted colleague. What you find online through Googling won’t be nearly as valuable as what someone in your own field, another artist would recommend doing. For example, if you are doing Arduino development on a complex project, I can recommend which development environment to set up based on your specific needs.

The Arudino IDE, for example, is fine for setting up something quick and easy, but for a more complex embedded project, I’d recommend Visual Studio Code with PlatformIO. This provides color-text options, context-specific lookups of functions, debugging and so much more. But, it takes a few hours to set this up and sort through the project management details.

How long will the technology be around? Languages like Javascript or Python will certainly be around in 5 years. Will the Polygon blockchain be relevant? Maybe. Others are more transient. When I worked at the Exploratorium, for example, I used the Eclipse IDE with Proclipsing to run our Processing projects. It was powerful, but at some point along the way, the Proclipsing extension stopped being updated and this left us all with projects that were near-impossible to update. The popularity of a tool also means that you will likely find more resources (e.g. Stackoverflow posts) on how to use that software tool.

Check out at the popularity of such tools. Will it be easy to go back to the more stable system? For example, with Visual Studio Code + Platform IO, I could port this project back to the Arduino IDE very easily. Since VS Code is a Microsoft product, it’s likely to be around for a while anyhow.

How hard is it to learn? If after 5 hours of mucking around, if the new technology is just too damn difficult, then that is probably time to think about outsourcing the project to a qualified engineer. Is it just that far beyond your skill set? Are you completely disoriented after a few hours or do you have a sense that this software tool will be your friend?

How is it suited to your needs? Don’t try to muscle something around that isn’t well-suited for your project. I have a close friend, not a coder, for example, who uses the After Effects scripting language to generate his projects. That’s fine for video work, but when he started talking about a fun project called Biden Bingo, that generated bingo cards for different states during the 2020 presidential election, well that’s where I stepped in with Processing and solved the problem much more quickly. Make sure the tool in question is actually useful and not a circuitous route to solve the problem.

How much time should you spend researching vs building? 

As Raunak pointed out: with software engineering, it’s likely that someone has already implemented something you are trying to do. Successful engineering involves learning when to look online for libraries or other people’s code and when to implement your own. On one hand, it can be a huge timesaver if you find that one library or Stack Overflow Post that does exactly what you need to do and it fits perfectly with other components of your project. On the other, this holy grail is often hard to find, and code which looks like it is useful often requires doing acrobatics around it to make it fit into your other code. A general rule is to familiarize yourself with common libraries used by the new technology, and to always do a couple of quick searches on how other people have accomplished tasks you are working on when working with a new tool. In a lot of ways, searching for code and discovering what’s out there is experience itself in getting to know a tool.


You don’t know how much you can do with the time you are given if you don’t know how long things take

Rank project necessities from highest priority to lowest priority, e.g. do you need a completely accurate visual sensor or do you want to focus on an aesthetically-pleasing UI. Most of the time, some features don’t get completed, so it will be helpful to bump the lowest priority stuff down the chain. Once again, this seems obvious in some ways, but many don’t do it. Having this sketched out before you start a project, helps since what often happens is that you get emotionally attached to the work you’ve already sunk into a project and make poor decisions. Maybe the least important things have become more vital in your work-addled brain.

Timelines are also important in balancing long term growth with project completion. Most people have an idea of how much time they want to spend on a project, and how much time they have to learn other things. But it’s hard to make decisions like this when you don’t know how much time things take.

This takes us to the classic Donald Rumsfeld quote:

…because as we know, there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns—the ones we don’t know we don’t know…it is the latter category that tends to be the difficult ones.

Right-wing war mongering aside, there is a chunk of wisdom for us to chew on here, which is simply that we don’t know what we don’t know.

First, try to get those unknown unknowns solved as quickly as possible. Don’t leave them for the second half of the project. Overestimate your timeline. Do the best you can.

Raunak’s advice, re-echoing here, is to take a short course or work through a book to learn what you don’t know, then you can re-cast your timeline. Courses or books are great for unknown unknowns.

Build what you don’t know first, then you can handle known unknowns. For me, for example, there is was a lot of JavaScript coding I did for NFT Culture Proof and I had to make various forms and other things that I had never done before, but I know JavaScript reasonably well and have worked with it before, so was confident I could solve these problems easily.

Some parting tips:

  1. Iterate on your design often. It’’s hard to keep a design fully in your head.
  2. Don’t get stuck in the “I can’t code” mental loop. It is a self-fulfilling prophecy. While some people have a more natural aptitude for code structures, anyone can learn to code in a “good enough” way for art projects.
  3. Identify bottlenecks, and design around them. There are often multiple solutions to the same problem. Determine the specific components that you are most concerned about working with, and come up with potential backup plans if you find that it’s too complicated to make it work. For example, in the NFT Culture Proof project, we initially wanted to generate our SVGs in Solidity, but we switched to doing that in JavaScript when that proved too difficult.
  4. Try to have multiple ways of accomplishing things. If something doesn’t work like it should or if it’s taking too much time/energy, then it’s always great to have some other technique to fall back on.
  5. Break down problems into bite-size pieces. It’s like doing work on your house. If you look at everything at once, it’s easy to get overwhelmed. If you work on just the shelving unit, that task can get done in a weekend and then you can move onto the next.
  6. Focus on handling one unknown at a time if possible. Don’t try to implement a smart contract and the UI for it in one go. It’s much easier to divide and conquer. Focus on a single component (e.g. the smart contract) first, and then, distill your work into as many simple tasks as you can (e.g. first deploy a trivially simple smart contract first, then work on how the smart contract token balances are stored, and then add transferring tokens between users).
  7. Know when you’re at the point of diminishing returns. If it’s 11pm and you can’t figure out a bug in the code, time to shut off the computer and work on it with a fresh can of Club-Mate in the morning.
  8. Prepare yourself for success. Figure out a workflow that is organized and soothing. For example, at the end of most days, I put together a to-do list for the next day. My brain is sharper in the morning and this is when I want to jump in and get shit done. Doing this is a good way to close out the work day and be focused on the next day.


Thanks Raunak for your insights!


Lessons from my Dry January

Rain blanketed San Francisco throughout January but it was dry for me. No alcohol for 31 days. Both easy and annoying. I know many people who make this commitment annually, well-before someone dubbed it “Dry January”(or just #Dryuary).

I had imagined a cinema-like moment where my right hand would reach for the whiskey bottle and my left hand would slap it away, but the temptation never beckoned. Alcoholism flows in my family and I sure like drinking. My internal deal is that I keep a close watch on the booze. If it ever becomes a problem, I’m going 12-step.

I don’t sink my emotions into the bottle and I don’t indulge in sessions of wine therapy when things get tough. I committed to Dry January because during November and December I ended up drinking a couple of glasses of wine each night. I felt sloppy. I didn’t like where the path was heading.

A few days into 2019, I discovered the land of deep sleep. I felt more focused in the daytime. I got significantly more work done. I sorted out new art projects, I banged out tedious grants, my meetings energized rather than depleted me. I didn’t feel overwhelmed as I often do. I felt clear in my intentions. I felt in balance. The effect cumulated.

And…I missed the socializing. I missed the taste of a French red loaded with tannins. I missed dressing up and going out for a cocktail date. The dinner parties where I was dry, while enjoyable, didn’t have quite that epic feeling of social joy. In January, I holed up and nurtured my introverted side, a smaller version of me. Most importantly, I didn’t feel like my genuine self.

What’s the balance between alcohol and not? I’ve been reading about Mindful Drinking, which seems to have several variations. Feel free to rabbit hole on this search term.

My interpretation is this: before ordering or pouring a drink, ask yourself: How does this serve me?

When I go to an art opening, I often head towards the free wine corral and pour myself a glass, before any social exchange. Alcohol acts as both social lubricant and social crutch. However, I’m a slightly worse conversationalist in this particular situation: with a loose networks of friends of varying degrees of intimacy with a lot of chaotic traffic flow. So, at art openings, probably not.

This Saturday night, I went to a social dance party-thing, where I knew only a few people, other than my date. It’s an intimate circle and I’m new to that community of creative thinkers and warm folks. I feel more rigid without drinking. Perhaps the conversations are better, but my personal vibe feels off. I’m a little less relaxed. Saturday night, I wanted to unwind a bit, smile, laugh and integrate. Two glasses of wine served me well.

How does this drink serve me? Make it a quick question. Answer yes or no and then drink or not. It’s simple, but takes mostly practice and a smidge of discipline.

And, as a good friend of mine points out, if you’re on the fence about having another drink, then the answer is always no.

As a practicing artist, who wants to amplify creativity, when does drinking help? Very rarely. Drinking makes me sloppy and unstructured. Lateral thinking, as opposed to linear thinking is what I need for increased creativity. Drinking certainly shatters linear-thinking, but the resulting journey is a meandering path of randomness.

My next inquiries will be into thinking more laterally and less literally. What are the spaces and mindsets that make this happen? Alcohol is clearly not one of them. The research begins.

ReFILL Workshop in Winnipeg

On March 27th & 28th (2015), Victoria Scott and I will be conducting a workshop in Winnipeg around the “libricide” in Canada’s DFO libraries. The full article on their closures is here.

Screen Shot 2015-02-26 at 8.30.29 AM

Here’s the description
On March 27th & 28th, 2015, San Francisco-based artists Victoria Scott and Scott Kildall will be leading 2-day, hands-on workshop to physically re-imagine and re-materialize some of the lost titles of the Freshwater Institute Library. We will discuss, imagine, draw, map and construct while listening to soothing water sounds and watching water-related videos. We will also discuss methodologies of data visualization and create a map which tracks the migration of these materials from publicly-funded resource into private hands and landfill.

Our project blog will always tell more!

Hacked By ReckLess

security %0 h4ck you bitchesss !

@SelfiesBot: It’s Alive!!!

@SelfiesBot began tweeting last week and already the results have surprised me.

Selfies Bot is a portable sculpture which takes selfies and then tweets the images. With custom electronics and a long arm that holds a camera that points at itself, it is a portable art object that can travel to parks, the beach and to different cities.

I quickly learned that people want to pose with it, even in my early versions with a cardboard head (used to prove that the software works).

Last week, in an evening of experimentation, I added text component, where each Twitter pic gets accompanied by text that I scrape from Tweets with the #selfie hashtag.

This produces delightful results, like spinning a roulette wheel: you don’t know what the text will be until the Twitter website pubishes the tweet. The text + image gives an entirely new dimension to the project. The textual element acts as a mirror into the phenomenon of the self-portrait, reflecting the larger culture of the #selfie.

Produced while an artist-in-residence at Autodesk.


And this is the final version! Just done.


This is the “robot hand” that holds the camera on a 2-foot long gooseneck arm.





My GitHub Instructable (while convalescing)

While a resident artist at Autodesk, we are supposed to write many Instructables. Often, the temptation is to make your projects and then write the how-to-guides in a haste.

Since I broke my collarbone, I really can’t make anything physical, but I can type one-handed. Besides the daily naps and the doctors’ appointments, and slowly doing one-handed chores like sorting laundry, I have to keep my mind active (I’m still too vulnerable up to go outside on my own).

Here is a new one: an Introduction to Git and GitHub. I originally found this source-control system to be weird and confusing, but now I’m 100% down with it. Feel free to add comments on the guide, as I’m a relative Git/GitHub nOOb and also have a thick skin for scathing Linux criticism.

Full Instructable here:

And here is my post-surgey selfie from yesterday, where they put the pins in my collarbone. The doctors told me it went well. All I know is that I woke up feeling groggy with extra bandages on my shoulder. That’s how easy it is these days.


Amazon Preferences & Queer Latinidad

I just finished reading “Queer Latinidad” by Juana Rodriguez, which I downloaded for the Kindle (perfect medium for theories of electronic discourse).

This single purchase seems to have glitched my Amazon preferences. As a straight, white male, I now get recommendations that contradict my “personality profile”. Check these out:


Onto the text itself: I found myself fascinated by Rodriguez’s textual interactions and queer latina identity, especially since her world of net.interaction happened in a pre-Facebook world with IRC chat rooms (really not that long ago…)

My favorite passage in the book is this one

Digital discourses, those virtual exchanges we glimpse on the Net, are textual performances: fleeting, transient, ephemeral, already past. Like the text of a play, they leave a trace to which meaning can be assigned, but these traces are haunted by the absence that was the performance itself, its reception, and its emotive power. To write about these online performances already alters their significance; a shift in temporal and spatial context produces a shift in meaning.

I remember the textual performances (as Second Front) we did in Second Life such as “Breaking News” (also not that long ago). The “playbook” for this performance was simply: we go into the Reuters headquarters and use the chat window to shout headlines such as: BREAKING NEWS: AVATARS IN REUTERS NEED ATTENTION!

But now, the performance only exists in writing, and absurd documentation videos like this:



Lasercut Measuring Tool

I like helping people and making simple tools to share. This measures plywood sheets, fits in your pocket and can be laser-cut in 3 minutes. The Instructable is here (Illustrator file included).


Augmented Reality workshop reportback

On the weekend of March 31st-April 1st, Upgrade! SF (I am one of the co-founders) produced its first ever workshop. The theme was Augmented Reality and the guest instructor from Boston was artist John Craig Freeman.

The full reportback is here on the Upgrade SF! site

Plastic Forever at Telluride

Here’s a reportback from the Plastic Forever project — an ongoing art collaboration by Richard Lang and Judith Selby — at the Mountain Film Festival in Telluride. Their process involves finding discarded plastic debris and displaying aggregates of toys, lighters and other knickknacks in photos, sculptures and other works, breathing aesthetic life into these (mostly) non-reusable items.

For the festival, they built trophies from found plastic materials in Telluride itself.


And here is an award recipient, who is displaying her prize.


The conceptual tension behind their work reminds me of Edward Burtynsky’s photographs, which are beautiful depictions of ugly manufacturing processes.


Foucault’s Heterotopias

Don’t be intimidated, this essay by Michel Foucault is an easy read and highly relevant to the theme of Re-conceptualizing Space.

Today begins my stint as Eyebeam’s guest reblogger for a two week cycle. You will see a breif study of common points along a number of disciplines including art interventions, astrophysics and virtual worlds, among others. I will examine how “space” itself has changed in the last 10 years.


Foucault coins the term “heterotopia” as a real place, which acts as a practical utopia and serve as a site to represent and invert the culture it surrounds. I’m particularly enamored of the forth principle: the linkage to time-slices. Cited examples include the cemetery, the boat and the brothel. Print it out, find a cafe and have a good read. Thanks to my good friend, Paul LaFarge for the suggestion.

New DVD by Second Front

Second Front has just released its Second DVD: Avvie Road. We will be having a formal DVD launch party at our performance night at Eyebeam on October 9th, 2009. This is a chance for everyone to see us perform live along with Alan Sondheim and Lily & Honglei and of course to get a collection of our performance art videos.


On the DVD will be 11 selections of iconic Second Front performances including Car Bibbe #2, Grand Theft Avatar, Summer of Love (performed in conjunction with Patrick Lichty’s 12×12 show at the MCA in Chicago) and Therapy.

Second Front is a 7-member performance art group that includes Gazira Babeli (Italy), Yael Gilks (London), Bibbe Hansen (New York), Doug Jarvis (Victoria), Scott Kildall (San Francisco), Patrick Lichty (Chicago) and Liz Solo (St. Johns).

Don’t Freeze Your Head

Alcor is a company which cryonically freezes people for a future afterlife and charges $150,000 to  freeze your whole body, but they offer a discounted $80,000 for just the head. My advice: go for the full monty.


Here’s why. Listen to this Radiolab podcast from our friends at WNYC. Mind-blowing stuff. The body is essential in the determination of emotional self. Feelings of fear, love, anger and everything else that makes us human stems from the direct observation its own physiological responses.

Forget the brain-in-a-vat and remember that there is no ghost in the machine.

Phantom limbs are real and (according to the broadcast) paraplegics feel less. The body is critical in how the brain works, contesting the alluring idea of uploading your consciousness in some sort of Kurzweilian fantasty.


Cameras as Projectors

Earlier this month, Nikon announced their CoolPix S1000pj camera, which has a built-in projector — the first camera to do this as of yet.

I’m not a gadget whore nor am I advocating buying this product, with its $430 price tag, but it does bring up some amazing social possibilities.

Imagine this: instead of 3 or 4 people huddled around a 3-inch LCD screen, you instead project your images from parties and travel against the walls of the local bar or restaurant. While some people don’t approve of this, I say why not? Cafes have become laptop opium dens, people gab on their cell phones on sidewalks, and I have been asked to move aside while looking at artwork for the sake of a quick photo.

Public space is replete with devices and this one will at least foster face-to-face social communication rather than isolation. I can’t wait.