This post was originally published on the Flatiron School Blog.
When I decided to enroll at the Flatiron School and shift my career from theater lighting design to web development, I worried unnecessarily that I would lose my drive to create. In practice, I constantly meet other developers with creative passions. My mentor, who I met through the Fog Creek Fellowship, is also a musician who keeps guitars in his office. One of my current Flatiron School students used to be a curator. The list goes on.
The fact that I’ve met a surprisingly large number of creative people in the NYC tech community may be explained by an essay written by programmer and writer Paul Graham entitled “Hackers and Painters,” which was one of the first readings assigned to me as a Flatiron School student. In his essay, Graham enumerates the similarities between computer programming and art. He explains:
What hackers and painters have in common is that they’re both makers. Along with composers, architects, and writers, what hackers and painters are trying to do is make good things.
Graham makes a number of excellent points in his essay; hackers and painters do indeed share many traits. However, I see a few key differences between web developers and painters that imply web development may in fact be more akin to theater-making than to painting.
Development Is Collaborative
Although programming is often thought of as a solitary activity, I haven’t found that stereotype to be true. Working with my peers on final projects was one of the most valuable experiences from my time as a Flatiron School student. Each member of the group brought a unique perspective, as well as a different set of strengths.
The benefits of working with others to complete a task are articulated in dancer and choreographer Twyla Tharp’s book The Collaborative Habit. In the book, Tharp explains how collaboration inherently grants new insight:
As a practical reality, let’s look at collaboration with a single partner. We bounce ideas off another person. Then the other person volleys them back to us. That exchange makes us hear our ideas with new ears for the simplest of reasons—what our partners say is not a literal repetition of what we said.
Theater at its core is a collaborative art form. Most successful production staffs include a director, a set designer, a lighting designer, a costume designer, and a sound designer, all working closely to realize the same vision. I’ve learned that a team full of talented specialists creates a spark. As Tharp states, “People in a good collaboration accomplish more than the group’s most talented members could achieve on their own.”
The open-source movement relies on this philosophy that multiple people working on different aspects of a project creates something greater than the sum of the individual parts. As I’m writing this blog post, Rails has 2,596 contributors on GitHub. Many tech companies have their developers program in pairs, in order to optimize efficiency, learning, and satisfaction and minimize code defects. And just recently, one of my Flatiron students declared, “It’s so rewarding to see how others at my table approach a problem. They think about it in completely different ways than I do.”
Application Evolve With Their Users
Unlike most paintings, works of theater continue to evolve even after they are revealed to an audience. What results is a living, breathing work of art that responds to human interaction. In his monumental book The Empty Space, theater and film director Peter Brook outlines an experiment in audience influence, involving an amateur actor reading a speech from Henry V:
The amateur actor was to read the speech again, stopping for a moment after each name: the audience was to endeavour silently in the pause to recall and put together its impressions of Auschwitz and Agincourt, to try to find a way of believing that these names were once individuals, as vividly as if the butchery had occurred in living memory…Now the audience’s concentration began to guide [the actor]: his inflexions were simple, his rhythms true: this in turn increased the audience’s interest and so the two-way current began to flow. When this was ended, no explanations were needed, the audience had seen itself in action, it had seen how many layers silence can contain.
Professional theater productions hold open “previews” before the official opening night. These previews allow the team to continue shaping the show based on audience response.
Similarly, most web applications continue to grow even after they are deployed. Here at the Flatiron School, students present their projects to their classmates and instructors throughout the building process, in order to get feedback from potential users.
But Why Does This Matter?
What I think developers, painters, and theater-makers all have in common is the desire to understand and contribute to the human experience. In order to do that, we must absorb our surroundings and let every interaction influence our work. In “Hackers and Painters,” Graham writes:
Empathy is probably the single most important difference between a good hacker and a great one. Some hackers are quite smart, but when it comes to empathy are practically solipsists. It’s hard for such people to design great software, because they can’t see things from the user’s point of view.
Developers can learn about empathy through great works of theater, and theater-makers can uncover truths about humanity through the ways in which people interact with applications. Regardless of our medium or our motivations—to make life more convenient, more beautiful, more entertaining—artists and programmers alike create for a better world.