Seeping Matter

Unresumé

December 23rd, 2010 Leave a comment Go to comments

Matt Ryan’s Unresumé

Anyone who has reviewed applicants for a job knows how lame resumes are. I have one of course. Like any good resume, it is only one page long, very straightforward, touches only on the high-level points, and is pretty boring.

So I created this page: my unresume. If you want to know what my career is really about, read this. Unlike a normal resume, it starts at the beginning of my career, so if you want to hear about the most recent stuff you’ll have to read through the whole thing. Or scroll to the bottom, I guess, if you must.

Spillman Technologies – June 1995-April 1998
IBM – April 1998-April 2000
Novell – April 2000 – April 2001
Volera – April 2001 – November 2001
Enterasys Networks – January 2002 – April 2002
Novell – July 2002 – May 2008
Mozy – May 2008 – July 2009
Microsoft – July 2009-Present

Company: Spillman Technologies

Location: Logan, Utah

When: June 1995-April 1998

My first software engineering job, I designed and implemented features and enhancements for Spillman’s flagship law enforcement database software. I started at this job during the summer after my sophomore year in Utah State University’s CS program. During my interview, I challenged the hiring manager to just give me a chance to prove myself. To my surprise and delight, he took me up on that challenge. It was a great opportunity for me to learn about software engineering in the real world and helped reassure me that I really would enjoy doing this for a living.
Spillman’s primary application at that time was a law enforcement database application for UNIX terminals written in C. The back end was a modified version of the C-Tree database, which is an API-access database using .dat and .idx files, similar to BerkeleyDB. Not as easy to use as a SQL database but it was lightning fast. Their application included a multitude of screens for entering and looking up database records for law incidents, people with criminal records, jail management, fleet management, dispatch center management, and a bunch of other things. Spillman customers included a number of county sheriff offices and police departments across the United States; when I worked there, Spillman had about 400 customers.
Things I Did There:

I designed and implemented a number of features for their law enforcement database product. I really can’t remember most of them, but some of them included some administrative security and auditing features, implementation of scrolling and paging functionality for a transaction log viewer, and various fields for different screens in their application.
I implemented customized TCP/IP interfaces in C to connect Spillman customers with external law enforcement databases, like state or federal databases. These were usually one-off efforts because each organization would have a customized secure connection to attach to.
I led our annual pre-release porting effort in 1997, for which I wrote a bunch of tools to help port our code, developed on HP-UX, to AIX, Solaris, DEC, and SCO.

Things I Learned:

Discipline compensates for many other weaknesses. While there were a number of very solid and capable software engineers at Spillman Technologies, overall the team was not what I would consider one of the strongest I’ve been on. But Spillman was very excellent at settling on a simple, straightforward software development methodology and sticking to that methodology.
The bearing of bad news. At no other company in my career have I worked more closely with customers than I did at Spillman. It was common practice there to talk with them frequently on the phone to discuss and resolve bugs they had reported or to implement new features or custom work they had requested. In one particular case I worked very closely with a customer on a very difficult and hard-to-reproduce bug. As time passed it became clear that this customer was the only customer experiencing the issue in question. This was a very difficult situation to manage and I worried about breaking the news to the customer. My approach, which worked out well, was to express sympathy, seek to understand, and state with complete honesty our position in every interaction along the way. The potential for dischord and frustration was high on both sides, but ultimately I was able to not only manage the situation well but create a strong professional business relationship with this person.

What I Would Do Differently:*
Spillman Technologies’ flagship product had some great strengths. Being terminal-based software built atop UNIX, it was instantly multi-user capable and was easily distributed to multiple desktops within an organization’s network. And since the software was built atop a b-tree style database, it was lightning fast. Customers loved the speed of the product.
Not long after I left, a couple of key industry trends became much more mainstream. First, web-based applications and web services became much more performant and viable for business-critical applications. Second, Linux came to be considered a stable and powerful platform, a viable option for server infrastructure.
So the first thing I would have done differently would be to port Spillman’s software to Linux and offer full product support on that platform. Spillman customers are government customers, and they purchase their software based on the amount of budget they have approved for the purchase. In a typical customer engagement, a Spillman customer might have had $500,000 to spend, and they would spend around $200,000 or so of that total on hardware in order to get equipment that was supported by Spillman. What if Spillman supported Linux instead? Likely the customer would still spend $500,000, but instead most of that would go into Spillman’s pockets. I can only assume that partnership deals with HP, IBM, and Sun (now Oracle) continually prevent them from doing this. Oddly, however, it did not prevent them from supporting SCO when I worked there, which was a substantially inferior UNIX variant for the x86 platform.
The other thing I would have done differently would be to provide a robust web services layer atop their existing infrastructure. There’s certainly a number of ways to do this; since the codebase at the time I was there was all written in C, Apache modules may have been a viable approach to solving this problem. Not only would this have facilitated a move to native rich client desktop applications instead of terminal server interfaces (a problem they were attempting to address while I was there), it would also have opened up the possibility of third-party or custom integration with their database, which was the real value of their solution.

