About me
I've been keeping an online journal since mid-2000 - long before they were called blogs. I've been through tons of technical problems, lived life in a cube for ages, worked in Banks, you name it, I've probably been exposed to it. Not that I'm special, we all have a Dilbert-side to our lives, it's just that I've been at it a very long time. Here's some basic stuff about my professional life, but you can see a lot more on my Home Page.
Basic Professional Background Stuff
I have been a professional programmer since the age of fourteen. At that time the Physics Department of Indiana University-Purdue University at Indianapolis, hired me to develop an assembly language program for their Nuclear Magnetic Resonance (NMR) research. After that, my programming jobs ranged from developing disk duplication software for the Radio Shack Color Computer, to scalable production schedule sheets written in Wang Wordprocessor scripting language, until I entered IUPUI in the Fall of 1979, and stopped programming for money and started doing it for grades. I transfered to Purdue at West Lafayette a year later because they had nicer computers and a better Electrical Engineering program.
When I graduated from Purdue University in 1988 with my Ph.D. in Electrical Engineering, I was the youngest Ph.D. graduate Purdue's School of Electrical Engineering had had. My thesis was on a new monolithic microwave source called a Contiguous Domain Oscillator, and included design, fabrication, and development of two-dimensional, transient, computer simulation programs for the new Gallium Arsenide (GaAs) device. While it might have taken me longer than I wanted it to, the thesis was very good work on the modeling of the physics of electron transport in GaAs in three-dimensions (two physical, and time).
I then went to Auburn University because of the work they were trying to establish themselves in the field of III-V and II-VI semiconductor research. The match seemed to be perfect - the Electrical Engineering Department and Physics Department were trying to develop cooperative projects, and I seemed like a natural link between the two fields because of my extensive work at Purdue in the fabrication and simulation of compound semiconductors.
After three years at Auburn, I had the feeling that I really wasn't fitting in. I had done some very good fundamental work in the field of stress in semiconductors, and development of ion-specific MOSFETs, but I didn't feel like writing papers as much as they wanted me to. The eventful day was after a particularly hard day, and a call came from Damon, the Best Man at my wedding, and my best friend of more than a decade.
The call quickly became about how hard our days were, and how, of course, we could do it better if we had their own company. "Yeah!" said Damon, "You bet!" I said. And before we could really think about it, we had agreed to quit their jobs and start a company based on telecommunications and computers. A few letters passed between us in the ensuing months, about what to do, etc. and within six months I was back in Indianapolis, and working for the start-up Port-to-Port Communications Corporation.
I was working my 12+ hours a day (5:10 am to 5:30-6:00 pm) when early in 1996 I decided that this wasn't all it was cracked up to be. Sure, I had been part of building Port-to-Port from nothing to over $1.2 million in 1995, but it was taking a toll on me that was not worth the compensation. I didn't like being the boss... worrying about payroll... hiring, firing, etc. So... I started looking for changes within Port-to-Port and seeking other alternatives. Port-to-Port didn't want to change, and that's what partnerships are all about - consensus, so I looked elsewhere.
I talked to Bret Young of the budding Architecture Group at First Chicago - NBD, and came up for an interview. For many months I worked as the NT person in the group. And then decided that I wanted to get back into management. Frankly, there just wasn't enough challenge to be found in the work I was assigned.
I lead Technical Architecture Group, and managed the reusable AKit - more than just a reuse library, AKit includes design philosophy, documentation standards, and applications.
The group flourished and did wonderful work. While at times it was hard, the work was wonderfully rewarding for me. But nothing good or bad lasts very long...
One day Marty Bronstein told me that he had to disband the group because the group held some of the best programming talent in the Capital Markets Systems staff, and while they would probably come to regret the decision in the future, there might not be a future if certain projects didn't get completed. And so the days of wine and roses came to an end.
I then filled in doing Year 2000 work until the BankOne merger finalized, at which time he was put into a rag-tag group of assorted talents and given the responsibilities of Research and Development for Commercial Banking. This was certainly up my alley from the work I did on Java/CORBA as part of my Technical Architecture Group Leadership, and the idea seemed good enough.
Unfortunately, the reality did not live up to the idea.
And so, after a time, I was approached by Joel Herm to help build a system for Commercial Card Services - OneCard. At the time, Commercial Card Services (CCS) in Commercial Banking was dealing with an unresponsive external vendor of their card maintenance application. The web version wasn't exceptional, and they were looking for an alternative. We provided them with one.
OneCard Started in early 1999 and by September of 1999 I had built over 250,000 lines of debugged Java code that was the majority of the back-end. I had also built the database, and worked with the Exodus folks to set up the production hardware and get the necessary leased lines working. I was just waiting for the final test data from Total Systems to finish off my part in the project.
And then it happened again...
The users decided that they didn't have enough money to continue this project, even though it was estimated that it would save them $10 million in less than 5 years, so they canceled it. And everyone had to move on.
After this, Joel and I tried to stay together and gravitated towards a project that Joel had been working on for almost a year - DealTracker. It is a web-based deal-tracking system that allows front-line people in many areas of Commercial Banking to track the deals they are working on, and by the tracking, get a better idea as to what they have done, and what they are doing.
Things were going well until the Summer of 2000 when once again, upper management decided that this was a system they could do without, and canceled it.
After a time, I was offered the choice of taking a package worth half a year's salary or getting another position in the Bank... needless to say, the package won.
I spent the first several months of 2001 looking for a really great position - something that reminded me of the best days at Port-to-Port and First Chicago. It was hard, as the job market had shrunk quite a bit, but I kept at it. Finally, in June, I met the folks at UBS O'Connor, and they seemed to be just what I was looking for - great people with interesting projects, but most of all, great people.
Bob spent the first several months of 2001 looking for a really great position - something that reminded him of the best days at Port-to-Port and First Chicago. It was hard, as the job market had shrunk quite a bit, but Bob kept at it. Finally, in June, Bob met the folks at UBS O'Connor, and they seemed to be just what he was looking for - great people with interesting projects, but most of all, great people.
Things at O'Connor started out great. I was working with a group of five really talented guys. Matt Parker and I were working on the client-side and Jeremy Mayes, Mike Elmore, Mike Osowski, and a part-time consultant were working on the server-side of a center-state risk platform called MarketMash. It was very exciting, and there was a lot of progress in a very short time making the Team feel that we were really part of something special. But nothing good or bad lasts forever, and the bubble burst and business had to let go all but Jeremy and me.
For the next several years Jeremy and I handled much of the back-end development for the single-manager funds in O'Connor. It was lean times, but it led to some of the most incredible work I have done. Analytics Engines, MarketData servers, ticker plants, all needed to be written for one reason or another. It still represents a fantastic portfolio for me, but things changed again and Jeremy left for another position and the fun went out of the position for me.
I then took a position at Chicago Trading Company in the new Risk Analytics Group. They were starting a new group to try and look at the global risk picture of the organization. Since my work at O'Connor was right along these lines, it made a lot of sense for everyone involved.
Rather than work on the engine that drove the numbers, as I had at O'Connor, I started work on the presentation system. This was a nice change, and the initial goals were to get the global risk numbers into a web system with a "Google Finance" style of presentation. With the nice web interface - including zoom, pan, and active refreshing of the data without refreshing the page. This lead to an AJAX/Tomcat system using the Google Visualization toolkit with a ton of JavaScript on the client side to manage the application.
This continued to the point that the application was really a suite of pages - each one a different view into the global risk picture. The data was constantly being collected, and a vast data warehouse was started. The majority of the displayed data was held in an H2 in-memory database approximately 100GB in size. The capabilities of this system are impressive and it's found many uses outside those initially planned.
Things were going well, but the fit wasn't exactly what I was looking for, and since my days at Port-to-Port I have believed the adage: Sometimes, good people don't fit., and deep-down, I knew I had to leave. Fortunately, another trading company in Chicago - also started by a group from the old O'Connor, PEAK6, was looking for good people, and I decided to head there.
Initially, I was to work on a risk system for the new next-generation trader tools that were being put together. The initial set of tools was built by David, my new manager at PEAK6, and a recent partner at the firm. But when I arrived, I found out that the project that needed my attention most was the feeds. In the previous two weeks, there had been outages on seven of the ten days. With my background in the feeds at O'Connor, they asked me to step in and see what I could do.
I starting working in the Messaging Team, and quickly realized that what was needed was not a simple updating of the existing code, but a complete re-write. The entire system needed to be re-imagined from a different perspective - one where multiple threads ran full-speed with lockless data structures, and the differences between the exchange feeds were handled in simple, modular codecs, and not in completely separate systems.
This work was a great success, but when it came time to integrate it with the existing systems, none were really ready to handle the feed. This was not completely unexpected, but it did lead to a very interesting turn of events. Rather than incorporate this new DataBus into an existing project, I would be tasked with another re-write - this being the pricing server that generated all the greeks and implied vols for the different systems in the firm. The thought was that as the primary client of the new feeds, this would be the code that could take greatest advantage of the new feed's potential.
It's interesting how history repeats itself, as I was working on a similar project back at O'Connor - MarketMash. But this time the goal here would be far greater than this previous effort. For this pricing server, the goal would be to integrate the ticker plants into the server - making it even lower latency, include a what if scenario capability, add in a demand-driven update scheme so the fastest clients got the latest data, and the slow clients didn't overload the system or compromise the data.
The new pricing server went to production with a record-low number of issues for an infrastructural component of it's size and scope. Things went very well for the deployment, but at the same time, several organizational changes were in the offing, some promises weren't kept, and PEAK6 and I agreed it was a good thing to part ways. As I always knew Some times good people don't fit.
While I was looking for a new position, I did quite a bit of Open Source work and placed it on GitHub. This has been a long-held goal of mine - to create some of the tools and libraries that I end up reinventing every time I go into a new position. I also was introduced to some guys at a very nice little startup, and I wanted to help them out with a little something that I'd done previously - again on GitHub.
In the end, however, it was full-time work that pulled me away and I was able to find a very interesting position outside Finance at Groupon. As one of the largest Ruby/Rails shops in the nation, it gave me a chance to learn a new language as well as tackle some very interesting problems. Currently, I'm working on an interesting matching problem with demand and merchants to make the sales team more efficient. I'm working with big data (Teradata) as well as Ruby (JRuby) and a lot of fun, interesting, smart guys. Great fun.