People tend to define themselves by their professions. My path through the working world has been circuitous; in a real sense, it's fair to say I've never had a profession as such.
Most people who know me, know me as a "web developer", though I didn't settle on that particulara appelation until 1997 or so. I've been writing since fifth grade, and only working in computing (off and on) since 1991, when I landed help desk and software-training jobs at the University of Rochester. My "professional" computing work, all since 1996, has included website copy, technical writing, requirements analysis, webmastery, web development, solution design, software training, and desktop support.
I used to cringe at writers' bios, filled with casual references to serving as cultural attaché to Iceland, working passage to Indonesia on a garbage scow, and so on. A while back, I counted my jobs and discovered I had accumulated a writer's bio of my own, including (in some cases several) stints as a janitor, cook, secretary, library assistant, unwitting "big-con" flunkie, microcomputer jock, web-doyen, and unarmed security guard.
While I like to think I offer some resistance to the "virtual life", computing has worked its way into many corners of my personal existence. In recent years I have spent a great deal of time thinking about the relationship between people and their computing technology, and in turn with the society in which people live and play.
Very recently, I have also been thinking about the nature and future of work and career, as we shift in fits and starts to a workforce organized around one or another form of contingent labor. In particular, I have been trying to find ways to help people reclaim more control over their own career paths and life-choices, instead of tacitly leaving them to be determined by employers or politicians.
As a web developer, I have worked primarily in the Presentation Layer -- that is, I have been responsible for laying the groundwork for user experience from the output of business logic through the point of presentation in the browser. In the late '90s, I built the front end code for many of the sites in Element K's family of online offerings. More recently, I designed and built an extensible presentation layer for the Xelus corporate website that would permit their corporate marketing personnel to make sweeping changes to appearance and information architecture by modifying only a few library files. I later used that as the basis for a similar system in PHP that I used to drive several websites.
My interests in site development extends to all areas that touch on user interactions: Information architecture, information design, interaction design, site usability, and product development, to name a few.
If I have had a specialty, it would have been in producing low-overhead solutions to the problem of separating content from presentation. Put in practical terms, every dynamic site I've worked on (professionally) between 1998 and 2007 could be radically changed in appearance by editing only two to three files (typically a function library and a stylesheet), without the use of high-overhead transformation technologies like XSLT.
More recently, though, I've been approaching these problems from a different angle. I've been working with Drupal since about 2003 or so, and using it to deliver sites for clients since 2007. (I've built 16 Drupal sites since 2007...that I can remember...and several in other CMSs, like WordPress or Joomla.) If the site is more than just a few pages, I can usually build it faster using a CMS than I can using static pages, and I'll also be able to show the client how to keep up their own content. That's a big deal: I never want to be in this game to keep people dependent on me. When I'm done working on a project, someone else should be able to come in and pick it up.