Thinking in Code Part 1 – On The Importance of Correctly Making Sandwiches

So before this gets started in earnest I’m going to point out that this post will contain very little, if any, actual computer code. Today is all about getting in the mindset required to make something from scratch, and sitting in front of a computer screen can hurt that process more than you’d think.

Select this paragraph, copy it into a text editor and print it out. Did you do that? Good. Now go to your kitchen and make a sandwich. Write down every single step you take on the path to a delicious lunch (or breakfast, or dinner, or midnight snack.)

Take a look at that list. How thorough were you? Did you start with ‘acquire bread’ or go straight to spreading the mayo? How about the middle? Did you specify how much ham and precisely how it gets placed? Did you list optional items, like mustard? The trick to beautiful code is painting a complete picture of everything that happens before you even sit down at the computer.

If this is your first foray into the world of code it’s time to get excited. Coding is actually a very relaxing activity (assuming you aren’t under deadline – then it’s exactly the opposite).  While my lady does her yoga thing to de-stress I’ll fire up Processing and try and make pretty shapes or something – it’s definitely a therapeutic past-time.

Here, then, are some important things to keep in mind over the coming weeks as this tutorial takes shape:

1. Syntax and Grammar Matter A LOT - The way you type your code in a given language is called syntax.  Much like a spoken language every computer language has it’s own rules as to how ideas have to be stated in order to be executed, as well as an order to how things have to happen.  You can’t, for example, declare a variable as an integer (a number without any decimal points, essentially) and then later expect that variable to be able to handle a value like ‘1.5.’  Get used to thinking in the code you’re working in – it’s a struggle to get there, to be sure, but with dilligence it’ll happen.  Here might be a good point to mention that when you see example code you don’t want to just copy and paste it into whatever editor you’re working in; a better call would be to type it out by hand, run it to see the result, delete it, and type it out by hand again (and again, and again, and again) tweaking things a little bit each time but keeping the core of the code the same.  This will achieve two ends – 1, it will drill grammar and 2 it will show you exactly what each line of the code is doing as you make you’re own adjustments.

2. Everything takes patience - Bugs happen.  All the time.  A lot.  There’s no getting around it.  These are beautiful – they allow you to learn, and maybe will compel you try something different next time.  Don’t rage, embrace.

3. No, really, you need to be patient - Learning this stuff takes a not insignificant amount of time, but it’s worth it!

4. Computers do what you tell them to, as long as you phrase it right – Rather self-explanatory but it bears mention.  I’ll use a personal example here – Ray at Vidvox, makers of the super-rad VDMX VJ software (who are the kings of responding to crash logs, by the way – if you work with live visuals at all you should check this software out if only for the super-awesome tech support) clued me in to the wonderful world of differences in what people can make using Quartz Composer.  My ignorance of these differences led VDMX to occasionally get grumpy, which is different from VDMX being buggy.  In short, when things don’t work, find out everything you can about what you’re trying to do before you throw your hands in the air and start screaming at your machine.

5. The end result is what drives a project, not how you get there – This is something I struggle with every day.  There are so many tools out there that it can get hard to choose how you want to go about doing something.  I’m going to go ahead and say it straight – if you can solve the problem without having to code your own solution that is generally better in most situations involving either time management or collaboration with others who might be waiting on you to deliver before they can move on.  If you’re reading this you are probably not a professional developer – using Ableton Live to get a peice of audio to playback at the speed you need, for example, instead of messing around in PureData playing with buffers and things you don’t understand yet will get you working towards the end result faster (and make clients happier because you’ve done it quicker, which is something to keep in mind) which will allow you to get moving on to the next bit of the project that much faster.  If, on the other hand, you’re looking to achieve something super-specific or you’re doing your own work or time isn’t an issue or you just really want to then rolling-your-own can be a great solution.

Alright, now for the fun stuff.  Over then next few months I’ll be showing you some nifty tricks in Processing, and you’ll be working along side me as I dig in to Max/MSP/Jitter and OpenFrameworks.  If there is significant interest I have no problem writing a short series on Isadora as well, but that’s a bit of a niche topic.  Because we all have different needs – I’m a live media designer, so a lot of what I’ll be doing is going to be oriented towards streamlining my performance process – we won’t all want to reach the same ends but we should definitely do our best to help each other get there.

Remember when I said there wouldn’t be any code?  I lied.  Go hit that Processing link and download the IDE for your system.  Once you’ve installed it type the following code into your editor window (it’s the only window, if you’ve just launched the progam and haven’t touched anything yet):

// Circles!
//by Ted Pallas
//Dec 20, 2009
//Shared Under a Creative Commons Non-Commercial Attribution License

void setup(){
size(screen.width, screen.height);
smooth();
background(#A5D1FF);
frameRate(30);
}

float count = 0.00;
float angle1 = 0.00;
float angle2 = 1.00;
float rectsize = 0.00;
float size1 = 0.00;

void draw(){
strokeWeight(5);
stroke(random(120, 220), random(120, 220), random(120, 220), random(30, 120));
angle1 = angle1 + 5;
count = count + 1;
}
void mouseMoved() {
strokeWeight(1);
stroke(0, 0, 0, 255);
fill(random(120, 220), random(120, 220), random(120, 220), random(30, 225));
size1 = random(8, 20);
ellipse (mouseX, mouseY, size1, size1);
}

//end code

Hit run (the little play button or, if you’re feeling fancy, apple-r on the Mac or cntrl-r on Windows (and maybe linux?) will do the same thing.)  If it doesn’t run make sure you typed it out correctly.

Does it run?  Do you see what happens when you click and move the mouse?  Pretty neat, right?  Now start messing with it – I might save a copy to fall back to if I break it.  Change variables, move things around, just have at it.  Please post what you’ve come up with here in the comments.

Your other bit of homework is to make three more lists of steps you need to take in order to achieve a task.  We already did a sandwich but I bet you’ll be hungry again soon so why don’t you try another food that involves cooking, sorting/washing laundry and hooking up a ster-erry-erry-oh system?  Again, please post these in the comments – we’ll learn more from each other (myself included) then we would without.