The Philosophy of Not Work

For the past four years, I’ve participated in Carnegie Mellon’s annual themed entertainment competition, Booth. It’s a rewarding and frenetic effort that culminates in building structures like these:

Each booth features a themed game, and my fraternity typically produces original video games each year. The game team is headed by a game chair, typically with one key assistant and a few other helpers. I was game assistant my Freshman year, game chair my Sophomore year, and worked on various aspects of installation and controller design my Junior and Senior years.

During the development of last year’s Lord of the Rings game, a core team formed of Game Chair Andy Biar, Lead Artist/Producer Eric Mackie, and myself developed the philosophy of Not Work.

It’s exemplified by the phrase:

“Why do Work when you can do Not Work”

It’s a concise, pithy strategy for getting things done on those just-for-fun projects. You can (and should) interpret it in a variety of ways as it applies to project decisions.

Sample uses include answering the following questions:
“Do I use this open source library or roll my own?”
“Should I build all the features for a full product or just a functional prototype?”

Often, the path of least resistance is the correct one for these types of prototype-is-final-product type projects. You can always use more time to focus on making your work great and fun vs wrassling with the technical details.

It’s not always just taking the easy way out, though. The philosophy of Not Work is really about simplifying problems down from large complicated ones into known, solvable ones.

To give an example, when we were looking at the Lord of the Rings booth game, we wanted to have the controller be Gandalf the White’s staff. We looked into a variety of ways to sense the position of the staff. Accelerometers were’t precise enough, CV with a bright dot was too buggy, and it looked like something along the lines of Johnny Lee’s wiimote tracking was our solution. After exploring a lot of different ways, we came to a realization: since players hold the staff out in front of them, couldn’t we just use a Kinect and track the closest point? With about 5 minutes and a quick processing sketch, we had a working tracking prototype.

Final Game Installation

Now that isn’t to say the philosophy of not work always pans out. In the end on LOTR, we had so many sensor jitters from the Kinect we were forced to change our game concept. Still, the core philosphy of not work was helpful for making critical decisions under intense time pressure at many points throughout the process. There’s this overwhelming relief when you face a problem that seems insurmountable and you find that one little trick to simplify it.

So the next time you have some work to do – ask yourself if you can do not work instead.

Leave a Reply

Your email address will not be published. Required fields are marked *