In 1987, at age eleven, I received a Commodore-64. It was at this moment that my love of computers started. As the computer did not come with much software, I spent the majority of my time typing in code from computer magazines. At first, I did not quite understand what each line of code did; I only had a general idea of what the code should do. This initially caused some frustration, as there would either be errors in my typing or in the printed code. In addition, I did not have any storage medium. If I were unable to complete a program by the end of the day, I would have to start over the next day. I had to learn quickly how the code was structured and how to optimize my programming. In my early coding attempts, I tried to work with a local users group. However, as most of the members were at least twenty to thirty years older than I was, they often ignored me and discounted my opinions. Undeterred, I had to solve my problems without outside help. In 1991, I attended Montgomery High School in Santa Rosa, CA, and took a few computer classes. In addition, I ran one of the computer labs. It was during my high school years that I got into telephony. A few of my classmates either ran a BBS (bulletin board system) or frequented them. On March 1, 1994, I started my own BBS: Company X. I ran Company X until April 1, 2000. During that time, I helped a number of users with their computer problems ranging from software crashes to slow dial-in speeds. I also made several modifications to the BBS source code (in C++) and configuration files. In addition, I created add-on software that extended the networking capability of the BBS software. The software originally allowed for a maximum of ten networks; however, my software erased this limit. It was with this software and my ability to configure properly the modems that my BBS was able to handle a huge chunk of the networking traffic in Northern California during that time.

In October of 1994, shortly after my high school graduation, I found temporary employment with SoftCell, Inc., a wireless billing company. At first, they were using QuickBASIC as the

programming language and Btrieve as the database engine. My job was to write data conversion software that would convert data from our customers’ proprietary formats to our format. In general, the customers would only give a data layout and a sample file with which to write the conversion. Sometimes, I would not even get the data layout. As most of our customers did not truly understand how their data was stored, I was usually on my own to understand their data. With this process came the inevitable challenge. In one example, each time I would do a data conversion run for one particular customer, it would outline problems with the way they were storing their data. I would have to change my software to handle these exceptions and start the data conversion over. With this customer, I started the process on a Wednesday morning and did not stop working until Friday morning. On January 1, 1995, SoftCell employed me full time. My official title was "Maintenance Programmer." I continued my data conversion software writing tasks. I also picked up maintenance of existing code as well as customer support calls. Anyone who has viewed a cell phone bill can appreciate the complexities with wireless rate plans. Some of the plans were so complex that even our customers (who originally set up the plans) could not understand. Therefore, I had to explain why all of the calls rated the way they did for a particular customer. This often involved doing the calculations by hand. Later in that year, we merged with BAJA Systems, Inc. BAJA Systems created software to collect call records off cellular switches and deliver the records to billing systems. My list of responsibilities expanded to include the bulk of data processing. Call Detail Records, or CDRs, generally had to be transferred from our customers’ sites to our site multiple times a day. The CDRs would be rated and split into files for the various roaming partners. The customers had to have the updated CDRs within a week, and the roaming partners had to have the files within thirty days. Not only was timeliness a big factor, but accuracy was equally important. Having to resend files with corrected rates was often a costly and time-consuming job.

SoftCell, now BAJA Systems, also printed and mailed invoices. Part of my job included designing the invoices, writing the software to produce the invoices, writing the sorting algorithms, and managing the printer queues. In 1999, a third party bought BAJA Systems. By this time, my coding expertise improved and my title changed to "Software Developer / System Analyst." Instead of simply modifying existing programs or writing new programs with close supervision, I had free reign to create software as I saw fit. This third party also owned a software development firm called Suntech and an ISP (internet service provider) named CruiseNet. In 2000, these companies merged and became United Support Systems (US²). It was also during this time that we started to convert our software from QuickBASIC to Visual Basic 6. Over the years, I would pick up other tasks, because I was curious how everything worked. Once I figured out how something worked, I kept at it. For example, I wanted to know how our NetWare servers worked. After reading up on them and working with our IT consultant, I was able to manage the servers on my own. Similarly, I educated myself with our database manager, Btrieve/Pervasive, and became the sole Database Administrator. I was single at the time and was happy to work from 8:00 AM until midnight every day. Eventually, in addition to my software development duties, I became the "Operations Lead." In that capacity, it was my responsibility to oversee the Operations department, which included the Information Technology department. It was the IT department’s responsibility to purchase and maintain equipment. We had a mix of equipment including Windows 98 and DOS workstations as well as Netware, NT, Solaris, and Linux servers.

