A working life, if done correctly, provides one with a variety of projects in which to learn while doing. Learn about people. Learn about situation. Learn about lifestyles. Learn about life itself. Sure, computer-mediated technologies provide a lot too, but without the variety of circumstance in which one investigates what's possible, how deep is the journey? I woke up one day recently and realized I didn't think about my working life properly. There have been so many projects. So many people, places, and objectives. Each project so fascinating in itself when provided a little reflection in which to be contemplated. A project unfolds before one's eyes. There is no inate ability to perceive the details in advance. One must stay open and listen for answers where no previous personal experience can anticipate their form. This project page is without time, place, or affiliation. It just documents one life as a series of projects whereby a person grows to become who he is. It's not about the resume or the accolades or the sense of the material rewards brought on by a working life. It is about the flow attainable in one working life when the awareness of flow begins to dominate one's consciousness.

If I can help another person see her working life in similar perspective, I think this page has been worthwhile. If a young person with much of their life ahead of them can gain some vicarious benefit, so be it. Even that potential suggests a most excellent reason for getting this down on-line. This page provides a list of projects in the chronological order of when I participated in them. The details can unfold over the weeks to come. The focus of each experience focuses on serendipity, surprise, lessons learned, and change.

The projects (in chronological order):

After school musings of a dead dog vector-based line drawing project

One of life's lessons taught to me often by respected elders is encapsulated by the phrase finish what you start. Sure, I'd been studying French since the sixth grade (when a crush on a mocha colored teacher from Haiti with glorious accent got my attention) and was doing very well in absorbing pages and pages of foreign words to be communicated in meaningful combinations. But, my high school had started a computer science course upon receiving two shiny new Apple 2e computers. How dare they schedule the course during the same academic period as my French series. Another crush on a high school teacher and trips frolicking with cousins in Quebec kept me true to my elders' advice. Luckily, I performed well in my trigonometry course as the teacher doubled as the school computer science teacher (she actually had a computer science degree from USC - southern cal, that is). So, she gave me the keys to the classroom, suggesting I stay after school and get to learn programming BASIC on my own. I was quickly drawn to vector-based line drawing (a precursor to today's popular pixel jockeying fad - line riding, perhaps). I developed a friendship with an aspiring artist (hey Tim, do you remember how we got hooked up on this?) and we hacked away at my first application. He drew out sequential scenes in a dead dog adventure on graph paper and I segmented the drawings into line segments of color I coded into the lines of BASIC I was getting accoustomed to. Basically, as a user, you experienced driving a car long enough to run over a dog in the street. Then, you had to choose what to do next? Would you drive on? Would you stop and put the dog on the side of the road? Would you try and find the owner? Depending on which steps you took, you got the next scene from a random list of scenes that was appropriate to your choice. Always the potential for a happy ending. Always a potential for conflict with society or a mad dog owner.

The main surprise was how much coding I could learn behind the scenes of what a user would actually see on the screen. I could play with all kinds of mathematical equations to incorporate interesting effects to how the visuals played out. I added animation to car wheels and car movement (I believe Tim helped refine that greatly). And still, the user experience was all about the eye candy. Nothing was as attention getting as the humor portrayed in every scene by simple, added artistic lines and animation. The lesson was how important the graphic artist is to the whole computer experience. Even if it is as simple as the design of a pretty icon placed on an attractive toolbar, the user experience is only as good as what the visual cortex receives (later on in life, I would read about the importance of sound in this consideration). Enter the screen saver. That simple piece of software that waged fierce competitions for use (or as a metric, screens deployed upon). I heard Tim postponed college to make a grand a night as a singer for a popular punk band. My French degraded as soon as I stopped taking courses two years later, but it sure did help me learn Spanish in a quarter of the time.

The world of punch tape and a simple program of chance

Soon enough, my beloved high school peers began bringing in Apple 2e programs to run on the two computers I'd been training on. Demand for the box use rose geometrically as a new game entered the mix. I was lucky if I could have the room to myself even after three hours of tennis practice. Well, actually, I'd make deals to let groups of people stay with me as long as they used just one of the two 2e's. I was always willing to watch them (my first hint I'd be interested in machine usability when part of an interesting process) when frustrated with my programming progress. Being the soon-to-be-called geeks of our graduating class, these guys didn't much care for the authenticity of the events being crudely displayed on a 1980-era computer. But, give me a break. A football game without the ability to kick a field goal? You could choose to score three points automatically if you were within the twenty yard line. How goofy was that?

I wanted the ability to offline the field goal process so that the game could continue without me needing to change the single file executable frozen on the seven-inch floppy disk. I chose to write a field goal kicking module on the Hewlett-Packard mainframe churning away in the far corner of the room (I never did ask much about how the machine had been used prior to the Apple 2e availability). Programming on that huge box was noisy as electricity seemed to surge through the components and make relevant surging sounds. And, once done, the pounding of the small hammer that made holes in the punch tape was no fun what so ever to listen to. Still, I found myself adding more and more realistic variables into the field goal experience: Wind direction and speed, field turf and condition, snap accuracy, hold accuracy, and kick accuracy. Choosing to kick a field goal at an appropriate time in the game was quite a study of situation by the time I was satisfied with the experience. But, integrating the module required some silly behavior: A player, upon reaching the mid-field line (center line for you CFL fans - fifty yard line for most of you) could start to consider whether to kick a field goal or not. If you sat outside the twenty and tried the field goal, you'd get a free walk to the end zone if you made the kick (gaining six points but with the knowledge they were really only worth three). Or, if missed, you'd fumble graciously to hand over the ball. If you were inside the twenty, you'd choose the field goal if you made the kick or you'd fumble (a little less graciously) to hand over the ball if you missed. The system worked and we incorporated the field goal module in our more serious matches. My surprise was how satisfying the opportunity to use an archaic programming machine still feels to this day (hey kids - I used to store my programs on paper tape and feed the tape back in to make the program active again). My lesson was that modular programming was an inevitability and yet still a black art that the whole effectiveness of the Web depends upon.

Looking inside with a blood-typing assembler program

Of course, as a senior in high school, it was not posh to hang out with the junior year students after school in the computer lab (which had not grown in assets despite the popularity of software being brought in competively). Besides, Advanced Placement credits meant lots of respect of your senior class friends (so, hitting the books was slightly more popular) while cutting down on the cost of college. And, spending three years of futility with the same tennis team friends begged for a little more commitment in our last chance season (that is a very sad story to be avoided here). I turned to the city community college to keep the programming experience alive and kicking. I forced my best friend to accompany me. As a result, I got to program two class projects for the price of one (thanks Dad for paying). Building upon the enthusiasm of trying out the paper tape technology that made expensive core memory less relevant, I decided to degrade to punch card technology where each statement in a program was stored on its own three-by-seven inch index card (without the lines, but with little numbers to reflect columns across the card from left to right). Everyone had heard of the dreadful shuffle event of humility - when you dropped your cards and got your sequential commands well out of sequence.

I would like to brag that we only used zeros and ones in that course (and as Dilbert says, some of the zeros didn't even work at times), but instead we used a very effective and concise instruction set with which to create programs out of physical machine instructions (move the data in register x to register y). I enjoyed doing that (but nowhere near as much as when I received a much deeper understanding of what I was actually doing in grad school) and found myself competent enough to let myself think I was going to write the program of programs in the course of thirteen weeks time. Being competitive with my best friend, I assigned him a simple blood-typing classification and recording database application. Sure, I would do the work for him, but it had to be a less impressive product than my own. I diligently spent equal time on the two projects, amazed often by how clearly I could see instructions actually doing stuff in the computer in my mind's eye. I got overwhelmed by the complexity of my programs of programs. I never got to a place worthy of submittal. Having done well on the tests, I received a B in the course. Having done a nice, clean, implementation of a blood-typing program, John received an A. The surprise was how motivating it was to program when you could actually feel the computer doing the work for you (mind the paper cuts). The lesson was iterate, iterate, iterate. I could have written a program of usefulness worthy of submittal and then added bells and whistles one by one (removing those that did not jive well with future editions). I am not talking software engineering here (though that is a pretty useful perspective as well). I am just talking a productive approach to rapid prototyping with extreme programming techniques (or, looking back, I can say that now).

Political boundaries in only two hundred lines of code

By the end of my high school senior year, I had learned to revision programming code much better than I could revision a term paper. Inefficiencies jumped out at me as I reviewed a print out of my code. I was well behind on my senior year science project (I had won an award in the state science fair with my junior year contribution). The only way to finish something respectable while dealing with Senioritis was to make it an self-assigned interesting programming assignment. Did I tell you I loved maps? Crazy about maps. Something about my mind's eye being able to experience a place (fictitiously, of course) from a map of it made maps the source of much pleasure (even more so now that travel is part of the experience). I decided to take the map of Connecticut and break city boundaries into line graphics that could be drawn on the Apple 2e (this is not a story of code reuse if it seems we're headed that way). That looked really nice.

In a questionable move, I decided to write an algorithm that would set political boundaries based on map characteristics (and a table of town populations). I didn't know about the famous map coloring problem (in fact, I didn't define anything as problems - just opportunities :). I did no research into potential political allocation algorithms. I just banged out an elegant algorithm (using my new found iteration skills) that was at the core of a map coloring program that showed newly developed political boundaries. I changed the number of electoral seats in the House of Representatives from four to five to six to (well, all the way up to fourteen) and let the algorithm determine which towns would be assigned to which districts. The maps were gorgeous. I tested the algorithm on the counties of New York state. They looked good too. I made a cool poster explaining my approach and displaying the maps. At the Connecticut State Science Fair, I won an advanced scientific calculator from a woman who had lost her husband and said he would have liked my exhibit. I was pleased with myself. Then, two of my so-called buddies pointed out to me how useful my algorithm would be for a bomb-dropping planning session (it was true that my algorithm also found the center of each district's population geographically so that a capitol could be built there). It bugged me for weeks that those boys were of almost pure German heritage and too enamored in the wars their ancestors had supposedly lost. The surprise from that project was the fact that so much could be done in so few lines of code. The lesson was that you might never anticipate the evil your invention could be ultimately used for.

Verifying loss tables for an international property and casualty insurer

I wish I could pretend to have participated in some really eye-opening programming assignments during my undergraduate experience. There were none. I had chosen to be a business major. Most assignments had to do with crunching numbers in formulas in a spreadsheet, balancing columns of numbers, playing out a case study in corporate america, or learning about the psychology of human beings and how they motivate each other or make decisions. There were no late night geek sessions or special keys to hidden caches of next generation computing machines. Basically, there is no Bill Gates story here. But, I became a well rounded human being. I learned about how the real world works. Yes, of course, it was a depressing time, but it was a back-drop from which the rest of my life could be judged (and thus, wildly exciting and productive). And, I did fun things with real people in the physical world. We should never underestimate the need for that to the human psyche, eh? Business assignments were straight-forward. There were no stories of going to the computer lab on Friday night to do an hour's worth of coding and waking up Sunday afternoon having missed the first game and in a deep sweat for not being able to find a coding mistake that was having mischievous consequences. The question of how to get back to the world of computers was an upcoming ten year story (of which you get a jist of it from the projects).

Anyway, I was out in that so-called real world, auditing the actions of so-called real people for the good of society who could be harmed by their misuse of fiduciary power. I was writing many formulae within Lotus 1-2-3 spreadsheets on very heavy portable computers. And, I was making a name for myself in the insurance industry. I had a knack for actuarial tables. I could almost say I liked them (well I did like them more than most auditing tasks). Then, I learned something that many people probably don't know. Auditors are not even allowed to write programs to verify people's analyses. We have to use algorithms that have been tied into programs that have been frozen - meaning that they aren't alterable. Every time I used a program to verify something in the financial statements, I had to check the size of the program in bits, date of the program to the second, and name of the program to the letter. And, since commercial insurance companies make so much of their profits based on state-approved actuarial loss tables, the program that calculated loss table ratios of experience versus charged premiums had to run on a special machine - one that could not be tampered with. There was no external drive. It was loaded with the program in Cleveland and sent to Boston for use. It was a Radio Shack Tandy machine that looked as much like a radio as a computer. Just one more box for me to lug around to the client (making those defiant days when you just have to take public transportation to be socially conscious a real challenge). With all that, I got reprimanded once for leaving the machine out of my sight in the home office (not the client, mind you), while I caught a quick lunch. Yeah, I was about to bring my radio computer to the Sbarro of the day. I was being brainwashed to hate computers. Perhaps I shouldn't have mentioned my interest in converting my career to become a process consultant so I could participating in programming some solutions. I hadn't considered the conspiracy angle before this exact moment (hence the benefit of writing one's story). Anyway, the surprise of this project was the treatment of the computers used as our allies. The lesson was the respect I got for potentially tampered code (it could get a multi-millionaire to invest in a stock she otherwise would not). OK. Fast forward to more optimistic times...

Airport runway control at a ficticious airport

After a series of programs that seemed no more advanced than what I had tinkered with in high school (but which taught me the Pascal programming language), I had finally found a program assignment that smelled like challenging new skills development. I was taking that most dangerous of dangerous classes, Data Structures; the course where hardcore computer scientists learn about the metrics of their craft (speed, size, and the trade-offs therein). That course is just too addictive while being strict in its vocabulary and approach. All too many computer science students come out of that course inside a new found, lead-walled, thinking box. That affectation was a big deal until recently when container objects started being thrown around as part of computing frameworks (and no longer need to be the all-intensive focus of data structure loving individuals). I was one of the addicts. Coding queues, stacks, sorts, and linked lists was just too euphoric for my own good. Connecting them to cute little, realtime visualizations made of x's, o's, and line segments made it more fun yet.

Luckily, some clown at Cornell had unleashed a wicked computer virus (the first successful worm) on to the national academic network and I was forced to deal with a whole heluva lot outside of the airport simulation task at hand. Like a wax-on, wax-off exercise of patience to teach me the insides of a Poisson distribution, I struggled against La Bomba - a cute little Macintosh graphic that filled the screen with a black, mostly circular bomb that grinningly identified, 'your core memory has been corrupted and the machine has froze solid as a result'. The virus didn't just infect core memory. It infected the floppy disks we saved our programs on. Any one of us on any of the two hundred Macintosh boxes could read off a diskette and drop the bomb on all other 199 users in a manner of minutes. And, should we get the whole campus allotment clean, some externally networked box could bring it back to us. How utterly frustrating for those of us who had no idea what was going on (those of us who actually worked alone on our programming assignments because we worked full-time during the day). I kept imaging what would happen if real air traffic software ran in a similarly networked manner, across the world. The project took three times as long to finish as it should have (and ten times as many floppy disks). For me, data structures was not the course experience other shiny new converts of later years had experienced (but, don't get me wrong, lectures were pure pleasure, the book was as useful as the Meaning of Life, and the tests were as fun to take as a jello swimming event. I had battled an unknown force which made precise, mathematically sound code of little value. My surprise was how ruthless a computer virus could be to a highly regarded computer lab. My lesson was to be on the look out for project issues that might not seem too important but could become number one, critical path legend.

A first database to manage credit card billing allocations

So, I couldn't get back to computer programming projects through the firm. I chose to go back to business school and take an advanced degree that got me programming intensively. Information science can be about the worth of information, the structuring of information to create knowledge, or the meta data description of information. Or, information science can be about discovering, processing, and disseminating information without necessarily knowing the meaning of what's being passed around. To get back on a computer science track, choose a program with a strong focus on the latter (while learning all you can about the rest of it). Most of the programming tasks in business graduate school are nicely academic, especially when you are working nearly full-time and can't dally with programming teams all day long. Since a project isn't quite the learning experience without other people to change your thinking, I choose a representative project from my work life at the time new ideas from grad school were filling my noggin.

