/   person work projects words pictures near far
              Devin, out of order Devin Carraway


This page never stays current. I gather that out in the world of non-tech jobs people sometimes stay in one place a long time; their employers don't go under or turn into marketing firms or stuff like that.

I write code. Various languages and purposes. Unless this page gets really old, I probably still do. Most everything I do is written for some flavor of UNIX -- still probably the finest environment for engineers. My best languages are Perl and C; the full list is about a dozen or so. Though I'm not much experienced with it I have a fondness for Scheme -- it's quite elegant and comprehensible at least in its simpler uses, for which reason it's taught to undergraduates with no computer experience (though unfortunately they tend to have little math experience, which screws them up a good deal.)

I have a generalized distrust of OOP-heavy languages and programming approaches. Mostly they tend to move the work around without actually getting it done -- and as it's taught academically, the focus seems to be to move all the actual computation into compiler-generated code.


An e-commerce company of some popularity -- I suspect you've heard of them. Amazon acquired some of the Bluemug staff in 2003. At Amazon I worked on browse systems (product taxonomies and navigation -- "stocking the shelves" essentially), then in early 2004 transferred to the Search team and then to Amazon's A9.com subsidiary to work on search technology in California.

Amazon is a strange place. Everything about it is immediately familiar to folks who have done professional software engineering, and yet it's all subtly different. Some of that is because unlike most of the software industry it's all geared around selling things. Some is because Amazon has a very strong sense of itself -- not always healthy, but always manifesting. It's at once the most challenging place I've worked as an engineer, and the most frustrating. One of my private little missions in the place is to spread the religions of convenience and simplicity through the Great Church of UNIX, exhorting the downtrodden masses to rise up and cast off the yoke of crappy environments, tools and burdensome designs.


A wonderful embedded software company focused on communications gadgets -- cellphones particularly. It's oddly interesting niggling over individual bytes, or having to care about the tiny elemental pieces of code without which the fancier parts don't function. Less interesting is dealing with the communications carriers who provide the connectivity to those cellphones, who woke up one morning and realized they weren't a monopoly, then went back to sleep and forgot. I'm a "project engineer," so I get to do a fairly varied selection of things on quite a few different gadgets.


An interesting rapid-contract job working on database performance monitoring software. Unlike many such items it worked. Some PHP4 sessions were involved, and I got the thing to work properly under Mozilla.

Touchtone Solutions, Book Exchange and Ejobs

A contract job that dovetailed fairly nicely with school. The Book Exchange project was, essentially, a way for students to trade in their textbooks at the end of a semester for the ones they'll need next at rates less ridiculous than those conventionally charged by college bookstores (and, more to the point, textbook publishers). Ejobs was an employer/jobsearcher matching service intended for colledge career centers. I wrote the former, and did the PHP3, wrote the template system and did the cosmetic work for the latter. Both projects are principally built using perl, MySQL and Apache.

Community Servers, c/o Keyplus

Somehow I keep getting into these little companies trying to grow out of their own shoes. Community Servers' sole product is/was the Community Content Server, a great big structured hulk of perl which does all kinds of neat stuff, when it's not broken. This was a fairly abstract piece of software, which had applications in various sorts of publishing -- online magazines, etc. It was probably most analogous to a synthesis of an RDBMS and an abstracted web publishing environment. The project was plagued by an unending series of design disasters, and was ultimately axed to cut the losses. If it had lived it would probably have been fairly useful -- instead, there's Zope, which can do similar things, albeit in Python rather than perl.

The big learning experience from the CCS project was that large software projects that don't follow some sort of preestablished software engineering process tend to fail, and make people bitter or miserable when they do.

Sonic.Net, Inc.

My second (and hopefully my last) stint with an ISP. Sonic is a regional ISP based in Santa Rosa, California. Originally one of those startups that come about when a few geeks notice they could do exactly the same thing but for money, and then as often as not go broke. Sonic hasn't gone broke, and indeed did fairly well for themselves, despite paying their employees on a level commensurate with the grunge end of the foodservice industry. While there I did programming, sysadmin, security analysis and highlevel support in approximately that order. Unfortunately, working conditions were sufficiently poor, and management sufficiently inept that Sonic ultimately fired almost its entire highlevel programming/sysadmin staff rather than negotiate a labor dispute following an informal strike. Here is the employee account of those events. Sonic, like most jobs, left me with a collection of odd personal mementos (see "the wages of career programming, below"); here's my favorite.