Why I Left:
I will forever be appreciative to Spillman Technologies. They took a chance on an unproven college undergraduate when they had many more experienced and qualified candidates to choose from. I learned a lot about software engineering from Spillman, but perhaps most importantly I learned that I really do enjoy software development and that I could make a living from it.
I think the reason I left was that I felt unappreciated. Despite being an undergrad, I learned fairly quickly and after about a year I knew I was one of their top performers. Yet I often felt that I wasn’t treated like a top performer and that Spillman was taking an unfair advantage from the fact that I had not graduated and had limited mobility.
When I graduated from college, due to the valuable experience I’d gained at Spillman while getting my degree, I had a variety of opportunities to choose from. When IBM made an offer, I felt the experience I could gain from IBM was too great to resist and so I decided to leave Spillman for IBM.

Company: IBM

Location: Boulder, CO

When: April 1998-April 2000

Everyone’s heard of IBM, the world’s largest computer company. I worked at IBM’s Boulder, Colorado campus, which is one of their smaller campuses, is about 200 acres and some 20-30 buildings. IBM is a really big company.
I worked as a software engineer for IBM’s Global Services division, which at that time was basically a consulting company with about 125000 employees (it is surely larger now). I worked for most of my time there on a product called RepliData, which was a near-real-time multisite DB2 database replication product.

Things I Did There:

The primary deliverable I had while at IBM was RepliData for AIX. When I was hired, RepliData existed as an OS/390 offering only, written in PL/1 code. My primary task for much of my tenure was to port RepliData to AIX in C++. I completed delivery of one side of the equation which would allow AIX to act as a replication target. This solution was written from scratch in C++ using MQ Series for network communications and DB2 as the data store. Some interesting aspects of this problem:
- Since AIX at that time did not support threads, I implemented a multiprocessing abstraction using processes, not threads, but which had an API similar to a threading API so that you could execute a function in a separate flow of execution, join the flow on termination, get exit status, etc.
- The entire application was responsive to graceful shutdown signals like SIGTERM. I created an application-wide signal handing component that others would register with, and when signals were captured it would propagate the signals to the interested components.
- I created my own logging stream class based on C++ ostreams which would format messages for logging with prepended date and time information, different logging levels, etc. By simply changing the assignment of a variable, you could send specially formatted messages to a log, or instead you could send them formatted normally to the console.
When I was hired, they did not have an AIX machine for me to use even though I’d been hired to port RepliData to AIX. So my first job was to figure out what requirements we had for an AIX system and then figure out how to acquire a machine that met our needs. Since I worked for IBM, you would think this would have been a) easy, and b) inexpensive, but it was neither. I eventually located a slightly used rack-mounted R50 that met our needs and obtained approval for the $40,000 purchase.
I managed the hardware inventory and purchases for our department for a year, which included understanding what our current hardware situation was, creating a plan within budget for replacing outdated hardware with current hardware that was sufficient for needs, and making that hardware available to the other employees once it arrived.

Things I Learned:

C++. I had a great opportunity at IBM to immerse myself in C++, taking classes, buying books, following and participating in comp.lang.c++.moderated, and just trying things out.
Working without deadlines is not as great as it sounds. When I started at IBM, I was told what to do (port RepliData to AIX/C++) but I wasn’t given a concrete timeline. I thought this would be a great, low-pressure opportunity, but I quickly learned that without a deadline it was hard to feel a sense of accomplishment. I learned to set my own goals and deadlines and work toward them in order to feel that sense of achievement again.
Kicking against the pricks just leaves you with bloody toes. It surprised me how difficult some things, like acquiring hardware, could be at IBM. One might initially think that, since IBM is so wealthy, and since IBM makes the hardware, obtaining it would be easy and relatively inexpensive. It was frustrating for me at first to find how difficult it was to get the equipment I needed to get my job done. It took some time for me to learn that companies have their reasons for doing things and that I can be most effective by working within the system instead of fighting it.

What I Would Do Differently:*
Why I Left:

Company: Novell

Location: Provo, UT

When: April 2000-April 2001