Harnessing the Abundance

There are actually two points embedded in that statement. The first is defining your goals. It's one thing to say, “I'm going to render something using Sunflow.” It's an entirely different — and more productive — thing to say, “I'm going to generate a cloth-like dynamic mesh, illuminated by two point lights, and render an image suitable for printing using Sunflow and Processing.

The latter statement is a much more refined goal. Something that has identifiable milestones and places to begin. By stating a goal with some precision, you're giving yourself a path to follow — a beacon to head toward. This will help you get started, help you keep moving, and help you know when you're done. Those milestones (in my example, "generate", "cloth-like", "mesh", "two lights", "print", "Sunflow", "Processing") define increments for progress. And each increment hit represents more creative fuel to keep pushing forward.

The second part of that statement is in the establishing of parameters. I usually call them constraints. Constraints are almost always the best thing that you can impose on an idea. As soon as you define parameters around your idea, you're no longer dealing with a blank canvas, and it becomes that much easier to get started and make progress toward the execution of your idea. Constraints can come in many forms:

• Medium / tools (the tangible stuff)
• Resources (people, time, money)
• Conceptual / thematic
• Technique
• Skill / know-how
• Quantity / scale

Some of these are self-imposed. Some are imposed due to circumstances. Regardless, by defining them you're helping to reduce the noise in decision-making; you're helping yourself understand your problem space. Think of constraints as a filter for your ideas. As valid ideas make it through, you've stripped them of the inessentials, and they become ripe for true creative exploration.

If your end goal is the execution of your idea, the fastest and smartest way to get there is to start with what you already know. You should be trying to lower all barriers to entry — those things that keep you from getting started or keep you from making progress. Starting with what you know gets you identifying the problems at hand and digging for possible solutions within your repertoire. You're not stuck trying to understand how to compile your code or how to use a specific feature of a program.

And seeing the state of technology's advancement combined with the sheer volume of open source projects, you can bet that some person or group has created a tool, library, or some other asset that works within the environment with which you're most comfortable.

While there is definitely merit in trying to learn a new tool or programming language in the process of executing your idea, what you're really doing is using your idea as a framework of constraints in order to execute a different goal: learn a new tool or programming language. If your true goal is to execute your idea, I advise taking as many shortcuts as you can.

Search is the tool for navigating the Abundance. There's simply too much out there, hiding in all sorts of digital nooks and crannies for you to make the most of it. Let Google become your new best friend.

But don't just use Google. Learn how to use Google. I implore you to read and memorize the Google Search Basics: More Search Help page to really master the art of the search query. Seriously, understanding these more advanced queries can make or break the success of your project.

And you have to go further than search engines. You need to be familiar with the forums, message boards, discussion lists, and communities associated with the problem space of your idea. Sometimes those places are walled gardens, and they're not up for search indexing. And remember: always do a thorough search before posting questions to a forum. Showing that you've done your due diligence will make the community more likely to help you out.

Lastly, you'll need to learn the art of skimming and result-hunting. This can come in a number of ways:

1. When scanning search results, try to identify those sites that are link bait. Usually they're stuffed with keywords, and the words from your query aren't embedded within an intelligible sentence.
2. Look for real human-written sentences. These usually imply a discussion about a topic. You're learning to identify context.
3. Keep mental note of the sites and domains that generally have reliable information. You'll notice they pop up quite often and can be a trusted go-to source.
4. When you decide to click-through to search result, immediately press Command/Control-F to bring up your browser's Find command. Type in a word or two from your query, and let the browser do the skimming for you.
5. Open up search results in browser tabs. Command/Control-click each result that looks promising (I usually do about 5 or so at a time). Explore those pages, closing the tabs when you're done, until you're back to where you left off in your search results page.

The big reason why you should learn to research — especially when you inevitably run up against a problem you've never encountered or enter a problem space with which you're unfamiliar — is that chances are, someone else has run into the same issue. Moreover, it's likely that a number of folks have run into the issue and that there are pages of information to help you understand your problem, get through it, and possibly even solve it for you entirely.

Often the key benefit to using open source software is the fact that it's free. But in my mind, that's really the least attractive thing it has going for it.

