Monday, January 24, 2011

Backstepping

I decided at some point last year that re-imagining a place to be carfree and transit happy was something that anyone should be able to do for their neighborhood given the right tools. The tools that I wanted to have don't exist or aren't available in the free and easy to use category. I figured that I could make some of those tools and add them to Sketchup, Google's freely available 3D modeling program. I would offer it has a plugin to Sketchup and create a web site to share and search submitted designs made with those tools. I dug into writing the plugin software, and I quickly hit roadblocks at every turn. Or road disfigurement I should say. I've spent months off and on playing with how to program roads to draw on a map, as I've highlighted in earlier posts. For some reason, other than it working perfectly and me moving on to something else, I've been stuck on this problem for a long time because roads intersect in complicated ways and my programming experience in the the graphics or trigonometry worlds is nonexistent.

I haven't given up on the software or the overall project, but I need to approach the software and a year of my work-time in a different manner, because it's starting to drive me crazy. Here's a list of my current problems, followed by potential solutions.

1. Coding is no fun when you don't make progress.
2. Coding all the time is not optimal for an urban planning student.
3. Big projects that get blocked on the first problem are intimidating.
4. Coding all day alone is lonely.
5. Other people may have solved some of my coding problems but I haven't been eager to invest time into finding and possibly adapting their code to my problems.
6. I have no support network of other urban planning software people.
7. My urban planning peers can't help me and my programming peers can't help me through such a large challenge with coding assistance.
8. I'm losing enthusiasm for the project before I've even completed a single part of it.

Some potential solutions.

1. Step back and look at the problems. Done.
2. Spend more time on researching the solutions to those problems instead of jumping right in to solve them.
3. Read about loosely related but relevant topics, like functional programming, user interfaces, streetscape design, plumbing, or whatever, and taking good notes.
4. Set up a diverse but consistent schedule--time to code, time to read, research, network, etc.
5. Always look around online before you assume that nobody's thought about your problem.
6. Take lots of breaks.
7. Ignore artificial deadlines, but make your own deadlines.

End Part 1 of Backstepping

No comments: