Paul Randal wrote a What three events brought you here article on his blog and asked some others in the SQL server community to do the same. I of course was not on that list. However, no one ever invited me to blog about anything before so why should I be shy now.

I have decided to not tell this story in terms of professional accomplishments. For me, my hobbies have always led my career.

Event 1: A trip to Borders

The year was 1999. At 18 years old I spent my last summer before college doing contract work at 590 Madison Avenue, a.k.a. The IBM building. Of course Lou Gerstner had already sold the IBM building. I had heard of this linux thing. Deciding that I needed something better than Windows 95 (read: wanting to be more 1337), I bought myself a linux book and Mandrake Linux. I only had a 14.4k modem at home, and had no way of downloading an ISO easily.

Try as I might I could not get linux working on that computer. That September I brought the machine to college and bough a NIC that proudly claimed to be linux compatible. Of course it required a special patched version of the tulip driver that I could not get compiled against the kernel. Someone told me about the even more awesome FreeBSD which actually worked with my NIC. Eventually, a version of the 2.4 kernel was released that supported my NIC out of the box.

Event 1 Epilogue

In college I learned a lot more about linux than I did in the month previous. All I really managed to learn in the few weeks on my own in my parents basement was how to use vi, and what sort of hardware tended to not be compatible with linux (modems, printers and damn near everything). However, had I not struggled those weeks on my own, I would have never sought acceptance with the other unix fans. That trip to borders changed the course of my time in college.

Event 2: Learning SQL from Stan in a bowling alley.

I would like to note that I never finished college. This part of the story takes place in the time period after I stopped going to school full time but while I was taking classes at what one would call a “junior college.”

So I am sitting one Saturday at my local bowling alley with and old Toshiba laptop. I believe it was a 133mhz pentium. This was probably 2002 so it was old at the time. At the time I knew half the employees and my brother was on a league there. So I spent Saturdays at the bowling alley, mostly because I could get free food.

I would hack at perl on the machine. It was running Wndows 95 with an ActiveState Perl install. I don’t think any of my perl programs ever did anything useful, b I had fun writing them. For whatever reason, the founder of this blog Stan, who worked the cash register at the time, decided to teach me SQL. It was relevant to whatever project I was working on at the time. I had recently finished a course in VB6 at this point in which a lesson at the end involved talking to an Access Database but no SQL was involved.

I ended up not using this knowledge until I began taking a SQL class that was taught with Microsoft Access. Because I had a basic understanding of SQL from Stan, and also had a clerical job at the time, I took to Access like a semi employed semi college dropout to free chicken fingers.

Event 2 Epilogue

Once again this was a catalyst event. Had I not learned SQL from Stan I might not have taken that MS Access course, and I might not have turned a clerical job into a development job.

Event 3: My first LIPHP meeting

March 2006 and I am back in a semi-employed state. This time by choice. I walked away from a unix administration position to take a programming contract and try to start a website. I didn’t take much of a paycut, and the next full time job I got was a big raise. However, this is not about my professional accomplishments.

So there I was programming on the side for money and the rest of the time for room, board, and potential millions. Unfortunately I was the only programmer in this boiler room startup. I had no one to talk about computers with. I was programming PHP at the time and became aware of a PHP user group in Suffolk county. So I traveled one Monday night from my bedroom/office in Manhattan to an office in Suffolk county less than a mile from the job I walked away from.

I don’t remember the topic, but it was a good time with good people. It was a great first experience at LIPHP a group that I eventually became the organizer of. I had been to one user group before, a LILUG meeting in 2001. However, it was not something I saw any value in at the time. I will note that I am an occasional LILUG attendee these days and the meetings in recent years have been very good.

Event 3 Epilogue

Its not easy to qualify the impact of LIPHP. It never got me a job. However, it has lead me to more user groups, more mailing lists, and some networking. I learned many things from the group. I learned about giving presentations, and running a user group.

I do not consider myself an expert on Microsoft SQL server. I prefer Postgresql. However, I am a fan of referential integrity and seek to enforce it at the database level, regardless of the engine. I like my databases to reject invalid data like DMV clerks rejecting incorrectly filled out forms.

When I work with Microsoft SQL server I struggle to enforce referential integrity in the same manner as I do with Postgres. Recently, I wanted to restrict the values that may be stored in a column in a table. A mapping table was not the answer in this case. I thought the answer was to user T-SQL RULES. I implemented a few and prepared to add them to my standard practices. However, about a week later I discovered this nugget on the MSDN:

CREATE RULE will be removed in a future version of Microsoft SQL Server. Avoid using CREATE RULE in new development work, and plan to modify applications that currently use it. We recommend that you use check constraints instead. Check constraints are created by using the CHECK keyword of CREATE TABLE or ALTER TABLE. For more information, see CHECK Constraints.

All of a sudden I needed to unlearn what I had learned. I do this on a regular basis. I consider myself quite stubborn. And I quite value this stubbornness. I will argue my position to the death if I believe it is right. I pride myself on caring about the things no one else cares about, and being able to explain why you should care, if necessary. However, I can be persuaded to change my mind. It’s not so much that I bend or break, it’s more like I recrystallize. Sometimes the transition is instantaneous. Sometime my faith in a concept is broken and I spend a while looking for a replacement. This transition was rather instantaneous as I was presented with a clear message: “What you are using is depreciated and doing it this other way will work better anyway.”

So what is the lesson here? The lesson is simple. Be unwavering in your beliefs, until you have a good reason to change them. Then be unwavering in the new beliefs until they are demonstratively proven inferior.