Sunday, March 04, 2007

Greetings, Program

I can't think of a snappy intro, so let's just dive right in to my programming background.

I've been giving this post some thought for about a week, and trying to come up with as much relevant information as I can remember. My dad has been involved with computers for as long as I can remember, so anything resembling talent on that front that I may possess has been osmotically obtained from him. And I'm talking waaaay back; not quite Pong - because I don't think I ever played Pong - but close. Early Atari and Intellivision days. We were among the few to actually have a home computer, one of those boring IBM jobbies with a couple of floppy drives. I don't remember doing much on this computer other than playing Bruce Jenner's Decathalon - you had to pound back and forth on the [ and ] keys to make him run - but I think I can trace my programming roots as far back as this. Maybe just the seed was planted here.

The next thing I remember is in middle school. It was some kind of rudimentary drawing program. It might have been called Logo or something like that. I remember a turtle. You'd feed the turtle a list of instructions, like go forward 10, turn left, go forward 5, turn right, and so on. Imagine a computerized Etch-A-Sketch, only harder.

Sometime in my late middle school/early high school years, we got an Apple II-compatible computer. I think it was called a Laser 128 EX. I would use this to type up reports for school, and it was here I got my first exposure to a markup language; though it would be years before I would really understand what that meant. The word processing program was called FrEdWriter - Free Education Writer. And if you wanted something to be bold, you had to put a ^B before and after it, or ^U and so on. But this was long before the days of WYSIWYG, so until you printed it out on the dot matrix printer, you never knew quite what your pages would look like. When I would later attempt to learn HTML, I was instantly reminded of good old FrEdWriter. I don't remember when, but somewhere along the line I started playing with BASIC. I am something of a BattleTech geek, and fellow geeks know that in order to create a customized 'Mech, there is a lengthy set of steps and formulas to go through. So I attempted to come up with something using BASIC that would allow me to automate some of this process. I never finished it, never quite got it to work, and years later I would perform a random software search and discover a Windows-based program that did things I could never dream of hoping to do with my feeble attempt.

In high school, I took a class on Pascal. I don't remember what I did with it at the time other than class projects, and I don't think I've ever used it since, but that was my first example of formal training.

Freshman year of college presented my with a class on C. I remember really enjoying this class, and being pretty good at it. But, this was a class intended for engineers, and an introductory class at that, so I never got into some the uglier things like memory management. Over the rest of my college career, I would be exposed to things like Matlab and LabView. In college, as an engineer, of course my primary purpose in programming was to use it to solve a particular problem. So I got pretty good at computational/procedural programming, but never really had to worry about things like user interface and graphics. And in some sick twist, I found that I actually do enjoy tracking down bugs.

I've made a couple of attempts over the years to get myself into hobbyist programming. While still in college, I got an educational discount on CodeWarrior, and still have a number of books on C and Mac Programming. I'd start out with a lot of enthusiasm, which of course would eventually bleed off and I'd lose interest. In hindsight, I think part of the reason is that I never had a goal in mind. I would tell myself that I wanted to program, but never decided WHAT I wanted to program. If you don't have a specific goal in mind, it is hard to maintain the discipline required to take the steps necessary to reach an ambiguous goal. This is part of the reason I've never messed with AppleScript very often. I feel that the vast majority of tasks I perform are not of a scriptable nature, and what's left doesn't happen often enough to motivate me to come up with a simpler solution.

At my current job, I'm the local guru of the CAD software that we use; I-DEAS. It took me far too long to realize that I was performing numerous repetitive tasks in Drafting. And even though I had been an instructor for this software for several years, and even though I had personally told students that Drafting has a macro language that is handy for automating repetitive tasks, it never occurred to me to use this capability. It wasn't until I attended my first I-DEAS conference and saw a presentation regarding Drafting customization that I finally made the connection. So I came home and quickly cranked out a handful of semi-useful macros. What had been 6 or 7 steps is now a single button click. And my madness grew from there. I began to identify needs that the users had, and realized I could address several of them with macros. With plenty of trail and error, and help from the I-DEAS user group, I was able to create a set of customized tools that have saved my department plenty of mouse clicks, and numerous potential errors. Along the way, a couple of coworkers started playing with Excel spreadsheets, and wanted to add some automation to them. I was able to help them by using some relatively simple VB scripts. It was during this time that I learned what a valuable programming resource Google is. Type in a description of what I want to do, and chances are you can find some sample code.

I've designed numerous web sites along the way, so I have exposure to HTML and also CSS. For both of these, I know just enough to get by, and am well aware that what I know is merely the tip of the iceberg. And historically, my web sites have had reasonably good structures, but miserable graphics. I'm not an artist.

So where does that leave me? I have exposure to several languages, but am a long way from mastering any of them. I understand user interaction at a very high level, but struggle with the details. I've never dealt with memory management, file management, and a whole host of other topics that full time programmers deal with on a daily basis, I'm sure. And I've never done object oriented programming before. In other words, I know just enough to be dangerous, and to be seriously overwhelmed.

I've made an attempt or two to learn how to program in Cocoa, but for me Apple's documentation did not do a great job of explaining things. I'm probably just a tad outside the target audience. Last year I picked up a few books, and have started working my way through them. It's slow going, and I've started over with each book several times and I haven't yet completed any of them, but the concepts start to sink in a little further each time. I think I'm starting to understand OOP at a high level, but am intimidated by the sheer volume of available objects in Cocoa. At least for now, Interface Builder should cover my needs. I won't be breaking any new ground, but at least the interfaces shouldn't suck (too hard).

This is the year I get serious. I'm signed up for the Objective-C/Cocoa Bootcamp at Big Nerd Ranch in July. Hopefully I'll finish a book by then.

No comments: