About

The author grew up in a small, rural community north of San Francisco. As a youngster, the author volunteered at the local public library. The library had received a grant to familiarize the community with telecommunications in the form of a FirstClass bulletin board system. The library had a few public access computers set up to use the local bulletin board system and a number of phone lines configured for dial-up access from more remote regions of the county. Community members telephoned and asked in-person questions about connectivity and conferencing software use. The author fielded these questions in-person and via telephone from the back offices of the local library. For many community members in a rural area, it was the first step to communicating with the world at large.

The volunteer position turned into a job with a local Internet Service Provider in their high school years. The Internet company provided opportunities to the author after the showing of an ability to take on additional tasks and responsibilities. The company gave the author root access to their servers, and also paid for the author’s relocation to manage a remote office’s technology, security, and data replication. It was during this time the owner who had coded the billing, payment, and marketing database provided their login credentials to the author. While the credentials were required for data replication purposes in primitive software, it showed an incredible amount of trust in a relatively young employee.

The author, after relocation and office configuration, began to play with UNIX systems (FreeBSD) on their own systems. They configured web services and ran interoffice communications software, in addition to starting a web-accessible build of the owner’s brainchild billing, payment and marketing database. The author ran the web services portion of the business including maintenance, software upgrades, and other infrastructure issues.

Then, disaster struck. The owner that had coded and managed the billing, payments, and marketing database passed away in his sleep one night. The small company of about fifteen employees was devastated. The loss, to this day, is still painful. The owner who had written the billing, payments, and marketing relational database entrusted an early twenties person with complete access to their system.

The death, as painful as it was, allowed the author a leadership opportunity within the company. As the author was the only person entrusted with login credentials to the software, nobody understood how the system worked. It was a relational database. While the data-entry persons understood what needed to happen, nobody understood the processes behind how it happened. The author self-tasked with the deconstruction, documentation, and further development the billing, payment, and marketing system.

The period following the owner’s death was spent in the office; departures occurred for bathing and sleep. All other time was spent in the office deconstructing the relational database, code that fetched between eight and ten million in gross revenue annually, written by the deceased. The ability to hyper-focus on code and relational databases was an asset to ensure billings and payments continued unabated.

Once the system was understood and somewhat documented, the author focused on code to delegate responsibilities to others in the office. The administration user interface was too complex and needed to be simplified for responsibility delegation purposes. After the responsibility delegation code was completed, the author entered into monthly business and strategy meetings with the other owner and investors.

Discussions with the investors routinely turned toward the currently instituted processes in conjunction with business and marketing strategies. The owner and investors made their desires clear; implementation was a different story. Ideas are simple, execution is complex. Relational databases are inherently difficult as single requests (queries) usually cannot produce all the necessary related information; easy-to-understand interfaces create layers of relational complexity. The user interface is the most important feature of a database; systems are useless without adequate user interfaces.

Investors asked questions about the issuance and redemption of coupons for customer retention. Technically, in relational database terms, those are two separate processes; the issuance of coupons, and the billing adjustments created by the application of coupons. The processes are largely unrelated in terms of technical data storage, but system’s interface required the processes appear to be related. These were issues that had to be devised, coded, and documented. The conception of coupons required the service of a program called concurrent versions system, a predecessor of git. CVS was used in an agile development process more than twenty years ago. The author has been at it a very long time.

In addition to the billing and payment system, marketing was incorporated. In those days, many companies used date of birth as a security question to verify identity when making changes to account information. While the birth information was originally obtained for security reasons, the author devised methods to incorporate the information into consumer and marketing profiles. It allowed questions about marketing and customer retention; “What is the average age of the person who heard about us by radio in the last ninety days?” “What demographics are more likely to require large-enough advanced notifications of upcoming billing cycles?” Later in the company’s life, before its eventual sale for its subscription user base, “What demographics are cancelling services to go with broadband access?” “If we issue coupons to those demographics, how long do they generally retain services before cancelling?” Those were questions about return on investment, customer acquisition and retention costs; adequate marketing, billing, and payment profiles on customers were required. These were questions that had complex data storage mechanisms to determine, as a person’s date of birth is in no way related (in a relational database context) to their service terminations or reactivations. Those questions are rudimentary with today’s data storage, but in those days the questions allowed incredibly targeted marketing campaigns.

After the company sold, the author began working with clients with developmental disabilities. The clients needed a facilitator to help them advocate for issues impacting themselves and others at the local and statewide levels. The author soon developed software for a non-profit organization after extensive discussions about requirements with diverse groups; people with disabilities, seniors, and low-income families. The software automatically imported California state legislation along with legislators’ proposed changes. (“Revisions”) The non-profit had requirements in maintenance of consumer notes, discussions, stories, legislative annotations and other information which required seamless integration with state legislative proposals and revisions. The software blended the non-profit’s requirements with the latest revisions of legislative proposals.

The work exposed the author to rules and regulations (e.g. permits, licensing boards, etc.) at the local, state and federal levels. It also provided first hand recognition of the dual federalism of California’s government and United States government. The global perspectives of each body, as a whole, and their relationships to the social contract.

While the author was working with non-profits and people with disabilities, they attended college. The author focused on sociology, economics, psychology and philosophy. The author was unsure of what to do with their life, and had done lots of coding, so computer science was also involved in the academics. The author was exposed to various disciplines, including applied behavior analysis, macro- and micro-level decision making processes, interpersonal and organizational dynamics. The author even started a doctoral thesis on empathy and self-interest after studying Adam Smith and John Locke. However, that was many years ago now…

In college, the author discovered they have autistic tendencies, and would have possibly been placed on the spectrum (ASD) were the American Psychiatric Association’s Diagnostic and Statistical Manual (DSM-5) around when they were a child. As collegiate colleagues asked the author about social media presence for help on exams and material understanding, the author said no social media accounts were maintained. The lack of social media accounts is/was a personal preference of the author, and no accounts exist on any of the majors: Facebook, Instagram, Twitter/X, MySpace, LinkedIn, or any others. Though the author does not maintain social media accounts, they have engaged openly and comfortably with diverse groups.

After college and working with non-profits, the author helped start a project to help farms, farmer’s markets, and restaurants more efficiently utilize resources. The software required input from farms about their produce, farmer’s markets about their vendors and events, and restaurants about their menus. The software determined which market events were most advantageous for farmers based on other vendors selling the same produce. The software helped markets diversify offerings by scheduling vendors with many different products, instead of many vendors with similar product. The software thirdly helped restaurants when market coordinators scheduled enough vendors with produce to fulfill bulk restaurant orders. This is a very simple representation of incredibly complex data relationships.

Since then, the author has spent a number of years working at a Fortune 50 company as a sales associate. The opportunity has afforded the author to learn various aspects of the consignment business, and insight into many processes and procedures. After Amazon, the author understood many retail businesses are actually the “freight” business. As a software developer, the author has had an abundance of thought experiments, including whole database diagrammed models to implement service-based solutions. The author has also submitted detailed diagrams to the internal software developer channel of the Fortune 50. While possibly coincidental, it appears portions of the diagrammed submission was used in an internally released product.