Career 2: My very early jobs (v1.0)

 I just thought I should very briefly sketch out my very early jobs for completeness (late 70's and early 80's). Not really that interesting relative to the others. It is unlikely most would be interested in this, and it is somewhat technical, but it completes my career blogs and they together cover all periods. On the database system, I think some teammates even after 30+ years don't have closure. I hope this blog gives them closure. This blog is dedicated to them. 

After I graduated, my first job was to run programs to analyze health data for a research project at Kuakini hospital in Oahu. I used punched cards and I think tapes. Not very interesting but paid the bills!!

A friend helped me get a job at a service bureau in Oahu (Data Technical Analyst) that provided services to many banks in Honolulu. I helped them shift to a semi-smart terminal that supported forms data entry with their online system. Started on a reporting system but left without completing soon after a local businessman acquired the company. 

I had tried my best to hang on in paradise. It was too difficult with too few opportunities for interesting work. I moved to Silicon Valley and started at a big computer company. 

My first job at the company was to maintain and enhance a generic forms data entry app front end for semi-smart terminals. I then shifted to a relational database system being developed inhouse. My focus was access methods - especially B-tree indexes. There was one other engineer working on access methods. Sometime later, I became the manager of the internals of the database system but continued to code the access methods. 

I did not really have any hands-on database system experience (or studied it in college) and neither did most on the internals team. I also did not have any management experience but was game to try since I was asked. Made plenty of rookie management mistakes. We pretty much adopted many of the ideas at that time from the existing highly successful workhorse database system the company already had (example static backup, operational logging + page before images, predicate locking, and table/index size limited by the biggest file size the OS supported). We did not realize that the latest cutting edge had moved in a big way in these areas. Also, the 16bit addressing limit of the current computer forced us to code the internals in a way that made the code non portable. It was not surprising at all that when a new 32-bit cutting-edge machine (later it was extended to 64 bits) became the focus of the company, it was replaced. It was replaced by a database internals built by a startup staffed by system R veterans and implemented by highly skilled and talented database system veteran developers. It was far superior to the internals we were building. The company made the right call. I was not involved in assessing the inhouse database system externals, but it was replaced too. 

That experience pretty much convinced me to stay technical and remain an individual contributor for the rest of my career. My real strength was technical, not managerial. I did that except for a short stint managing a performance team of 3 people much later (not what I would call a real management job - more of a tech lead).