Working for a credit card processing department within the second largest bank in a midwest state, I saw a lot of data as I contemplated information science. Monthly, I received a tape of transactions for every merchant or cardholder for eigthy-four banks who authorized each buying or selling involved in a Visa or Mastercard processed event. There are many possible problems that can come up with credit card transactions. You probably guessed that fraud was the biggest issue. Yes, in fact, Visa and Mastercard together wrote off $4 billion worth of fraud in 1988. That amount is allocated to the rate they charge for each transaction (something like .000000767 cents per transaction, if memory serves). Each of those eighty-four banks could choose to protect themselves against fraud via various services (a sophisticated market, for sure). The reporting organization that worked with Visa and Mastercard to record all those transactions was located in Columbus, GA (a nice place to go in January for a yearly meeting, I can vouch for). They did not want to figure out who to charge various expenses to. They just lumped those charges and I got to decide which bank should receive which allocation of these miscellaneous monthly charges. It was like no auditing task I ever was assigned. I got to be creative and yet try to be fair based on my sense of ethics (which had been challenged in a philosophy course more thoroughly than most undergraduates). I decided to automate this allocation process. First, I learned how to convert the reporting tape into a stream of text and floating point values (millions of them). Then, I learned how to write simple aggregation routines to get buckets of subtotals. Then, I wrote an allocation algorithm that used the subtotals to dictate percent of charge allocated. Then, being a good auditor, I created a second method for cross-checking my totals allocated. Lastly, the step I considered a growth step worthy of my business school prerequisites, I called the eighty-four banks and spoke with the person who has power over fraud protection decisions. I introduced myself and sent them my algorithm in a written format (via interbank mail). Then then called me to challenge my decisions (which did change over time as I learned more about bank behavior - the lesson is to charge those who can change bad behavior the most - not those who can't really change their behavior based on mitigating circumstances). The surprise the project offerred was the thrill of automating a tedious manual task. The lessons were many about human behavior and the ability of a computer program to outperform a human being in allocating large, tedious, series of numbers.

Job control and COBOL programs that pay field agents due commission

Moving on to another organization, I chose a program where you work five information science projects in five years and then decide whether you want to become a director and dive deeper into a specific business line. Perhaps you've met a few recent computer science graduates from prestigous programs in your lifetime. They tend to think they can do anything with a computer and have a hard time relating to people who don't feel the same way. So, this organization wisely put new recruits to work on very small teams who are dealing with very tedious and cumbersome problems. Although a step up from punch cards and machine assembly language, writing job control instructions to an enormous mainframe certainly felt just as archaic compared to today's computing environments. I did battle in the trenches with six other programmers who basically duct-taped pages and pages (screens and screens) of spaghetti code together to get field agents and remote office personnel their monthly commission checks accurately on time. The system was written twenty years earlier and tracked over four thousand individuals for sales volumes, profitability of policies, and policy cancellations. The more you sold, the more commission you made. The more profitable the sales, the higher the commission percentage. Yes, these software programs were from the days of massive COBOL language programs written when GO TO statements were still acceptable.

My favorite memory of that tour of duty was the fact that each program had a name such as the maintainer, the accumulator, the balancer, and the reporter. They ran in sequence overnight during a six hour period. We would run four practice runs to make sure our monthly programming changes worked before the official run would go and actually cut checks, print letters, address envelopes, and send the pieces down the line to an in-house post office. The software had many checks and balances in it. If any assertion was violated, the whole run would back out to go back to the start. If that checkpoint was near the end of the six hour run, the backout might add another two hours to the night. How bizarre that a series of computer programs could create such a family atmosphere of support and communication. One error would put us all back at square one. My one year-end run seemed to last twenty hours (each of us had to do an overnight actually watching the run interactively through screen print-outs that reported the status of tens of milestones within a run). The lesson I learned was how mission critical software required a more conservative approach (agents who got overpaid weren't very likely to return the overpay). The surprise was how personal and quirky the humans were when dealing with such a boring, calcuation-intense software environment. Some of my peers made fools of themselves with their high and mighty attitudes. Others surprised me with their passion for work and consideration of every person throughout the organization.

Cash value illustrations in a C sweatshop

Moving on to year two, I found myself parked on an all male development staff who were forging ahead with the C language and making colorful business charts for customers to consider when looking at various life insurance policy options. An insurance company can suggest that you let them manage all your free cash. In that case, they bundle investment with life insurance such that you are covered for risk of death while accumulating a cash balance on your policy. We wrote the calculation engines that crunched future value of premium accumulations and subtracted out monthly, quarterly, semi-annual, or yearly premium payments (your choice). Since every dot printed on a piece of paper was within our control (a liberating experience after character based systems), we challenged ourselves to print the best looking business charts (bar charts, line charts, pie charts) that would graphically depict the yearly numbers that were printed in multiple page tables. The guys were close knit and, well, guys. My mentor actually held a swearing session with me to make sure I could fit in with the team culture.

I had dabbled in C previous and had come to the conclusion that there was quite a bit of flexibility in C technique and formatting. And, so, I decided to take up conversations with other C coders throughout the organization who had a reputation of being very knowledgeable about computer science in general. I came back from my first consultation to find everyone else working head's down and my supervisor motioning me into his office. That's when I learned, through a red-faced tirade, that I had committed an act of treason (labelled insubordination, but obviously more serious than that) by speaking with the enemy. My supervisor had managed a Montana silo for six years prior to choosing a more commercial occupation. He had one of two keys that could have launched a missile aimed at the USSR. He did not take fraternizing lightly. I spoke calmly and clearly to let him know I was only trying to help by scouting intelligence that could make our work more productive (and my participation more knowledgeable). How was I to know that our team had been hand-picked by him to be fully self-reliant and capable of researching all needed data via internal methods (he had a nice budget for programming books). I felt like I had all my stripes ripped from my sleeve and was sent on latrine duty. Only after eight months of working quietly and diligently (and participating in sixty hour work weeks without comment) did I gain his respect back. He was able to give me a satisfactory job review and ship me onwards with a rating of C+ (before the days of C++ being popular). A C for a C rotation. My lesson was about learning to gauge group dynamics before acting. My surprise is how still to this day, I imagine what it would be like to be trained as a military specialist. The thought of it is quite terrifying and yet those with similar personalities to mine of years past were sent to battle enemies they knew very little about.

Evangelizing groupware in a company of 35,000

Just as I had submitted myself to considering the computer's sole real value as a computation machine, I was given the opportunity to drive improved computer-mediated communications across time and place for business groups attempting to improve their workflows and communication quality. Things got wonderfully messy as computational functions spread across minds and machines. I spent a year participating in insightful case studies of top-down versus group-driven decision-making. Visiting nurses who knew their clients well made huge jumps in life quality and efficiency by joining the electronic communications realm, downloading patient-support information from anywhere at any time, and uploading their mandatory reports from the luxury of their homes. Telecommunications engineers thrived in a group process that let them negotiate their work without top-down favoritism that was the rule of the day when 250 engineers could not be managed any other way - only those who had enjoyed unfair benefits in the past fought the system. And yet, other groups so used to top-down communication patterns could only use their new tools for gossip and chatter unbecoming of the investment made in technology by their employer. They key, I learned, for thriving in computer-mediated communication processes meant having a meaningful role, valuing connections with human beings versus machines, and taking a pride in the quality of your contribution to shared knowledge and improved group process. I could not judge others for their lack of these qualities, but I found it came easy to myself and so I became a little manic in contemplating the potential.

Shared underwriting infrastructure for regional commercial insurers

The rubber hit the road (literally in the amount of travel to establish trust with teammates) as I was given a year to build computer-mediated communications infrastruture for fifteen regional lead underwriters for sophisticated mid-size commercial risk insurance policies. These people are incredible communicators who spend their days madly coordinating activities among risk-assessment specialists, financiers, claims specialists, field agents, pricing and policy-production specialists, and, of course, existing and potential customers. They are used to connecting one-on-one with their peers in other regions by telephone, and meeting face-to-face a few times a year to discuss strategy and financial results. How could I convince them to become more transparent and documenting for the good of the order? The year was a fascinating journey to the four corners of the U.S., but how would a trained evangelist make in-roads with such a savvy group of communication veterans who enjoyed the responsibility that came with their hard-earned authority? I learned the most important lessons in the attempt. These things take time, but are enevitable as changes in communication patterns among the young move forward in time through their life stories. I learned to admire the current state of communication evolution and respect it for what it is while still seeing the better future that is to come. And, I learned some manners and business protocol in doing so. Thanks to all the regional underwriters for opening your world to me!

Task management for paper mid-size commercial policy producers

I guess I did alright. I was passed from one senior director to another. The next task: help organize six policy-production centers into a single group of responsible hard-working communicators. Two-hundred and fifty people deep in the trenches of providing the paper support required by law and common-sense good customer relations. What an accumulated case-history of legal requirements that one is! Anyway, there are good days and bad days in each office. Some days Richmond is sailing smoothly and Napierville is getting crushed. Others, Denver is living the good life, and Richmond is in crisis-management mode. Why not share the burden and reward one office for bailing another out when the opportunity arises - returning the favor when the favor avails itself? My job - provide the shared communications infrastructure so unbiased mediators in Hartford, CT could pass the work around between offices equitably. I built a task-management process to help each worker manage their workload while at the same time transparently sharing their current state behind the scenes to a benevolent management team looking out for them and the customer. Here comes Big Brother, right? Nope... they loved it and I loved them. A year-long lovefest and anthropological study of management theories. Richmond staffed by college graduates just out of school. Denver staffed by secondary-income earning spouses. Napierville, Rochester, Buffalo, and Dallas interesting mixes along that continuum of homemaker to careermaker. That one was the best win-win-win-win job of my career to date. And, boy did we have fun!

Web site for an early adopter technical recruiter

Life is a fascinating journey if you learn to listen, contemplate, and meditate closely. The Web phenomenon took off in 1994 for me. There was more to life than connecting people to build a better insurance industry. Where else might we be able to drive a superior computer-mediated communications process to improve quality of life? Nothing had had a more substantial impact on my quality of life than the opportunity to participate in work projects that introduced me to new people, new ideas, and new societal roles. So, why not help facilitate the process that connects motivated worker with need-identified employer? Basically, I built a humble Web site that demonstrated the underpinnings of what Monster.com has become so impressively twelve years later. It was so easy to do! The internet service providers of that era were trailblazers with bubbling passion for the changes possible in society through their efforts. An incredible heady time for meeting new people in discussions where ideas were emerging and reinforcing through empassioned discussions.

3-D virtual environments for the Web

Authoring and editing text-based Web pages got me this far, but the thought of a shared virtual reality burst out of flatland. Just my luck, a spot opened up on the Virtual Playground project with a very comunicative and organized project director. He and I signed up to help our Taiwanese client demonstrate the value of an affordable, on-board graphics co-processor through shared virtual worlds accessible via the Web. Paul introduced me to the fascinating potential of multicast communications between large research laboratories and I researched the more prevalent client-server protocols to reach out to small, home users. Our client gave us so much freedom to design as we wished that I lost my program manager after six months. He seemed so concerned and uncomfortable that our client could not agree on a specification - a by-product of his formal computer science education, no doubt. I took over as product manager just as Paul had put together a real great system architecture based on Java and Java 3D technologies. I worked with stylish traditional building architects and artists and prototyped all kinds of cool features within our Netgate Shopping Mall and Science City prototpyes. I delivered a keynote address in Taipei along with demonstration of how quickly Web networking protocols could be hooked into navigable 3-D cyberspace. We built a process by which anyone could load any VRML model from anywhere in the web into Science City. I investigated models from all over the world. I worked with a Chinese artist from Kaohsiung in southern Taiwan and we built a fun little scavenger hunt for 8 to 10 year-olds to play in while racing to fill their team home with a shopping list of items. An earthquake abruptly ended our twenty-two day experiment attended by kids all over Taiwan, fifteen at a time. We have very few technical difficulties but did drop a lot of multicast packets across the Pacific. The client-server model ruled the day but multicast seemed so much better.

I don't expect to ever feel better on a day-to-day basis than the two years the Virtual Playground project provided me with such a dreamscape skunkworks. I learned more about people, life, and technology in those two years than any academic experience could possibly have provided. I saw a possible future we are likely to all gravitate towards five to ten generations from now. It is a grand vision, but quite scary to people like me born and raised in the late 20th century. We aren't wired to thrive in virtual cyberspace yet and so we don't know where we are heading. The only thing I feel sure of is that we won't really recognize leading edge technology people two hundred years hence - not even sure we'll recognize the average Joe on the street. So many questions about utopia and idealism, pain and suffering, morality and mortality brought about by playing in a virtual world one designs from a platform one designs. Even more questions as people inhabit artificial avatars and you don't know the nodding skateboarding kid across from you is driving his experience from Malaysia. No wonder people get lost in these jobs - a very happy and engaged lost. I don't purport to even begin to suggest what it all means for us. I just can't imagine turning back. It's a waiting game, for sure.

Procedural worlds for learning to navigate in 3-D cyberspace

Handcrafting 3-D virtual worlds is lots of fun and uber-empowering. A little imagination and you are playing god to a timeless universe of your own making. A lot of imagination and you can't sleep at night. Then again, to do the kind of quality work worthy of getting paid, I leave the domain to the capable hands of the cadre of competent artists I have been meeting in my life. My strengths are more algorithmic and so I joined up with the Digitalspace guys to consider how we could proceduralize virtual world development. The result of our shared vision was a Java-enabled browser page from within groups of people could choose artwork and configure a virtual world using a series HTML forms and JavaScripted behaviors. We sold it to an insurance company that manages insurance policies for 2.5 million public school teachers. The hope was that teachers from around the world would meet in stylish virtual classrooms and discuss violence and bullying and escalating issues that came to light as a result of the Columbine tragedy.

It was great to merge my interest in futuristic virtual reality solutions with my belief in transitional paths. We demonstrated how shared 3-D virtual worlds of use could be evolved from the current Web. We made it usable by public school teachers who needed the opportunity to get a sense of the video game worlds their students were inhabitating and thriving in after hours (or during hours given a truency tendency brought on by old-school, sage-on-the-stage drivel). The teachers were intimidated and uncomfortable. It is good to know our public teachers are so gregarious and friendly in their preferred face-to-face communication styles. Video gamer teachers are hopefully just a few generations away and the idea will click. Always thankful for the optimistic dreamer in corporate America who risks there career to do something out of conscience than payback. Not that I invest much in the stock market, mind you. Might have a different opinion in that case. Anyway, not appropriate to out the company who provided us such a great ride (telecommuting friends between Australia, Amsterdam, Italy, Seattle, and the San Jose hills). More dreaming and implementation, but closer to mainstream society. Just not close enough yet.

A first book project on a 3-D graphics file format for the Web

I finally got it: The best learning experiences don't come from sitting idle in a classroom absorbing more content than your peers and regurgitating it on an exam. Sure, that exercises the brain cells a bit for short-term capacity, but it does little for long-term retension. I would have to say, the best learning experience comes from being on the hook to deliver a book to a demanding and eager audience on a topic you bearly understand in detail, but are motivated in concept. Out of the blue, a book publisher contacted me via e-mail to ask if I would be willing to co-author a book on an emerging graphical file format - the one I'd been using on the last two projects through an iterative hack-and-see process. I jumped at the chance and found myself working fourteen hour days that felt like three hour days. Four editors, a co-author, and a Web filled with fodder to consider in the book.

We sold 8,000 books within the U.S, had the book translated to a few other languages, sold the rights to the text to various software houses, and used the book to teach courses at the community college course evening program level. My interaction with people all over the world in public visual 3-D chat spaces provided context as can-you-help-me e-mail messages began to come in from every continent at every hour of the day. As my co-author had no time for being helpful on a one-on-one basis (he had earned his wings doing some very difficult technological implementations), I took on the task with gusto. Amazing how much goodwill a person can build up in a short time just by knowing a body of knowledge cold and enjoying the challenge of a is-it-possible-to-do-this threaded discussion. Seeing your name on the cover of a book in the Oxford University Bookstore front window is nothing compared to seeing the world map of everyone you have had a useful discussion with one-on-one. I am still scratching my head as to how all that came about. As they say, 'it could happen to you'.

A second book project on making HTML more dynamic

My publisher was very thankful that I was able to join a project so late in its schedule and deliver a quality product. Had I ever done that before? Hmmmmm. Don't think so. Anyway, perhaps goodwill always comes back at you if you stick to it. I was offered the opportunity to write a book on the emergent HTML 4.0 standard and was promised I would have a seasoned co-author (who had just moved to a small town in South Dakota and lots of time to write) in order to be first to market with a book on the empowering dynamic scripting capability called Dynamic HTML. Of course, Microsoft and Netscape were warring and the term Dynamic HTML had little clout as a trusted consensus specification. I was on Netscape's side in terms of hopes for creativity and yet on Microsoft's side for getting better user-feedback data incorporated in an HTML specification. I spent a very engaging day at Microsoft's author-preparation day for HTML 4 and met my competition in terms of getting first to market. Of course, our book would include fair mention of Netscape's implemented Dynamic scripting features without the HTML 4 blessing afforded Microsoft.

Cutting to the chase, I found out what first to market means. You sell a helluva lot of product, but you discover lots of mistakes soon after it hits the streets. Our mistakes were not typographical or programming mistakes as the four members of the editing team were super, but of the fluid specification type - Our examples, one by one, no longer worked in the browsers we were pitching as both Netscape and Microsoft changed their approach to Dynamic HTML. The book sold more than twice as many copy as the first (I had learned to take the variable contract with royalties this time around), was translated into fourteen languages, was sold to six software houses I know of, and had a retail tail of five years before it was sold for an overvalued twenty cents at tag sales. Oh, but I was so sure we'd get the gig for the second edition. I wanted to do it out of pride and a devotion to my 25,000 readers out there, but not for the struggle of having to review something I had already got everything I wanted out of it. The re-write never happened. The market for Dynamic HTML turned out to be oversaturated. Our book probably did the best of all of them financially. There is a lesson for Microsoft's traditional approach in general in there somewhere. And, yes, if you are envisioning the e-mail traffic on that one, you likely got it right - ouch for any author who doesn't enjoy reaching out to a planet's worth of tinkerers and wannabe developers (basically, people like myself in this case).

A platform for shared 3-D virtual environments

And then along came OWorld (will continue soon - only nine years behind present now)...

An attempt to share dynamic 3-D environments on the Web

Procedural plants in augmented reality

Applying a shared 3-D platform to ocean science content

Open source code for low-bandwidth groupware products delivered on the Web

Roll your own graphics engine for ocean science visualizations

An integration platform for earth science simulation modules

(more to come)