Program Like a Pixar Story Artist
A friend recently tweeted a list of story basics from Pixar Story Artist Emma Coats. These basics are some of the story-writing guidelines Emma has learned from her colleagues and they’re pure gold for writers.
As I was reading the list I was struck by just how many of the items on her list–with just a little modification–apply to programming as well. It’s all creative work. It’s all writing.
| Story | Code |
|---|---|
| #2: You gotta keep in mind what’s interesting to you as an audience, not what’s fun to do as a writer. They can be v. different. | You gotta keep in mind what’s interesting to you as a user, not what’s fun to do as a coder. They can be very different. |
| #4: Once upon a time there was _\_. Every day, ___. One day ___. Because of that, ___. Because of that, ___. Until finally __. | In order to ___ as a ___ I want to _\_. Given __ when ___ then ___. |
| #5: Simplify. Focus. Combine characters. Hop over detours. You’ll feel like you’re losing valuable stuff but it sets you free. | Simplify. Focus. DRY it up. Hop over detours. You’ll feel like you’re losing valuable stuff but it sets you free. |
| #6: What is your character good at, comfortable with? Throw the polar opposite at them. Challenge them. How do they deal? | What are you good at, comfortable with? Throw yourself at the polar opposite. Challenge yourself. How do you deal? |
| #7: Come up with your ending before you figure out your middle. Seriously. Endings are hard, get yours working up front. | Come up with your test before you figure out your method. Seriously. Passing tests are hard, get yours working up front. |
| #8: Finish your story, let go even if it’s not perfect. In an ideal world you have both, but move on. Do better next time. | Ship your code, let go even if it’s not perfect. In an ideal world you have both, but move on. Do better next time. |
| #10: Pull apart the stories you like. What you like in them is a part of you; you’ve got to recognize it before you can use it. | Pull apart the code you like. What you like in it is valuable; you’ve got to recognize it before you can use it. |
| #11: Putting it on paper lets you start fixing it. If it stays in your head, a perfect idea, you’ll never share it with anyone. | Put it ‘on paper’ lets you start fixing it. If it stays in your head, a perfect idea, you’ll never share it with anyone. |
| #13: Give your characters opinions. Passive/malleable might seem likable to you as you write, but it’s poison to the audience. | Be careful with your users’ options. Abundant options may seem good to you as you code, but it’s poison to the product usability. |
| #16: What are the stakes? Give us reason to root for the character. What happens if they don’t succeed? Stack the odds against. | What are the stakes? Know the reason for the feature. What happens if it doesn’t work? Handle this gracefully. |
| #17: No work is ever wasted. If it’s not working, let go and move on – it’ll come back around to be useful later. | No work is ever wasted. If it’s not working, let go and move on – it’ll come back around to be useful later. |
| #18: You have to know yourself: the difference between doing your best & fussing. Story is testing, not refining. | You have to know yourself: the difference between doing your best and fussing. Coding is iterative. |
| #19: Coincidences to get characters into trouble are great; coincidences to get them out of it are cheating. | A hack to get the test to pass is great; a hack which ends up in production is cheating. |
| #20: Exercise: take the building blocks of a movie you dislike. How d’you rearrange them into what you DO like? | Exercise: take the building blocks of some code you dislike. How would you rearrange them into what you DO like? |
| #21: You gotta identify with your situation/characters, can’t just write ‘cool’. What would make YOU act that way? | You gotta identify with your users; you can’t just code ‘cool’. What would make YOU use this feature? |
| #22: What’s the essence of your story? Most economical telling of it? If you know that, you can build out from there. | What’s the essence of your feature? Most economical coding of it? If you know that, you can build out from there. |
Look at the world around you and what people in other fields are doing and you’ll be amazed at the lessons they can teach you.