Learning from Pixar

By Matt Roberts
July 10, 2012 | Comments: 0

Good developers avoid duplicating processes that have already been created or optimized by others. You don't want to spend time reinventing the wheel. Instead, you want to be able to search for existing solutions to programming problems, often in unexpected places. My experience with those kinds of searches is why I found Emma Coats's #storypoints list so interesting. I recently came across her short blog post that originally appeared as a series of tweets on Twitter.

When I read over her list, I was struck by how many of the points applied not just to storytelling, but to software design and development as well. I've fallen victim to some of the more cautionary ones myself (some of them more than once). For example, list item #7 is a near-constant struggle for most developers, including me. Establishing clear and elegant programming goals, often with non-developers, and then staying on track to reach them requires focus.

And about half of the useful features that we've incorporated into CodeRunner for OST would've benefitted during development from a bit more of what's prescribed in list item #2: consider your audience. For me, that audience is OST students (special thanks to those students who help me continue to refine those features).

In the same way that Coats's list may help fiction writers navigate the creative process, I'll share my experiences here that may help new programmers avoid some of the pitfalls I've run into, and also assist other developers to refine their own processes.

To those ends, here's my interpretation of a slightly abridged version of Coats's list. The next time you start up a new project, you may want to keep these tips in mind to help you along. (I've retained Coats's list item numbers so you can reference the original blog post):

#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 very different.
- Most of the time, you won't be the only one using the software you've written. Just because a feature is intuitive to you doesn't mean the user will connect with it so readily. What you perceive as the cool way of interacting with your software isn't always the most accessible to others.

#3: Trying for theme is important, but you won't see what the story is actually about till you're at the end of it. Now rewrite.
- The neat idea you had may not make much sense until you've actually written an application that implements it. Once you've gotten it working, refactor it. You'll catch errors you missed the first time, and maybe even get rid of redundant code.

#5: Simplify. Focus. Combine characters. Hop over detours. You'll feel like you're losing valuable stuff but it sets you free.
- Don't try and do too much for your first release. Get the core functionality working solidly and release it. If you start too big, you may never finish!

#7: Come up with your ending before you figure out your middle. Seriously. Endings are hard, get yours working up front.
- Beware of feature creep! Before you start your project agree on the end goal. Once you have that, stick to it. You can always add new features in version 2.

#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.
- User feedback is far more valuable than the addition of one more feature. Get your application in front of someone who will be using it and listen to what they have to say. Take notes and refer to them when you're working on the next version (or your next project).

#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.
- Write a proof-of-concept version of your application. It doesn't have to be feature-rich and it doesn't have to work 100% of the time, but it should show what you're trying to accomplish. Once that's done, start fixing what's broken, getting help if you need it. There's a huge community of developers out there willing to share their knowledge.

#14: Why must you tell THIS story? What's the belief burning within you that your story feeds off of? That's the heart of it.
- It's easy to lose steam when you start hitting roadblocks, but that doesn't mean you should quit. If you're working on a project and your enthusiasm starts to fade, stop and recall why you were excited about it in the first place and then refocus that energy.

#16: What are the stakes? Give us reason to root for the character. What happens if they don't succeed? Stack the odds against.
- Why should users use your application? What makes it different, unique? Why should they keep coming back? You should know the answers to these questions before you even start coding.

#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.
- Even old, broken, and abandoned projects are worthwhile. You always learn from them and sometimes they even contain chunks of code you can reuse and refine for your new projects.

#18: You have to know yourself: the difference between doing your best & fussing. Story is testing, not refining.
- Fussing over a specific section of code can keep you from solving another problem. If it works well enough for now, give it a rest, make a note, and refactor it later. Just don't forget to revisit it.

Whether you're writing stories or writing code, creative processes have a lot of overlap. Intuitively, I had already put some of the processes on the list into practice, but until now I had never actually described elements of my own approach.

The original blog post brought to mind how useful it's been for me to get a fresh take when I'm tackling a particular problem. I work to solve problems daily, and a new point of view is often the catalyst that helps me to figure out how to do that.

Learning from Pixar

Tags:

Leave a comment

Search the Blog

Tag Cloud

Archives