I'm going to stop short of saying I've become a bad programmer over the last year, but I will definitely say I've written alot of bad code. Well, alright, that's actually not true on two counts:
- It hasn't been bad code, just poorly, well, no, lazily architected code.
- I didn't really become a bad programmer, i just maintained my level of already not good programmering.
That said, it's been really interesting making the transition from tools...eh...programmer to software prototyper/artist. It's gotten me thinking quite a bit about what elements of coding are important to me as an artist and more than that, how I would present the idea of programming to someone who was interested in software art, or creative coding as it were. I've often ranted about how the reason more people don't get into programming is not because the act itself is hard, but more because of how it's taught. That's the problem I know I had with learning C++ especially, all the books start out with variables, then move onto simple functions, then eventually get to the meat of the language, but by then I'm just bored. One could argue that people need to be introduced to the concepts slowly, which I agree with, but I think it's the order of the presentation and the way we connect concepts to each other that's up for review. For example, when I'm in my (somewhat questionable) artist mind, I'm a very visual learner, I like to see things happen. So when I have to read chapters that drone endlessly on about simple variables, of course I get bored. In the same vein, I like building things. I feel like if programming were presented in the context of building something, rather than a set of disjointed programs/code listings that just focus on single concepts, it would be easier for people to make the connection from theory to application.
So where am I going with this? Well, me being the arrogant know-it-all that I am, I think I've come up with a good way to teach, not programming in full perse, but enough to get someone started down the path of creative coding. Even though I'm convinced the world doesn't need another set of "Learn to code using processing" tutorials, I feel like I need to write this line of thinking down because it may just be useful. Or I may be crazy. Or...crazy useful, right, right? Anyway, if you're interested in following along, I'd recommend a few things before diving in:
- Download Processing. I'll be using Processing 2 for this tutorial series, so the most recent version (2 beta 7 as of this writing) on the website should suffice.
- Make an account on OpenProcessing and sign up at the Coding For Creative Non-Coders 101 Classroom. Send me an email when you do and you'll get free OpenProcessing Plus+ membership.
I'll admit i'm picking a rather lame time to kick this off, as I'm up to my nasal hairs in CES demos, but my goal is to have the first five sections done by mid-February. Stay tuned and I'll see you in the first lesson!
No comments:
Post a Comment