The Operations department also included the Billing department, which handled all of the data processing. Our software and hardware would handle several million call records a month. In addition, data had to be processed within a 30-day window; otherwise, there would be severe financial

repercussions. To help the Billing department, I rewrote most of the call processing software so that at least ninety percent of the process was automated. Lastly, the Operations department included the Mail Services department. Mail Services handled printing of the invoices as well as sorting, folding, stuffing, and stamping. I wrote all of the invoice printing and sorting software for the Mail Services department. At US², the word "department" was probably a misnomer. The company never had more than thirty people at its largest; consequently, the departments only consisted of a few people. And as several people wore multiple "hats," I never directly managed more than five people at any one time.

As cellular companies gobbled each other up, the number of customers started to dwindle. In 2006, US² dropped down to five employees. Eventually, the company’s inflow could not support all five of us, so I opted for a new job. In September of 2006, I found employment as a Software Design Engineer II at GED Integrated Solutions. GED creates machines that build windows and doors. My job was to create Human-Machine Interfaces (HMI) for the Research and Development department. I used Visual Basic.NET and SQL server to create an HMI for a corner-cleaning machine. The machine was supposed to be based on an existing product. The idea was to make a better machine with more options; however, once I came onto the project, we decided to rewrite the HMI software from scratch. The resulting product was light years ahead of the prior product. A number of the modules designed for this project were modified and reused in subsequent projects.

My next project was an HMI for a new welding machine called "Speedloader." The project was based around an existing welder, but included an automated loading system. The project team earned the 2008 Crystal Achievement Award for "Most Innovative Machine". One of the innovations

was the ability for a user to enter a formula to calculate window frame dimensions. I wrote a .NET class that converted a human-entered formula into a format that the computer could understand that would actually calculate a value for the given equation.

Prior applications made limited use of storage for various parameters. Due to the sheer number of parameters and configurations, I had to create a database structure that could handle it. Instead of using a single table for parameters and values, I create several tables to record the various configuration permutations.

The welder has four heating plates that have independent temperature controls. The prior welder had a simple display that would show the current temperature of each plate. It would also change the color of the display to indicate if the plate was too hot or cold for welding. The problem was that it was nearly impossible to tell how the temperature fluctuated over time. I create a custom control that could draw a graph of the temperatures in real time. It was smart enough to scale the graph automatically based on the minimum and maximum historical values. Future projects included HMIs for saws and other welding machines. In addition, I maintained existing projects that were written in Visual Basic 6. Due to a struggling economy, GED dropped one third of their workforce in October. Unfortunately, this reduction included me. In August 2008, I started work with oDesk.com as an independent contractor. Essentially, I would bid and work on small programming jobs. My assignments ranged from a custom address-printing program for a dot matrix printer to a real-time stock analysis and trading application.

On January 5, 2009, I started work as a Developer / Analyst III (Sr. Developer) at Cuyahoga Community College (Tri-C) in the Distance Learning department. Since the department is lacking in several areas (code design, database design, documentation, project management, issue tracking, etc.),

it has been my job to "fix" these problem. This means that I have to document how the systems work currently, then I will have to create a more robust design and go from there. As I have been there only a short time, I do not yet have much work to show for it. However, I hope to completely change the department and plan to stay there for the next several years