By using open source software, you're standing on the shoulders of giants. As I mentioned earlier regarding search, if you're running into a problem in need of a solution, there's a really good chance you aren't the only one. It seems these days that there's a library or tool out there for just about everything — written in or ported to almost any language you're familiar with. Oftentimes, the best solution to a problem is one that's already been devised, tested, and created by experts in a given problem space. There's no need to reinvent the wheel (unless learning is your ultimate goal).

With many open source projects, you get another big benefit: a community of support and experience. If a project exists, there are usually at least a few people that use it, in addition to the creators. If you have questions about implementation or functionality, there's an opportunity to get a dialogue going to help get you up to speed.

One of my favorite aspects of open source is the fact that it's open. This means you get access to the inner workings of the software. You can learn from how it was built, how certain features were created. This will inevitably help make you a better programmer and problem solver. Because it's open, you can modify it to suit your particular needs should the software not handle what you were looking for. Imagine being able to do that with any of your readymade appliances or commercial software packages.

Some folks insist that a given programming language or environment is king — that all others are inferior and don't deserve their time or attention.

But I feel any experienced programmer will tell you that all programming languages have their strengths and weaknesses. For any given task, you could easily choose from three or four that would do the job equally well. And while I firmly believe you should try to keep within your current scope of knowledge (again, assuming that execution of an idea is the #1 priority), you should always be open to any solution written in any language. The reason: it'll help you get to your goal that much faster.

With enough experience, you'll find that the tool isn't the language of choice, but instead it's actually the act of computer programming itself.

Prototyping is about keeping your eye on that end goal and trying to get there as quickly as possible. It's not about proper technique or general correctness. Prototyping means doing as little work as you can to validate or confirm that an idea or an approach has merit.

Spending too much time planning, tweaking, and getting things "just right" will only ensure one thing: you'll never execute on your idea. Or if you do, it'll take a terribly long time.

Prototyping has another side benefit: it gets you in the habit of actually producing something. By prototyping, you're forced to put thought into action. And in doing so, you'll gain confidence, experience, and knowledge — all of which will make you a better creator in the end.

I use the word community to refer to the group of your peers and heros working in the same and tangental medium(s) as you, in both your digital and physical surroundings. But I also use it to refer to that information input stream to which we submit ourselves — that thing I like to call inspiration. Being a part of this community can be both a passive and an active activity.

On the passive side, you should be following forums, blogs, Twitter feeds, Flickr photostreams, Vimeo activty, YouTube, Delicious — pretty much everything. But you should start by following those streams where the signal to noise ratio is good. Start with your heros, then your closest peers, and follow what they're following. Periodically you should both prune and expand your inspiration stream, in an attempt to keep that signal high and fresh.

One of the best reasons to be taking a passive part in these communities is that you never know when you'll run across something that will resonate with you at a future date. If your interest lies in interactive installations and you're primarily a Processing / Arduino person, there's no reason you shouldn't be following the Cinder and openFrameworks forums. You may not understand everything that's being discussed, but I can almost guarantee you that you'll read a discussion that's remotely interesting and has a serious impact on a project of yours months later.

The point: inspiration can come from anywhere.

On the more active side of community participation, do post questions and answers to forums and blogs. By getting a dialogue going within a community on a given topic, you'll be generating a new resource for the rest of the community. No question is too stupid (unless you didn't search first). And sharing your knowledge is useful not just for the recipient, but for everyone else. Often, you'll find you're contributing something that makes an impact larger than you originally intended.

But participation in a community doesn't just mean getting engaged in dialogue. It means being a beacon, a contributor to the community. Posting your code and posting your work (even if simply for show) adds a tremendous amount of value to the community at large. People will learn from and be inspired by your work. They'll offer suggestions, pose questions, and possibly provide alternative solutions. Moreover, they'll create new work from your work. You will help enable others to bring their own ideas to fruition.

This one's dead simple, and you probably hear people saying it all the time. In fact, I was particularly inspired by a talk from Merlin Mann of 43 Folders at MaxFunCon in 2009 on this very topic. Take a listen because it's worth the 27 minutes.

The point is this: stop reading all those "27 Tips for a Better Drop Shadow" blog entries. Stop over-analyzing your idea, how to execute it, and how to get it noticed by other people. Stop saying you don't have enough time or enough smarts or enough money.

Just start doing. Nothing will get you faster from point A to point B than simply starting. I highly recommend trying it. It's the most addictive and gratifying thing you'll ever do.