 Twitter is crafted by humans for humans. Software is crafted by humans for humans. Our calling, our purpose as craftspeople is to create an experience for an audience. We take very different elements, code, databases, graphics, and we weave them together into a cohesive whole, a harmony and illusion. When I log onto Twitter and I tweet something, I may literally be typing characters into a keyboard having those characters appear in a text field, moving my mouse and clicking a button, but that's not what my brain experiences. To my brain, I'm just talking to my friends or announcing something to the world. The technicalities behind Twitter become invisible, all hidden behind the illusion of the user experience. I didn't start off in software. I started off in the world of theater, creating productions intended to make people laugh, to make them cry, to show them something familiar in a new way, to showcase the universal human experience. It wasn't until I began doing software professionally that I realized how similar these two worlds are. The creative process that goes into creating a theater production is identical to the creative process that goes into crafting a software application. Theater is where I learned my greatest lessons on software development. It's where I learned to work with a group of passionate people to create something extraordinary. It's where I was empowered to create experiences that can change a business, an industry, a society, even the world itself. I want to share these lessons with you. I want to empower you. I divided this presentation into five acts. Each act will highlight a lesson I learned in theater and how it applies to software. Let's start with Act One, Vision. Many software applications try to pack in as much functionality as possible. Want email and social networking? We've got it. Want server management and hardware purchasing? We've got it. Want the kitchen sink? We've got that, too. These applications do many things somewhat okay and nothing very well. In striving to be useful for everything, they become desired for nothing. It's easy to fall into this trap in a theater production, too. A director might say, let's add a musical number to a production of Hamlet. A producer might say, I saw Peter Pan last week and the flying was awesome. Let's make Henry the fifth fly. These may sound like exaggerations, but I've both seen and worked on productions that were not very far off. Before a role is cast, before a line of dialogue is rehearsed, before any costumes have been designed, it's critical to establish a clear vision. This vision must answer one question. What experience do I want to give my audience? In software, we can amend this slightly to what experience do I want to give my users? Apple does this brilliantly. Their vision is it just works. This drives everything, from their hardware, to their software, to their mobile applications. I want to give you an example on a smaller scale, though. A few months ago, I began working on an application I'm calling the wedding gift coordinator. My vision for the application was this. Wedding guests will have an easy, intuitive way to find other guests to split gift costs with. This application will take stress away from the process of finding a gift for a wedding. This vision is not requirements. It's not specifications. It's simply two to three sentences that say what your application is supposed to do. Know thyself is a phrase from ancient Greece that I think applies well to defining your vision. Know your app. Know what it does. Know what experience it needs to provide. Let this drive everything about your development. Shakespeare wrote in Hamlet, to thine own self, be true. With everything, from your user interface, to your databases, to your models, to your views, controllers, to your vision, be true. If anything drives the software industry forward, other than caffeine, it is ambition. So many of us have a drive to create applications that do things better and faster than what has come before, to push the industry to new heights. This is essential. However, with any software application, as well as any theater production, there are limits. Act two. In my years in the theater, I had to say no many, many times. This was sometimes because of people constraints, budget constraints, time constraints. Once it was the laws of gravity, I found there's an art to saying no. And that art comes in three parts. I once served as technical coordinator for a director who had very little theater experience. In our first meeting, she told me she absolutely needed 18 spotlights. I had to tell her no after I got over my initial shock. And I did so using three parts. Part one is no. I cannot give you 18 spotlights. It's stating the limit clearly, making clear that no amount of arguing or convincing is going to change it. Part two is explaining why. We don't own 18 spotlights. Even if we did, the light from a spotlight is very harsh. If we've shown 18 of those on stage, it would blind not only the performers but the audience as well. Part three, instead, this is where you put a positive spin on it, where you present an alternative. I can give you two spotlights along with some stationary lights on stage. In his book, The Clean Coder, Robert C. Martin, also known as Uncle Bob, gives the example of a manager coming to an engineer saying he absolutely needs a login page done by tomorrow. She also tells him no, and I found the way she tells him no fits well into these three parts. Part one, no. I cannot give you the login page tomorrow. Part two, why? It's 10 days worth of work. The original estimates may have said three days, but new people got the requirements. Part three, instead, I can give you a mock-up of the login page. You'll be able to enter in a username, password, click a button, and be logged on to something that kind of looks like their system. The key in both these examples is finding intent. What is it we're trying to get done here, and what can I provide with the resources that I have? It took some conversation, but in the case of the 18 spotlights, all the director was really looking for was some sort of dramatic lighting effect on her actors. I could give her that, just not in the way she thought I would have to. In the case of the login page, all the manager was really looking for was something he could demo to a client the next day. The engineer could give him that, just not in the way he thought she would have to. Most people don't ask, pardon me, most people who ask for the impossible aren't doing so just to be a jerk. They simply don't understand the limits that are involved and don't understand there is a way for you to give them what they want, just not in the way they expect. The key is to communicate. It may take some conversation, but when we communicate, we can still create extraordinary things, even within limits. Act three, casting. Just as it takes a village to raise a child, it takes an ensemble to put on a theater production or create a software application. One of the things I love most about both the world of theater and the world of software is that having an eccentric personality is not only tolerated, it's expected. The key is figuring out how to create a team that balances these personalities. As programmers, we're used to a world of defined limits with reasonably predictable outcomes. Humans don't work this way, though. We're organic, squishy, emotional human beings. It can be hard to figure out how to put together a team of humans that will work well together. When I'm casting a show, I look for whether someone is right for the part. There is a core technical competency that needs to be met. If I'm casting a dancing show, I want the lead dancer to have a background in dance to be able to execute complex choreography. Once this core technical competency is met, however, the most important question to answer is, can I work with this person? Will this person just get the job done, or will they lift the rest of the team up to new heights? In software recruiting, we do the same thing, but we call it being right for the team. Extraordinary experiences are crafted by passionate and effective teams. Teams with a sense of trust, with personalities that are different enough to have a diversity of opinion, but not in a way that clashes. But what about a situation where the only person who has the technical competency I need has a difficult personality? In the world of theater, we refer to personalities like this as divas. This term applies to both men and women, by the way. In software, we experience the same thing, but we generally refer to these personalities as ninjas and rock stars. So when would you work with a diva? Marlon Brando, the film actor, was notorious for being extremely difficult to work with. Yet because he could produce such mesmerizing performances, many actors were willing to put out with his antics. You work with a diva when the contribution they bring to your production or software application is greater than the maintenance cost of keeping them happy. An actor or actress might demand tea from a certain island in the South Pacific, but is able to produce magnificent performances. I may be willing to make some accommodations. An engineer might demand energy drinks that can only be imported from Germany, yet be able to produce mind-blowing and well-written code. I may be willing to make accommodations. There are things I will say no to, probably using the three-part method that I outlined before. But to keep someone happy while they're doing work, to help them work effectively, I'm willing to make some accommodations. I want to make clear, however, that no amount of talent justifies certain behaviors. No amount of talent is worth abuse, whether physical, verbal, or emotional, harassment of any kind, or a lowering of your team's morale. The biggest danger to bringing a diva on your team is that tending to the diva can distract you from tending to the rest of your team. No matter how much talent one person has, experiences, extraordinary experiences, are created by teams. Your priority needs to be your team as a whole. Act four, rehearsal. The real creation of a theater production comes in rehearsals. Flawless execution depends upon relentless rehearsal. In early rehearsals, it's common to break a show down into individual scenes, individual pieces, individual units, and experiment to play with the lines of dialogue or delivered, to play with the movement, with the flow. This is essential. A show is the sum of its parts. Each part needs to be strong and stand on its own for the show to be strong. In software, we do something similar with unit tests. We use these to break or code down into modules where we can develop and explore and experiment with new ways of doing things. This is also essential. A software application is the sum of its parts. Like a theater production, every part needs to be strong and stand on its own for a software application to be strong. A theater production that only rehearses individual scenes, however, is not a full production. My senior year in college, I played a lead role in a production of the Arabian Knights. At one point in the show, I exited the stage as one character and about 30 seconds later, I had to re-enter the stage as another character. This involved a pretty significant costume change that I only had about 30 seconds to make. When we ran each scene individually with full costumes, hair, makeup, everything worked fine. It wasn't until we rehearsed the entire production that we realized there was no way for me to make that change on my own. It's never a good thing when a show is running, even in rehearsal, to hear the director screaming your name from the audience, asking, where are you? The variable, which in this case was myself, was not being passed properly between modules. We fortunately started these rehearsals early enough. We had the time and resources to make a change. What we did was we had a dresser move from being stationed in the dressing room to being stationed backstage to help me with the change. Had we waited until just before opening night, or God forbid, opening night itself, we would not have had the time and resources to make this change. Integration tests, running your application from beginning to end, are essential. There is time and cost to setting these up and maintaining them, but the benefits are worth it. There are bugs you will never catch until you run through your entire application. Doing this early and often ensures that you too will have the time and resources to fix these bugs. So far, we've covered vision, limits, casting, rehearsals. After rehearsals comes opening night, and after opening night comes Act Five of this presentation, reviews. There's a saying in show business, don't read your own reviews. The truth is everybody does. As a performer, I do what I do to entertain. I want to know what people thought. I want to know whether they found it entertaining, whether they experienced what I was trying to convey to them. I do the same thing as a developer. When I release an application, whether it's a public application or an internal tool that will only be used by my company, I want to know what people think. I want to know whether they find it useful, whether it added to their workflow. I'll admit I do sit at Twitter right after I launch it, watching it, refreshing it, and waiting for the reaction. Those few minutes of waiting for the reaction on Twitter, though, are terrifying. The key to dealing with reviews and maintaining your sanity is knowing the difference between constructive and unconstructive reviews. Constructive reviews may tear you down, but they also build you back up. They're what will make you a better developer. They may hurt to hear, but it's what will make you grow. In theater, an example of this is a review which reads, the performance of Hamlet was rather weak, because the actor playing Hamlet spoke very softly. If the actor playing Hamlet would speak louder, he would be much more effective. A software example of this is this web application is difficult to use because the links are not in any kind of order. Putting the links in a logical order would make it much easier to use. These reviews not only tell me exactly what the problem is, they also give me a foundation upon which to build a solution. Unconstructive reviews, by comparison, only tear you down. Their purpose is only to complain or to incite a reaction from you. A theater example of this is this show is completely without merit. Don't go see it. Again, sounds like an exaggeration, but it's not. An example of this in the software world, this has actually happened, by the way, is I hate this app and it makes my life horrible. These reviews don't give me any indication of where the problem is and don't give me any basis upon which to build a solution. When you receive unconstructive reviews, remember the canon rule of the internet. Don't feed the trolls. It's not worth it. Knowing the difference between constructive reviews and unconstructive reviews is also very useful when it comes time for you to give reviews. You will occasionally have to give a negative review, sometimes to a member of your own team. Keeping it constructive and keeping your criticism to the application itself rather than the person who wrote the application will help them maintain their sanity. Once you've isolated the constructive reviews from the unconstructive reviews, it's time to consider incorporating those reviews. It can be tempting to dismiss your audience as not sophisticated enough or not technical enough, but this really isn't fair. This is the audience you built the application for in the first place. It's your responsibility as the developer to show them what they should do, what they need to pay attention to, most importantly, why they should care. If the majority of constructive reviews are negative, it's time to revisit your vision, to figure out why people aren't experiencing it and what you can do to fix it. The best way I found to do this is to engage with constructive reviewers. If someone gives you a constructive review on Twitter, it can be really helpful to message them, to start a conversation with them, to figure out what it is they're not getting, what it is they're not seeing, and what you can do to fix it. Once you figure this out, it's important to incorporate these changes as quickly as possible. The quicker a user sees their problem fixed, the more good will you will restore. Additionally, the more good will you'll carry over the long term. Nobody likes to receive criticism. It's not fun. It took me a long time, both as a performer and a developer, to realize there is something useful in negative reviews. There would urge me to grow, and in the ever-changing world of software and theater, growth is essential for survival. We wield tremendous power. We create experiences that transport people to new places. In software, this may be creating a website where someone can easily book a flight from San Francisco to New York. In a theater production, this may be transporting an audience to the magical forest of Arden in a production of As You Like It. We weave these experiences out of seemingly nothing. Software, at its most fundamental level, is just ones and zeros that are understood by a computer. Theater, at its most fundamental level, is just a story, maybe a few actors, maybe a few props. These experiences can change a business, an industry, a society, even the world itself. You have this power. Use it wisely. Thank you.