One of the good bits at Sonic was the development of Sontec, the tech support management system. Sontec took about a month to write using mod_perl, MySQL, Text::ParsePrint and a few other tidbits. Sontec replaced TkReq, a fairly simpleminded trouble ticket system with a horrid interface and which, to put it mildly, didn't scale. Sontec scaled nicely to the job, and ultimately was handling most of the data flow for the Support department -- trouble tickets, FAQs, tech call logs, user tech support data, some support resource analsysis, etc. The project helped illustrate a number of things to do and avoid in a web applications. Also it revealed that tech support folks are fun to please.


Sonoma.Net (pronounced "sonomanet") was another startup -- a little more than two years of programming, sysadmin and running extension cords next door to run the servers when the power bill didn't get paid and PG&E cut us off. Sonoma.Net's biggest obvious problem, other than bad small-business luck, was overambitious management, who tended to get us work in the wrong quantities and of the wrong nature, while I and the other geek there played a lot of catch-up and got ulcers. Sonoma.Net made for a lot of good stories and memories that seem a lot more pleasant now that it's all behind me. My very first paycheck ($65 for two afternoon's work) bounced.

Sonoma.Net started out doing ISP stuff with four lines and a TribeLink-8 PPP/AppleTalk box, which broke down a lot and which got administered by either a web interface or power cycling, depending on the specific problem. The machine room contained two pentiums (tuna and halibut), which ran Linux and Apache with near-perfect operational records throughout my employ.

Virtually all of the major work I did while at Sonoma.Net has now been replaced, sadly enough. Some of it was replaced quite justifiably -- often we'd get halfway through a supreme job of engineering a project, then get our timeline slashed or our priorities rearranged and the rest would be done at a breakneck pace with contracts being frantically renegotiated to allow for what was eventually going to be produced. Some of it, though, can be found on my less embarassing creations page.

Sonoma.Net finally collapsed in early 1998. Among the remnants were some O'Reilly books, a few pens, a lot of unpaid back wages and a Sun "Ultracomputing" mousepad which came free with a Sun Ultra 1.

The Wages of Career Programming (incomplete and unsorted)

Piles of paper with scribbles on them. You can never escape these if you permit yourself to acquire a desk. Everytime you finish a project or change jobs, the paper content will suddenly become useless. Yet for some reason, unless you're a Virgo, they will remain in your life, the papers for each job slipping away at a logarithmically decreasing rate. Some of these make pleasant memory-laden reading material, others give you nightmares. You will glance back through the paper or not depending on the proportions.
Manuals you hope never to use again. Assuming, in fact, that you used them to begin with. Some people who write code own a lot of manuals, and know instantly in which one to find what they need. They have good mental indexing skills, but their hash buckets have 16-bit addressing at best.
Books that seemed to be a good idea at the time. Mine include at least 15kg of fortran, PL/I and Algol books obtained for no more than $1.50 each at thrift stores. The idea was that I'd read them for amusement and historical intrigue, but they're far too dull to bother. So I use them to swat wasps with (this is also a good use for those $75-each C textbooks you're forced to buy several of during the average CS degree.)
Documentation CDs. These are almost as pernicious as the obsolete manuals, but you can use them as drink coasters if you're running out of windoze install CDs.
TLAs. Asymptotes appear a lot in this kind of work. One that applies here is the rate at which the proportion of used/remaining TLAs, f(x) = n/363, approaches 1.
Homedir cruft. No matter if the server you're doing the work on is across the world and the code won't even run on your workstation, this happens, and then you're afraid to delete bits because you can't remember if you ever got them into the main codebase or not.
Harmful nutritional, behavioral or sexual habits. Mine include Safeway "balanced nutritional supplement," a brown liquid sold in packages of six cans each, tasting sort of like Yoo-Hoo, but with enough nutrition to keep your stomach from eating itself if you consume it at a sufficient rate. This rate varies with your caffeine and food intakes. Behaviorally you tend to see people and situations as input-output systems, which leads to problems with girls. Though that, as commented elsewhere, is probably just as well, since if you get roped into doing tech support for your own product, it tends to put you off one or both genders for extended periods.

A few complaints about voicemail.